一文读懂直播卡顿优化那些事儿 如何解决直播卡顿( 二 )



  1. Vsync 调度:很多同学的一个认知误区在于认为 vsync 是每 16ms 都会有的 , 但是其实 vsync 是需要调度的 , 没有调度就不会有回调;
  2. 消息调度:主要是 doframe 的消息调度 , 如果消息被阻塞 , 会直接造成卡顿;
  3. input 处理:触摸事件的处理;
  4. 动画处理:animator 动画执行和渲染;
  5. view 处理:主要是 view 相关的遍历和三大流程;
  6. measure、layout、draw:view 三大流程的执行;
  7. DisplayList 更新:view 硬件加速后的 draw op;
  8. OpenGL 指令转换:绘制指令转换为 OpenGL 指令;
  9. 指令 buffer 交换:OpenGL 的指令交换到 GPU 内部执行;
  10. GPU 处理:GPU 对数据的处理过程;
  11. layer 合成:surface buffer 合成屏幕显示 buffer 的流程;
  12. 光栅化:将矢量图转换为位图;
  13. Display:显示控制;
  14. buffer 切换:切换屏幕显示的帧 buffer;
Google 将这个过程划分为:其他时间/VSync 延迟、输入处理、动画、测量/布局、绘制、同步和上传、命令问题、交换缓冲区 。也就是我们常用的 GPU 严格模式 , 其实道理是一样的 。到这里 , 我们也就回答出来了第二个问题:16ms 内都需要完成什么?
准确地说 , 这里仍可以进一步细化:16ms 内完成 APP 侧数据的生产;16ms 内完成 sf layer 的合成

View 的视觉效果正是通过这一整条复杂的链路一步步展示出来的 , 有了这个前提 , 那就可以得出一个结论:上述任意链路发生卡顿 , 均会造成卡顿 。
2.3 生产者和消费者
我们再回到 Vsync 的话题 , 消费 Vsync 的双方分别是 App 和 sf , 其中 App 代表的是生产者 , sf 代表的是消费者 , 两者交付的中间产物则是 surface buffer 。
再具体一点 , 生产者大致可以分为两类 , 一类是以 window 为代表的页面 , 也就是我们平时所看到的 view 树这一套;另一类是以视频流为代表的可以直接和 surface 完成数据交换的来源 , 比如相机预览等 。
对于一般的生产者和消费者模式 , 我们知道会存在相互阻塞的问题 。比如生产者速度快但是消费者速度慢 , 亦或是生产者速度慢消费者速度快 , 都会导致整体速度慢且造成资源浪费 。所以 Vsync 的协同以及双缓冲甚至三缓冲的作用就体现出来了 。
思考一个问题:是否缓冲的个数越多越好?过多的缓冲会造成什么问题?

答案是会造成另一个严重的问题:lag , 响应延迟
这里结合 view 的一生 , 我们可以把两个流程合在一起 , 让我们的视角再高一层:
2.4 机制上的保护这里我们来回答第三个问题 , 从系统的渲染架构上来说 , 机制上的保护主要有几方面:
  1. Vsync 机制的协同;
  2. 多缓冲设计;
  3. surface 的提供;
  4. 同步屏障的保护;
  5. 硬件绘制的支持;
  6. 渲染线程的支持;
  7. GPU 合成加速;
这些机制上的保护在系统层面最大程度地保障了 App 体验的流畅性 , 但是并不能帮我们彻底解决卡顿 。为了提供更加流畅的体验 , 一方面 , 我们可以加强系统的机制保护 , 比如 FWatchDog;另一方面 , 需要我们从 App 的角度入手 , 治理应用内的卡顿问题 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: