iOS 26 的控制中心中的緩存錯誤

自從 iOS 26.2 Developer Beta 1，我的 iPhone 控制中心中的 Wi-Fi 組件（單個按鈕，非組合組件）出現了狀態反應不同步的現象。

具體表現為，開機時長 5h+，且 1h 未開啟控制中心時，開啟控制中心後 0.5-1s 內 Wi-Fi 的組件未 inactive 樣式，然後恢復為正確的 Wi-Fi 狀態。此錯誤樣式不影響網路連接和設置中 Wi-Fi 的實際狀態，也不會中斷以透過 Wi-Fi 建立的網路連接，僅為視覺錯誤。

在 iOS 26.4.1 Release 中，我嘗試了一次 Reset Network Settings，但錯誤仍然存在。

我推測為 SpringBoard 進程在透過 XPC 向 wifid 守護進程請求 Wi-Fi 狀態時，出現了延遲，從而導致在開啟控制中心 0.5-1s 後才顯示出了正確的 Wi-Fi 狀態。但在我研究後，發現這可能完全不是其原因。

據我所知，SpringBoard 在 啟動時會向 wifid 註冊 Observer，只要 Wi-Fi 的狀態改變，wifid 就會主動發送一個 XPC 廣播給 SpringBoard。SpringBoard 收到後會將狀態儲存在快取中。當用戶下拉控制中心後，控制組件會直接根據快取狀態顯示對應的組件樣式。根據我的假設，問題出現在了 SpringBoard 緩存的 accessibility。由於控制組件無法讀取上一次獲得的 Wi-Fi 緩存狀態，控制組件會顯示預設 1 by 2 組件的模板，也就是透明狀態而非高亮，對於用戶來說也就是 Wi-Fi 組件處於 inactive 樣式。

根據以上的推測，我在 iOS 26.4.1 Release 中，嘗試透過 Force Restart 後，緩存機制貌似恢復，Wi-Fi 組件顯著減少了出現同步延遲的概率。但根據各 forum 對於 Force Restart 不認為有區別於軟重啟，所以尚不清楚是什麼因素修復了狀態緩存的讀取性問題。

不同於軟重啟僅在軟件層面重新執行系統引導，Force Restart 是 iPhone 透過將主板斷電以強制關機的恢復手段。根據我的經驗和猜測，這次由透過 Force Restart 修復的 SpringBoard Wi-Fi 狀態緩存問題，是由於主板由於斷電中斷後，再次啟動時會觸發緩存清理機制和自檢流程，意外的修復了緩存讀取問題。