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


2.5 再看卡顿的成因经过上面的讨论 , 我们得出一个卡顿分析的核心理论支撑:渲染机制中的任何流转过程发生异常 , 均会造成卡顿 。
那么接下来 , 我们逐个分析 , 看看都会有哪些原因可能造成卡顿 。
2.5.1 渲染流程

  1. Vsync 调度:这个是起始点 , 但是调度的过程会经过线程切换以及一些委派的逻辑 , 有可能造成卡顿 , 但是一般可能性比较小 , 我们也基本无法介入;
  2. 消息调度:主要是 doframe Message 的调度 , 这就是一个普通的 Handler 调度 , 如果这个调度被其他的 Message 阻塞产生了时延 , 会直接导致后续的所有流程不会被触发 。这里直播建立了一个 FWtachDog 机制 , 可以通过优化消息调度达到插帧的效果 , 使得界面更加流畅;
  3. input 处理:input 是一次 Vsync 调度最先执行的逻辑 , 主要处理 input 事件 。如果有大量的事件堆积或者在事件分发逻辑中加入大量耗时业务逻辑 , 会造成当前帧的时长被拉大 , 造成卡顿 。抖音基础技术同学也有尝试过事件采样的方案 , 减少 event 的处理 , 取得了不错的效果;
  4. 动画处理:主要是 animator 动画的更新 , 同理 , 动画数量过多 , 或者动画的更新中有比较耗时的逻辑 , 也会造成当前帧的渲染卡顿 。对动画的降帧和降复杂度其实解决的就是这个问题;
  5. view 处理:主要是接下来的三大流程 , 过度绘制、频繁刷新、复杂的视图效果都是此处造成卡顿的主要原因 。比如我们平时所说的降低页面层级 , 主要解决的就是这个问题;
  6. measure/layout/draw:view 渲染的三大流程 , 因为涉及到遍历和高频执行 , 所以这里涉及到的耗时问题均会被放大 , 比如我们会降不能在 draw 里面调用耗时函数 , 不能 new 对象等等;
  7. DisplayList 的更新:这里主要是 canvas 和 displaylist 的映射 , 一般不会存在卡顿问题 , 反而可能存在映射失败导致的显示问题;
  8. OpenGL 指令转换:这里主要是将 canvas 的命令转换为 OpenGL 的指令 , 一般不存在问题 。不过这里倒是有一个可以探索的点 , 会不会存在一类特殊的 canvas 指令 , 转换后的 OpenGL 指令消耗比较大 , 进而导致 GPU 的损耗?有了解的同学可以探讨一下;
  9. buffer 交换:这里主要指 OpenGL 指令集交换给 GPU , 这个一般和指令的复杂度有关 。一个有意思的事儿是这里一度被我们作为线上采集 GPU 指标的数据源 , 但是由于多缓冲的因素数据准确度不够被放弃了;
  10. GPU 处理:顾名思义 , 这里是 GPU 对数据的处理 , 耗时主要和任务量和纹理复杂度有关 。这也就是我们降低 GPU 负载有助于降低卡顿的原因;
  11. layer 合成:这里主要是 layer 的 compose 的工作 , 一般接触不到 。偶尔发现 sf 的 vsync 信号被 delay 的情况 , 造成 buffer 供应不及时 , 暂时还不清楚原因;
  12. 光栅化/Display:这里暂时忽略 , 底层系统行为;
  13. Buffer 切换:主要是屏幕的显示 , 这里 buffer 的数量也会影响帧的整体延迟 , 不过是系统行为 , 不能干预 。


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

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