Eventos de motor adiados

*Este conteúdo é traduzido por IA (Beta) e pode conter erros. Para ver a página em inglês, clique aqui.

A propriedade Workspace.SignalBehavior controla se os manipuladores de eventos são disparados imediatamente ou adiados.Recomendamos a opção Enum.SignalBehavior.Deferred 5, que ajuda a melhorar o desempenho e a precisão do motor.Os manipuladores de eventos para eventos adiados são retomados no próximo ponto de retomada, juntamente com quaisquer manipuladores de eventos recém-ativados.

O seguinte diagrama compara o comportamento do evento Immediate e o comportamento do evento Deferred.

  • Com o comportamento Immediate, se um evento disparar outro evento, o segundo manipulador de eventos é acionado imediatamente.
  • Com o comportamento Deferred, o segundo evento é adicionado ao fim de uma fila e executado mais tarde.

O tempo total levado não muda, mas a ordem é diferente.

A comparison of three event handlers firing with Immediate and Deferred behavior

A "reentrada" impede que eventos disparem um ao outro continuamente quando atingirem uma determinada profundidade. O limite atual para isso é 10.

Benefícios de evento adiados

O comportamento Immediate tem algumas desvantagens.Para cada instância adicionada ao seu jogo, propriedade que muda ou algum outro gatilho que é invocado, o motor precisa executar código Luau antes que qualquer outra coisa aconteça.

  • Para alterar 1.000 propriedades, 1.000 pedaços de código potencialmente precisam ser executados após cada alteração.
  • Bugs estranhos e difíceis de diagnosticar podem ocorrer, como um evento de remoção ativado antes de algo fosse adicionado.
  • Sistemas críticos de desempenho podem disparar eventos que exigem que eles retornem de e para Luau.
  • Os manipuladores de eventos podem fazer alterações no local ou acionar outros eventos sempre que um evento for disparado.
  • Um evento pode disparar várias vezes apesar de ser redundante, como uma propriedade mudar duas vezes.

Ao ter porções específicas do ciclo de vida do motor em que o Luau pode executar, o motor pode obter melhor desempenho usando uma série de suposições:

  • Sistemas críticos de desempenho não precisam ceder ao Luau, o que leva a ganhos de desempenho.
  • A menos que o próprio motor o altere, o local nunca muda fora de um ponto de retomada.

Pontos de retomada

Após ser adiado, um manipulador de eventos é retomado no próximo ponto de retomada. Atualmente, o conjunto de pontos de retomada inclui:

Padrões de código afetados comuns

Com eventos remotos, os seguintes exemplos param de funcionar corretamente ou têm um comportamento sutilmente diferente; eles dependem de eventos sendo retomados imediatamente.

Gatilhar e capturar eventos durante a execução midiática

Neste exemplo, false é sempre retornado quando os eventos diferidos são habilitados porque o retorno não foi executar.Para funcionar corretamente, o subprocesso deve ceder até que pelo menos quando o evento deveria ter sido disparado.


local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- Causa `event` para Iniciar / executar
return success

Ouça a primeira ocorrência de um evento


connection = event:Connect(function ()
connection:Disconnect()
-- faça algo
end)

Com eventos atrasados ativados, várias invocações de manipulador de eventos podem ser colocadas em espera antes de você se desconectar do evento.Chamando Disconnect() descarta todas as invocações de manipulador de eventos pendentes - o mesmo comportamento que existe para eventos imediatos.

Alternativamente, use Once() como um método mais conveniente para se conectar a um evento de que você só precisa da primeira invocação.

Eventos que alteram ancestralidade ou propriedades

Eventos adiados causam eventos que lidam com uma mudança na ancestralidade ou em uma propriedade após a alteração da ancestralidade ou da propriedade:


local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("In signal:", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()

Porque Destroy() funciona imediatamente após o script que o chamou produzir, a instância já foi destruída antes que onPartDestroying() seja chamada.Para mais exemplos, veja Instance.Destroying .