Bei Anwendungen, die keine Worker verwenden, wird der Anwendungscode in einem einzelnen, linearen Block von Ausführungsschritten ausgeführt, der als Ausführungs
thread
bezeichnet wird. Der Thread führt den Code aus, den ein Entwickler geschrieben hat. Außerdem führt er viel von dem Code aus, der zur Laufzeitumgebung gehört, vor allem den Code, der den Bildschirm aktualisiert, wenn sich die Eigenschaften von Anzeigeobjekten ändern. Zwar wird Code in größeren Abschnitten wie Methoden und Klassen geschrieben, zur Laufzeit wird der Code jedoch Zeile für Zeile ausgeführt, als ob er in einer einzelnen, langen Folge von Schritten geschrieben worden wäre. Hypothetisches Beispiel der Schritte, die von einer Anwendung ausgeführt werden:
-
Frameeintritt: Die Laufzeitumgebung ruft alle vorhandenen
enterFrame
-Ereignisprozeduren auf und führt ihren Code nacheinander aus
-
Mausereignis: Der Benutzer bewegt die Maus und die Laufzeitumgebung ruft alle Mausereignisprozeduren auf, während die verschiedenen Rollover- und Rollout-Ereignisse auftreten
-
Ereignis „Ladevorgang abgeschlossen“: Eine Anforderung, eine XML-Datei aus einer URL zu laden, gibt die geladenen Dateidaten zurück. Die Ereignisprozedur wird aufgerufen und führt ihre Schritte aus. Dabei wird der XML-Inhalt gelesen und es werden Objekte aus den XML-Daten erstellt.
-
Mausereignis: Die Maus wurde erneut bewegt, sodass die Laufzeitumgebung die entsprechenden Ereignisprozeduren aufruft
-
Rendering: Es warten keine weiteren Ereignisse, sodass die Laufzeitumgebung den Bildschirm entsprechend den Änderungen an Anzeigeobjekten aktualisiert
-
Frameeintritt: Der Zyklus beginnt erneut
Wie im Beispiel beschrieben, werden die hypothetischen Schritte 1-5 nacheinander innerhalb eines einzelnen Zeitblocks (Frame genannt) ausgeführt. Da sie nacheinander in einem einzelnen Thread ausgeführt werden, kann die Laufzeitumgebung nicht einen Schritt des Prozesses unterbrechen, um einen anderen auszuführen. Bei einer Framerate von 30 fps hat die Laufzeitumgebung weniger als eine Dreißigstelsekunde Zeit, um alle diese Operationen auszuführen. Häufig reicht dies zum Ausführen des Codes, und die Laufzeitumgebung wartet einfach während der verbleibenden Zeit. Stellen Sie sich jedoch die XML-Daten, die in Schritt 3 geladen werden, einmal als sehr große, sehr verschachtelte XML-Struktur vor. Es kann merklich länger als eine Dreißigstelsekunde dauern, bis der Code die XML durchläuft und Objekte erstellt. In diesem Fall passieren die späteren Schritte (Antwort auf die Mausaktion und Neuzeichnen des Bildschirms) nicht so schnell wie gewünscht. Dadurch friert der Bildschirm ein und kommt ins Stocken, da der Bildschirm nicht schnell genug neu gezeichnet wird, wenn der Benutzer die Maus bewegt.
Wenn der gesamte Code in demselben Thread ausgeführt wird, gibt es nur eine Möglichkeit, gelegentliches Stocken und Einfrieren zu vermeiden: Es dürfen keine Operationen, die sehr lange dauern, ausgeführt werden, zum Beispiel Wiederholschleifen durch eine große Datenmenge. ActionScript-Worker bieten eine andere Lösung an. Code mit langer Ausführungsdauer kann in einem separaten Worker ausgeführt werden. Jeder Worker wird in einem separaten Thread ausgeführt, sodass der Hintergrundworker den Code mit langer Ausführungsdauer in einem eigenen Thread ausführt. So kann im Ausführungsthread des Hauptworkers der Bildschirm neu gezeichnet werden, ohne dass der Vorgang durch andere Operationen blockiert wird.
Die Möglichkeit, auf diese Weise mehrere Codeoperationen zur gleichen Zeit auszuführen, wird als
Parallelität
bezeichnet. Wenn der Hintergrundworker seine Operation abgeschlossen hat, können dem Hauptworker Benachrichtigungen und Daten gesendet werden. Dies kann auch bei bestimmten „Fortschrittspunkten“ während der Operation erfolgen. So können Sie Code schreiben, der komplexe oder zeitaufwändige Operationen ausführt, ohne dass der Benutzer erleben muss, dass der Bildschirm einfriert.
Worker sind hilfreich, da sie die Wahrscheinlichkeit verringern, dass die Framerate aufgrund der Blockierung des Hauptrenderingthreads durch anderen Code abfällt. Auf der anderen Seite erfordern Worker zusätzlichen Systemarbeitsspeicher und CPU-Rechenleistung, was die allgemeine Anwendungsleistung verringern kann. Da jeder Worker seine eigene Instanz der virtuellen Maschine der Laufzeitumgebung verwendet, kann der Mehraufwand auch bei trivialen Workern erheblich ins Gewicht fallen. Wenn Sie Worker verwenden, testen Sie Ihren Code auf allen Zielplattformen, um sicherzustellen, dass die Anforderungen an das System nicht zu groß sind. Adobe empfiehlt, in einem typischen Szenario nicht mehr als ein oder zwei Hintergrundworker zu verwenden.
