1. 从“感知流畅”到“精准控制”：Android 10 屏幕刷新率管理的范式转变

如果你在2019年之后才开始接触Android开发，可能觉得在App里设置一个高刷新率是件理所当然的事。但往前倒几年，在Android 10（代号Android Q）发布之前，这件事充满了不确定性。开发者能做的，往往只是在清单文件里声明一个模糊的“高性能”需求，然后把控制权完全交给系统和OEM厂商，祈祷自己的游戏或视频应用能在高刷屏上跑满帧。结果呢？应用可能跑在90Hz，也可能被锁在60Hz，甚至出现令人头疼的帧率撕裂和功耗激增。这种“黑盒”体验，对于追求极致流畅和能效的应用来说，无疑是场噩梦。

Android 10引入的这套新的屏幕刷新率（Display Refresh Rate）切换API，正是为了解决这个核心痛点。它标志着Android系统在显示管理上，从“系统全局粗略管控”转向了“应用场景化精细调度”。简单来说，它把“何时用何种刷新率”的部分决策权，以一种更安全、更可控的方式，交还给了应用开发者。这不仅仅是多了一个setRefreshRate的API调用那么简单，其背后是一整套关于显示管道、表面缓冲区（SurfaceFlinger）和功耗管理的复杂协同逻辑。理解这套机制，不仅能让你在支持高刷新率的设备上榨干每一帧的性能，更能让你避免因滥用高刷新率而导致的续航“血崩”。接下来，我们就深入这套机制的内核，看看Google是如何设计这套“带着镣铐跳舞”的自由度。

2. 核心机制解析：Display.Mode与DisplayManager的协同

在Android 10之前，应用与屏幕刷新率的交互是间接且无力的。Android 10通过扩展android.view.Display和android.hardware.display.DisplayManager这两个核心类，建立了一套标准化的刷新率协商机制。

2.1Display.Mode：刷新率信息的标准化容器

Display.Mode类是这个新体系的基础单元。它封装了显示模式的几个关键属性：

• getModeId(): 模式的唯一标识符，由系统分配。
• getPhysicalWidth()/getPhysicalHeight(): 该模式对应的物理分辨率。
• getRefreshRate():核心属性，返回该模式的刷新率，单位是赫兹（Hz）。这是一个浮点数，可以精确表示如59.94Hz、90.015Hz等非整数刷新率。

系统会通过Display.getSupportedModes()返回一个Display.Mode数组，列出了当前显示设备（通常是主屏幕）支持的所有显示模式。一个典型的列表可能如下所示：

这里有一个非常重要的细节：同一个物理分辨率可能对应多个不同的刷新率。这意味着切换刷新率通常不需要改变分辨率，避免了因分辨率切换导致的短暂黑屏或画面拉伸，体验更加无缝。

2.2DisplayManager：全局调度与模式切换的执行者

获取了支持的刷新率列表后，如何申请切换呢？这就是DisplayManager的职责所在。你需要通过Context.getSystemService(Context.DISPLAY_SERVICE)获取DisplayManager实例。

核心方法是DisplayManager.setGlobalDisplayMode(int displayId, Display.Mode mode, int callbackId)。这个方法的名字就揭示了其设计哲学：“全局”和“模式”。

• 全局性：当你为一个应用窗口请求一个刷新率模式时，这个请求会影响整个屏幕的刷新率。这是出于硬件限制的考量——绝大多数移动设备的显示面板在同一时间只能运行在一个固定的刷新率下。因此，Android 10的API设计是“应用提议，系统裁决”。系统会综合考虑所有前台、后台应用的请求（通过后面要讲的Window设置），以及电源、热限制等因素，最终决定一个全局最优的刷新率。
• 模式切换：你传递的是一个完整的Display.Mode对象，而不仅仅是刷新率数值。这要求你必须使用从Display.getSupportedModes()中获取的、系统明确支持的模式对象。直接new一个Display.Mode是无效的。

注意：虽然setGlobalDisplayMode是公开API，但在实际应用中，Google更推荐通过Window属性来设置（见下文），因为这能更好地与Activity生命周期和窗口状态集成。直接使用DisplayManager进行切换，通常用于系统级应用或特殊场景，需要更精细的生命周期管理。

2.3 刷新率切换的底层信号流

理解高层API后，我们看一眼底层发生了什么。这有助于排查那些“设置了但没生效”的诡异问题。

1. 应用请求：应用通过Window.setPreferredDisplayModeId()或DisplayManager.setGlobalDisplayMode()发起请求。
2. SurfaceFlinger 仲裁：作为Android显示系统的核心合成器，SurfaceFlinger会收集所有可见层（Layer）的刷新率偏好。每个窗口对应的Surface都可以携带一个刷新率偏好。
3. 策略决策：SurfaceFlinger内部（或通过DisplayManagerService）运行一套策略算法。这套算法的默认逻辑通常是：选择所有请求中数值最高的那个刷新率。例如，前台游戏请求90Hz，后台视频播放器请求60Hz，系统UI请求60Hz，那么全局刷新率会被设置为90Hz。
4. 驱动层通信：决策结果通过HAL层（Hardware Abstraction Layer）传递到显示驱动（Display Driver）。
5. 硬件重同步：驱动会重新配置显示面板的时序控制器（Timing Controller），改变其像素扫描频率。这个过程通常会在垂直消隐区间（VBlank）进行，以避免屏幕撕裂，因此你会看到刷新率切换是平滑的，而不是瞬间跳变。

这个链条中任何一个环节不匹配，都可能导致切换失败。比如，你请求了一个Display.getSupportedModes()列表里不存在的模式，请求会在步骤1或步骤2被过滤掉。

3. 应用层实践：通过Window属性进行场景化设置

对于绝大多数应用开发者，直接与DisplayManager交互并非最佳实践。Android 10提供了更优雅、与组件生命周期绑定的方式——通过Window的属性（Attributes）来设置刷新率偏好。

3.1Window.setPreferredDisplayModeId(int modeId)

这是最常用的方法。你可以在Activity的onCreate()或onResume()中调用：

@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Window window = getWindow(); Display display = window.getDecorView().getDisplay(); // 1. 获取当前显示支持的所有模式 Display.Mode[] supportedModes = display.getSupportedModes(); // 2. 遍历寻找目标刷新率模式（例如90Hz） int targetModeId = -1; float targetRefreshRate = 90.0f; for (Display.Mode mode : supportedModes) { // 通常我们保持当前分辨率，只切换刷新率 if (mode.getPhysicalWidth() == display.getMode().getPhysicalWidth() && mode.getPhysicalHeight() == display.getMode().getPhysicalHeight() && Math.abs(mode.getRefreshRate() - targetRefreshRate) < 0.1) { targetModeId = mode.getModeId(); break; } } // 3. 如果找到，则设置偏好 if (targetModeId != -1) { window.setPreferredDisplayModeId(targetModeId); } }

关键点解析：

• 生命周期：通过Window设置的偏好，会随着该窗口的可见性变化而自动被系统纳入或移出考量。当你的Activity进入后台（onPause），其刷新率请求通常就不再影响全局决策。这比手动在onPause/onResume中调用DisplayManager要可靠得多。
• “偏好”而非“命令”：setPreferredDisplayModeId设置的是一个“偏好值”。系统会尊重它，但最终决策权在系统。这防止了恶意应用将刷新率锁死在极高值而耗尽电量。
• 模式ID的持久性：modeId是硬件相关的，在不同设备上，同一个刷新率对应的ID可能不同。绝对不要硬编码一个modeId值。必须通过getSupportedModes()动态查询。

3.2 在WindowManager.LayoutParams中设置

你也可以通过修改WindowManager.LayoutParams的preferredDisplayModeId字段来达到相同效果，这在某些动态添加窗口的场景下更灵活。

WindowManager.LayoutParams params = getWindow().getAttributes(); params.preferredDisplayModeId = targetModeId; getWindow().setAttributes(params);

3.3 实战中的注意事项与坑点

在实际项目中，直接套用上面的代码可能会遇到一些问题。下面是我踩过坑后总结的经验：

1. 检查API级别：Window.setPreferredDisplayModeId()和相关的Display.ModeAPI 都是从API level 29（Android 10）开始引入的。在调用前务必进行版本判断。

   if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { // 使用Android 10+的刷新率API } else { // 回退方案：例如使用旧版`WindowManager.LayoutParams.preferredRefreshRate`（已废弃） // 或者不进行刷新率控制 }

2. “支持”不等于“可用”：getSupportedModes()返回的是硬件层面支持的模式。但设备制造商（OEM）可能出于功耗或稳定性考虑，在某些场景（如低电量、高温）下禁用高刷新率模式。因此，即使你成功设置了90Hz的modeId，最终屏幕也可能运行在60Hz。监听当前实际刷新率至关重要：

   // 可以定期检查，或在界面需要时检查 Display.Mode currentMode = display.getMode(); float currentRefreshRate = currentMode.getRefreshRate(); Log.d("RefreshRate", "当前实际刷新率: " + currentRefreshRate + " Hz");

3. 多窗口模式下的行为：在分屏或多窗口模式下，情况变得复杂。通常，系统会选择一个能兼顾所有可见窗口需求的刷新率（往往是最高请求值）。但你的应用需要做好适配，当窗口尺寸变化时，重新评估是否需要调整刷新率偏好。例如，一个视频播放器在全屏时可能需要匹配视频帧率（24/30/60Hz），但在小窗模式下，或许60Hz就足够了。

4. 游戏引擎的特殊处理：对于Unity、Unreal等游戏引擎，它们通常有自己更底层的图形渲染循环和显示接口。在Android 10及以上设备，它们可能会绕过WindowAPI，直接通过NDK调用ANativeWindow或Choreographer相关接口来设置显示速率。如果你在游戏项目中集成，需要查阅引擎的官方文档，使用引擎提供的设置方法，而不是直接调用Android SDK的API。

4. 系统级策略与功耗管理的平衡艺术

Android 10的刷新率管理，并非让应用无节制地索取高刷新率。系统内置了一套智能策略，在流畅度和功耗之间寻找最佳平衡点。理解这些策略，能帮助你的应用表现得更好。

4.1 系统默认策略：最高请求者获胜

如前所述，SurfaceFlinger的默认策略是选择所有可见窗口中请求的最高刷新率。这保证了前台最需要流畅度的应用（如游戏）能得到满足。但是，系统UI（如状态栏、导航栏）本身也会有一个基础刷新率请求（通常是60Hz或90Hz，取决于设备默认值）。

4.2 功耗与热限制的介入

这是最关键的限制因素。当设备电池电量低、温度过高时，系统可能会完全禁用高刷新率模式，强制所有应用运行在基础刷新率（如60Hz）下。此时，无论你的应用如何请求，display.getMode()返回的都将是低刷新率模式。

开发建议：对于强依赖高刷新率的应用（如竞速游戏、绘图软件），应该监听系统的相关状态（如电源、温度广播），并在UI上给予用户适当的提示，例如：“设备温度较高，已切换至节能模式以保持稳定运行”，而不是让用户单纯地感觉“变卡了”。

4.3 动态刷新率与可变刷新率（VRR）的雏形

虽然Android 10的API主要还是针对“静态”刷新率切换（即切换后在一段时间内保持固定值），但其设计为未来的动态刷新率（如LTPO屏幕的1Hz-120Hz自适应）奠定了基础。Display.Mode对象可以包含刷新率范围等信息。在后续的Android版本（如Android 12）中，Google进一步引入了更精细的刷新率范围设置API。

在Android 10上，你可以通过监听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或调整渲染逻辑 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 与“峰值刷新率”和“智能刷新率”开关的兼容

许多OEM厂商在设置中提供了“高刷新率”或“智能切换”开关。当用户选择“智能刷新率”时，系统可能会采用更激进的降频策略，例如在静态图片、阅读场景下自动降低到60Hz甚至更低。此时，即使你的应用请求了90Hz，系统也可能不予采纳。

应对策略：作为开发者，我们应尊重系统的全局能效策略。你的应用应该设置一个“合理的”偏好，而不是“最高的”偏好。例如，一个阅读类应用，在翻页动画时可以请求90Hz以获得流畅的翻页效果，但在静止阅读时，则不需要主动请求，交由系统智能调度即可。这需要结合Choreographer来感知用户的交互状态，动态调整请求。

5. 性能优化与调试指南

正确地使用刷新率API，不仅能提升体验，还能避免性能反噬。下面是一些优化和调试的实战技巧。

5.1 匹配内容帧率：避免无效渲染

最严重的浪费是“渲染了但没显示”。如果你的应用内容帧率（如游戏逻辑帧、视频播放帧）是30 FPS，但你却让屏幕运行在120Hz。那么屏幕每刷新一次，有3/4的时间是在显示重复的帧，这纯粹浪费了GPU、CPU和屏幕的功耗。

最佳实践是匹配帧率：

• 游戏：将Window.setPreferredDisplayModeId()设置的刷新率与游戏引擎的目标帧率（如Application.targetFrameRatein Unity）保持一致。
• 视频播放：使用MediaPlayer或ExoPlayer时，可以获取视频流的帧率（如23.976, 29.97, 59.94 Hz），然后选择系统支持的最接近的刷新率模式进行设置。这能带来更平滑的播放体验，减少因帧率不匹配导致的抖动（Judder）。

5.2 使用Choreographer监测帧生成

Choreographer是协调动画、输入和绘制时序的核心类。你可以通过它来监测你的应用是否跟得上当前的刷新率。

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; // 记录或上报当前FPS，与display.getRefreshRate()对比 if (currentFps < display.getRefreshRate() * 0.8) { // 应用掉帧了，需要优化 } } mLastFrameTimeNanos = frameTimeNanos; mChoreographer.postFrameCallback(this); // 注册下一帧回调 } }); } }

如果监测到应用的稳定帧率远低于屏幕刷新率，你就应该考虑降低申请的刷新率偏好，或者优化渲染性能。

5.3 ADB调试命令

在开发和调试阶段，ADB命令是无价之宝。

• 查看当前显示信息：

  adb shell dumpsys display | grep -A 10 -B 5 "mSupportedModes\|current mode"

  这个命令会输出当前显示支持的所有模式以及当前正在使用的模式，非常直观。

• 模拟系统限制（需要root或工程模式）： 有些设备可以通过ADB命令强制设置最大刷新率，用于测试应用在低刷新率下的表现。

  # 此命令因设备而异，并非标准命令 adb shell settings put system peak_refresh_rate 60.0

  注意：这类命令不是官方API，高度依赖OEM实现，且可能需要特定权限。

• 监控SurfaceFlinger状态：

  adb shell dumpsys SurfaceFlinger | grep "refresh rate"

  可以查看SurfaceFlinger内部记录的各层（Layer）的刷新率请求和最终合成的刷新率。

5.4 功耗评估

高刷新率带来的功耗提升是线性的吗？并不完全是。功耗主要来自两部分：

1. 屏幕本身：更高的刷新率意味着像素单元更频繁地充电和放电，这部分功耗增加几乎是线性的。
2. SoC（处理器）：为了驱动更高的帧率，GPU和CPU需要更努力地工作。但如果你的应用内容帧率本身没有提升（例如UI动画还是60FPS），那么SoC的额外功耗可能很小。

建议：在性能测试中，除了关注帧率和流畅度，一定要加入功耗测试项。使用电池统计工具或功耗仪，对比你的应用在60Hz和90Hz模式下的整机功耗差异。如果开启高刷新率后，用户体验提升不明显但功耗显著增加，就需要重新评估策略。

6. 向后兼容与未来演进

6.1 在Android 10以下版本的兼容方案

对于需要支持Android 10以下版本的应用，可以采用条件编译和回退策略。

• 检查可用性：使用Build.VERSION.SDK_INT进行版本判断。
• 回退到旧API：在API level 21-28之间，可以使用WindowManager.LayoutParams.preferredRefreshRate字段（这是一个浮点数）。但请注意，这个API已被废弃，且效果远不如Android 10的新API可靠，它只是一个“建议值”，很多OEM厂商的定制系统会忽略它。
• 功能降级：最务实的方案是，在旧版本上不主动进行任何刷新率控制，完全交由系统管理。同时，确保你的应用在60Hz下也能提供良好的基础体验。

6.2 面向Android 12及更高版本

Android 12引入了更强大的Window.setFrameRate()API，它允许你：

• 指定一个精确的帧率（不一定等于显示刷新率）。
• 指定一个帧率兼容性策略（如FRAME_RATE_COMPATIBILITY_DEFAULT,FRAME_RATE_COMPATIBILITY_FIXED_SOURCE），告诉系统当你的内容帧率与显示刷新率不匹配时该如何处理（例如是否启用垂直同步V-Sync）。
• 这对于视频播放和游戏是巨大的改进，能实现真正的可变刷新率（VRR）体验。

如果你的应用minSdkVersion已经可以设到31（Android 12），应该优先使用这套新的帧率API。对于仍需兼容Android 10/11的应用，可以构建一个封装类，根据版本动态调用不同的API。

我个人在多个高刷新率适配项目中的体会是，Android 10的这套API是一个重要的分水岭，它给了开发者一个标准化的“对话”渠道。但真正用好它，关键在于理解其“协商”而非“命令”的本质，并时刻将用户体验（流畅度）与系统健康（功耗、发热）的平衡放在首位。盲目追求最高刷新率数字，往往不如在恰当的时机提供稳定的帧率来得实在。在实现功能后，花时间在不同品牌、不同型号的设备上进行充分的兼容性测试和功耗评估，是保证功能上线后不引发用户投诉的关键一步。