相信不少Android用戶都會有一種困惑，那就是明明自己的手機已經用上高通/聯發科旗艦SoC+LPDDR5X內存+UFS4.0快閃記憶體的「性能鐵三角」，可日常使用中還是偶爾會卡頓。在即將到來的Android 17上，谷歌方面終於決定修復這個困擾用戶許久的頑疾了。
日前海外科技媒體Android Authority爆料，谷歌將在Android 17引入DeliQueue系統，通過優化MessageQueue（消息隊列）的內存鎖定機制，從而縮短軟體線程之間的等待時間。按照海外開發者的說法，谷歌這一調整極有可能會讓Android系統在流暢度上追平蘋果的iOS。
先來說說，為什麼配置再高的Android旗艦機會不可避免地遇到卡頓問題。其實Android系統卡頓的「病根」就是前文提到的MessageQueue，這是服務架構中常見的組件，用於服務間解耦、事件廣播、任務非同步/延遲處理等，在Android系統中它扮演了Surfaceflinger（負責圖形合成和顯示的核心系統服務）主線程中消息處理的「管家」角色。
MessageQueue在Android系統中被設計為一個無限循環的隊列，會持續輪詢消息，當有新的消息時就去處理，否則就等待。可問題在於，MessageQueue處理消息時必須遵循嚴格的單線程鎖定順序、來排隊訪問內存，所有工作線程必須按順序等待內存鎖釋放才能執行任務。
換而言之，一旦某個線程鎖定了隊列，其它線程便會被迫閑置，進而產生被迫丟幀（Dropped frames）現象，大家就會感受到滑動屏幕時出現不跟手、視覺拖影等卡頓現象。在早期的Android系統中，由於硬體配置的限制，「排隊檢票」的MessageQueue模式以犧牲流暢性的代價保證了系統穩定運行。
當然，谷歌此前也不是沒有嘗試解決這個歷史遺留問題，並為Android引入了Sync barrier（同步屏障）機制。Sync barrier是一個優先隊列，會給要處理的消息加一個優先順序機制，其中特別是關於UI渲染的消息，從而確保Android系統的屏幕繪製更流暢。
可問題在於，Sync barrier是典型的亡羊補牢措施，並不是在設計之初就考慮到的東西。當Sync barrier需要保護的消息被處理後，就需要調用者（通常是App）來手動移除它。假如要處理的高優先順序消息過多，多個線程一起爭奪Sync barrier，或是邏輯出錯、Sync barrier沒有被移除，消息隊列就會停止工作，App則出現應用未響應狀態。
谷歌在Android 17上將要推出的DeliQueue系統，是從以往「一次服務一個線程」的排隊模式改為了並行調度機制，會根據實時運算資源動態分配任務。簡而言之，DeliQueue將Android系統的消息處理從單行道改為多車道，其中負責UI界面渲染的高優先順序消息可以快速通行。
為了更直觀地說明DeliQueue的優越性，谷歌還用「餐廳排隊取號」的例子來進行了解釋，消費者在領取號碼後，取餐順序不必完全受限於排隊順序。也就是說DeliQueue允許線程根據實際資源情況靈活調度，從而避免因等待而造成的性能擁堵。
按照目前曝光的測試結果，DeliQueue能讓App丟幀率穩定降低4%，在更考驗優化功底的主系統界面和啟動器滑動場景中，漏幀率的降幅更是達到了7.7%。雖然DeliQueue帶來的提升從絕對值來看並不大，但它的意義在於重構了Android的消息處理機制，徹底解決了歷史遺留問題。
未來對於Android手機的用戶，特別是中高端機型來說，剛買手機時流暢絲滑，用了一兩年就開始出現滑動拖影、App響應慢的情況幾乎將不會再發生。所謂的「N年不卡」不再需要手機廠商針對性調優，而是每一款機型都能享受到的普惠式升級。
