Avatar von /mecki78
  • /mecki78

mehr als 1000 Beiträge seit 03.07.2004

Ich denke, das hat etwas mit "App Thinning" zu tun

Apple hatte mal die Idee, dass auch wenn zwei iOS Geräte die gleiche App laden, diese ja nicht wirklich die gleiche App bekommen müssen. Theoretisch kann der App Store ja einem iPad eine andere App Version ausliefern als einem iPhone. Damit wollte man erreichen, dass ein Gerät nicht mehr Daten herunterladen muss, als absolut notwendig. Die Idee ist so alt, das Apple damals als Beispiel noch angeführt hat, z.B. braucht man einem Gerät ohne Retina Display keine Grafiken in Retina Auflösung ausliefern. Heute haben alle noch aktuellen iOS Geräte Retina, ergo hat sich das schon mal erledigt. Aber es kann ja wirklich sein, dass einen App manche Resourcen nur auf einem iPad braucht und mancher nur auf einem iPhone und vielleicht manche sogar nur auf einem iPhone X. Daher erlaubt es Apple, dass man Resourcen an bestimmte Bedingungen knüpft (z.B. "Diesen Shader brauche ich nur, wenn das Gerät mindestens OpenGL-ES x.y kann") und anhand dieser entscheidet der App Store wirklich erst im Moment des Ladens, was er dem Nutzer jetzt konkret ausliefert. Das ganze nennt sich "Slicing". Bei Apps, die das sehr intensiv nutzen, kann also der Speicherverbrauch für ein und die selbe App auf zwei unterschiedlichen Geräten stark unterschiedlich ausfallen. Eine solche App von einem Geräte kann auch nicht einfach so auf das andere Gerät übertragen werden, weil ihr dort ggf. notwendig Resourcen fehlen, wenn dieses Gerät nicht identische Hardware aufweist.

Dann hatte Apple noch eine weitere Idee, nämlich dynamische Resourcen. Statt sämtliche Datendateien direkt mit der App auszuliefern, kann man sie in so Art Pakete aufteilen, die man Apple zusammen mit der App übersendet. Lädt dann ein Nutzer die App herunter, bekommt er erst einmal nur die App selber. Resourcen Pakete, die als "Prefetch" markiert sind, werden danach automatisch im Hintergrund schon mal geladen, darauf muss man aber nicht warten (die App ist sofort startklar auch während das noch passiert; ggf. fehlen dann halt in der Anzeige noch irgendwo Bilder oder so). Alle anderen Resourcen Pakete werden erst dann geladen, wenn die App dem System sagt, dass es die auch braucht. Anders als beim Slicing bietet sich dieses Verfahren natürlich nur für optionale Resourcen an, als Resourcen ohne die man die App dennoch nutzen kann, denn sonst muss der Nutzer zwischendurch pausieren, bis die Resourcen nachgeladen worden sind und das soll natürlich nicht der Fall sein. Außerdem wirft das System diese Resourcen auch selbständig wieder weg, wenn man sie schon länger nicht mehr gebraucht hat und der Speicherplatz knapp wird, alleine deswegen müssen sie optional sein. Apple nennt das "On-Demand Resources". Diese werden aber nicht in der App selber gespeichert und werden somit auch nicht mitübertragen, wenn man die App überträgt, d.h. sie müssen sowieso am Zielsystem neu herunter geladen werden.

Und dann ist da noch Bitcode. Apps, die man zu Apple lädt, müssen aktuell immer in zwei Formaten vorliegen: ARM64 und Bitcode. ARM64 da alle aktuellen iOS Geräte eine 64-bittige ARM CPU verbaut haben, aber was ist Bitcode? Bitcode ist eine CPU neutrale Zwischensprache. Bitcode ist so aufgebaut, dass es sich nicht mehr in Quelltext zurückwandeln lässt (also zumindest nicht viel besser als das mit CPU Instruktionen möglich ist), man aber Bitcode selber leicht in Anweisungen für eine beliebige CPU übersetzen kann. Sprich: Aus Bitcode lässt sich ARM Code machen, aber auch x86 Code oder PPC Code. Dabei hat Apple nicht vor, Bitcode direkt jemals auszuliefern. Die Idee ist vielmehr: Was wenn Apple morgen das iPhone 9 vorstellt und, Achtung, das hat keine ARM CPU mehr? BOOM! Dann ist ARM Code dort nicht mehr lauffähig. Aber kein Problem wenn die App in Bitcode vorliegt, weil dann kann der App Store sie ja einfach für die neue CPU übersetzen. Ein bisschen wie Java mit AOT Compiler, nur dass das bauen nicht erst auf dem SmartPhone sondern schon auf dem Store Server passiert. Natürlich kann es dort auch passieren, dass man selbst wenn man die gleiche Version zweimal lädt, zweimal unterschiedlichen Code bekommt (z.B. weil Apple die AOT Compiler verbessert hat und der macht jetzt noch performanteren Code als bisher). Damit macht sich Apple komplett unabhängig von einer CPU Architektur, denn die meisten Apps liegen heute auch schon in Bitcode vor und sollte das iPhone 9 wirklich keine ARM CPU mehr haben, würden die wenigsten Nutzer irgend etwas davon bemerken. Aber waren schon sliced Apps nicht so ohne weiteres übertragbar, so wird das erst recht ein Problem, wenn der Store sogar die den CPU Code dynamisch und auf dein System optimiert erstellt.

Mehr Infos zu diesen Themen gibt es hier:
https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

Diese 3 Verfahren sind dummerweise nicht damit kompatibel, dass man eine App erst auf seinen Rechner lädt und dann auf ein Gerät spielt, weil der Store beim Laden nicht weiß auf welche Geräte die App nachher gespielt werden soll, bzw. man müsste iTunes alles das beibringen, was sonst die Store Server bei Apple machen. Stattdessen hat iTunes einfach immer eine App mit allen Resourcen geladen (das Slicing wurden einfach ignoriert), on-Demand Resources wurden von iTunes gar nicht geladen und beim Code bekam man halt einfach immer die vorgefertigte ARM Version, denn aktuell sind ja alle iPhones ARM (und alles ab 5s ist ARM64). D.h. aber auch, hat man diese Version dann auf sein iPhone gespielt, dann hatte man dort ggf. nicht das, was man bekommen hätte, hätte man sie direkt aus dem Store auf das iPhone geladen. Die aus dem Store kann z.B. deutlich kleiner gewesen sein und ggf. auch schneller, denn auch wenn Apple bereits vom Entwickler ARM Code bekommen hat, sofern sie auch Bitcode bekommen haben, können sie ja den in ARM Code übersetzen und diesen dann ausliefern, der aufgrund eines bessern Compilers (kann ja schon ewig her sein, dass der Entwickler den Code gebaut hat) eben deutlich besser ist, oder um mal was aktuelles einfließen zu lassen, sicherer ist (z.B. weil er jetzt gegen Spectre gesichert ist).

Apple baut das schon lange aus, es wird aber glaube ich nicht so stark genutzt wie Apple das gerne hätte, also machen sie dabei demnächst wahrscheinlich mehr Druck. Vielleicht plant Apple sogar schon an einem iPhone mit einer andersartigen CPU. Auf jeden Fall kann ich mir vorstellen, dass das iPhone Team hier vor einem Haufen Problemen stand und vom Produkt Manager wissen wollte, wie das denn künftig alles mit dem Store in iTunes zusammen arbeiten soll und angesichts der ganzen Arbeit und der ganzen möglichen Probleme und des daraus resultierenden Supports, hat dann irgend ein Manager entschieden: "Ganz einfach. Der Store fliegt! Problem gelöst."

Kenne ich.

A: "Aber... aber wenn wir das so machen, dann wird das ein riesiges Problem, wenn der Kunde zwei verschiedene Konfigurationen speichern will!"

B: "Wie viele Kunden wollen denn so was?"

A: "Boah... kein Ahnung... vielleicht 5% oder ein paar mehr?"

B: "Okay, dann geht das halt einfach nicht mehr. Man kann ab Version X nur noch eine speichern. Problem gelöst."

/Mecki

Bewerten
- +
Anzeige