本文禁止转载，如有需求，请联系作者。
1. 屏幕刷新率和应用的显示帧率首先请区分好屏幕刷新率(Panel Refresh Rate)和应用的帧率(APP Frame Rate)两个概念。
屏幕刷新率是显示器（LCD/OLED等）的硬件性能参数，即它每秒钟能刷新几幅画面，一般用物理单位Hz来表示。我们知道显示器的面板始由物理像素铺满的。比如目前的手机屏幕，主流是1080P的分辨率，那么就是1080*1920个像素点，即每行1080个像素，每列1920个像素。我们一般把显示器画完一行的1080个像素叫做行扫描，把1920行全部画完叫做场扫描，把开始扫描一行的物理信号叫做水平同步信号（HSYNC），把开始扫描一场的物理信号叫做垂直同步信号（VSYNC）。这里的VSYNC就是跟我们要讲的屏幕刷新率直接相关的了。显示器每秒钟能画完几场，就会有多少个VSYNC信号，称为场频，也就是屏幕的刷新率是多少。比如目前大部分手机屏幕的刷新率是60Hz，也就意味着它们每秒钟产生60个VSYNC信号。进而又衍生出另一个概念即场同步周期（vsync period），对于60Hz刷新率的屏幕来说，vsync period就是1000/60=16.6ms。
那什么是应用显示帧率呢？可以认为它是应用画图的速度，一般用fps（frames per second）来表示。比如在微信的聊天界面上下滑动屏幕，微信界面的聊天内容也跟随我们的手指上下移动。假设我们正好要在一秒内往上移动一屏的内容，那么这一屏的内容移动过程在一秒内更新了多少次，是微信应用开发者可以控制的。如果一秒内只更新两三次，你会看到明显的画面丁顿，而如果更新24次以上，你一般就感觉不到卡顿，除非你不是人，是神：）这里应用更新界面的次数，或者应用画图的次数，我们可以理解为应用的显示帧率。当然应用的显示帧率不是越快越好，超过了屏幕刷新率，系统还要做pulldown，反而增加系统的负担。而且应用显示帧率是一个动态的量，因为应用界面并不是总是在变化，当你看新闻的时候，不拖动屏幕，那么显示内容是静态的，当你看一个动画的时候，这个动画的源文件可能是15fps的，也可能是30fps的，也会影响到应用显示帧率。
2. 应用程序(app)与刷新率(refresh rate)上面我们讲了屏幕刷新率和应用显示帧率的概念。现在来看在应用显示设计中，他们的关系。
在应用开发特别是游戏的设计中，有时候对屏幕刷新率是很敏感的。
这里有几个数据，在60Hz刷新率时，场同步周期(vsync period)是1000/60=16.6ms；而在90Hz刷新率时，场同步周期变成1000/90=11.1ms。也就是说，如果应用想要达到跟刷新率相同的显示帧率，在60Hz的时候，他只要在16.6毫秒内画完一幅图就行，而如果想在90Hz刷新率时跟上屏幕刷新率的话，它就只有11.1毫秒的画图时间了。很显然对于动画或界面比较复杂的应用来说，如果在60Hz的时候已经比较吃力的话，在90Hz的时候就必须调整自己的画图方式和步骤，优化自己的效率。从另一个角度看，原来应用程序画动画的时候，只要是能跟60Hz的分频频率合拍（比如15/20/30/...fps），就能保证不会产生抖动(jitter)。但是，如果Android设备运行在90Hz刷新率的话，则合适的数字变成（15/30/45/...）。也就是说，如果应用开发工程师以20fps画图的话，在90Hz刷新率的时候是不合适的，会造成抖动。这就需要应开开发工程师知道Android设备的屏幕刷新率，并根据屏幕刷新率来调整自己的画图速度。或者，实在没办法的话，想办法让设备把屏幕刷新率改成合适的那个。
以前，因为绝大部分Android设备屏幕的显示屏都是60Hz的刷新率，所以游戏开发工程师都会假设他们的应用是运行在60Hz的设备上，从而以在60Hz的刷新率下流畅运行作为开发目标，游戏动画的设计也理论上要求以60的倍频或者分频来设计，比如15/20/30/60/120fps，这样在手机上render的时候正好扣紧vsync的鼓点而不会造成抖动。所以应用设计者不会关心手机的屏幕刷新率是否会改变。但是随着手机屏幕硬件的不断升级，新的机型越来越多的开始支持更高的刷新率，比如90/120Hz。如果这时候仍然按照以前的开发经验来设计应用的话，一来无法体现高刷新率屏幕的优势，二来因为刷新率提升导致vsync period画图时间缩短，可能出现掉帧的情况。
为了跟上技术的更新，应用开发工程师需要从以下4点来优化自己的代码(可参考“多屏幕刷新率(refresh rate)模式下的帧显示流水线”一文)：
1. 想办法提升画图的效率，保证在更短的vsync period中画完一幅图，可以引入并行线程；
2. 增加自己的render pipe line；
3. 监测设备屏幕刷新率的变化，根据刷新率的变化调整应用的画图速度；
4. 调用系统接口改变设备的刷新率（如果设备支持的话）。
对于屏幕刷新率只有一个的Android设备，应用的适配相对简单。只要使用Display.getSupportedModes获取设备的刷新率，然后做适配就行。对于支持多个屏幕刷新率的设备，在Android Q上对目前对屏幕刷新率的接口较少。可以使用displayListener或注册回调来获取，或者通过WindowManager.LayoutParams.preferredDisplayModeId来控制。Google在Pixel 4上实现了自动的屏幕刷新率切换，可以根据场景变化在60Hz和90Hz之间自适应的切换。
如果只是想熟悉，可以试试下面的命令来看看不同刷新率下的效果。它并不是把刷新率固定在某个值，只是限定了最高刷新率。如果想同时体验固定帧率和自动帧率，可以参考的手机型号有Motorola Edge和Nubia Red Magic 3。
adb shell settings put system peak_refresh_rate 90.0/60.0
3. Framework层的刷新率接口和策略Google已经在Android Q(10.0)上实现了对屏幕刷新率的操控策略，代码主要在DisplayManagerService和SurfaceFlinger，一个是Java层，一个是native层。
3.1 Java层相关代码DisplayManagerService通过DisplayModeDirector来管理屏幕刷新率。当系统启动ready的时候，DisplayModeDirector会注册。
frameworks/base/services/core/java/com/android/server/display/DisplayManagerService.java
447
450 public void systemReady(boolean safeMode, boolean onlyCore) {
451 synchronized (mSyncRoot) {
452 mSafeMode = safeMode;
453 mOnlyCore = onlyCore;
454 mSystemReady = true;
455 // Just in case the top inset changed before the system was ready. At this point, any
456 // relevant configuration should be in place.
457 recordTopInsetLocked(mLogicalDisplays.get(Display.DEFAULT_DISPLAY));
458 }
459
460 mDisplayModeDirector.setListener(new AllowedDisplayModeObserver());
461 mDisplayModeDirector.start();
462
463 mHandler.sendEmptyMessage(MSG_REGISTER_ADDITIONAL_DISPLAY_ADAPTERS);
464 }
而DisplayModeDirector会通过mSettingsObserver和mDisplayObserver两个观察哨来监测setting中用户操作对刷新率的改变和设备显示硬件的变动（比如第二块显示屏幕，或者外接了显示设备，投影等）导致的刷新率改变。
84 public DisplayModeDirector(@NonNull Context context, @NonNull Handler handler) {
85 mContext = context;
86 mHandler = new DisplayModeDirectorHandler(handler.getLooper());
87 mVotesByDisplay = new SparseArray();
88 mSupportedModesByDisplay = new SparseArray();
89 mDefaultModeByDisplay = new SparseArray();
90 mAppRequestObserver = new AppRequestObserver();
91 mSettingsObserver = new SettingsObserver(context, handler);
92 mDisplayObserver = new DisplayObserver(context, handler);
93 }
SettingObserver的onChange处理函数，和DisplayObserver的onDisplayAdded/onDisplayRemoved/onDisplayChanged处理函数，就是监测setting中用户的操作，和设备显示硬件变化的。
540 public void onChange(boolean selfChange, Uri uri, int userId) {
541 synchronized (mLock) {
543 if (mRefreshRateSetting.equals(uri)) {
545 updateRefreshRateSettingLocked();
546 } else if (mLowPowerModeSetting.equals(uri)) {
547 updateLowPowerModeSettingLocked();
548 }
549 }
550 }
690 @Override
691 public void onDisplayAdded(int displayId) {
692 updateDisplayModes(displayId);
693 }
694
695 @Override
696 public void onDisplayRemoved(int displayId) {
697 synchronized (mLock) {
698 mSupportedModesByDisplay.remove(displayId);
699 mDefaultModeByDisplay.remove(displayId);
700 }
701 }
702
703 @Override
704 public void onDisplayChanged(int displayId) {
705 updateDisplayModes(displayId);
706 }
他们都会调用到DisplayModeDirector的notifyAllowedModesChangedLocked()。
371 private void notifyAllowedModesChangedLocked() {
372 if (mListener != null && !mHandler.hasMessages(MSG_ALLOWED_MODES_CHANGED)) {
373 // We need to post this to a handler to avoid calling out while holding the lock
374 // since we know there are things that both listen for changes as well as provide
375 // information. If we did call out while holding the lock, then there's no guaranteed
376 // lock order and we run the real of risk deadlock.
377 Message msg = mHandler.obtainMessage(MSG_ALLOWED_MODES_CHANGED, mListener);
378 msg.sendToTarget();
379 }
380 }
409 public void handleMessage(Message msg) {
410 switch (msg.what) {
411 case MSG_ALLOWED_MODES_CHANGED:
412 Listener listener = (Listener) msg.obj;
413 listener.onAllowedDisplayModesChanged();
414 break;
415 }
416 }
并最终调用DisplayManagerService的onAllowedDisplayModesChangedInternal()。其中display.setAllowedDisplayModesLocked则会通过SurfaceControl.setAllowedDisplayConfigs传递给native层SurfaceFlinger的屏幕刷新率Schedule策略模块。
1422 private void onAllowedDisplayModesChangedInternal() {
1423 boolean changed = false;
1424 synchronized (mSyncRoot) {
1425 final int count = mLogicalDisplays.size();
1426 for (int i = 0; i < count; i++) {
1427 LogicalDisplay display = mLogicalDisplays.valueAt(i);
1428 int displayId = mLogicalDisplays.keyAt(i);
1429 int[] allowedModes = mDisplayModeDirector.getAllowedModes(displayId);
1430 // Note that order is important here since not all display devices are capable of
1431 // automatically switching, so we do actually want to check for equality and not
1432 // just equivalent contents (regardless of order).
1433 if (!Arrays.equals(allowedModes, display.getAllowedDisplayModesLocked())) {
1434 display.setAllowedDisplayModesLocked(allowedModes);
1435 changed = true;
1436 }
1437 }
1438 if (changed) {
1439 scheduleTraversalLocked(false);
1440 }
1441 }
1442 }
上面讲到DisplayManagerService调用SurfaceControl.setAllowedDisplayConfigs接口来影响屏幕刷新率，通过JNI接口和libgui，直接call到了SurfaceFlinger服务.
frameworks/base/core/jni/android_view_SurfaceControl.cpp::
nativeSetAllowedDisplayConfigs();
frameworks/native/libs/gui/SurfaceComposerClient.cpp::
getComposerService()->setAllowedDisplayConfigs(displayToken, allowedConfigs);
上面的getComposerService()就是得到SurfaceFlinger的服务句柄，进而调用它的接口setAllowedDisplayConfigs来对屏幕刷新率做更新。请注意这个接口里传下来的allowedConfigs是一个数组，不一定是某一个刷新率的索引。
SurfaceFlinger通过mRefreshRateConfigs和mAllowedDisplayConfigs来维护Android设备支持的屏幕刷新率和系统目前允许使用的屏幕刷新率。比如有一款手机，它的显示屏可以支持60Hz、90Hz、120Hz三个刷新率，则mRefreshRateConfigs则记录了这3个刷新率。而应用或者系统可以通过setAllowedDisplayConfigs让SurfaceFlinger只能在某几个刷新率之间切换，就是设置的mAllowedDisplayConfigs，比如只让这个手机在60Hz和90Hz之间切换，则mAllowedDisplayConfigs就只记录了60Hz和90Hz。
SurfaceFlinger在初始化时，会对mRefreshRateConfigs做初始化。其中getHwComposer().getConfigs是从HAL层获取设备支持的所有屏幕刷新率。
754 void SurfaceFlinger::init() {
......
890 int active_config = getHwComposer().getActiveConfigIndex(*display->getId());
891 mRefreshRateConfigs.setActiveConfig(active_config);
892 mRefreshRateConfigs.populate(getHwComposer().getConfigs(*display->getId()));
893 mRefreshRateStats.setConfigMode(active_config);
......
}
如前面讲JAVA层代码时提到过，系统开机过程中DisplayObserver的onDisplayAdded()会被调到，进而调用setAllowedDisplayConfigs来初始化mAllowedDisplayConfigs。一般来说，开机时初始化的mRefreshRateConfigs和mAllowedDisplayConfigs是一致的，除非设备开发商做了定制，比如让设备开机默认固定在某个刷新率。比如motorola edge开机默认是auto模式，它开机后mRefreshRateConfigs和mAllowedDisplayConfigs是一致的。而motorola edge plus开机后默认是90Hz模式，它开机后mRefreshRateConfigs和mAllowedDisplayConfigs就不一致。
为了保证从上层传过来的allowedConfigs在本机支持的刷新率内，在setAllowedDisplayConfigs时还用经过mRefreshRateConfigs的筛选。在mRefreshRateConfigs.getAllowedConfigs中，会根据设备的支持情况更新displayConfigs。
7661 void SurfaceFlinger::setAllowedDisplayConfigsInternal(const sp& display,
7662 const std::vector& allowedConfigs) {
7672
7676 // Set Phase Offsets type for the Default Refresh Rate config.
7677 RefreshRateType type = mRefreshRateConfigs.getDefaultRefreshRateType();
7678 mPhaseOffsets->setDefaultRefreshRateType(type);
7679
7685 // Update the allowed Display Configs.
7686 mRefreshRateConfigs.getAllowedConfigs(getHwComposer().getConfigs(*display->getId()),
7687 &displayConfigs);
7688
7689 mAllowedDisplayConfigs = DisplayConfigs(displayConfigs.begin(), displayConfigs.end());
7693
7711 setPreferredDisplayConfig();
7712 }
改变mAllowedDisplayConfigs除了使用SurfaceFlinger服务的setAllowedDisplayConfigs接口外，还可以使用SurfaceFlinger的transact code 1035。这个对调试非常有用。你可以使用类似下面的命令行来手动切换刷新率：
adb shell service call SurfaceFlinger 1035 i32 X(X是所要切换的屏幕刷新率的索引)
在Android Q不断迭代的后期，Google也加入了更多的直观的调试方法来让系统开发者监控设备当前的屏幕刷新率变化，比如在屏幕的左上角增加颜色方块或者数字来直观的显示当前的刷新率，同时在开发者选项中增加开关来控制这个调试功能（Android R上是肯定有的，目前Q上开发者选项里还没看到，但可以使用命令行来开关）。
回到重点，那么，SurfaceFlinger中真正的调用底层切换屏幕刷新率的地方在哪里呢？它在刷新下一帧的准备阶段。我们继续看setAllowedDisplayConfigs接口，它最后调用了setPreferredDisplayConfig()。如果设备上enable了Google的auto切换策略，则从策略中获取最合适的刷新率，如果没有enable，则找到设备支持的最大刷新率。当然，都是在allowed的前提下。然后通过接口setDesiredActiveConfig往下调。
7638 void SurfaceFlinger::setPreferredDisplayConfig() {
7639 const auto& type = mScheduler->getPreferredRefreshRateType();
7640 const auto& config = mRefreshRateConfigs.getRefreshRate(type);
7641 if (config && isDisplayConfigAllowed(config->configId)) {
7642 ALOGV("switching to Scheduler preferred config %d", config->configId);
7643 setDesiredActiveConfig({type, config->configId, Scheduler::ConfigEvent::Changed});
7644 } else {
7645 // Set the highest allowed config by iterating backwards on available refresh rates
7646 const auto& refreshRates = mRefreshRateConfigs.getRefreshRates();
7647 for (auto iter = refreshRates.crbegin(); iter != refreshRates.crend(); ++iter) {
7648 if (iter->second && isDisplayConfigAllowed(iter->second->configId)) {
7651 mRefreshRateConfigs.setActiveConfig(iter->second->configId);
7653 setDesiredActiveConfig({iter->first, iter->second->configId,
7654 Scheduler::ConfigEvent::Changed});
7655 break;
7656 }
7657 }
7658 }
7659 }
我们继续看setDesiredActiveConfig接口。它只是把选择好的ActiveConfigInfo赋值给mDesiredActiveConfig并记一个标记mDesiredActiveConfigChanged=true。
1194 void SurfaceFlinger::setDesiredActiveConfig(const ActiveConfigInfo& info) {
......
1202 mDesiredActiveConfig = info;
1203 mDesiredActiveConfig.event = mDesiredActiveConfig.event | prevConfig;
......
1219 mDesiredActiveConfigChanged = true;
......
1225 }
上面标记的结果的真正使用是在SurfaceFlingerm每次收到MessageQueue::INVALIDATE信号并调用performSetActiveConfig()的时候。这里首先判断mCheckPendingFence和previousFrameMissed，如果mCheckPendingFence被标记并且前一个frame没有被drop，则表示刚刚前一个frame刷新过程中改变了屏幕刷新率并成功了，这时需要调用setActiveConfigInternal去更新SF的跟显示性能相关的vsync offset等参数。如果mCheckPendingFence是false则继续判断是否需要改变屏幕刷新率，如果需要的话，则用getHwComposer().setActiveConfig发命令给HAL并标记mCheckPendingFence和触发一次INVALIDATE。
1281 bool SurfaceFlinger::performSetActiveConfig() {
1282 ATRACE_CALL();
1283 if (mCheckPendingFence) {
1284 if (previousFrameMissed()) {
1285 // fence has not signaled yet. wait for the next invalidate
1286 mEventQueue->invalidate();
1287 return true;
1288 }
1290 // We received the present fence from the HWC, so we assume it successfully updated
1291 // the config, hence we update SF.
1292 mCheckPendingFence = false;
1293 setActiveConfigInternal();
1294 }
1295
1296 // Store the local variable to release the lock.
1303 desiredActiveConfig = mDesiredActiveConfig;
1322 mUpcomingActiveConfig = desiredActiveConfig;
1327 getHwComposer().setActiveConfig(*displayId, mUpcomingActiveConfig.configId);
1328
1340 // we need to submit an empty frame to HWC to start the process
1341 mCheckPendingFence = true;
1342 mEventQueue->invalidate();
1343 return false;
1344 }
不要在SurfaceFlinger中随便调用HidlHAL的setActiveConfig()去设置硬件刷新率。因为这样的话虽然硬件的刷新率变了，但是SurfaceFlinger和RenderThread并不知道，因此相关的pipeline性能相关的参数没有同步更新，会造成显示性能的未知问题。比如mVsyncModulator的setPhaseOffsets就是很重要的参数，它决定了SF和APP开始画图的针对vsync的偏移时间。只有调用SurfaceFlinger标准接口来设置刷新率，才能通过setActiveConfigInternal更新所有的刷新参数并通知关心的上层模块。
1243 void SurfaceFlinger::setActiveConfigInternal() {
1250
1251 std::lock_guard lock(mActiveConfigLock);
1252 mRefreshRateStats.setConfigMode(mUpcomingActiveConfig.configId);
1253
1254 display->setActiveConfig(mUpcomingActiveConfig.configId);
1255
1256 mPhaseOffsets->setRefreshRateType(mUpcomingActiveConfig.type);
1257 const auto [early, gl, late] = mPhaseOffsets->getCurrentOffsets();
1258 mVsyncModulator.setPhaseOffsets(early, gl, late,
1259 mPhaseOffsets->getOffsetThresholdForNextVsync());
1260 ATRACE_INT("ActiveConfigMode", mUpcomingActiveConfig.configId);
1261
1262 if (mUpcomingActiveConfig.event != Scheduler::ConfigEvent::None) {
1263 mScheduler->onConfigChanged(mAppConnectionHandle, display->getId()->value,
1264 mUpcomingActiveConfig.configId);
1265 }
1266 }
在SurfaceFlinger的RefreshRateConfigs类中，有Google目前的屏幕刷新率相关的一些定义。比如它定义了默认的刷新率是60Hz，并定义了RefreshRateType，其中DEFAULT就对应60Hz。
35 class RefreshRateConfigs {
37 static const int DEFAULT_FPS = 60;
39 public:
44 enum class RefreshRateType {POWER_SAVING, LOW0, LOW1, LOW2, DEFAULT, PERFORMANCE, HIGH1, HIGH2};
99 }
在SurfaceFlinger服务启动成功的时候，会调用setRefreshRateTo接口把屏幕刷新率设置为设备支持的最高刷新率。然后如果setting里有默认值的话，会通过setAllowedDisplayConfigs再改变一次。
643 void SurfaceFlinger::bootFinished()
644 {
......
698 // set the refresh rate according to the policy
699 int maxSupportedType = (int)RefreshRateType::HIGH2;
700 int minSupportedType = (int)RefreshRateType::LOW0;
701
702 for (int type = maxSupportedType; type >= minSupportedType; type--) {
703 RefreshRateType refreshRateType = static_cast(type);
704 const auto& refreshRate = mRefreshRateConfigs.getRefreshRate(refreshRateType);
705 if (refreshRate && isDisplayConfigAllowed(refreshRate->configId)) {
706 setRefreshRateTo(refreshRateType, Scheduler::ConfigEvent::None);
707 return;
708 }
709 }
......
xxx }
等这一切都完成后，除非用户在setting里做手动操作，屏幕刷新率就不会变化了。如果想要让屏幕刷新率根据场景进行自适应的变化，就需要加入自己的策略，或者打开Google的Schedule策略。自己加策略大家可以百花齐放，我们这里说说Googel的Schedule策略。
我们看SurfaceFlinger的init()函数，一上来就拿到一个mScheduler句柄。这个mScheduler的一项重要功能，就是管理屏幕刷新率的策略。
754 void SurfaceFlinger::init() {
755 ALOGI( "SurfaceFlinger's main thread ready to run. Initializing graphics H/W...");
760 Mutex::Autolock _l(mStateLock);
762 mScheduler = getFactory().createScheduler([this](bool enabled) { setPrimaryVsyncEnabled(enabled); },
xxx }
它并没有创建一个线程去监控场景(SurfaceFlinger里的线程已经够多了)，而是使用了两个timer（Q的后期又添加了一个，我们这里不讲）。一个是mIdleTimer，一个mTouchTimer。Google这个刷新率策略的初衷就是，让用户在屏幕上手动操作的时候，纵享丝滑，体验到如丝般顺滑。其他时候，是怎样就怎样吧。
来看Scheduler的构造函数，两个timer在这里开始了他们的人生，每个人都在SF的操控下处理两件事情，resetTimerCallback和expiredTimerCallback。
60 Scheduler::Scheduler(impl::EventControlThread::SetVSyncEnabledFunction function,
61 const scheduler::RefreshRateConfigs& refreshRateConfig)
62 : mHasSyncFramework(running_without_sync_framework(true)),
63 mDispSyncPresentTimeOffset(present_time_offset_from_vsync_ns(0)),
64 mPrimaryHWVsyncEnabled(false),
65 mHWVsyncAvailable(false),
66 mRefreshRateConfigs(refreshRateConfig) {
74
75 mSetIdleTimerMs = set_idle_timer_ms(0);
78 mSetTouchTimerMs = set_touch_timer_ms(0);
126
127 if (mSetIdleTimerMs > 0) {
137 mIdleTimer = std::make_unique(std::chrono::milliseconds(
138 mSetIdleTimerMs),
139 [this] { resetTimerCallback(); },
140 [this] { expiredTimerCallback(); });
142 mIdleTimer->start();
143 }
144
145 if (mSetTouchTimerMs > 0) {
146 // Touch events are coming to SF every 100ms, so the timer needs to be higher than that
147 mTouchTimer =
148 std::make_unique(std::chrono::milliseconds(mSetTouchTimerMs),
149 [this] { resetTouchTimerCallback(); },
150 [this] { expiredTouchTimerCallback(); });
151 mTouchTimer->start();
152 }
164 }
Google把mIdleTimer和mTouchTimer的timeout时间分别设定在500毫秒和2000毫秒。这两个timer的控制逻辑具体是这样：
当用户手动在触屏上操作时，会触发notifyPowerHint，进而reset mTouchTimer，在resetTouchTimerCallback中，把刷新率类型改成PERFORMANCE(90Hz)，等到mTouchTimer timeout的时候，维持当前的刷新率，等于无操作。 当屏幕显示内容有更新时，会resetIdleTimer()，而resetTimerCallback没什么操作，只有等到IdleTimer timeout时，在expiredTimerCallback()的时候，把刷新率改为DEFAULT(60Hz)。部分代码如下，其中handleTimerStateChanged和calculateRefreshRateType是策略的灵魂：
当系统touch事件reset touch timer时，把mCurrentTouchState改为TouchState::ACTIVE，而在idle timer expired的时候，把mCurrentIdleTimerState改为IdleTimerState::EXPIRED。
frameworks/native/libs/gui/ISurfaceComposer.cpp
1060 status_t BnSurfaceComposer::onTransact(
1061 uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
1062 {
1063 switch(code) {
1685 case NOTIFY_POWER_HINT: { //从inputmanager来的事件
1686 CHECK_INTERFACE(ISurfaceComposer, data, reply);
1687 int32_t hintId;
1688 status_t error = data.readInt32(&hintId);
1689 if (error != NO_ERROR) {
1690 ALOGE("notifyPowerHint: failed to read hintId: %d", error);
1691 return error;
1692 }
1693 return notifyPowerHint(hintId);
1694 }
1716 }
1717 }
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
1697 status_t SurfaceFlinger::notifyPowerHint(int32_t hintId) {
1698 PowerHint powerHint = static_cast(hintId);
1699
1700 if (powerHint == PowerHint::INTERACTION) {
1701 mScheduler->notifyTouchEvent(); //reset touch timer
1702 }
1703
1704 return NO_ERROR;
1705 }
1729 void SurfaceFlinger::signalTransaction() {
1730 mScheduler->resetIdleTimer();
1731 mEventQueue->invalidate();
1732 }
1733
1734 void SurfaceFlinger::signalLayerUpdate() {
1735 mScheduler->resetIdleTimer();
1736 mEventQueue->invalidate();
1737 }
536 void Scheduler::resetTouchTimerCallback() {
537 handleTimerStateChanged(&mCurrentTouchState, TouchState::ACTIVE, true);
538 ATRACE_INT("TouchState", 1);
539 }
528 void Scheduler::expiredTimerCallback() {
532 handleTimerStateChanged(&mCurrentIdleTimerState, IdleTimerState::EXPIRED, false);
533 ATRACE_INT("ExpiredIdleTimer", 1);
534 }
576 template
577 void Scheduler::handleTimerStateChanged(T* currentState, T newState, bool eventOnContentDetection) {
578 ConfigEvent event = ConfigEvent::None;
579 RefreshRateType newRefreshRateType;
580 {
581 std::lock_guard lock(mFeatureStateLock);
582 if (*currentState == newState) {
583 return;
584 }
585 *currentState = newState; //改变current state
586 newRefreshRateType = calculateRefreshRateType();
587 if (mRefreshRateType == newRefreshRateType) {
588 return;
589 }
590 mRefreshRateType = newRefreshRateType;
591 if (eventOnContentDetection &&
592 mCurrentContentFeatureState == ContentFeatureState::CONTENT_DETECTION_ON) {
593 event = ConfigEvent::Changed;
594 }
595 }
596 changeRefreshRate(newRefreshRateType, event);
597 }
下面是策略所在，在calculateRefreshRateType()中，如果发现当前mCurrentTouchState是TouchState::ACTIVE，则返回Performance，如果mCurrentIdleTimerState是IdleTimerState::EXPIRED，会返回DEFAULT。
604 Scheduler::RefreshRateType Scheduler::calculateRefreshRateType() {
......
649 // As long as touch is active we want to be in performance mode
650 if (mCurrentTouchState == TouchState::ACTIVE) {
651 REFRESH_RATE_RESULT(RESULT_TOUCH_ACTIVE);
652 return RefreshRateType::PERFORMANCE;
653 }
......
655 // If timer has expired as it means there is no new content on the screen
656 if (mCurrentIdleTimerState == IdleTimerState::EXPIRED) {
657 REFRESH_RATE_RESULT(RESULT_IDLE_EXPIRED);
658 return RefreshRateType::DEFAULT;
659 }
......
707 return currRefreshRateType;
708 }
策略函数给出的刷新率，会在handleTimerStateChanged中调用changeRefreshRate callback到SurfaceFlinger中，通过setRefreshRateTo接口往下传递，后面的调用关系，就基本跟setAllowedDisplayConfigs一致了。
综上所诉，Google的刷新率策略如我所说，就是让你动手的时候，充分体验到高刷新率屏幕的硬件优势。至于其他情况，比如，有个应用界面，上面有个按钮，你点击这个按钮后，会播放一段动画。在你点击按钮的时候，Google的刷新率策略触发屏幕刷新率被改成90Hz，那么你看按钮按下抬起这个效果是很顺畅的。但是如果你的动画开始显示第一帧的时间跟按钮抬起结束的时间之间的间隔大于Idletimer的500毫秒生命周期的话，对不起，刷新率又被策略改回60Hz了。虽然你很想让动画也享受到90Hz的极致体验，但是奈何掌权者不给啊。所在Google的自适应策略下，如果想在用户操作后保持90Hz，你需要不停的更新显示内容，且每次更新之间不能大于500毫秒。这就是为什么很多支持高刷新的产品会设计固定刷新率的模式让用户做选择，因为只有在固定高刷新率的情况下，才能满足用户永远丝滑感受。当然，固定在90Hz也会带来不确定的问题，比如功耗的提高，比如对那些针对60Hz做过精心调试的游戏是否有负面效果。
4. HAL层刷新率相关代码上面讲了Android系统中APP和frameworks中跟显示刷新率和帧率相关的代码和策略。因为代码比较common，大家都可以做参考。现在讲到HAL层，因为不同平台的实现方法会有不同，我们就只依据高通平台的HAL粗略提一下，不做展开。
前面有提到SurfaceFlinger是调用setActiveConfig()到HidlHAL去设置硬件刷新率的。在高通的HAL层，是一级级调到DisplayBase的SetActiveConfig接口，然后调用DRM HAL接口SetDisplayAttributes和UpdateMixerAttributes()，
去更新全局变量current_mode_index_和标记update_mode_ = true。current_mode_index_是记录系统当前的刷新率索引，update_mode_为true表示需要更新刷新率。
656 DisplayError DisplayBase::SetActiveConfig(uint32_t index) {
......
673 error = hw_intf_->SetDisplayAttributes(index);
......
678 return ReconfigureDisplay();
679 }
在SetDisplayAttributes还要确认一下所选的刷新率是否跟当前显示硬件的属性匹配：
847 DisplayError HWDeviceDRM::SetDisplayAttributes(uint32_t index) {
......
875 for (uint32_t mode_index = 0; mode_index < connector_info_.modes.size(); mode_index++) {
876 if ((to_set.vdisplay == connector_info_.modes[mode_index].mode.vdisplay) &&
877 (to_set.hdisplay == connector_info_.modes[mode_index].mode.hdisplay) &&
878 (to_set.vrefresh == connector_info_.modes[mode_index].mode.vrefresh) &&
879 (current_bit_clk == connector_info_.modes[mode_index].bit_clk_rate) &&
880 (mode_flag & connector_info_.modes[mode_index].mode.flags)) {
881 index = mode_index;
882 break;
883 }
884 }
885
886 current_mode_index_ = index;
887 PopulateHWPanelInfo();
888 UpdateMixerAttributes();
......
902 return kErrorNone;
903 }
2023 void HWDeviceDRM::UpdateMixerAttributes() {
2024 uint32_t index = current_mode_index_;
2025
2026 mixer_attributes_.width = display_attributes_[index].x_pixels;
2027 mixer_attributes_.height = display_attributes_[index].y_pixels;
2028 mixer_attributes_.split_left = display_attributes_[index].is_device_split
2029 ? hw_panel_info_.split_info.left_split
2030 : mixer_attributes_.width;
2031 mixer_attributes_.split_type = kNoSplit;
......
2043 update_mode_ = true;
2044 }
最后向kernel层发命令是在每帧刷新的Validate函数调用的SetupAtomic()中。它发送DRM驱动的property set code 命令CRTC_SET_MODE 给kernel，来改变驱动的刷新率。HAL层还有自己的刷新率更新策略来应对显示设备的变化，具体可以跟踪first_cycle_ 、vrefresh_ 、panel_mode_changed_这几个变量的变化。
1393 DisplayError HWDeviceDRM::Validate(HWLayers *hw_layers) {
......
1398 SetupAtomic(hw_layers, true );
1399
1400 int ret = drm_atomic_intf_->Validate();
......
1409 return err;
1410 }
1076 void HWDeviceDRM::SetupAtomic(HWLayers *hw_layers, bool validate) {
......
1337 // Set CRTC mode, only if display config changes
1338 if (first_cycle_ || vrefresh_ || update_mode_ || panel_mode_changed_) {
1339 drm_atomic_intf_->Perform(DRMOps::CRTC_SET_MODE, token_.crtc_id, ¤t_mode);
1340 }
......
1352 }
高通平台的DRM驱动比较复杂，且一般不需要大的修改。我们这里只提一下不同刷新率在device tree里的设定。在panel driver bringup阶段，从panel的spec中找出所支持的刷新率，并从IC vendor支持那里拿到相应的timing参数以后，就可以在device tree里生成该panel的device tree。关键的几个值是“qcom,mdss-dsi-panel-framerate”、“qcom,mdss-dsi-timing-switch-command”、“qcom,mdss-dsi-timing-switch-command-state”。
qcom,mdss-dsi-display-timings {
timing@0{
// 60 FPS
qcom,mdss-dsi-cmd-mode;
qcom,mdss-dsi-panel-framerate = ;
.......
qcom,mdss-dsi-timing-switch-command = [.....];
qcom,mdss-dsi-on-command = [......];
qcom,mdss-dsi-off-command = [......];
qcom,mdss-dsi-timing-switch-command-state = "dsi_lp_mode";
......
};
timing@1{
// 90 FPS
qcom,mdss-dsi-cmd-mode;
qcom,mdss-dsi-panel-framerate = ;
.......
qcom,mdss-dsi-timing-switch-command = [......];
qcom,mdss-dsi-on-command = [......];
qcom,mdss-dsi-off-command = [......];
qcom,mdss-dsi-timing-switch-command-state = "dsi_lp_mode";
......
};
}；
以上，在Android系统中跟屏幕刷新率相关的关键代码就理完了。虽然设备硬件的更新换代，相信大家会越来越多关注这方面对Android软件开发的影响。这里抛砖引玉，希望在Android的持续迭代过程中，与大家共同进步。欢迎不吝指正。
本文禁止转载，如有需求，请联系作者。
whoatenereyhow
原创文章 2获赞 0访问量 95
关注
私信
展开阅读全文
作者：whoatenereyhow
