多屏幕刷新率 到底多少合适呢 这是个问题

应用的收到 调用应用的并更新 ’

应用的发送到GPU

GPU进行绘图工作

负责各应用窗口显示工作的系统服务对各应用的显示内容进行合成并把合成后的发送给HAL有些硬件合成的过程就是往屏幕发送数据的过程

frame开始扫描并更新到屏幕上比如通过MIPI接口。

    整个流水线是由Android Choreographer控制的.Choreographer的运行又基于屏幕的verticalsynchronization(vsync)events。vsyncevent代表显示硬件开始扫描输出图像到屏幕上一行一行的显示.基于vsyncevents应用和SurfaceFlinger有不同的唤醒时间偏移量。下图显示了Pixel4在60Hz刷新率模式下的帧处理流水线。 应用在vsyncevent发生后2毫秒被唤醒而SurfaceFlinger是在vsyncevent发生后的6毫秒被唤醒.这样应用就有20毫秒(阶段2阶段3)的时间去处理一帧数据而SurfaceFlinger也有10毫秒的时间去合成显示数据阶段4。这个处理时间对于一般的硬件平台都是可以胜任的。

    当手机运行在90Hz刷新率模式下的时候应用仍是是在vsyncevent发生后2毫秒被唤醒而SurfaceFlinger是在vsyncevent发生后的1毫秒被唤醒这样为了给Surface留下足够的10毫秒时间去合成数据。但是如果仍然要求数据在第2帧就往屏幕上发送的话应用就只有10毫秒的时间去画图了如下图。 这是一个非常短的时间稍微复杂一些的显示工作对于大部分平台的AP和GPU性能都难以这么短的时间内完成画图工作。

    为了减轻画图的负担Android的UI系统(hwui)使用一种 “renderahead”机制(SurfaceFlinger合成时间推迟一帧但仍然在vsyncevent发生后1毫秒开始)把显示时间延迟一个vsyncperiod来拉长一帧数据的流水线时长.这样应用就有21ms的时间去处理数据画图包括APrender和GPU渲染而仍然能保持90Hz的帧率。

    有些应用包括大部分游戏会根据他们的画图的工作量来定制自己的render流水线增加或减少render阶段数量。一般来说因为画图工作量太大会增加render流水线的长度即在阶段2和阶段3增加并行处理阶段来提升计算效率。然而这样的折中方案又会引入更大的帧延时(thelatencywillbe number_of_pipeline_stages x longest_pipeline_stage)需要综合权衡考量。

Takingadvantageofmultiplerefreshrates

    如上所述多刷新率的支持给应用程序提供了更多的可用render帧率选择。这一点对于经常需要改变显示帧率的游戏应用和需要以一个固定的帧率来显示内容的视频应用来说尤其有用。例如要在60Hz的刷新率模式下播放24fps的视频则需要使用3:2pulldown算法(如下图)理论上说是有抖动的但一般人感觉不到。然而如果设备支持合适的屏幕刷新率并因而可以支持相匹配的render帧率比如120Hz正好是24的倍频的话则不再需要pulldown算法也就不会有抖动问题。

    设备何时以什么刷新率运行是Android平台控制的。应用或者游戏可以通过多种方法来影响刷新率的切换最终的刷新率有Android平台来决定。当不止一个应用程序比如Motorola的多窗口模式在屏幕上显示时这一点很关键平台需要给出一个能够让所有前台应用流畅显示的刷新率。假设有个手机支持24Hz的屏幕刷新率我们拿一个把平台刷新率设置为24Hz的视频播放器应用为例当它播放24fps的视频时我们肯定感觉非常流畅。但是24fps对于手机的系统信息通知动画的播放来说就很糟糕了我们能感觉弹出信息框到抖动。在这种情况下平台需要能综合考虑各种因素给出一个合适的刷新率来满足不同的内容从而让屏幕上的不同内容看起来都很流程。

    基于这个原因应用很可能想知道设备当前的刷新率据此来调整自己的显示速度。有以下方法可以拿到这个信息