1. 從“感知流暢”到“精準(zhǔn)控制”Android 10 屏幕刷新率管理的范式轉(zhuǎn)變?nèi)绻阍?019年之后才開始接觸Android開發(fā)可能覺得在App里設(shè)置一個(gè)高刷新率是件理所當(dāng)然的事。但往前倒幾年在Android 10代號Android Q發(fā)布之前這件事充滿了不確定性。開發(fā)者能做的往往只是在清單文件里聲明一個(gè)模糊的“高性能”需求然后把控制權(quán)完全交給系統(tǒng)和OEM廠商祈禱自己的游戲或視頻應(yīng)用能在高刷屏上跑滿幀。結(jié)果呢應(yīng)用可能跑在90Hz也可能被鎖在60Hz甚至出現(xiàn)令人頭疼的幀率撕裂和功耗激增。這種“黑盒”體驗(yàn)對于追求極致流暢和能效的應(yīng)用來說無疑是場噩夢。Android 10引入的這套新的屏幕刷新率Display Refresh Rate切換API正是為了解決這個(gè)核心痛點(diǎn)。它標(biāo)志著Android系統(tǒng)在顯示管理上從“系統(tǒng)全局粗略管控”轉(zhuǎn)向了“應(yīng)用場景化精細(xì)調(diào)度”。簡單來說它把“何時(shí)用何種刷新率”的部分決策權(quán)以一種更安全、更可控的方式交還給了應(yīng)用開發(fā)者。這不僅僅是多了一個(gè)setRefreshRate的API調(diào)用那么簡單其背后是一整套關(guān)于顯示管道、表面緩沖區(qū)SurfaceFlinger和功耗管理的復(fù)雜協(xié)同邏輯。理解這套機(jī)制不僅能讓你在支持高刷新率的設(shè)備上榨干每一幀的性能更能讓你避免因?yàn)E用高刷新率而導(dǎo)致的續(xù)航“血崩”。接下來我們就深入這套機(jī)制的內(nèi)核看看Google是如何設(shè)計(jì)這套“帶著鐐銬跳舞”的自由度。2. 核心機(jī)制解析Display.Mode與DisplayManager的協(xié)同在Android 10之前應(yīng)用與屏幕刷新率的交互是間接且無力的。Android 10通過擴(kuò)展android.view.Display和android.hardware.display.DisplayManager這兩個(gè)核心類建立了一套標(biāo)準(zhǔn)化的刷新率協(xié)商機(jī)制。2.1Display.Mode刷新率信息的標(biāo)準(zhǔn)化容器Display.Mode類是這個(gè)新體系的基礎(chǔ)單元。它封裝了顯示模式的幾個(gè)關(guān)鍵屬性getModeId(): 模式的唯一標(biāo)識符由系統(tǒng)分配。getPhysicalWidth()/getPhysicalHeight(): 該模式對應(yīng)的物理分辨率。getRefreshRate():核心屬性返回該模式的刷新率單位是赫茲Hz。這是一個(gè)浮點(diǎn)數(shù)可以精確表示如59.94Hz、90.015Hz等非整數(shù)刷新率。系統(tǒng)會(huì)通過Display.getSupportedModes()返回一個(gè)Display.Mode數(shù)組列出了當(dāng)前顯示設(shè)備通常是主屏幕支持的所有顯示模式。一個(gè)典型的列表可能如下所示模式ID (示例)分辨率刷新率 (Hz)常見場景11080x234060.0默認(rèn)、省電模式21080x234090.0高刷新率模式31080x2340120.0極致流暢模式部分游戲這里有一個(gè)非常重要的細(xì)節(jié)同一個(gè)物理分辨率可能對應(yīng)多個(gè)不同的刷新率。這意味著切換刷新率通常不需要改變分辨率避免了因分辨率切換導(dǎo)致的短暫黑屏或畫面拉伸體驗(yàn)更加無縫。2.2DisplayManager全局調(diào)度與模式切換的執(zhí)行者獲取了支持的刷新率列表后如何申請切換呢這就是DisplayManager的職責(zé)所在。你需要通過Context.getSystemService(Context.DISPLAY_SERVICE)獲取DisplayManager實(shí)例。核心方法是DisplayManager.setGlobalDisplayMode(int displayId, Display.Mode mode, int callbackId)。這個(gè)方法的名字就揭示了其設(shè)計(jì)哲學(xué)“全局”和“模式”。全局性當(dāng)你為一個(gè)應(yīng)用窗口請求一個(gè)刷新率模式時(shí)這個(gè)請求會(huì)影響整個(gè)屏幕的刷新率。這是出于硬件限制的考量——絕大多數(shù)移動(dòng)設(shè)備的顯示面板在同一時(shí)間只能運(yùn)行在一個(gè)固定的刷新率下。因此Android 10的API設(shè)計(jì)是“應(yīng)用提議系統(tǒng)裁決”。系統(tǒng)會(huì)綜合考慮所有前臺、后臺應(yīng)用的請求通過后面要講的Window設(shè)置以及電源、熱限制等因素最終決定一個(gè)全局最優(yōu)的刷新率。模式切換你傳遞的是一個(gè)完整的Display.Mode對象而不僅僅是刷新率數(shù)值。這要求你必須使用從Display.getSupportedModes()中獲取的、系統(tǒng)明確支持的模式對象。直接new一個(gè)Display.Mode是無效的。注意雖然setGlobalDisplayMode是公開API但在實(shí)際應(yīng)用中Google更推薦通過Window屬性來設(shè)置見下文因?yàn)檫@能更好地與Activity生命周期和窗口狀態(tài)集成。直接使用DisplayManager進(jìn)行切換通常用于系統(tǒng)級應(yīng)用或特殊場景需要更精細(xì)的生命周期管理。2.3 刷新率切換的底層信號流理解高層API后我們看一眼底層發(fā)生了什么。這有助于排查那些“設(shè)置了但沒生效”的詭異問題。應(yīng)用請求應(yīng)用通過Window.setPreferredDisplayModeId()或DisplayManager.setGlobalDisplayMode()發(fā)起請求。SurfaceFlinger 仲裁作為Android顯示系統(tǒng)的核心合成器SurfaceFlinger會(huì)收集所有可見層Layer的刷新率偏好。每個(gè)窗口對應(yīng)的Surface都可以攜帶一個(gè)刷新率偏好。策略決策SurfaceFlinger內(nèi)部或通過DisplayManagerService運(yùn)行一套策略算法。這套算法的默認(rèn)邏輯通常是選擇所有請求中數(shù)值最高的那個(gè)刷新率。例如前臺游戲請求90Hz后臺視頻播放器請求60Hz系統(tǒng)UI請求60Hz那么全局刷新率會(huì)被設(shè)置為90Hz。驅(qū)動(dòng)層通信決策結(jié)果通過HAL層Hardware Abstraction Layer傳遞到顯示驅(qū)動(dòng)Display Driver。硬件重同步驅(qū)動(dòng)會(huì)重新配置顯示面板的時(shí)序控制器Timing Controller改變其像素掃描頻率。這個(gè)過程通常會(huì)在垂直消隱區(qū)間VBlank進(jìn)行以避免屏幕撕裂因此你會(huì)看到刷新率切換是平滑的而不是瞬間跳變。這個(gè)鏈條中任何一個(gè)環(huán)節(jié)不匹配都可能導(dǎo)致切換失敗。比如你請求了一個(gè)Display.getSupportedModes()列表里不存在的模式請求會(huì)在步驟1或步驟2被過濾掉。3. 應(yīng)用層實(shí)踐通過Window屬性進(jìn)行場景化設(shè)置對于絕大多數(shù)應(yīng)用開發(fā)者直接與DisplayManager交互并非最佳實(shí)踐。Android 10提供了更優(yōu)雅、與組件生命周期綁定的方式——通過Window的屬性Attributes來設(shè)置刷新率偏好。3.1Window.setPreferredDisplayModeId(int modeId)這是最常用的方法。你可以在Activity的onCreate()或onResume()中調(diào)用Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Window window getWindow(); Display display window.getDecorView().getDisplay(); // 1. 獲取當(dāng)前顯示支持的所有模式 Display.Mode[] supportedModes display.getSupportedModes(); // 2. 遍歷尋找目標(biāo)刷新率模式例如90Hz int targetModeId -1; float targetRefreshRate 90.0f; for (Display.Mode mode : supportedModes) { // 通常我們保持當(dāng)前分辨率只切換刷新率 if (mode.getPhysicalWidth() display.getMode().getPhysicalWidth() mode.getPhysicalHeight() display.getMode().getPhysicalHeight() Math.abs(mode.getRefreshRate() - targetRefreshRate) 0.1) { targetModeId mode.getModeId(); break; } } // 3. 如果找到則設(shè)置偏好 if (targetModeId ! -1) { window.setPreferredDisplayModeId(targetModeId); } }關(guān)鍵點(diǎn)解析生命周期通過Window設(shè)置的偏好會(huì)隨著該窗口的可見性變化而自動(dòng)被系統(tǒng)納入或移出考量。當(dāng)你的Activity進(jìn)入后臺onPause其刷新率請求通常就不再影響全局決策。這比手動(dòng)在onPause/onResume中調(diào)用DisplayManager要可靠得多?！捌谩倍恰懊睢眘etPreferredDisplayModeId設(shè)置的是一個(gè)“偏好值”。系統(tǒng)會(huì)尊重它但最終決策權(quán)在系統(tǒng)。這防止了惡意應(yīng)用將刷新率鎖死在極高值而耗盡電量。模式ID的持久性modeId是硬件相關(guān)的在不同設(shè)備上同一個(gè)刷新率對應(yīng)的ID可能不同。絕對不要硬編碼一個(gè)modeId值。必須通過getSupportedModes()動(dòng)態(tài)查詢。3.2 在WindowManager.LayoutParams中設(shè)置你也可以通過修改WindowManager.LayoutParams的preferredDisplayModeId字段來達(dá)到相同效果這在某些動(dòng)態(tài)添加窗口的場景下更靈活。WindowManager.LayoutParams params getWindow().getAttributes(); params.preferredDisplayModeId targetModeId; getWindow().setAttributes(params);3.3 實(shí)戰(zhàn)中的注意事項(xiàng)與坑點(diǎn)在實(shí)際項(xiàng)目中直接套用上面的代碼可能會(huì)遇到一些問題。下面是我踩過坑后總結(jié)的經(jīng)驗(yàn)檢查API級別Window.setPreferredDisplayModeId()和相關(guān)的Display.ModeAPI 都是從API level 29Android 10開始引入的。在調(diào)用前務(wù)必進(jìn)行版本判斷。if (Build.VERSION.SDK_INT Build.VERSION_CODES.Q) { // 使用Android 10的刷新率API } else { // 回退方案例如使用舊版WindowManager.LayoutParams.preferredRefreshRate已廢棄 // 或者不進(jìn)行刷新率控制 }“支持”不等于“可用”getSupportedModes()返回的是硬件層面支持的模式。但設(shè)備制造商OEM可能出于功耗或穩(wěn)定性考慮在某些場景如低電量、高溫下禁用高刷新率模式。因此即使你成功設(shè)置了90Hz的modeId最終屏幕也可能運(yùn)行在60Hz。監(jiān)聽當(dāng)前實(shí)際刷新率至關(guān)重要// 可以定期檢查或在界面需要時(shí)檢查 Display.Mode currentMode display.getMode(); float currentRefreshRate currentMode.getRefreshRate(); Log.d(RefreshRate, 當(dāng)前實(shí)際刷新率: currentRefreshRate Hz);多窗口模式下的行為在分屏或多窗口模式下情況變得復(fù)雜。通常系統(tǒng)會(huì)選擇一個(gè)能兼顧所有可見窗口需求的刷新率往往是最高請求值。但你的應(yīng)用需要做好適配當(dāng)窗口尺寸變化時(shí)重新評估是否需要調(diào)整刷新率偏好。例如一個(gè)視頻播放器在全屏?xí)r可能需要匹配視頻幀率24/30/60Hz但在小窗模式下或許60Hz就足夠了。游戲引擎的特殊處理對于Unity、Unreal等游戲引擎它們通常有自己更底層的圖形渲染循環(huán)和顯示接口。在Android 10及以上設(shè)備它們可能會(huì)繞過WindowAPI直接通過NDK調(diào)用ANativeWindow或Choreographer相關(guān)接口來設(shè)置顯示速率。如果你在游戲項(xiàng)目中集成需要查閱引擎的官方文檔使用引擎提供的設(shè)置方法而不是直接調(diào)用Android SDK的API。4. 系統(tǒng)級策略與功耗管理的平衡藝術(shù)Android 10的刷新率管理并非讓應(yīng)用無節(jié)制地索取高刷新率。系統(tǒng)內(nèi)置了一套智能策略在流暢度和功耗之間尋找最佳平衡點(diǎn)。理解這些策略能幫助你的應(yīng)用表現(xiàn)得更好。4.1 系統(tǒng)默認(rèn)策略最高請求者獲勝如前所述SurfaceFlinger的默認(rèn)策略是選擇所有可見窗口中請求的最高刷新率。這保證了前臺最需要流暢度的應(yīng)用如游戲能得到滿足。但是系統(tǒng)UI如狀態(tài)欄、導(dǎo)航欄本身也會(huì)有一個(gè)基礎(chǔ)刷新率請求通常是60Hz或90Hz取決于設(shè)備默認(rèn)值。4.2 功耗與熱限制的介入這是最關(guān)鍵的限制因素。當(dāng)設(shè)備電池電量低、溫度過高時(shí)系統(tǒng)可能會(huì)完全禁用高刷新率模式強(qiáng)制所有應(yīng)用運(yùn)行在基礎(chǔ)刷新率如60Hz下。此時(shí)無論你的應(yīng)用如何請求display.getMode()返回的都將是低刷新率模式。開發(fā)建議對于強(qiáng)依賴高刷新率的應(yīng)用如競速游戲、繪圖軟件應(yīng)該監(jiān)聽系統(tǒng)的相關(guān)狀態(tài)如電源、溫度廣播并在UI上給予用戶適當(dāng)?shù)奶崾纠纭霸O(shè)備溫度較高已切換至節(jié)能模式以保持穩(wěn)定運(yùn)行”而不是讓用戶單純地感覺“變卡了”。4.3 動(dòng)態(tài)刷新率與可變刷新率VRR的雛形雖然Android 10的API主要還是針對“靜態(tài)”刷新率切換即切換后在一段時(shí)間內(nèi)保持固定值但其設(shè)計(jì)為未來的動(dòng)態(tài)刷新率如LTPO屏幕的1Hz-120Hz自適應(yīng)奠定了基礎(chǔ)。Display.Mode對象可以包含刷新率范圍等信息。在后續(xù)的Android版本如Android 12中Google進(jìn)一步引入了更精細(xì)的刷新率范圍設(shè)置API。在Android 10上你可以通過監(jiān)聽Display的變更來感知刷新率變化public class MyActivity extends Activity implements DisplayManager.DisplayListener { private DisplayManager mDisplayManager; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mDisplayManager (DisplayManager) getSystemService(Context.DISPLAY_SERVICE); mDisplayManager.registerDisplayListener(this, null); } Override public void onDisplayChanged(int displayId) { if (displayId Display.DEFAULT_DISPLAY) { Display display getDisplay(); float newRate display.getMode().getRefreshRate(); // 更新UI或調(diào)整渲染邏輯 runOnUiThread(() - updateUIForRefreshRate(newRate)); } } Override public void onDisplayAdded(int displayId) {} Override public void onDisplayRemoved(int displayId) {} Override protected void onDestroy() { super.onDestroy(); mDisplayManager.unregisterDisplayListener(this); } }4.4 與“峰值刷新率”和“智能刷新率”開關(guān)的兼容許多OEM廠商在設(shè)置中提供了“高刷新率”或“智能切換”開關(guān)。當(dāng)用戶選擇“智能刷新率”時(shí)系統(tǒng)可能會(huì)采用更激進(jìn)的降頻策略例如在靜態(tài)圖片、閱讀場景下自動(dòng)降低到60Hz甚至更低。此時(shí)即使你的應(yīng)用請求了90Hz系統(tǒng)也可能不予采納。應(yīng)對策略作為開發(fā)者我們應(yīng)尊重系統(tǒng)的全局能效策略。你的應(yīng)用應(yīng)該設(shè)置一個(gè)“合理的”偏好而不是“最高的”偏好。例如一個(gè)閱讀類應(yīng)用在翻頁動(dòng)畫時(shí)可以請求90Hz以獲得流暢的翻頁效果但在靜止閱讀時(shí)則不需要主動(dòng)請求交由系統(tǒng)智能調(diào)度即可。這需要結(jié)合Choreographer來感知用戶的交互狀態(tài)動(dòng)態(tài)調(diào)整請求。5. 性能優(yōu)化與調(diào)試指南正確地使用刷新率API不僅能提升體驗(yàn)還能避免性能反噬。下面是一些優(yōu)化和調(diào)試的實(shí)戰(zhàn)技巧。5.1 匹配內(nèi)容幀率避免無效渲染最嚴(yán)重的浪費(fèi)是“渲染了但沒顯示”。如果你的應(yīng)用內(nèi)容幀率如游戲邏輯幀、視頻播放幀是30 FPS但你卻讓屏幕運(yùn)行在120Hz。那么屏幕每刷新一次有3/4的時(shí)間是在顯示重復(fù)的幀這純粹浪費(fèi)了GPU、CPU和屏幕的功耗。最佳實(shí)踐是匹配幀率游戲?qū)indow.setPreferredDisplayModeId()設(shè)置的刷新率與游戲引擎的目標(biāo)幀率如Application.targetFrameRatein Unity保持一致。視頻播放使用MediaPlayer或ExoPlayer時(shí)可以獲取視頻流的幀率如23.976, 29.97, 59.94 Hz然后選擇系統(tǒng)支持的最接近的刷新率模式進(jìn)行設(shè)置。這能帶來更平滑的播放體驗(yàn)減少因幀率不匹配導(dǎo)致的抖動(dòng)Judder。5.2 使用Choreographer監(jiān)測幀生成Choreographer是協(xié)調(diào)動(dòng)畫、輸入和繪制時(shí)序的核心類。你可以通過它來監(jiān)測你的應(yīng)用是否跟得上當(dāng)前的刷新率。public class FrameRateMonitor { private Choreographer mChoreographer; private long mLastFrameTimeNanos 0; public void start() { mChoreographer Choreographer.getInstance(); mChoreographer.postFrameCallback(new Choreographer.FrameCallback() { Override public void doFrame(long frameTimeNanos) { if (mLastFrameTimeNanos ! 0) { long frameIntervalNanos frameTimeNanos - mLastFrameTimeNanos; double currentFps 1_000_000_000.0 / frameIntervalNanos; // 記錄或上報(bào)當(dāng)前FPS與display.getRefreshRate()對比 if (currentFps display.getRefreshRate() * 0.8) { // 應(yīng)用掉幀了需要優(yōu)化 } } mLastFrameTimeNanos frameTimeNanos; mChoreographer.postFrameCallback(this); // 注冊下一幀回調(diào) } }); } }如果監(jiān)測到應(yīng)用的穩(wěn)定幀率遠(yuǎn)低于屏幕刷新率你就應(yīng)該考慮降低申請的刷新率偏好或者優(yōu)化渲染性能。5.3 ADB調(diào)試命令在開發(fā)和調(diào)試階段ADB命令是無價(jià)之寶。查看當(dāng)前顯示信息adb shell dumpsys display | grep -A 10 -B 5 mSupportedModes\|current mode這個(gè)命令會(huì)輸出當(dāng)前顯示支持的所有模式以及當(dāng)前正在使用的模式非常直觀。模擬系統(tǒng)限制需要root或工程模式 有些設(shè)備可以通過ADB命令強(qiáng)制設(shè)置最大刷新率用于測試應(yīng)用在低刷新率下的表現(xiàn)。# 此命令因設(shè)備而異并非標(biāo)準(zhǔn)命令 adb shell settings put system peak_refresh_rate 60.0注意這類命令不是官方API高度依賴OEM實(shí)現(xiàn)且可能需要特定權(quán)限。監(jiān)控SurfaceFlinger狀態(tài)adb shell dumpsys SurfaceFlinger | grep refresh rate可以查看SurfaceFlinger內(nèi)部記錄的各層Layer的刷新率請求和最終合成的刷新率。5.4 功耗評估高刷新率帶來的功耗提升是線性的嗎并不完全是。功耗主要來自兩部分屏幕本身更高的刷新率意味著像素單元更頻繁地充電和放電這部分功耗增加幾乎是線性的。SoC處理器為了驅(qū)動(dòng)更高的幀率GPU和CPU需要更努力地工作。但如果你的應(yīng)用內(nèi)容幀率本身沒有提升例如UI動(dòng)畫還是60FPS那么SoC的額外功耗可能很小。建議在性能測試中除了關(guān)注幀率和流暢度一定要加入功耗測試項(xiàng)。使用電池統(tǒng)計(jì)工具或功耗儀對比你的應(yīng)用在60Hz和90Hz模式下的整機(jī)功耗差異。如果開啟高刷新率后用戶體驗(yàn)提升不明顯但功耗顯著增加就需要重新評估策略。6. 向后兼容與未來演進(jìn)6.1 在Android 10以下版本的兼容方案對于需要支持Android 10以下版本的應(yīng)用可以采用條件編譯和回退策略。檢查可用性使用Build.VERSION.SDK_INT進(jìn)行版本判斷。回退到舊API在API level 21-28之間可以使用WindowManager.LayoutParams.preferredRefreshRate字段這是一個(gè)浮點(diǎn)數(shù)。但請注意這個(gè)API已被廢棄且效果遠(yuǎn)不如Android 10的新API可靠它只是一個(gè)“建議值”很多OEM廠商的定制系統(tǒng)會(huì)忽略它。功能降級最務(wù)實(shí)的方案是在舊版本上不主動(dòng)進(jìn)行任何刷新率控制完全交由系統(tǒng)管理。同時(shí)確保你的應(yīng)用在60Hz下也能提供良好的基礎(chǔ)體驗(yàn)。6.2 面向Android 12及更高版本Android 12引入了更強(qiáng)大的Window.setFrameRate()API它允許你指定一個(gè)精確的幀率不一定等于顯示刷新率。指定一個(gè)幀率兼容性策略如FRAME_RATE_COMPATIBILITY_DEFAULT,FRAME_RATE_COMPATIBILITY_FIXED_SOURCE告訴系統(tǒng)當(dāng)你的內(nèi)容幀率與顯示刷新率不匹配時(shí)該如何處理例如是否啟用垂直同步V-Sync。這對于視頻播放和游戲是巨大的改進(jìn)能實(shí)現(xiàn)真正的可變刷新率VRR體驗(yàn)。如果你的應(yīng)用minSdkVersion已經(jīng)可以設(shè)到31Android 12應(yīng)該優(yōu)先使用這套新的幀率API。對于仍需兼容Android 10/11的應(yīng)用可以構(gòu)建一個(gè)封裝類根據(jù)版本動(dòng)態(tài)調(diào)用不同的API。我個(gè)人在多個(gè)高刷新率適配項(xiàng)目中的體會(huì)是Android 10的這套API是一個(gè)重要的分水嶺它給了開發(fā)者一個(gè)標(biāo)準(zhǔn)化的“對話”渠道。但真正用好它關(guān)鍵在于理解其“協(xié)商”而非“命令”的本質(zhì)并時(shí)刻將用戶體驗(yàn)流暢度與系統(tǒng)健康功耗、發(fā)熱的平衡放在首位。盲目追求最高刷新率數(shù)字往往不如在恰當(dāng)?shù)臅r(shí)機(jī)提供穩(wěn)定的幀率來得實(shí)在。在實(shí)現(xiàn)功能后花時(shí)間在不同品牌、不同型號的設(shè)備上進(jìn)行充分的兼容性測試和功耗評估是保證功能上線后不引發(fā)用戶投訴的關(guān)鍵一步。