前言
昨天在IT之家留言说如果应用无法满足120hz的绘制，假设如果绘制一帧的时间如果大于1/120秒，哪怕是多了1毫秒，就会导致应用在120hz的手机上也就变成了60hz。
后来仔细想想这句话说的并不是特别严谨，为什么这么说呢？
一、证明我的观点
首先我写一个demo来证明我的观点意思
1.1 满帧的应用
代码语言：javascript复制ublic class MyTextView extends TextView {
int i = 0;
public MyTextView(Context context) {
super(context);
}
public MyTextView(Context context, @Nullable AttributeSet attrs) {
super(context, attrs);
}
public MyTextView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
if (i < 6) {
this.post(new Runnable() {
@Override
public void run() {
MyTextView.this.setText(i "");
}
});
}
}
}
我写了一个只绘制6帧的一个界面，activity中包含这个TextView，通过抓trace可以看到，下面这个漂亮6帧绘制，都是在一个vsync周期（图中黑白背景，一个白色或者黑色就是一个vsync周期）绘制一帧。
为什么第一帧会有点延迟是因为主线程在干其他事情，好在绘制花不了太多时间。 大概绘制也就3毫秒左右，毕竟界面简单。
1.2 帧数减半的应用
代码语言：javascript复制public class MyTextView extends TextView {
int i = 0;
public MyTextView(Context context) {
super(context);
}
public MyTextView(Context context, @Nullable AttributeSet attrs) {
super(context, attrs);
}
public MyTextView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
try {
Thread.sleep(16);
} catch (Exception e) {
}
if (i < 6) {
this.post(new Runnable() {
@Override
public void run() {
MyTextView.this.setText(i "");
}
});
}
}
}
我人为在MyTextView.onDraw方法中sleep了16毫秒，来模拟很多应用写的不好，例如View层级厉害复杂，甚至在onDraw方法中进行文件读写。通过抓trace可以看到，原本1.1中6帧6个时间周期绘制完成，现在变成了6帧12个时间周期完成了。
1.3 总结
这就是我一直想说的一个观点，120hz的手机体验不一定有90hz的手机好的原因，一旦主线程一次traversal(一次ViewRootImpl的ondraw的遍历)的事情超出了vsync的时间周期1/120s，就会导致帧率直接砍半，降为60帧，90hz可以让这个折半降帧率的现象减少。
二、绘制一帧指的是什么
为什么我的观点不准确的原因，就是我太笼统的定义了绘制一帧这个词。
在硬件加速开启的情况下： 如果我将绘制一帧的时间定义成：主线程一次traversal，那我说的话是正确的。 如果我将绘制一帧的时间定义成：主线程一次traversal renderthread一次渲染，那我说的话是不严谨的。
2.1 引发我思考的trace
因为要让主线程一次traversal renderthread超时不是特别好写demo，我就用一个昨天引发我思考的一个trace给大家讲解一下。
大家从第一个黄色F的圆圈开始看，UI Thread的doFrame RenderThread的DrawFrame的时间超出了一个Vsync周期，接下来每一帧的情况都是按照第一帧绘制的情况一样的情况运行，最好造成的现象就是虽然帧数是满帧，但是每一帧其实都是延迟显示的。
用一句哲学的话来概括就是：你眼睛看到任何事物，其实都是事物过去的样子
假如主线程一次traversal renderthread一次渲染时间超出了vsync周期不多，这样子的应用大概率是可以满帧运行（满帧不代表显示正常）。
我上面一句话中用了不多，大概率这种模糊的文字，因为这个情况下能否满帧的临界点比较难定义。
2.2 如何定义这个120变成60帧的临界点
继续下面这个图，你会发现UI Thread的doFrame会非常happy的按照vsync信号执行，但是下面renderthread已经忙的不可开交了。
其实第一帧已经延迟了，假如运气不好导致了drawframe的时间横跨了2个vsync周期，还是会导致丢帧，这个时候就从120帧降为60帧。
三、总结
3.1 理想中的结论
假设开启硬件加速，一帧绘制的时间 = UI线程（T1） RenderThread线程（T2） Vsync时间的周期是1/120s，约等于8.3ms 如果 16.6ms > T1 > 8.3ms，会导致从120帧降为60帧。 如果T1 < 8.3ms，16.6ms > T1 T2 > 8.3ms，虽然还是满帧，但是你看到的永远是前一帧的画面。 如果 T1 T2 > 16.6ms，毫无疑问会导致从120帧降为60帧。
上面理论看起来是很完美的结论，千万别把这个当做定理去记忆，因为其实现实会比这些情况复杂的多。
3.2 显示中的结论
可能会有人说现在CPU，GPU那么强，怎么可能会超时呢？ 举个微信在865的手机的滑动消息列表的例子，T1 约等于6ms，T1 T2约等于8.2ms。 这还是不怎么复杂的界面，大家会发现，6ms已经很接近8.3ms了。
3.3 给开发者的建议
对于要适配120hz手机的应用的工程师，你们要注意以下事情。 1.避免T1 > 8.3ms，也就是要减少主线程干的活，要减少一次draw的时间。千万别再draw的流程进行文件访问或者sleep。 2.避免在滑动响应的时候T1 T2 > 8.3ms，虽然界面在显示的时候，推迟一帧用户是察觉不了的，但是在滑动的响应中如果推迟一帧，可能会有跟手性的问题出现了。 3.千万别关闭硬件加速，一旦关闭硬件加速T1 T2 > 8.3ms就会导致120降为60帧。
四、尾巴
说到这里，如果听得懂我在说什么的人，应该能懂我想表达的意思。 如果不懂我说的什么的人，希望你去补一下以下知识点，再回过头来看这个文章。
知识点1：
TextView.setText到屏幕显示文字，整个过程发生了什么。
知识点2：
硬件加速之后，主线程（UI Thread）和RenderThread之间的协同工作的方式。
知识点3：
APP界面和SurfaceFlinger之间的关系
可能会有人说，你揪那么细致干嘛，对于用户来说，掉了几帧的影响也不大，，但是对于性能优化工程师来说，有时候就是要纠结那几个丢帧的情况，只有做好了每一帧的完美绘制，才能给用户带来最完美的用户体验。
