La propriété Workspace.SignalBehavior contrôle si les gestionnaires d'événements sont déclenchés immédiatement ou différés. L'option Enum.SignalBehavior.Deferred est recommandée car elle contribue à améliorer la performance et la justesse du moteur. Les gestionnaires d'événements pour les événements différés sont repris au prochain point de reprise, avec tous les nouveaux gestionnaires d'événements déclenchés.
La valeur Enum.SignalBehavior.Default de Workspace.SignalBehavior est actuellement équivalente à Enum.SignalBehavior.Immediate, mais finira par être équivalente à Enum.SignalBehavior.Deferred. Les lieux de modèle sont directement définis sur Enum.SignalBehavior.Deferred par défaut.
Le diagramme suivant compare le comportement d'événements Immediate et Deferred.
- Avec le comportement Immediate, si un événement déclenche un autre événement, le gestionnaire du deuxième événement est exécuté immédiatement.
- Avec le comportement Deferred, le deuxième événement est ajouté à l'arrière d'une file d'attente et s'exécute plus tard.
Le temps total pris ne change pas, mais l'ordre est différent.
La "réentrée" empêche les événements de se déclencher continuellement les uns les autres lorsqu'ils atteignent une certaine profondeur. La limite actuelle pour cela est de 10.
Avantages des événements différés
Le comportement Immediate a certains inconvénients. Pour chaque instance ajoutée à votre jeu, propriété qui change, ou tout autre déclencheur qui est invoqué, le moteur doit exécuter du code Luau avant que quoi que ce soit d'autre se produise.
- Pour changer 1 000 propriétés, 1 000 extraits de code doivent potentiellement s'exécuter après chaque changement.
- Des bogues étranges et difficiles à diagnostiquer peuvent se produire, comme un événement de suppression se déclenchant avant qu'un élément ne soit même ajouté.
- Les systèmes critiques pour la performance peuvent déclencher des événements nécessitant qu'ils reviennent à Luau.
- Les gestionnaires d'événements peuvent apporter des modifications au lieu ou déclencher d'autres événements chaque fois qu'un événement est déclenché.
- Un événement peut se déclencher plusieurs fois bien qu'il soit redondant, comme une propriété changeant deux fois.
En ayant des portions spécifiques du cycle de vie du moteur dans lesquelles Luau peut s'exécuter, le moteur peut bénéficier d'une amélioration de la performance en utilisant un certain nombre d'hypothèses :
- Les systèmes critiques pour la performance n'ont pas besoin de céder à Luau, ce qui entraîne des gains de performance.
- À moins que le moteur lui-même ne change, le lieu ne change jamais en dehors d'un point de reprise.
Points de reprise
Après avoir été différé, un gestionnaire d'événements est repris au prochain point de reprise. Actuellement, l'ensemble des points de reprise comprend :
- Traitement des entrées (reprend une fois par entrée à traiter, voir UserInputService)
- Reprises de script d'attente héritées comme wait(), spawn(), et delay()
Modèles de code couramment affectés
Avec les événements distants, les exemples suivants cessent de fonctionner correctement ou ont un comportement subtilement différent ; ils dépendent de la reprise immédiate des événements.
Déclenchement et capture d'é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é exécuté. Pour fonctionner correctement, le fil doit céder au moins jusqu'au moment où l'événement aurait dû se déclencher.
local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- Fait déclencher `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 gestionnaires d'événements peuvent être mises en file d'attente avant que vous ne vous déconnectiez de l'événement. Appeler Disconnect() annule toutes les invocations de gestionnaires d'événements en attente - le même comportement qui existe pour les événements immédiats.
Toute autre méthode de déconnexion à part Disconnect(), comme appeler Destroy() sur Instance, déconnecte le signal immédiatement, mais exécute le gestionnaire d'événements associé pour tous les événements qui sont encore en attente.
Alternativement, utilisez Once() comme méthode plus pratique pour se connecter à un événement dont vous n'avez besoin que de la première invocation.
Événements qui changent d'ascendance ou de propriétés
Les événements différés provoquent des événements qui gèrent un changement d'ascendance ou de propriété à se déclencher après que l'ascendance ou la propriété ait été changée :
local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("Dans le signal :", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()
Parce que Destroy() fonctionne immédiatement après que le script qui l'a appelé cède, l'instance a déjà été détruite au moment où onPartDestroying() est appelé. Pour plus d'exemples, voir Instance.Destroying.