Die Workspace.SignalBehavior Eigenschaft steuert, ob Event-Handler sofort oder verzögert abgefeuert werden.Wir empfehlen die Enum.SignalBehavior.Deferred Option, die dazu beiträgt, die Leistung und Korrektheit der Engine zu verbessern.Die Event-Handler für verzögerte Ereignisse werden am nächsten Wiederaufnahmepunkt fortgesetzt, zusammen mit allen neu aktivierten Event-Handlern.
Der Enum.SignalBehavior.Default Wert von Workspace.SignalBehavior ist derzeit gleichbedeutend mit Enum.SignalBehavior.Immediate , wird sich aber schließlich auf gleichbedeutend mit Enum.SignalBehavior.Deferred ändern.Vorlagenplätze werden standardmäßig direkt auf Enum.SignalBehavior.Deferred festgelegt.
Das folgende Diagramm vergleicht das Immediate Eventverhalten und das Deferred Eventverhalten.
- Mit dem Verhalten Immediate, wenn ein Ereignis ein anderes Ereignis auslöst, wird der zweite Ereignishändler sofort feuert.
- Mit dem Verhalten Deferred wird das zweite Ereignis zum Ende einer Warteschlange hinzugefügt und später ausgeführt.
Die insgesamte benötigte Zeit ändert sich nicht, aber die Reihenfolge ist anders.
Re-Entry verhindert, dass Ereignisse sich gegenseitig kontinuierlich abfeuern, wenn sie eine bestimmte Tiefe erreichen. Das aktuelle Limit dafür ist 10.
Verschiebte Ereignisvorteile
Das Immediate-Verhalten hat einige Nachteile.Für jede Instanz, die zu deinem Spiel hinzugefügt wird, Eigenschaft, die sich ändert, oder einen anderen Trigger, der ausgeführt wird, muss die Engine Luau-Code ausführen, bevor irgendetwas anderes passiert.
- Um 1.000 Eigenschaften zu ändern, müssen möglicherweise 1.000 Code-Schnipsel nach jeder Änderung ausgeführt werden.
- Seltsame, schwer zu diagnostizierende Fehler können auftreten, wie ein Entfernen von Ereignissen, die vor dem Hinzufügen von etwas abgefeuert wurden.
- Leistungskritische Systeme können Ereignisse abfeuern, die sie dazu bringen, hin und her zu Luau zurückzugeben.
- Event-Handler können Änderungen am Ort vornehmen oder andere Ereignisse auslösen, jedes Mal, wenn ein Ereignis ausgelöst wird.
- Ein Ereignis kann mehrere Male feuern, obwohl es redundant ist, z. B. wenn sich ein Eigenschaft zweimal ändert.
Durch das Vorhandensein bestimmter Teile des Motorlebenszyklus, in denen Luau ausführenwerden kann, kann der Motor eine verbesserte Leistung erzielen, indem er eine Reihe von Annahmen verwendet:
- Leistungskritische Systeme müssen sich nicht Luau unterordnen, was zu Leistungsgewinnen führt.
- Es sei denn, die Engine selbst ändert es, ändert sich der Ort nie außerhalb eines Wiederaufnahmepunkts.
Wiederaufnahmepunkte
Nach der Verschiebung wird ein Ereignishändler beim nächsten Wiederaufnahmepunkt fortgesetzt. Derzeit umfasst der Satz der Wiederaufnahmepunkte:
- Eingabeverarbeitung (wird wieder aufgenommen, sobald eine Eingabe verarbeitet werden soll, siehe UserInputService )
- Legacy-Wartungs-Skriptfortsetzung wie wait() , spawn() und delay()
Gewöhnliche betroffene Code-Muster
Mit Remote-Ereignissen funktionieren die folgenden Beispiele entweder nicht mehr richtig oder haben ein subtil anderes Verhalten; sie verlassen sich darauf, dass Ereignisse sofort wieder aufgenommen werden.
Auslösen und Fangen von Ereignissen während der Ausführung mittels
In diesem Beispiel wird false immer zurückgegeben, wenn verzögerte Ereignisse aktiviert sind, weil der Rückruf nicht ausführenwurde.Um richtig zu arbeiten, muss der Thread bis zumindestens dann aufgeben, wenn das Ereignis abgefeuert werden sollte.
local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- Verursacht das "Ereignis" zum initiieren
return success
Hören Sie auf die erste Auftreten eines Ereignisses
connection = event:Connect(function ()
connection:Disconnect()
-- etwas tun
end)
Mit deferred Events aktiviert, können mehrere Ereignishändler-Aufrufe in die Warteschlange gestellt werden, bevor du dich vom Ereignis abmeldest.Das Anrufen von Disconnect() löscht alle ausstehenden Ereignishändler-Aufrufe - das gleiche Verhalten, das für sofortige Ereignisse existiert.
Jede andere Methode der Trennung abgesehen von Disconnect(), wie das Anrufen von Destroy() auf dem Instance, trennt das Signal sofort, führt aber den zugeordneten Ereignishändler für alle Ereignisse durch, die noch ausstehend.
Alternativ verwende Once() als bequemere Methode zum Verbinden mit einem Ereignis, von dem du nur die erste Einladung benötigst.
Ereignisse, die die Vorfahren oder Eigenschaften ändern
Verschiebte Ereignisse verursachen Ereignisse, die eine Änderung der Abstammung oder ein Eigenschaft feuern, nachdem die Abstammung oder das Eigenschaft geändert wurde:
local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("In signal:", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()
Da Destroy() sofort nach der Ausführung des Skripts, das es aufgerufen hat, funktioniert, ist die Instanz bereits zerstört, wenn onPartDestroying() aufgerufen wird.Für weitere Beispiele siehe Instance.Destroying.