Anwendungsentwicklung für Symbian OS
Anwendungsentwicklung für Symbian OS
Anwendungsentwicklung für Symbian OS
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Lauferk Speicher Datenhaltung Speicherinhalt<br />
Z: ROM persistent Betriebssystemdaten, werkseitig<br />
installierte Anwendungen<br />
C: Flash-RAM persistent nachinstallierte Anwendungen,<br />
Anwendungs- und System-<br />
Dateien (.ini), Daten<br />
C: RAM flüchtig Ausführung der Anwendungen<br />
D:, E:, ... Memory-Cards persistent Anwendungen, Daten<br />
3.3 Speichermanagement<br />
Tabelle 2: Speicher<br />
Ein großer Unterschied zu anderen Betriebssystemen ist, dass Programme<br />
unter <strong>Symbian</strong> <strong>OS</strong> nicht zuerst ins RAM geladen müssen, um ausgeführt<br />
werden zu können. Sie werden direkt aus dem ROM gestartet. Im Vergleich<br />
zur Festplatte eines normalen PCs ist das ROM eines mobilen Geräts deutlich<br />
schneller und ermöglicht so das direkte Starten der Anwendung. Zur Laufzeit<br />
entstandene Daten werden in <strong>Symbian</strong> aber ebenfalls im RAM abgelegt.<br />
Ferner unterstützt <strong>Symbian</strong> ein Konzept, das es ermöglicht es den knappen<br />
Speicher eines Geräts optimal auszunutzen. Dabei werden Bibliotheken,<br />
die von mehreren Anwendungen benötigt werden, nur einmal in den Speicher<br />
geladen und von den Programmen gleichzeitig genutzt (Vergleiche [Symb<strong>OS</strong>,<br />
Seite 77]).<br />
Anders als bei Desktop-PCs gibt es bei <strong>Symbian</strong> keine Auslagerungsdatei.<br />
Wenn keine freien Speicherblöcke mehr vorhanden sind, tritt ein outof-memory-<br />
oder ein disk-full-Fehler auf. Da der verfügbare Speicher auf<br />
mobilen Geräten ohnehin sehr begrenzt ist, muß verstärkt auf solche Fehler<br />
geachtet werden. Zur Vermeidung vom Memory Leaks 15 stellt <strong>Symbian</strong> daher<br />
diverse Mechanismen zur Verfügung(siehe Abschnitt 4.3).<br />
Speicher, der bei der Objekterzeugung oder durch explizite Allokierung<br />
reserviert wird, wird vom zugeteilten Speicher (Heap) des jeweiligen Threads<br />
geholt. Falls im Heap nicht genug freie Speicherblöcke zur Verfügung stehen,<br />
versucht der Heap-Manager den Heap um weitere Blöcke zu vergößern. Jeder<br />
Thread hat zusätzlich einen 12 kByte großen Stack. Hier können entsprechend<br />
nur geringe Datenmengen (z.B. Variableninhalte von Grunddatentypen) abgelegt<br />
werden.<br />
15 Speicherlöcher - nicht freigegebener Speicher<br />
8
Change language