Wanneer een toepassing geen worker gebruikt, wordt de toepassingscode stapsgewijs uitgevoerd middels een enkel lineair blok. Dit wordt een
thread
genoemd. De thread voert de code uit die door de ontwikkelaar is geschreven. Naast deze code wordt ook code uitgevoerd die onderdeel is van de runtime. Hierbij gaat het met name om de code waarmee het scherm wordt bijgewerkt nadat de eigenschappen van de weergaveobjecten zijn veranderd. Alhoewel de code is geschreven in blokken die bestaan uit methoden en klassen, wordt de code tijdens runtime regel voor regel uitgevoerd, net als achtereenvolgende stappen in een uitgerekt proces. Neem het volgende hypothetische voorbeeld van stappen die door een toepassing worden uitgevoerd:
-
Enter Frame-gebeurtenis: de runtime roept alle
enterFrame
-gebeurtenishandlers op en voert de bijbehorende coderegels één voor één uit.
-
Mouse-gebeurtenis: de gebruiker verplaatst de muis en de runtime roept alle Mouse-gebeurtenishandlers aan zodra de verschillende rollover- en rollout-gebeurtenissen plaatsvinden.
-
Load Complete-gebeurtenis: het verzoek om een XML-bestand vanuit een URL te laden wordt geretourneerd met de geladen bestandsgegevens. De gebeurtenishandler wordt aangeroepen en doorloopt de benodigde stappen, waarbij de XML-inhoud wordt gelezen en een aantal objecten worden gemaakt op basis van de XML-gegevens.
-
Mouse-gebeurtenis: de muis is weer verplaatst en als gevolg roept de runtime de relevante Mouse-gebeurtenishandlers aan.
-
Rendering: er staan geen gebeurtenissen meer in de wachtrij, zodat de runtime het scherm kan bijwerken op basis van de eventuele wijzigingen die zijn toegepast op weergaveobjecten.
-
Enter Frame-gebeurtenis: de cyclus begint van voor af aan.
Zoals wordt beschreven in het voorbeeld, worden de hypothetische stappen 1-5 achter elkaar uitgevoerd binnen een enkel tijdblok dat een frame wordt genoemd. Aangezien de stappen achtereenvolgens in een enkele thread worden uitgevoerd, kan de runtime geen stap onderbreken om een andere stap uit te voeren. Bij een framesnelheid van 30 frames per seconde moet de runtime alle bewerkingen binnen eendertigste van een seconde uitvoeren. In veel gevallen is dat voldoende tijd om de code uit te voeren en kan de runtime wachten tot de vastgestelde tijdsperiode voor het frame verloopt. Maar stel nu dat de XML-gegevens die in stap 3 worden geladen, bestaan uit een hele grote, diepgeneste XML-structuur. Dan kan het gebeuren dat de stap waarin de XML-gegevens door de code worden opgehaald en de bijbehorende objecten gemaakt, langer duurt dan eendertigste van een seconde. In dat geval worden de latere stappen(reageren op de muis en vernieuwen van het scherm) later dan verwacht uitgevoerd. Dit leidt tot een schokkerige schermweergave, omdat het scherm niet snel genoeg wordt vernieuwd in reactie op de muisverplaatsing door de gebruiker.
Als alle code binnen dezelfde thread wordt uitgevoerd, kan een dergelijke schokkerige weergave slechts op één manier worden voorkomen. De oplossing? Er eenvoudigweg voor zorgen dat langdurige bewerkingen, zoals het ophalen van een grote gegevensset, niet in de code worden opgenomen. Een andere oplossing wordt geboden door ActionScript-workers. Met workers kunt u langdurige code laten uitvoeren door een aparte worker. Elke worker wordt in een afzonderlijke thread uitgevoerd, zodat de worker de langdurige bewerking in een eigen thread op de achtergrond uitvoert. Dit geeft de uitvoeringsthread van de hoofdworker meer ruimte, zodat het scherm in elk frame probleemloos kan worden vernieuwd.
De mogelijkheid om meerdere codebewerkingen tegelijkertijd uit te voeren wordt
gelijktijdige uitvoering
genoemd. Zodra de worker op de achtergrond zijn codebewerking heeft voltooid (of op 'voortgangspunten' tijdens de uitvoering), kunt u de meldingen en gegevens verzenden naar de worker van de hoofdcode. Op deze manier kunt u code opnemen voor complexe en intensieve bewerkingen, en tegelijkertijd voorkomen dat de gebruiker moet werken met een schokkerige schermweergave.
Workers zijn handig omdat het risico op een tragere framesnelheid doordat de hoofdthread voor rendering wordt geblokkeerd door andere code, wordt verkleind. Workers vereisen echter ook extra systeemgeheugen en CPU-gebruik, en dat gaat soms ten koste van de algehele prestaties van de toepassing. Aangezien elke worker een eigen instantie van de runtime-VM gebruikt, kan zelfs een eenvoudige worker leiden tot een aanzienlijke overhead. Wanneer u workers gebruikt, moet u uw code dan ook testen op alle doelplatforms om te voorkomen dat het systeem niet te zwaar wordt belast. Adobe raadt aan dat u niet meer dan een of twee workers op de achtergrond gebruikt in een typisch scenario.
