Sự kiện động cơ bị trì hoãn

Các điều khiển thuộc tính Workspace.SignalBehavior xác định xem các xử lý sự kiện có bị kích hoạt ngay lập tức hay trì hoãn.Chúng tôi khuyên bạn nên chọn lựa chọn Enum.SignalBehavior.Deferred , giúp cải thiện hiệu suất và độ chính xác của động cơ.Các xử lý sự kiện cho sự kiện bị trì hoãn được tiếp tục tại điểm tái khởi động lại tiếp theo, cùng với bất kỳ xử lý sự kiện mới được kích hoạt nào.

Sơ đồ sau đây so sánh hành vi sự kiện Immediate và hành vi sự kiện Deferred.

• Với hành vi Immediate, nếu một sự kiện kích hoạt một sự kiện khác, người xử lý sự kiện thứ hai bắt lửa ngay lập tức.
• Với hành vi Deferred, sự kiện thứ hai được thêm vào phía sau của hàng đợi và chạy sau.

Tổng thời gian được tiêu thụ không thay đổi, nhưng thứ tự là khác nhau.

“Re-entrancy” ngăn chặn các sự kiện liên tục bắn nhau khi chúng đạt đến một độ sâu nhất định. Giới hạn hiện tại cho điều này là 10.

Lợi ích sự kiện bị trì hoãn

Hành vi Immediate có một số nhược điểm.Cho mỗi ví dụ được thêm vào trò chơi của bạn, thuộc tính thay đổi hoặc một số kích hoạt khác được kích hoạt, động cơ cần chạy mã Luau trước khi bất cứ điều gì khác xảy ra.

• Để thay đổi 1.000 thuộc tính, 1.000 dòng mã tiềm ẩn có thể cần chạy sau mỗi lần thay đổi.
• Có thể xảy ra các lỗi kỳ lạ, khó chẩn đoán, chẳng hạn như một sự kiện xóa bắn trước khi thêm bất cứ thứ gì.
• Các hệ thống quan trọng về hiệu suất có thể phát ra sự kiện yêu cầu chúng phải quay lại và lại Luau.
• Các xử lý sự kiện có thể thay đổi nơi hoặc kích hoạt các sự kiện khác bất cứ khi nào một sự kiện bị kích hoạt.
• Một sự kiện có thể bắn nhiều lần mặc dù là trùng lặp, chẳng hạn như một thuộc tính thay đổi hai lần.

Bằng cách có các phần cụ thể của chu kỳ cuộc sống của động cơ mà Luau có thể chạy, động cơ có thể nhận được hiệu suất cải thiện bằng cách sử dụng một số giả định:

• Các hệ thống quan trọng về hiệu suất không cần phải hiến dâng cho Luau, dẫn đến sự gia tăng hiệu suất.
• Trừ khi chính động cơ thay đổi nó, nơi không bao giờ thay đổi bên ngoài điểm tiếp tục.

Điểm tiếp tục

Sau khi bị trì hoãn, một xử lý sự kiện được tiếp tục tại điểm tái khởi động tiếp theo. Hiện tại, bộ các điểm tái khởi động bao gồm:

• Xử lý nhập (tiếp tục một lần mỗi lần nhập được xử lý, xem UserInputService )
• RunService.PreRender
• Kịch bản chờ lặp lại di sản như wait(), spawn() và delay()
• RunService.PreAnimation
• RunService.PreSimulation
• RunService.PostSimulation
• Đang chờ khởi động lại kịch bản như task.wait() , task.spawn() , và task.delay()
• RunService.Heartbeat
• DataModel.BindToClose

Mẫu mã bị ảnh hưởng phổ biến

Với các sự kiện từ xa, các ví dụ sau sẽ dừng hoạt động đúng cách hoặc có hành vi khác nhau; chúng dựa vào việc sự kiện bị dừng lại ngay lập tức.

Kích hoạt và bắt sự kiện giữa thực thi

Trong ví dụ này, false luôn được trả về khi sự kiện bị trì hoãn được bật kích hoạt vì callback chưa chạy.Để hoạt động đúng cách, luồng phải hiến cho đến khi ít nhất khi sự kiện nên đã bắt lửa.

local success = false
event:Connect(function ()
   success = true
end)
doSomethingToTriggerEvent() -- Gây ra sự kiện `event` bắn
return success

Lắng nghe sự xuất hiện đầu tiên của một sự kiện

connection = event:Connect(function ()
   connection:Disconnect()
   -- làm điều gì đó
end)

Với sự kiện bị trì hoãn được bật, nhiều lần gọi xử lý sự kiện có thể được lên lịch trước khi bạn kết nối từ sự kiện.Gọi Disconnect() loại bỏ tất cả các lời gọi xử lý sự kiện đang chờ - cùng hành vi tồn tại cho các sự kiện ngay lập tức.

Thay thế, sử dụng Once() như một phương pháp thuận tiện hơn để kết nối với một sự kiện mà bạn chỉ cần khởi động lần đầu tiên.

Sự kiện thay đổi tổ tiên hoặc thuộc tính

Sự kiện bị trì hoãn gây ra sự kiện xử lý thay đổi trong dòng dõi hoặc một tính năng xảy ra sau khi dòng dõi hoặc tính năng được thay đổi:

local part = Instance.new("Part", workspace)

local function onPartDestroying()
	print("In signal:", part:GetFullName(), #part:GetChildren())
end

part.Destroying:Connect(onPartDestroying)
part:Destroy()

Bởi vì Destroy() hoạt động ngay lập tức sau khi kịch bản gọi nó sản xuất, ví dụ, instance đã bị phá hủy bởi thời gian onPartDestroying() được gọi.Đối với nhiều ví dụ hơn, xem Instance.Destroying .