美文网首页
开启硬件加速导致动画掉帧分析

开启硬件加速导致动画掉帧分析

作者: 倦飞知还 | 来源:发表于2019-07-13 17:02 被阅读0次

    背景

    最近碰到一个动画卡顿的问题,花了比较多的精力进行解决,并从中总结出来一些分析的套路,特此进行分享。
    卡顿掉帧的现象:


    gte96-fhw59.gif

    正常的现象:


    94njj-wcbhv.gif

    从现象可以看出,应用信息展开的时候,有一定的卡顿。

    绘制原理

    image.png

    要在屏幕上显示,其实要经过一系列的过程,Android 应用程序把经过测量、布局、绘制后的 surface 缓存数据,通过进程通信的方式,把数据给到SurfaceFlinger ,SurfaceFlinger这把这些图层的数据根据surface的排序进行混合,最后把混合之后的数据渲染到显示屏幕上, 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制,系统层负责渲染,通过进程间通信把应用层需要绘制的数据传递到系统层服务,系统层服务通过刷新机制把数据更新到屏幕上。


    image.png

    surfaceflinger在初始化时设置VnSync信号周期,一般为16ms,之后监听Vnsync信号,在收到信号之后,重新走混合渲染流程。
    开发app的性能目标就是保持60fps,这意味着每一帧你只有16ms≈1000/60的时间来处理所有的任务。Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需要的60fps。


    image.png
    如果你的某个操作花费时间是24ms,系统在得到VSYNC信号的时候就无法进行正常渲染,这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面。
    image.png

    丢帧情况 卡顿情况
    0-10帧 流畅
    10-20帧 较卡
    20-40帧 很卡
    40-60帧 卡死了

    卡顿分析

    通过systrace抓取launcher应用卡顿时候的信息,获取的traceview,掉帧的的部分如下:


    捕获1.PNG

    线程在traceview中的信息包括两部分,线程运行状态,和线程运行方法栈。
    通过颜色判断线程运行状态,各个颜色的含义为:
    灰色:sleeping,线程休眠状态
    蓝色:runnable,线程就绪状态
    绿色:running,线程运行状态
    从掉帧的的线程的运行状态判断,在掉帧的时候,UI线程状态色颜色为长时间灰色,处于sleeping状态。直接原因找到了,找到导致卡顿的元凶近了一步。
    导致UI线程挂起的线程,一般也是将UI线程唤醒的线程。
    在traceview中双击UI线程结束休眠后,变成就绪的第一个状态,也就是从灰色变成蓝色的第一个状态,可以发现,导致挂起的线程的线程号为27005。


    捕获2.PNG

    在traceview中搜索27005,可以知道此线程名为RenderThread,也就是硬件加速专门用来渲染的线程。


    捕获3.PNG

    并且从图中可看出在UI线程被唤醒前,RenderThread线程刚刚执行完syncFrameState方法。


    捕获4.PNG

    RenderThread的工作流程

    RenderThread的工作流程可以参考 https://www.jianshu.com/p/bc1c1d2fadd1
    简单的来说RenderThread的工作流程为:
    1.将Main Thread维护的Display List同步到Render Thread维护的Display List去。这个同步过程由Render Thread执行,但是Main Thread会被阻塞住。
    2.如果能够完全地将Main Thread维护的Display List同步到Render Thread维护的Display List去,那么Main Thread就会被唤醒,此后Main Thread和Render Thread就互不干扰,各自操作各自内部维护的Display List;否则的话,Main Thread就会继续阻塞,直到Render Thread完成应用程序窗口当前帧的渲染为止。
    3.Render Thread在渲染应用程序窗口的Root Render Node的Display List之前,首先将那些设置了Layer的子Render Node的Display List渲染在各自的一个FBO上,接下来再一起将这些FBO以及那些没有设置Layer的子Render Node的Display List一起渲染在Frame Buffer之上,也就是渲染在从Surface Flinger请求回来的一个图形缓冲区上。这个图形缓冲区最终会被提交给Surface Flinger合并以及显示在屏幕上。

    注意第二步:“如果能够完全地将Main Thread维护的Display List同步到Render Thread维护的Display List去,那么Main Thread就会被唤醒”,这个就验证了我们从traceview中看到的在RenderThread完成syncFrameState之后,UI线程被唤醒。

    综述

    掉帧的根本原因是RenderThread的绘制时间过长。UI线程在Draw方法中,完成将数据放入displaylist之后会挂起,等待Render Thread将displaylist的数据同步,也就是完成syncFrameState方法。如果RenderThread一直在绘制,那么UI线程挂起的时间就会很长,整个绘制市场就会超过16ms,最终导致掉帧。

    相关文章

      网友评论

          本文标题:开启硬件加速导致动画掉帧分析

          本文链接:https://www.haomeiwen.com/subject/ielmkctx.html