Dabei bin ich auf einige interessante Ergebnisse gestossen, die ich in den letzten Posts zum Thema TableView erläutert habe. Da ich zunächst annahm, dass die vielen transparenten Labels in den TableView-Zellen für die schwache Performance verantwortlich waren nahm ich sie raus. Dummerweise mit keinem Ergebnis, die Performance war genauso schwach wie vorher. Als nächstes hatte ich versucht die Zellen zwischenzuspeichern, so wie es von Apple vorgesehen ist. Das hatte zwar eine bombastische Performance zur Folge, allerdings konnte ich die angezeigten Daten nicht mehr verändern, so dass der Stundenplan immer bei einem Tag hängen blieb. Ein kurzer, verzweifelter Abstecher ließ mich einen ScrollView erzeugen um die einzelnen Stunden dort drin anzuzeigen, aber das Ergebnis war nicht zufriedenstellend.
Deswegen hab ich mich gestern Abend nochmal hingesetzt und ca. 2 Stunden lang gedebugged und Sample-Code gelesen wie blöd, bis ich darauf gekommen bin mal die geladenen Daten für die Tagesansicht (Fach, Lehrer, Farbklecks, Uhrzeit, usw) rauszunehmen. Anschliessend habe ich Information für Information wieder hinzugefügt um zu sehen, was die Performance so in den Keller treibt. Ergebnis dieser Untersuchung ist, man kann es sich denken.... Weder das Datenmodell (der eigentliche Stundenplan), noch die ganzen transparenten Labels und Zugriffe darauf sind schuld, sondern das Erzeugen eines maskierten UIImage-Objekts mit einer bestimmten Farbe - der Farbklecks auf der rechten Seite...
- Ohne Farbklecks liegt der Speicherverbrauch des Programms beim Start bei ca 1MB und wächst während der Benutzung auf ungefähr 4 - 5MB an.
- Mit Farbklecks liegt der Speicherverbrauch am Anfang bei ca. 2,5MB und steigt solange an, bis das Programm förmlich platzt (bzw. vom System beendet wird).
Keine Kommentare:
Kommentar veröffentlichen