Speicher-Management in iOS
Die App-Entwicklung für iOS mit Objective-C unterscheidet sich gründlich von dem, was der Entwickler aus Mac OS X gewohnt ist. Die Speicherverwaltung erfolgt hier manuell und erfordert daher besondere Aufmerksamkeit.
- Thomas Reppa
Die App-Entwicklung für Apples iOS-Betriebssystem setzt in aller Regel auf Objective-C als Programmiersprache auf. Deren Einsatz unterscheidet sich jedoch gründlich von dem, was der Entwickler aus Mac OS X gewohnt ist. Die Speicherverwaltung erfolgt hier manuell und erfordert daher besondere Aufmerksamkeit.
Unter Entwicklern gewinnt Objective-C immer weiter an Popularität, was nicht zuletzt iOS geschuldet ist. Denn Apple verkauft über den App Store wesentlich mehr kostenpflichtige Apps, als Google über den Android Market – obwohl die Anzahl der Android-Geräte die der Apple-Konkurrenz bei weitem übersteigt.
Hinweis: Auf Anregung unserer Leser aktualisierte Version des Artikels, Stand: 25. April 2012. (Red.)
Einen Einstieg in die iOS-Entwicklung zu finden, ist häufig eine größere Herausforderung als mit anderen Technologien. Das liegt neben der etwas ungewöhnlichen, an Smalltalk angelehnten Syntax von Objective-C vor allem an einer fehlenden Garbage Collection innerhalb von iOS. Die Sprache setzt im Gegensatz zu Objective-C 2.0 für Mac OS X auf ein manuelles Speichermanagement, bei dem sich der Entwickler selbst um den Lebenszyklus seiner Objekte kümmern muss.
Mobilgeräte ticken anders
Der Grund dafür liegt in der begrenzten Verfügbarkeit von RAM (Random Access Memory), das jeder iOS-Anwendung nach dem Start zur Verfügung steht. Dieser verfügbare Speicherplatz nennt sich Heap, seine Belegung erfolgt durch die Erstellung von Objekten während der Laufzeit der Anwendung. Benötigt das Programm ein Objekt nicht mehr, kann es aus dem Heap gelöscht werden, um Speicher freizugeben. So lässt sich sicherstellen, dass der Heap nicht irgendwann "überläuft" und die Anwendung in dem Fall nicht mehr dazu in der Lage ist, weitere Objekte zu erstellen.
Dabei kann es zu zweierlei Problemen kommen. Zum einen besteht die Gefahr, dass ein Objekt aus dem Speicher entfernt wird, obwohl noch andere Objekte darauf angewiesen sind. Das hat in der Regel einen Absturz der Anwendung zur Folge, da dadurch Nachrichten an ein nicht mehr existierendes Objekt beziehungsweise dessen unbelegte Speicheradresse geschickt werden (englisch: premature deallocation).
Der zweite Fall tritt ein, wenn ein Objekt von seinen Besitzern zwar nicht mehr benötigt oder referenziert, es aber dennoch nie gelöscht wird. Das Ergebnis ist ein sich zunehmend füllender Heap, bis irgendwann kein freier Speicher mehr zur Verfügung steht (memory leak).
Um innerhalb einer iOS-Anwendung Heap-Speicher für ein Objekt zu bekommen, muss das Programm die Nachricht alloc an das entsprechende Objekt senden. Das entfernt die korrekte Anzahl an Bytes aus dem Heap und gibt die Speicheradresse an den Pointer innerhalb des aufrufenden Objekts zurück (Abbildung 1).
Um nicht mehr benötigte Objekte aus dem Heap zu entfernen und so Speicherressourcen freizumachen, implementiert jedes Objekt die Methode dealloc. Im Gegensatz zu alloc darf dealloc nie direkt von außen aufgerufen werden, sondern immer nur vom Objekt selbst. Sonst besteht die Gefahr, dass Pointer anderer Besitzer-Objekte auf eine nicht mehr verfügbare Speicheradresse verweisen und die Applikation abstürzt.
Damit stellt sich die Frage, wie ein Objekt wissen kann, wann es sich selbst löschen darf beziehungsweise wie viele Besitzer noch auf seine Existenz angewiesen sind?
