Workspace.SignalBehavior プロパティは、イベントハンドラーが即座に発射されるか、遅延されるかを制御します。エンジンのパフォーマンスと正確性を向上させるのに役立つ Enum.SignalBehavior.Deferred オプションをお勧めします。遅延イベントのイベントハンドラーは、新しくトリガーされたイベントハンドラーとともに、次の 再開ポイント で再開されます。
次の図では、Immediate イベント動作と Deferred イベント動作を比較します。
- Immediate 動作では、イベントが別のイベントをトリガーすると、2番目のイベントハンドラーがすぐに発動します。
- Deferred 動作では、2番目のイベントがキューの後ろに追加されて後で実行されます。
合計所要時間は変更されませんが、順序は異なります。

「再入り」は、イベントが特定の深さに達すると、相互に連続して発射するのを防ぎます。現在の制限は 10 です。
遅延イベントベネフィット
Immediate 行動にはいくつかのデメリットがあります。ゲームに追加されたすべてのインスタンス、変更されるプロパティ、または他のトリガーが呼び出される前に、エンジンは Luau コードを実行する必要があります。
- 1,000のプロパティを変更するには、1,000行のコードが潜在的に各変更後に実行する必要があります。
- 奇妙で診断が困難なバグが発生する可能性があります。例えば、何かが追加される前に除去イベントが発射されるなどです。
- パフォーマンスクリティカルなシステムは、ルアウにバックアンドフォワードする必要のあるイベントを発射できます。
- イベントハンドラーは、イベントが発動するたびに場所を変更したり、他のイベントをトリガーしたりできます。
- プロパティが 2 回変更されても、イベントは重複して複数回発射できます。
Luau が実行できるエンジンのライフサイクルの特定の部分を持つことにより、エンジンは複数の仮定を使用してパフォーマンスを向上させることができます:
- パフォーマンスの重要なシステムは、Luau に従わなくても、パフォーマンスが向上することがあります。
- エンジン自体が変更しない限り、場所は再開ポイントの外では決して変更されません。
再開ポイント
遅延された後、イベントハンドラーは次の再開ポイントで再開されます。現在、再開ポイントのセットには以下が含まれます:
- 入力処理 (処理する入力を一度再開、詳細は UserInputService )
- レガシー待機スクリプトの再開、例: wait()、spawn()、およびdelay()
影響を受けるコードパターンの一般
リモートイベントでは、次の例が正しく機能しなくなるか、微妙に異なる動作を示す;彼らは、イベントがすぐに再開されることを信頼している。
実行中のイベントをトリガーしてキャッチする
この例では、false は、コールバックが実行されていないため、遅延イベントが有効になっているときに常に返されます。正しく動作するには、スレッドが発射するまで、少なくともイベントが発火する必要があります。
local success = false
event:Connect(function ()
success = true
end)
doSomethingToTriggerEvent() -- `event` を発射させる原因
return success
イベントの最初の発生を聞く
connection = event:Connect(function ()
connection:Disconnect()
-- 何かする
end)
遅延イベントが有効になっているため、イベントから切断する前に複数のイベントハンドラー呼び出しがキューに追加されることができます。呼び出し Disconnect() は、すべての保留のイベントハンドラー呼び出しをキャンセルします—即時イベントの場合と同じ動作です。
代わりに、Once() を使用して、必要なのは最初の呼び出しのみのイベントに接続する便利な方法として使用します。
祖先またはプロパティを変更するイベント
遅延イベントは、祖先またはプロパティが変更された後に発火するイベントを引き起こします:
local part = Instance.new("Part", workspace)
local function onPartDestroying()
print("In signal:", part:GetFullName(), #part:GetChildren())
end
part.Destroying:Connect(onPartDestroying)
part:Destroy()
スクリプトが呼び出された後すぐに Destroy() が動作するため、インスタンスは onPartDestroying() が呼び出される時までに既に破壊されています。詳しい例は、Instance.Destroying を参照してください。