Quando um aplicativo não usa workers, o código do aplicativo é executado em um bloco linear único de etapas de execução conhecido como uma cadeia de
execução
. A cadeia executa o código escrito pelo desenvolvedor. Executa também a maioria dos códigos que fazem parte do runtime, notavelmente o código que atualiza a tela quando mudam as propriedades dos objetos de exibição. Apesar dos códigos serem escritos em blocos como métodos e classes, durante o runtime, o código executa uma linha por um tempo como se por vez ainda estivessem escritos em uma única longa série de etapas. Considerando este exemplo hipotético de etapas que um aplicativo executa:
-
Inserir quadro: o runtime chama quaisquer manipuladores de eventos
enterFrame
e executa um código de cada vez
-
Evento de mouse: o usuário movimenta o mouse e o runtime chama quaisquer manipuladores de eventos de mouse conforme os vários eventos rollover e rollout acontecem
-
Carregar evento completo: uma solicitação para carregar um arquivo xml de uma url retorna com os dados de arquivo carregados. O manipulador de eventos é chamado e executado por etapas, lendo o conteúdo xml e criando um conjunto de objetos com base nos dados xml.
-
Eventos de mouse: o mouse é movido novamente, assim o runtime chama a manipulação de eventos de mouse relevante
-
Renderização: não há mais eventos aguardando, por isso o runtime atualiza a tela com base nas alterações feitas aos objetos de exibição
-
Inserir quadro: reinicia o ciclo
Conforme descrito no exemplo, as etapas hipotéticas de 1 a 5 é executada na sequência dentro de um único bloco de tempo chamado de quadro. Como eles são executados em sequência em uma cadeia única, o runtime não pode interromper uma etapa do processo para executar outra. Em uma taxa de quadros de 30 quadros por segundo, a execução possui menos de um trigésimo de segundo para executar todas as operações. Em alguns casos, é tempo suficiente para executar o código e o runtime apenas aguarda durante o tempo restante. Entretanto, suponha que os dados xml carregados na etapa 3 sejam de uma estrutura xml muito grande e profundamente aninhada. Como o código é repetido no xml e cria objetos, provavelmente pode levar mais que um trigésimo de segundo para realizar este trabalho. Neste caso, as próximas etapas (responder ao mouse e redesenhar a tela) não acontecem logo como deveriam. Isso causa o congelamento e o corte na tela como se ela não fosse redesenhada rápido o suficiente em resposta ao movimento do mouse pelo usuário.
Se todos os códigos forem executados na mesma cadeia, só há um modo de evitar cortes e congelamentos ocasionais. Isso serve para não realizar operações longas como um loop em um grande conjunto de dados. Os workers do ActionScript fornecem outra solução. Usando um worker, você pode executar códigos longos em um worker separado. Cada worker é executado em uma cadeia separada para que o worker de segundo plano movimente a operação longa em sua própria cadeia. Isso libera a cadeia de execução do worker principal para redesenhar a tela a cada quadro sem ser bloqueada por outro trabalho.
A capacidade de executar várias operações de código ao mesmo tempo dessa forma é conhecida como
simultaneidade
. Quando o worker de segundo plano finaliza o seu trabalho, ou está em pontos de "andamento" durante o processo, você pode enviar notificações e dados do worker principal. Deste modo, você pode escrever o código que realiza operações complexas ou demoradas, evitando uma má experiência de usuário de ter a tela congelada.
Workers são úteis, pois diminuem as chances de uma queda na taxa de quadros devido ao bloqueio da cadeia de renderização principal por outro código. No entanto, os workers requerem um sistema de memória adicional e o uso de CPU, que podem afetar o desempenho geral do aplicativo. Como cada worker utiliza sua própria instância da máquina de runtime virtual, mesmo a sobrecarga de um worker trivial pode ser grande. Ao utilizar workers, teste o seu código em todas as plataformas de destino para certificar-se de que as demanda do sistema não são tão grandes. A Adobe recomenda que você não use mais de um ou dois workers de segundo plano em um cenário típico.
