上一篇講原子事務時,我們聊了狀態一致性如何保證。這次往下挖一層,看看調度器(Scheduler)是怎么設計的。不同的調度策略各有什么取舍,以及我們的實現怎么對應到那張調度流程圖里的路徑。
調度器是響應式系統里的"隱形指揮官"。
![]()
它不負責決定"要不要算",只負責決定"什么時候算"。
調度策略大致分幾類。按優先級排序是其中一種:好處是能防止低價值更新卡住高優先級交互;壞處是實現復雜得多,系統得同時追蹤截止時間和優先級。這個差異會影響整個系統的策略走向。
從數據更新到UI更新,不同框架在調度器設計上做了不同取舍。這些取舍直接影響性能優化方向和開發者的心智模型。
原子事務那章有三個關鍵場景。事務中讀取值有兩種做法。之前我保留了原始的transaction()實現,方便跟早期例子對比。但實際用起來,transaction()的邏輯應該被atomic()取代。
從代碼角度看,具備完整事務語義的是atomic()。現在的transaction()只相當于批量操作,缺了回滾能力,語義跟上一篇說的不完全對得上。
代碼里把transaction()直接代理給了atomic(),簽名保持兼容同步和異步兩種情況。這樣對外接口沒變,內部實現換成了語義更完整的版本。
給scheduleJob()加了muted檢查,防止回滾期間塞進新任務。如果job已銷毀、或者處于muted狀態,直接返回不加入隊列。其他邏輯不動,只是讓實現行為和上面說的調度策略保持一致。
有個有意思的問題:開發者需要知道調度器存在嗎?
React里開發者經常得考慮"狀態更新不會立即生效",所以心智模型必須包含批量化的概念。Solid或者基于Signals的系統里,計算……
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.