Leistungsoptimierung für die ADOBE FLASH-PLATTFORM

LEISTUNGSOPTIMIERUNG FÜR DIE FLASH-PLATTFORM
Einführung
Die erste Phase enthält zwei Teile (Ereignisse und das enterFrame-Ereignis), die beide potenziell dazu führen, dass
Ihr Code aufgerufen wird. Im ersten Teil dieser ersten Phase werden Laufzeitereignisse empfangen und abgesetzt.
Diese Ereignisse können den Abschluss oder den Fortschritt von asynchronen Vorgängen darstellen, zum Beispiel als
Antwort auf das Laden von Daten über ein Netzwerk. Sie beinhalten auch Ereignisse aus Benutzereingaben. Wenn
Ereignisse abgesetzt werden, führt die Laufzeitumgebung Ihren Code in Listenern aus, die Sie registriert haben. Wenn
kein Ereignis auftritt, wartet die Laufzeitumgebung auf den Abschluss dieser Ausführungsphase, ohne Aktionen
auszuführen. Die Laufzeit setzt die Bildrate auch bei fehlender Aktivität niemals herauf. Wenn während anderer Teile
des Ausführungszyklus Ereignisse auftreten, stellt die Laufzeitumgebung diese Ereignisse in eine Warteschlange und
setzt sie im nächsten Bild ab.
Der zweite Teil der ersten Phase ist das enterFrame-Ereignis. Dieses Ereignis unterscheidet sich von den anderen, da
es immer einmal pro Bild abgesetzt wird.
Nachdem alle Ereignisse abgesetzt wurden, beginnt die Renderingphase der Bildschleife. Zu diesem Zeitpunkt
berechnet die Laufzeitumgebung den Status aller sichtbaren Elemente auf dem Bildschirm und zeichnet sie auf dem
Bildschirm. Dann wiederholt sich der Prozess, wie ein Läufer seine Stadionrunden auf der Rennbahn zieht.
Hinweis: Bei Ereignissen, die eine updateAfterEvent-Eigenschaft enthalten, kann das Rendern sofort erzwungen
werden, ohne dass auf die Renderphase gewartet werden muss. Verzichten Sie jedoch auf updateAfterEvent, wenn es
häufig zu Leistungsproblemen führt.
Stellen Sie sich am besten vor, dass die beiden Phasen in der Bildschleife gleich lange dauern. In diesem Fall werden in
einer Hälfte jeder Bildschleife Ereignisprozeduren und Anwendungscode ausgeführt, während in der anderen Hälfte
das Rendering erfolgt. In der Realität sieht es jedoch oft anders aus. Manchmal benötigt Anwendungscode mehr als
die Hälfte der in einem Bild verfügbaren Zeit, dehnt seine Zeitzuweisung aus und verringert somit die für das
Rendering verfügbare Zeit. In anderen Fällen, besonders bei komplexen grafischen Inhalten wie Filtern und
Mischmodi, benötigt das Rendering mehr als die Hälfte der Bildzeit. Da die tatsächlich von den Phasen beanspruchte
Zeit flexibel ist, kann man sich die Bildschleife als „elastische Rennbahn“ vorstellen.
Wenn die gesamten Operationen der Bildschleife (Codeausführung und Rendering) zu lange dauern, kann die
Laufzeitumgebung die Bildrate nicht aufrechterhalten. Das Bild wird erweitert, nimmt mehr Zeit in Anspruch als
vorgesehen, deshalb gibt es eine Verzögerung, bevor das nächste Bild ausgelöst wird. Wenn eine Bildschleife
beispielsweise länger als eine dreißigstel Sekunde dauert, kann die Laufzeit den Bildschirm nicht mit 30 fps
aktualisieren. Wenn sich die Bildrate verringert, verschlechtert sich das Benutzererlebnis. Im besten Fall wirken
Animationen abgehackt. Im schlimmsten Fall reagiert die Anwendung nicht mehr und das Fenster ist leer.
Ausführliche Informationen zum Codeausführungs- und Renderingmodell der Flash Plattform-Laufzeitumgebung
finden Sie in den folgenden Ressourcen:
Flash Player Mental Model – The Elastic Racetrack (Artikel von Ted Patrick)
Asynchronous ActionScript Execution (Artikel von Trevor McCauley)
Optimizing Adobe AIR for code execution, memory & rendering unter
http://www.adobe.com/go/learn_fp_air_perf_tv_de (Video der MAX-Konferenzpräsentation von Sean
Christmann)
Letzte Aktualisierung 9.5.2012
2