[053]一条评论引发的思考

前言

昨天在IT之家留言说如果应用无法满足120hz的绘制,假设如果绘制一帧的时间如果大于1/120秒,哪怕是多了1毫秒,就会导致应用在120hz的手机上也就变成了60hz。

后来仔细想想这句话说的并不是特别严谨,为什么这么说呢?

一、证明我的观点

首先我写一个demo来证明我的观点意思

1.1 满帧的应用

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 帧数减半的应用

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之间的关系

可能会有人说,你揪那么细致干嘛,对于用户来说,掉了几帧的影响也不大,,但是对于性能优化工程师来说,有时候就是要纠结那几个丢帧的情况,只有做好了每一帧的完美绘制,才能给用户带来最完美的用户体验。