SDK (Software Development Kit)

Beispiele:

• JDK (Java Development Kit): Brauchst du, um Java zu kompilieren. (Die JRE reicht nur zum Ausführen).
• Android SDK: Enthält adb (Android Debug Bridge), Emulator, Gradle Plugins.
• AWS SDK: Damit dein Python-Code mit Amazon S3 reden kann (boto3).

1. SDK vs. API

Oft verwechselt.

• API: Die Schnittstelle ("Hier ist die URL google.com/maps, schick mir JSON").
• SDK: Der Code, der die API für dich aufruft. (googleMaps.getRoute()). Das SDK ist oft ein "Wrapper" um die API, damit du nicht rohe HTTP-Requests schreiben musst.

2. Versionierung (Target SDK)

Bei Android extrem wichtig. minSdkVersion: "Läuft ab Android 5." targetSdkVersion: "Ich habe es für Android 14 optimiert." Wenn du das Target SDK erhöhst, aktiviert Android neue Sicherheitsregeln ("Du darfst nicht mehr einfach so auf Dateien zugreifen"). Lässt du es alt, läuft die App im "Kompatiblitätsmodus".

3. Fat SDKs (Bloat)

Viele Werbe-Netzwerke (AdMob, Facebook) zwingen dich, ihr SDK einzubauen. Jedes SDK macht deine App größer (Meganytes) und langsamer (Startzeit). Zu viele SDKs ("SDK Fatigue") sind der Hauptgrund für langsame Mobile Apps.

1. Statische vs. Dynamische Bindung

Wenn ein SDK Code zur Verfügung stellt, muss dieser in dein Programm kommen:

• Static Linking: Der Code des SDKs wird beim Kompilieren fest in deine .exe oder .app kopiert. Vorteil: Keine Abhängigkeiten. Nachteil: Riesige Dateien und Sicherheitslücken im SDK können nur durch ein Re-Kompilieren der gesamten App gefixt werden.
• Dynamic Linking: Das SDK liegt als .dll (Windows) oder .so (Linux) separat vor. Deine App ruft sie erst zur Laufzeit auf. Vorteil: Kleinere Apps und Updates des SDKs (z.B. Security Patches) wirken sofort auf alle Apps, ohne dass diese neu gebaut werden müssen.

2. ABI Compatibility (Die Binär-Ebene)

Ein SDK-Entwickler muss nicht nur die API (Quellcode) stabil halten, sondern oft auch das ABI (Application Binary Interface). Wenn ich eine Funktion im SDK ändere (z.B. einen Parameter hinzufüge), bricht die Binärkompatibilität. Apps, die gegen die alte Version kompiliert wurden, stürzen ab, weil sie an die falsche Speicheradresse springen. Professionelle SDKs nutzen Techniken wie das PIMPL-Pattern (Pointer to Implementation) in C++, um interne Datenstrukturen zu ändern, ohne die äußere "Hülle", die die App sieht, zu verändern.

3. Tree Shaking & Dead Code Elimination

Moderne Web-SDKs (wie Firebase oder Stripe JS) sind modular aufgebaut. Wenn ein SDK 2 MB groß ist, aber du nur die "Zahlungs-Funktion" nutzt, wäre es fatal, den Rest an den User auszuliefern. Gute SDKs unterstützen Tree Shaking: Das Build-Tool (Webpack, Vite) erkennt, welche Funktionen eines SDKs nie aufgerufen werden, und wirft sie beim finalen Packen einfach raus. Ein SDK muss dazu in ES-Modules (import/export) geschrieben sein, da bei altem CommonJS (require) diese statische Analyse kaum möglich ist.