När ett program inte använder arbetare körs programmets kod linjärt i steg som kallas
körningstråd
. I tråden utförs den kod som utvecklaren har skrivit. Dessutom körs kod som är en del av miljön, vanligtvis kod som uppdaterar skärmen när egenskaper för visningsobjekten ändras. Trots att kod skrivs i segment som metoder och klasser kommer koden vid körningen att exekveras en rad i taget som om den var skriven i en enda lång serie med steg. Här följer ett hypotetiskt exempel på steg som utförs i ett program:
-
Öppna bildruta: I miljön anropas en
enterFrame
-händelsehanterare och kör koden i den, en rad i taget
-
Mushändelse: Användaren rör musen och i miljön anropas mushändelsehanteraren när olika rollover- och rollout-händelser inträffar
-
Läser in slutförd händelse: En begäran om att läsa in en xml-fil från en url returneras med inlästa fildata. Händelsehanteraren anropas och stegen i den körs, xml-innehållet läses in och en objektuppsättning skapas från xml-data.
-
Mushändelse: Musen har på nytt flyttats, så relevant mushändelsehanterare anropas
-
Återgivning: Inga fler händelser förväntas, så skärmen uppdateras utifrån ändringar gjorda i visningsobjekt
-
Öppna bildruta: Kodcykeln återupptas
Så som det beskrivs i exemplet körs de hypotetiska stegen 1 till 5 i en sekvens inom ett tidsblock som kallas en bildruta. Eftersom de körs i en sekvens i en tråd går det inte att avbryta ett steg i processen för att köra ett annat. Med en frekvens på 30 bildrutor per sekund finns det endast tid för att utföra alla dessa operationer under en trettiondels sekund. I de flesta fall är det tillräckligt för att hinna köra koden och miljön väntar under den återstående tiden. Anta emellertid att de xml-data som läses in i steg 3 är mycket stora och djupt inkapslade i xml-strukturen. När koden körs i en slinga i xml-koden och skapar objekt kan det ta längre tid än en trettiondels sekund att utföra denna uppgift. I detta fall kommer de återstående stegen (svar på mushändelser och omritning av skärmen) inte att inträffa så snabbt som de borde. Detta leder till att skärmen låser sig och att dataströmmen blir ojämn så att den inte ritas om tillränkligt snabbt för användaren som rör musen.
Om all kod körs i samma tråd finns det bara ett sätt att undvika ojämna dataströmmar och frysningar. Motdraget är att inte skapa åtgärder som tar lång tid, såsom slingor över stora datamängder. Med ActionScript-arbetare erbjuds du en annan lösning. Om du använder arbetare kan du göra omfattande kodkörningar i en separat arbetare. Varje arbetare körs i en separat tråd så att den omfattande kodkörningen utförs i en egen tråd i bakgrunden. Detta frigör arbetarens huvudprogram så att skärmen kan ritas om för varje bildruta utan att blockera annat arbete.
Möjligheten att utföra flera kodoperationer samtidigt på detta sätt kallas för
samtidighet
(concurrency). När bakgrundsarbetaren är klar med sitt arbete eller medan det pågår, kan du skicka meddelanden och data för huvudarbetaren. Detta medför att du kan skriva kod som utför komplexa och tidskrävande operationer, men slippa nackdelar så som att skärmen fryser.
Arbetare är värdefulla eftersom de minskar riskerna för bildrutebortfall på grund av att huvudåtergivningstråden blockerats av annan kod. Emellertid kräver arbetare mer systemminne och processorkapacitet vilket kan påverka programmets generella prestanda negativt. Eftersom varje arbetare använder egna instanser av den virtuella miljön kan även pålägget för en enkel arbetare vara stort. När du använder arbetare ska du testa koden på alla målplattformar för att försäkra dig om att inte belastningen på systemet blir för stor. Adobe rekommenderar att du inte använder mer än en eller två bakgrundsarbetare i vanliga situationer.
