Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Warum iOS 9 weniger Speicherplatz benötigt - App Thinning und mehr

Mehr Leistung, weniger Speicherbedarf - das sind zwei Ziele, die sich Apple mit iOS 9 gesteckt hat. Schon bei der Aktualisierung auf iOS 9 wird dies erstmals deutlich, denn iOS 9 benötigt für das Update erheblich weniger freien Speicherplatz. Beim Update auf iOS 8 musste ein Gerät noch 4,6 GB freien Speicherplatz haben, was gerade bei Geräten mit nur 16 GB Kapazität ein Problem darstellte. Auch wenn die 4,6 GB anschließend wieder freigegeben wurden, so war das Update für einige Nutzer dennoch mit einer Löschaktion verbunden. iOS 9 hingegen begnügt sich beim Update mit gerade einmal 1,3 GB.

Doch auch beim permanent erforderlichen Speicherplatz wird sich etwas tun - sprich: Bei der Größe von Apps. Momentan bringt eine App sämtlichen Code und alle Grafiken damit, um auf jedem kompatiblem Gerät zu laufen. 32 Bit, 64 Bit, Grafiken für Retina und Nicht-Retina, unterschiedliche Ressourcen für iPhone und iPad, angepasste Grafiken für bestimmte Displaygrößen sowie Metal-Code, der auf einem iPhone 5 oder 5c gar nicht verwendet werden kann. Dies soll sich mit iOS 9 ändern.


Da eine App, die den genannten Ballast unnötigerweise mit sich herumschleppt, bis zu 50% mehr Speicherplatz belegt, ergibt sich enormes Einsparpotenzial. Apps unter iOS 9 erhalten hingegen nur noch jenes Gepäck, das sie auf dem jeweiligen Gerät auch benötigen. Entwickler markieren, welche Ressourcen für welches Gerät erforderlich sind - beim Download erhält jeder Nutzer dann die genau passende App-Ausstattung.


Als weiteren Ansatzpunkt sieht Apple die so genannten "On-Demand Resources". Die Idee dahinter ist recht einfach. Lädt man sich beispielsweise ein Spiel herunter, das über 20 Level verfügt, so benötigt man anfangs lediglich die Daten für die ersten Level. Erst wenn die höheren Level in Reichweite kommen, lädt das Spiel dann die zusätzlichen Inhalte von Apples Servern nach - und gibt stattdessen andere Inhalte aus früheren Leven wieder frei. Gerade bei stark grafiklastigen Titel kann dieses (optionale!) Vorgehen viel Speicherplatz sparen. Apple nennt als weiteres Beispiel auch Tutorials, die meist nur ein einziges Mal ausgeführt werden, später aber permanent Speicherplatz fressen.

Man darf gespannt sein, wie wirkungsvoll die Mechanismen in der Praxis dann wirklich sind. Wer sein iPad und iPhone mit nur 16 GB Speicher erwarb, wird auf jeden Fall erheblich weniger von Platznot betroffen sein. Doch auch auf Geräten mit 64 oder 128 GB und einer Vielzahl an installierten Apps sollten die Auswirkungen direkt ins Auge fallen und mehrere GB an Speicherplatz einsparen. Allerdings lehrt hier wohl die Erfahrung: Hat man mehr Speicherplatz, so wird dieser ebenso im Nu voll - und sei es, weil man nicht mehr aufräumt...

Weiterführende Links:

Kommentare

o.wunder
o.wunder10.06.15 09:25
Warum iOS 9 nun nur noch 1,3 GB für die Installation benötigt, ist damit nicht erklärt. Ist iOS 9 wirklich so viel geschrumpft, oder ist es eine andere Methode das iOS stückweise zu laden und zu installieren?

Ich empfand das freigeben von Speicher nie als Problem:
Einfach direkt auf dem iPhone zB die Musik löschen, dann war genug Platz vorhanden und beim nächsten Sync kam die Musi wieder automatisch drauf.
0
gritsch10.06.15 09:34
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.
0
MetallSnake
MetallSnake10.06.15 09:44
o.wunder
Warum iOS 9 nun nur noch 1,3 GB für die Installation benötigt, ist damit nicht erklärt. Ist iOS 9 wirklich so viel geschrumpft, oder ist es eine andere Methode das iOS stückweise zu laden und zu installieren?

Doch, das ist damit erklärt. Es werden nur noch die Grafikdateien etc. geladen die auf dem jeweiligen Gerät auch benötigt werden.
Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.
0
ExMacRabbitPro10.06.15 09:54
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.

Das wäre Rechenzeittechnisch aber eine ganz andere Hausnummer. Alles Images immer als PDF laden, parsen und rendern, das bringt ordentlich Last (=Stromverbrauch) auf die kleinen mobilen Geräte.
0
dan@mac
dan@mac10.06.15 09:58
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.
Genau das geht doch.
0
bmc desgin10.06.15 10:33
ExMacRabbitPro

Stimmt so nicht ganz, da ja lediglich die Vector geladen werden muss und dann als bezier Kurve gerendert werden kann, das nimmt weniger Speicher in Anspruch als Images und die lade Action kann vernachlässigt werden, da sind die Phones schnell genug für...


Ich mach das schon seit Jahren so - und alles läuft ohne Probleme...
Ask your questions...
0
BWeigelt10.06.15 10:38
IPhone 4S mit 8gb einfach mal per iTunes updaten? Hat bei meiner Mutter prima funktioniert!
0
ExMacRabbitPro10.06.15 10:52
bmc desgin
ExMacRabbitProStimmt so nicht ganz, da ja lediglich die Vector geladen werden muss und dann als bezier Kurve gerendert werden kann, das nimmt weniger Speicher in Anspruch als Images und die lade Action kann vernachlässigt werden, da sind die Phones schnell genug für...


Ich mach das schon seit Jahren so - und alles läuft ohne Probleme...

Die "Lade Action" ist auch nicht das Problem, sondern das Rendern. Mich würde mal interessieren wo(wie Du das bei Software Entwicklung unter iOS seit jaren machst. Mit Cocoa? UIImage unterstützt nämlich kein PDF Format.

Sobald die Grafiken größer und fotorealistisch werden und viele Farbgradiente dazu kommen (z.B. für Sprites und Hintergründe bei Spielen), geht die Rechnung nicht mehr auf. Da ist dann das Rendering mitunter sehr aufwändig. Kann man leicht sehen, wenn man mal so eine Grafik als PDF in iBooks öffnet.

Außerdem ist bei einfachen Grafiken der Gewinn zwischen einem Vektorformat und einem Komprimierten png oder jpg mitunter gar nicht vorhanden bzw. unerheblich. Da hilft der Ansatz den Apple nun fährt (einfach das nicht genutzt weg lassen) mehr.
0
Waldi
Waldi10.06.15 11:21
Mir wäre viel lieber, wenn man endlich den Bereich „Andere“ zumindest während einer iTunes-Synchronisation editieren könnte.

Seit 8.3 (oder war es auch das aktuelle iTunes?) hat sich zwar schon viel gebessert, aber da fehlt noch immer viel.
vanna laus amoris, pax drux bisgoris
0
o.wunder
o.wunder10.06.15 11:38
BWeigelt
IPhone 4S mit 8gb einfach mal per iTunes updaten? Hat bei meiner Mutter prima funktioniert!
Es geht darum das Update über WLAN durchführen zu können. Dafür wird mehr Platz benötigt, weil das iOS zunächst geladen und gespeichert werden muss und danach erst installiert werden kann. Dafür war bisher immer die ca doppelte Grösse des iOS als Speicher notwendig.
0
gritsch10.06.15 12:05
1. so oft werden die dinger nicht angezeigt,
2. kann man cachen
3. auch jpg/png müssen zuerst "geparsed" und dann gerendert werden!
ExMacRabbitPro
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.

Das wäre Rechenzeittechnisch aber eine ganz andere Hausnummer. Alles Images immer als PDF laden, parsen und rendern, das bringt ordentlich Last (=Stromverbrauch) auf die kleinen mobilen Geräte.
0
gritsch10.06.15 12:06
nein eben nicht. du kannst zwar in Xcode ein PDF verwenden, beim build process werden dann aber die ganzen @1x, @2x, @3x etc pngs generiert.
dan@mac
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.
Genau das geht doch.
0
sierkb10.06.15 12:29
ExMacRabbitPro
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.

Das wäre Rechenzeittechnisch aber eine ganz andere Hausnummer. Alles Images immer als PDF laden, parsen und rendern, das bringt ordentlich Last (=Stromverbrauch) auf die kleinen mobilen Geräte.

SVG! Wie dafür geschaffen!
0
ExMacRabbitPro10.06.15 13:55
Ein jpg/png zu entpacken sind vorwiegend einfache Byte-copy bzw. Memory-fill Operationen. Aus einer Beschreibung grafischer Primitive ein Bild zu rendern, ist eine andere Hausnummer.

"1. so oft werden die dinger nicht angezeigt" - Wie? Andauernd werden Grafiken angezeigt. Bei jedem Screenwechsel. Caching kosten wertvollen Speicherplatz. Insbesondere auf Mobilen Geräten.

Und, wie gesagt, für viele kleine Grafiken bringt ein Vectorformat keine Speicherplatzvorteile.
gritsch
1. so oft werden die dinger nicht angezeigt,
2. kann man cachen
3. auch jpg/png müssen zuerst "geparsed" und dann gerendert werden!
ExMacRabbitPro
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.

Das wäre Rechenzeittechnisch aber eine ganz andere Hausnummer. Alles Images immer als PDF laden, parsen und rendern, das bringt ordentlich Last (=Stromverbrauch) auf die kleinen mobilen Geräte.
0
ExMacRabbitPro10.06.15 13:56
sierkb
ExMacRabbitPro
gritsch
würden sie endlich mal vektorgrafiken (zb pdf) über UIImage und für icons/assets unterstützen würde sich noch vieles einsparen lassen.

Das wäre Rechenzeittechnisch aber eine ganz andere Hausnummer. Alles Images immer als PDF laden, parsen und rendern, das bringt ordentlich Last (=Stromverbrauch) auf die kleinen mobilen Geräte.

SVG! Wie dafür geschaffen!

Ein Vektorformat duch ein anderes zu ersetzen bringt zuerst mal gar nix.
0
sierkb10.06.15 15:59
ExMacRabbitPro
Ein Vektorformat duch ein anderes zu ersetzen bringt zuerst mal gar nix.

Ihr habt von PDF geredet. PDF ist erstmal ein riesengroßer Container. Der u.a. auch Vektorformat ermöglicht bzw. beinhaltet als Inhalt. Und drumherum ist Overhead inkl. Metadaten, den es nicht braucht. Reduzierung auf das Eigentliche, auf das Notwendigste, nämlich die reinen Grafikinformationen als Inhalt und Verpackung. Ohne Overhead, ohne Container drumherum. Deshalb SVG als Vektorformat. Da es zudem ein reines Text-Format ist, lässt es sich zudem noch viel effektiver komprimieren als ein binäres Format – auch bei der bzw. für die Übertragung im Netz.
0
MetallSnake
MetallSnake10.06.15 16:09
gritsch
2. kann man cachen

also als jpg/png Datei oder wie?
Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.
0
kennytb
kennytb10.06.15 16:43
@sierkb

oh ja das wünsche ich mir auch nur allzu gerne. Immer die blöden unzähligen Grafiken in unterschiedlichen Größen (kotz) und am besten gleichzeitig noch für Android mit (Doppel kotz)!!!!!!!!!!!! Also für manche Apps wäre das echt klasse…
0
ExMacRabbitPro10.06.15 17:07
sierkb
ExMacRabbitPro
Ein Vektorformat duch ein anderes zu ersetzen bringt zuerst mal gar nix.

Ihr habt von PDF geredet. PDF ist erstmal ein riesengroßer Container. Der u.a. auch Vektorformat ermöglicht bzw. beinhaltet als Inhalt. Und drumherum ist Overhead inkl. Metadaten, den es nicht braucht. Reduzierung auf das Eigentliche, auf das Notwendigste, nämlich die reinen Grafikinformationen als Inhalt und Verpackung. Ohne Overhead, ohne Container drumherum. Deshalb SVG als Vektorformat. Da es zudem ein reines Text-Format ist, lässt es sich zudem noch viel effektiver komprimieren als ein binäres Format – auch bei der bzw. für die Übertragung im Netz.

Informationen als Text kann man effektiver Komprimieren als im Binär Daten format? Wer hat Dir denn das erzählt?
Der Eindruck entsteht, weil Daten als Text gegebüber Binär extrem aufgebläht sind und die gleiche Information als Text wesentlich mehr Speicherplatz benötigt als die Binäre Darstellung.

Beispiel:

Als Binär ist die Zahl 2147483647 4 Byte groß. Den UTF8-String "2147483647" kannst Du gerne mal versuchen in 4 Byte zu komprimieren.

Und was die Übertragung im Netz angeht, so sind Formate wie XML, HTML oder JSON allesamt eigentlich sehr sehr teuer in der Übertragung und Verarbeitung. Das ist nur möglich, weil heutzutage so hohe Rechenleistungen und Übertragungsbandbreiten zur Verfügung stehen.
In der Kindertagen der EDV als 16KB viel Hauptspeicher, eine CPU mit 1MHz schnell und Datenmessages von 500 Byte länge groß waren, da wurde versucht möglichst nix als Text zu übertragen. Alles als Binary.
0
Stefab
Stefab10.06.15 17:10
Man könnte die Grafiken auch optional als Vektorgrafiken mit der App anbieten & wenn PNG da effizienter funktioniert, einfach bei Installation die SVGs einmalig als PNG in der korrekten Auflösung für das Gerät rendern & dauerhaft speichern fertig.

Und wie? Bei Xcode kann man auch Vektor-PDFs als Icons & andere Grafiken nehmen, die dann von Xcode automatisch in PNG gewandelt werden?
Auch in allen Größen? Das wäre schon mal eine ziemliche Arbeitserleichterung bei der Entwicklung, sofern Vektorgrafiken für die jeweilige App passen.

Auch verstehe ich nicht, warum man (wenn es passt), nicht einfach immer nur die größte von den Grafiken (glaube aktuell 3x?) in Xcode einfügt & die kleineren automatisch erstellen lassen kann.

Bei SpriteBuilder geht das zB, zumindest nach dem, was ich gelesen habe. Probiert habe ich es noch nicht.
0
gritsch10.06.15 18:23
sorry, aber ein jpg/png anzeigen ist schon mehr arbeit als die daten einfach in den speicher zu kopieren. die daten müssen entpackt (dekomprimiert) werden denn das macht nicht die GPU.
0
ExMacRabbitPro10.06.15 20:33
gritsch
sorry, aber ein jpg/png anzeigen ist schon mehr arbeit als die daten einfach in den speicher zu kopieren. die daten müssen entpackt (dekomprimiert) werden denn das macht nicht die GPU.

Spaßvogel! Und was bedeutet "dekomprimieren"?
Durch ausführen eines Algorithmus (z.B. RunLength Encoding oder Huffmann) werden aufgrund gepackter Daten die Ursprünglichen Daten wieder hergestellt. D.h. im Falle von einem Bitmap wird ein Speicherbereich mit Zahlenwerten (RGB bzw. RGBA) gefüllt, welcher dann das ursprüngliche Bild darstellt (Byte Copy bzw. Memory Fill).
Dabei ging natürlich niemand davon aus, dass die Daten der jpg/png Datei vom Filesystem einfach in den Speicher kopiert werden und fertig. Das wäre wirklich naiv.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.