一個被全網封殺的影片，卻揭露了 Android 音頻鏈路的結構性劣勢。
作為 Android OS 開發者，我從中學到了什麼？
事件背景：一場讓整個手機產業震動的測評
2026 年 2 月 15 日，B站知名科技媒體「極客灣 Geekerwan」發布了一期名為《手機遊戲性能大橫評：廠商作弊太瘋狂！》的影片。他們自費購買了 44 台零售手機，在完全無廣告合作的條件下，進行了覆蓋幀率、功耗、觸控延遲、音頻延遲等維度的全面測試。
結果震驚了整個產業：除了 iPhone，幾乎所有中國 Android 廠商都在對媒體測評機「做手腳」。
影片在 2 月 22 日被 B站以「不可抗力」為由下架，隨後全網封殺。但作為一個在做自定義 Android OS 的開發者，我想聊的不是八卦，而是極客灣的測試方法論中，有哪些值得 OS 開發者深入理解和借鑑的。
兩條被忽視的鏈路：Video Linkage 和 Audio Linkage
大多數性能評測只看「幀率」和「功耗」。極客灣這次橫評的突破在於，他們測試了兩條真正影響用戶體驗的完整路徑：
Video Linkage Path（觸控到畫面）
從手指觸碰螢幕，到畫面上產生對應變化，中間經過的完整路徑：
觸碰螢幕
→ Touch Controller (採樣率: 120~480Hz)
→ Kernel Input Driver
→ InputDispatcher (system_server)
→ 遊戲引擎處理
→ GPU 渲染
→ BufferQueue (雙重/三重緩衝)
→ SurfaceFlinger 合成
→ Display 更新極客灣的做法：在《和平精英》中測量「按下開火鍵→畫面出現槍口火花」的時間，用高速攝影機拍攝，多輪取平均值 + 標準差。
Audio Linkage Path（觸控到聲音）
從手指觸碰螢幕，到聲音從喇叭/耳機出來，中間的路徑：
觸碰螢幕
→ 遊戲決定播放音效
→ Audio API (AudioTrack / AAudio)
→ AudioFlinger 混音
→ Audio HAL
→ DAC → 喇叭極客灣和《喵斯快跑》(Musedash) 開發者合作，使用內部開發工具精確測量音頻鏈路延遲。
測試結果：Android 贏了畫面，iOS 贏了聲音
Video Linkage（觸控→畫面）
| 排名 | 機型 | 延遲 | 觸控採樣率（遊戲中） |
|---|---|---|---|
| 1 | 榮耀 WIN | ~35ms | 480Hz |
| 中位數 | Android 旗艦 | 40~50ms | 240~360Hz |
| 墊底 | iPhone 17 Pro Max | ~60ms | 240Hz |
Android 靠硬體規格贏了。 480Hz 觸控採樣率 + 雙重緩衝 vs iPhone 的三重緩衝，硬體優勢直接轉化為低延遲。
但這裡有個有趣的發現——
白名單效應
極客灣用了一個聰明的測試：同一台手機，分別在遊戲和空白 App 中測觸控延遲。
| 平台 | 遊戲中 | 普通 App | 差異 |
|---|---|---|---|
| iPhone | ~60ms | ~45ms | App 中反而更低（無三重緩衝開銷） |
| Android（以榮耀 WIN 為例） | ~35ms (480Hz) | ~48ms (145Hz) | 普通 App 反而更差 |
結論：Android 廠商的低延遲是靠「白名單」針對特定遊戲開啟高觸控採樣率。 一旦離開白名單，採樣率降回 120~145Hz，延遲不但沒改善，反而比遊戲中更高。iPhone 則相反——遊戲因三重緩衝而延遲較高，普通 App 反而更低且穩定。
對 OS 開發者的啟示：系統級優化 > 白名單式優化。 白名單拉高了遊戲體驗，卻犧牲了其他 App 的一致性。
Audio Linkage（觸控→聲音）
| 機型 | 平均延遲 | 標準差 |
|---|---|---|
| 小米 17 系列 | ~25ms | ~1.2ms |
| iPhone 17 Pro Max | ~28ms | 極低（工具顯示穩定） |
| iQOO Z10 Turbo+ | ~26ms | ~2.6ms |
| Android 多數旗艦 | 30~65ms | 1~12ms |
| OPPO Find X9 Pro | ~89ms | ~4.1ms |
整體格局比想像中更複雜。 最好的 Android 手機（小米 17 系列 ~25ms）已經追平甚至超越 iPhone 的 28ms。但 Android 陣營的離散度極大——最差的 OPPO Find X9 Pro 高達 89ms，跟 iPhone 差了三倍。
更重要的是標準差——iPhone 的音頻延遲一致性極高，而 Android 即使平均值低，標準差普遍在 1~12ms 之間波動。這對音遊來說是致命差異，也影響任何需要音頻反饋的應用。
為什麼 iOS 音頻延遲遠低於 Android？
這不是某個廠商做得不好，而是 Android 音頻架構的結構性問題。
Android 的包袱
App → AudioTrack (Java) → AudioFlinger (混音器) → Audio HAL → ALSA → DAC
↑
這一層是問題根源AudioFlinger 是 Android 音頻系統的核心混音器。所有音頻流都必須經過它，混合後再送到 HAL。這個設計保證了多個 App 同時播放音頻時不會衝突，但代價是 10-30ms 的額外延遲。
即使使用 AAudio（Android 8.0+ 引入的低延遲 API），如果不開啟 MMAP 模式（直接寫入 DSP buffer），仍然要走 AudioFlinger。
而 MMAP 模式需要：
- Audio HAL 明確支援
- 設備 kernel driver 支援
- App 使用正確的 API 參數
三個條件缺一不可。大多數 Android 設備和 App 都沒有全部滿足。
iOS 為什麼不需要這些
App → CoreAudio → Audio Unit → HAL → DACiOS 的 CoreAudio 是從 macOS 繼承的成熟音頻框架，從第一天就設計為低延遲。加上 Apple 垂直整合硬體和驅動，Audio HAL 層極薄，不存在「碎片化」問題。
一句話總結：Android 要在多廠商、多硬體的生態裡做低延遲，每一層都有碎片化成本；iOS 全部自己控制，所以可以做到系統級一致的低延遲。
廠商作弊手法：我們該避免什麼
極客灣揭露的作弊手法，對做自定義 Android OS 的人是一面鏡子：
1. 特挑 + 特調
從產線精選體質較佳的 SoC 給媒體測評機，並推送專屬高性能調度策略。
教訓： 不要為了跑分或媒體評測做特殊版本。你的用戶拿到的是零售機，用戶體驗才是真實指標。
2. 強制 VRS（可變率著色）
小米 17 被發現強制開啟 VRS，犧牲畫質換幀率數字。
教訓： 效能優化要透明。如果降了畫質，用戶應該知道並且可以選擇。
3. 白名單式優化
只對特定遊戲開啟 Game Turbo / 高觸控採樣率。
教訓： 這在自定義 OS 上尤其危險。你能把所有 App 都加白名單嗎？不能的話，做系統級優化才是正道。
4. 三重緩衝 Bug
榮耀 Magic 8 Pro 的「幻影穩幀」宣稱可關閉，但實際關閉後仍在運作。
教訓： 用戶設定項必須真正生效。「假開關」遲早會被發現。
對自定義 Android OS 開發者的實踐建議
基於以上分析，如果你在做自定義 Android 平台（車載、IoT、嵌入式裝置），以下是具體可做的事：
音頻鏈路優化（ROI 最高）
Android 音頻是最大的短板，也是最值得投資的方向：
# 1. 確認 Audio HAL 支援 MMAP
grep -r "MMAP" hardware/*/audio/
# 2. 設定低延遲 audio profile
# 在 audio_policy_configuration.xml 中添加:
# <mixPort name="low_latency" role="sink" flags="AUDIO_OUTPUT_FLAG_FAST">
# <profile format="AUDIO_FORMAT_PCM_16_BIT" samplingRates="48000"
# channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
# </mixPort>
# 3. 減小 buffer size
# 預設常是 960 frames (20ms @48kHz)
# 可嘗試降到 240 frames (5ms @48kHz)
# 4. 測量 round-trip latency
# 使用 Superpowered Latency Test 或 AAudio loopback視頻鏈路優化
# 1. 調整 SurfaceFlinger VSync offset
# 在 device overlay 中設定:
# ro.surface_flinger.vsync_event_phase_offset_ns=2000000 # App wakeup: 2ms after vsync
# ro.surface_flinger.vsync_sf_event_phase_offset_ns=6000000 # SF wakeup: 6ms after vsync
# 2. 確認 buffer 策略
adb shell dumpsys SurfaceFlinger | grep -A5 "Buffer"
# 3. Input 事件延遲分析
adb shell perfetto -c /data/misc/perfetto-configs/input.cfg -o /tmp/trace.pb建立內部 Benchmark
借鑑極客灣的方法：
| 項目 | 測試方法 | 工具 | 通過標準 |
|---|---|---|---|
| 幀率穩定性 | 30min 持續遊戲 | dumpsys gfxinfo | 1% Low > 55fps |
| 觸控延遲 | 高速攝影機 + Perfetto | 高速相機 240fps+ | < 50ms |
| 音頻延遲 | Round-trip loopback | Superpowered / AAudio | < 40ms |
| 延遲穩定性 | 多輪測試取標準差 | 自建工具 | σ < 3ms |
| 長時間溫度 | 30min 壓力後幀率 | thermald + gfxinfo | 降幅 < 10% |
最重要的原則：用零售機（或最終出貨的 build）測試，不做特殊版本。
總結：三個 Takeaway
-
Audio Linkage 是 Android 最大的結構性短板。 雖然最好的 Android 手機已能追平 iPhone，但整體離散度極大。如果你的平台涉及音頻反饋（遊戲、語音助手、即時互動），投資 AAudio MMAP + Audio HAL 調優的 ROI 最高。
-
系統級優化 > 白名單式優化。 不要走 Game Turbo 的路子。做好 SurfaceFlinger VSync 調優、Input 優先級、Audio 低延遲路徑，讓所有 App 都受益。
-
測試方法比測試結果更重要。 極客灣的價值不只是數據，而是他們的方法論：自購零售機、長時間壓力、多輪取均值 + 標準差、白名單對照測試。建立類似的內部 benchmark 流程，比追求某個數字更有意義。
極客灣的影片可能被封殺了，但他們揭露的問題不會因此消失。作為 OS 開發者，我們能做的是把這些洞察轉化為更好的系統設計。
相關文章：
參考資料：
- AOSP Audio Latency Documentation
- Android Low Latency Audio (Oboe)
- Android Graphics Pipeline
- Android Frame Pacing Library