引言
對于Android開發(fā)者來說，MessageQueue肯定都不陌生，幾乎每次的UI操作，或者各種面試題都有MessageQueue的身影，它一直采用synchronized來保障的消息隊列的管理。然而，隨著移動設(shè)備性能需求的不斷提升和多核 CPU 的普及，這種synchronized方式逐步成為瓶頸。
如果大家對日常ANR關(guān)注很多，會發(fā)現(xiàn)很多top疑難ANR都有MessageQueue的相關(guān)堆棧的身影。
Android 17 帶來了革命性的變化 —— 全新的無鎖 MessageQueue 實現(xiàn) DeliQueue。
一、歷史方案回顧
1.1 傳統(tǒng) MessageQueue 架構(gòu)
傳統(tǒng) MessageQueue 采用經(jīng)典的生產(chǎn)者-消費者模式，通過單一監(jiān)視器鎖來保護共享狀態(tài)。其架構(gòu)如下圖所示：
核心組件：
- 生產(chǎn)者線程：包括后臺線程、UI 線程等，負(fù)責(zé)向隊列中提交消息
-
監(jiān)視器鎖：通過
synchronized代碼塊實現(xiàn)獨占訪問控制 - 消息隊列：使用單鏈表存儲消息，按時間順序排列
- Looper 線程：作為消費者，從隊列中取出消息并分派給 Handler 處理
工作流程：
- 生產(chǎn)者線程嘗試獲取監(jiān)視器鎖
- 成功獲取鎖后，將消息插入到鏈表的合適位置
- 釋放鎖，通知 Looper 線程有新消息
- Looper 線程獲取鎖，從鏈表頭部取出消息
- 釋放鎖，處理消息
1.2 設(shè)計初衷
這種設(shè)計在 Android 早期版本中是合理的選擇：
- 簡單易實現(xiàn)：單鎖模型邏輯清晰，易于維護
- 線程安全：監(jiān)視器鎖確保同一時間只有一個線程訪問隊列
- 低內(nèi)存占用：單鏈表結(jié)構(gòu)簡單，內(nèi)存開銷小
然而，隨著設(shè)備性能的提升和應(yīng)用復(fù)雜度的增加，這種架構(gòu)的局限性逐漸顯現(xiàn)。
二、歷史方案存在的問題
2.1 鎖競爭問題
當(dāng)多個線程同時嘗試訪問 MessageQueue 時，會產(chǎn)生鎖競爭。如下圖所示，所有生產(chǎn)者線程都必須等待鎖的釋放：
具體表現(xiàn)：
- 高并發(fā)場景下，線程頻繁阻塞和喚醒
- CPU 時間浪費在鎖等待上，而非實際業(yè)務(wù)處理
- 隨著線程數(shù)量增加，性能急劇下降
2.2 擴展性不足
傳統(tǒng) MessageQueue 使用單鏈表存儲消息，其時間復(fù)雜度為：
| 操作 | 時間復(fù)雜度 | 說明 |
|---|---|---|
| 插入 | O(N) | 需要遍歷鏈表找到插入位置 |
| 移除 | O(1) | 直接從頭部移除 |
當(dāng)消息量大時，插入操作的線性掃描成為性能瓶頸。特別是在消息密集的場景（如批量下載、數(shù)據(jù)處理），隊列長度可能達到數(shù)百甚至上千，插入延遲顯著增加。
2.3 實際影響
根據(jù) Google 的內(nèi)部數(shù)據(jù)分析：
- 鎖競爭導(dǎo)致應(yīng)用主線程 15% 的時間處于等待狀態(tài)
- 在消息密集型應(yīng)用中，插入延遲可達數(shù)十毫秒
三、新方案：DeliQueue 的解決方案
3.1 核心設(shè)計思想
DeliQueue 的核心思想是分離消息插入與處理，通過無鎖數(shù)據(jù)結(jié)構(gòu)消除鎖競爭：
關(guān)鍵創(chuàng)新：
- Treiber 棧：無鎖并發(fā)棧，支持任意線程無阻塞地推送消息
- 最小堆：按時間排序的消息隊列，由 Looper 獨占訪問
- 批量傳輸：Looper 將消息從棧批量轉(zhuǎn)移到堆，再逐個處理
3.2 解決鎖競爭問題
DeliQueue 完全消除了鎖競爭：
生產(chǎn)者端（Treiber 棧）：
- 使用 CAS（Compare-And-Swap） 原子操作實現(xiàn)無鎖插入
- 任何線程都可以隨時推送消息，無需等待
- 插入時間復(fù)雜度為 O(1)，與隊列長度無關(guān)
消費者端（最小堆）：
- 最小堆由 Looper 線程獨占訪問，無需鎖保護
- 消息按時間自動排序，取出操作時間復(fù)雜度為 O(logN)
- 批量傳輸減少了線程切換開銷
3.3 提升擴展性
DeliQueue 的時間復(fù)雜度顯著優(yōu)于傳統(tǒng)實現(xiàn)：
| 操作 | 傳統(tǒng) MessageQueue | DeliQueue | 提升 |
|---|---|---|---|
| 插入 | O(N) | O(1) | 從線性到常數(shù) |
| 移除 | O(1) | O(logN) | 對數(shù)級，可接受 |
| 鎖競爭 | 高 | 無 | 完全消除 |
四、新方案的實現(xiàn)原理
4.1 Treiber 棧：無鎖并發(fā)的基礎(chǔ)
Treiber 棧是一種經(jīng)典的無鎖數(shù)據(jù)結(jié)構(gòu)，使用 CAS 操作實現(xiàn)線程安全的入棧和出棧：
public class TreiberStack<E> {
AtomicReference<Node<E>> top = new AtomicReference<>();
public void push(E item) {
Node<E> newHead = new Node<>(item);
Node<E> oldHead;
do {
oldHead = top.get();
newHead.next = oldHead;
} while (!top.compareAndSet(oldHead, newHead));
}
}
工作原理：
- 線程讀取當(dāng)前棧頂指針
- 創(chuàng)建新節(jié)點，將其 next 指向當(dāng)前棧頂
- 使用 CAS 嘗試更新棧頂指針
- 如果 CAS 失敗（其他線程已修改棧頂），則重試
這種設(shè)計保證了至少有一個線程能取得進展，符合無鎖算法的定義。
4.2 最小堆：高效的消息排序
最小堆是一種完全二叉樹，父節(jié)點的值總是小于或等于子節(jié)點的值。在 DeliQueue 中：
- 消息按
when時間戳排序 - 插入和移除操作的時間復(fù)雜度均為 O(logN)
- 相比單鏈表的 O(N) 插入，性能提升顯著
為什么選擇最小堆而非其他數(shù)據(jù)結(jié)構(gòu)？
- 平衡性：完全二叉樹天然平衡，操作穩(wěn)定
- 緩存友好：數(shù)組存儲，內(nèi)存訪問局部性好
- 實現(xiàn)簡單：相比紅黑樹等，堆的實現(xiàn)更輕量
4.3 墓碑機制：安全的消息移除
在無鎖環(huán)境下，如何安全地移除消息是一個挑戰(zhàn)。DeliQueue 采用墓碑（Tombstone）機制：
-
邏輯移除：使用 CAS 將消息的
removed標(biāo)志設(shè)為 true - 延遲清理：消息仍保留在數(shù)據(jù)結(jié)構(gòu)中，但被視為已移除
- 物理清理：由 Looper 線程在合適時機執(zhí)行實際的內(nèi)存回收
這種設(shè)計避免了復(fù)雜的并發(fā)內(nèi)存管理，同時保證了數(shù)據(jù)一致性。
4.4 無分支編程：CPU 層面的優(yōu)化
DeliQueue 還進行了底層的 CPU 優(yōu)化。傳統(tǒng)的消息比較器使用條件分支：
// 傳統(tǒng)實現(xiàn)：使用條件分支
if (whenDiff > 0) return 1;
if (whenDiff < 0) return -1;
這會導(dǎo)致分支預(yù)測失敗和流水線刷新。DeliQueue 改用無分支實現(xiàn)：
// 無分支實現(xiàn)：純算術(shù)運算
final int whenSign = Long.signum(when1 - when2);
return whenSign * 2 + insertSeqSign;
這種優(yōu)化在某些場景下帶來了 5 倍的性能提升。
五、性能對比與實際效果
5.1 理論性能對比
時間復(fù)雜度對比：
- 插入操作：從 O(N) 優(yōu)化到 O(1)，提升顯著
- 鎖競爭：從阻塞等待到完全無鎖
- 整體吞吐：多線程場景下提升 5000 倍
5.2 實際測試數(shù)據(jù)
根據(jù) Google 的內(nèi)部測試：
https://android-developers.googleblog.com/2026/02/under-hood-android-17s-lock-free.html
| 指標(biāo) | 傳統(tǒng)實現(xiàn) | DeliQueue | 改善幅度 |
|---|---|---|---|
| 多線程插入速度 | 1x | 5000x | 5000 倍提升 |
| 主線程鎖競爭時間 | 基準(zhǔn) | -15% | 減少 15% |
| 應(yīng)用丟幀率 | 基準(zhǔn) | -4% | 減少 4% |
| 系統(tǒng) UI 丟幀率 | 基準(zhǔn) | -7.7% | 減少 7.7% |
| 應(yīng)用啟動時間（95% 分位） | 基準(zhǔn) | -9.1% | 減少 9.1% |
5.3 用戶體驗改善
這些數(shù)字背后，是實實在在的用戶體驗提升：
- ? 更流暢的界面：減少卡頓和掉幀
- ? 更快的響應(yīng)：消息處理延遲降低
- ? 更好的多任務(wù)處理：后臺任務(wù)不再阻塞 UI
六、開發(fā)者注意事項
6.1 兼容性
DeliQueue 在 Android 17 中面向 SDK 37 或更高版本的應(yīng)用自動啟用。對于依賴 MessageQueue 私有字段和方法反射的應(yīng)用，可能需要進行適配。
6.2 調(diào)試與監(jiān)控
Android 17 提供了新的 Perfetto 跟蹤支持：
data_sources {
config {
name: "track_event"
target_buffer: 0
track_event_config {
enabled_categories: "mq"
}
}
}
開發(fā)者可以通過 Perfetto 分析 MessageQueue 的性能表現(xiàn)。
七、總結(jié)與展望
7.1 技術(shù)演進的意義
DeliQueue 的實現(xiàn)展示了系統(tǒng)級性能優(yōu)化的典型路徑：
- 問題識別：通過數(shù)據(jù)分析發(fā)現(xiàn)性能瓶頸
- 架構(gòu)革新：采用無鎖數(shù)據(jù)結(jié)構(gòu)突破鎖競爭限制
- 細(xì)節(jié)優(yōu)化：從算法到 CPU 指令的多層次優(yōu)化
7.2 對開發(fā)者的啟示
- 無鎖編程：在合適的場景下，無鎖數(shù)據(jù)結(jié)構(gòu)能帶來巨大性能提升
- 數(shù)據(jù)結(jié)構(gòu)選擇：根據(jù)訪問模式選擇合適的數(shù)據(jù)結(jié)構(gòu)至關(guān)重要
- 性能分析：數(shù)據(jù)驅(qū)動的優(yōu)化比直覺更可靠
7.3 未來展望
DeliQueue 的成功為 Android 系統(tǒng)的其他組件優(yōu)化提供了參考。未來，我們可能會看到更多核心組件采用無鎖設(shè)計，進一步提升系統(tǒng)整體性能。
參考資料
Under the hood: Android 17’s lock-free MessageQueue
https://android-developers.googleblog.com/2026/02/under-hood-android-17s-lock-free.html
MessageQueue 行為變更文檔
https://developer.android.com/about/versions/17/changes/messagequeue?hl=zh-cn
轉(zhuǎn)載自：鴻洋
