La propriété Workspace.SignalBehavior contrôle si les gestionnaires d'événements sont déclenchés immédiatement ou reportés.Nous recommandons l'option Enum.SignalBehavior.Deferred qui aide à améliorer les performances et la correction du moteur.Les gestionnaires d'événements pour événements reportés sont repris au prochain point de reprise, ainsi que tous les gestionnaires d'événements nouvellement déclenché.
La valeur Enum.SignalBehavior.Default de Workspace.SignalBehavior est actuellement équivalente à Enum.SignalBehavior.Immediate, mais passera finalement à être équivalente à Enum.SignalBehavior.Deferred .Les emplacements de modèle sont directement définis à Enum.SignalBehavior.Deferred par défaut.
Le diagramme suivant compare le comportement de l'événement Immediate et le comportement de l'événement Deferred.
- Avec le comportement Immediate, si un événement déclenche un autre événement, le deuxième gestionnaire d'événement se déclenche immédiatement.
- Avec le comportement Deferred, le deuxième événement est ajouté à la fin d'une file d'attente et est exécuté plus tard.
Le temps total pris ne change pas, mais l'ordre est différent.
« Réentrée » empêche les événements de tirer les uns les autres en continu lorsqu'ils atteignent une certaine profondeur. La limite actuelle pour cela est de 10.
Avantages d'événement différés
Le comportement Immediate a quelques inconvénients.Pour chaque instance ajoutée à votre jeu, propriété qui change ou autre déclencheur qui est invoqué, le moteur doit exécuter du code Luau avant que toute autre chose n'arrive.
- Pour modifier 1 000 propriétés, 1 000 morceaux de code potentiellement doivent être exécutés après chaque changement.
- Des bugs étranges et difficiles à diagnostiquer peuvent survernir, tels qu'un événement de suppression déclenché avant même l'ajout de quelque chose.
- Les systèmes sensibles aux performances peuvent déclencher des événements nécessitant qu'ils retournent et retournent à Luau.
- Les gestionnaires d'événements peuvent apporter des modifications au lieu ou déclencher d'autres événements à tout moment qu'un événement est tiré.
- Un événement peut se déclencher plusieurs fois malgré son caractère redondant, comme la modification d'une propriété deux fois.
En ayant des parties spécifiques du cycle de vie du moteur dans lesquelles Luau peut s'lancer, le moteur peut obtenir une meilleure performance en utilisant un certain nombre d'hypothèses :
- Les systèmes sensibles aux performances n'ont pas besoin de céder à Luau, ce qui entraîne des gains de performance.
- À moins que le moteur lui-même ne le change, l'endroit ne change jamais en dehors d'un point de reprise.
Points de reprise
Après avoir été reporté, un gestionnaire d'événement reprend au prochain point de reprise. Actuellement, le ensemble de points de reprise inclut :
- Traitement des entrées (reprend une fois par entrée à traiter, voir UserInputService )
- Script d'attente hérité reprendre comme wait() , spawn() , et delay()
Modèles de code affectés communs
Avec des événements à distance, les exemples suivants cessent de fonctionner correctement ou ont un comportement subtillement différent ; ils comptent sur le fait que les événements soient repris immédiatement.
Déclencher et capturer des événements en cours d'exécution
Dans cet exemple, false est toujours renvoyé lorsque les événements différés sont activés car le rappel n'a pas été lancer.Pour fonctionner correctement, le thread doit céder jusqu'à ce que l'événement ait au moins été déclenché.
local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- Fait déclencher l'lancer`event`
return success
Écouter la première occurrence d'un événement
connection = event:Connect(function ()
connection:Disconnect()
-- faire quelque chose
end)
Avec les événements différés activés, plusieurs invocations de gestionnaire d'événements peuvent être en file d'attente avant que vous vous déconnectiez de l'événement.Appeler Disconnect() annule toutes les invocations de gestionnaire d'événement en attente — le même comportement qui existe pour les événements immédiats.
Toute autre méthode de déconnexion en plus de Disconnect(), comme l'appel de Destroy() sur le Instance, déconnecte le signal immédiatement, mais exécute le gestionnaire d'événements associé pour tous les événements qui sont toujours en attente.
Alternativement, utilisez Once() comme méthode plus pratique pour vous connecter à un événement dont vous avez besoin seulement de la première invocation.
Événements qui modifient l'ascendance ou les propriétés
Les événements reportés causent des événements qui gèrent un changement d'ascendance ou une propriété de tirer après que l'ascendance ou la propriété ait été modifiée :
local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("In signal:", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()
Parce que Destroy() fonctionne immédiatement après le script qui l'a appelé, l'instance a déjà été détruite au moment où onPartDestroying() est appelé.Pour plus d'exemples, voir Instance.Destroying .