消息调度：主要是 doframe Message 的调度，这就是一个普通的 Handler 调度，如果这个调度被其他的 Message 阻塞产生了时延，会直接导致后续的所有流程不会被触发 。这里直播建立了一个 FWtachDog 机制，可以通过优化消息调度达到插帧的效果，使得界面更加流畅；input 处理：input 是一次 Vsync 调度最先执行的逻辑，主要处理 input 事件 。如果有大量的事件堆积或者在事件分发逻辑中加入大量耗时业务逻辑，会造成当前帧的时长被拉大，造成卡顿 。抖音基础技术同学也有尝试过事件采样的方案，减少 event 的处理，取得了不错的效果；动画处理：主要是 animator 动画的更新，同理，动画数量过多，或者动画的更新中有比较耗时的逻辑，也会造成当前帧的渲染卡顿 。对动画的降帧和降复杂度其实解决的就是这个问题；view 处理：主要是接下来的三大流程，过度绘制、频繁刷新、复杂的视图效果都是此处造成卡顿的主要原因 。比如我们平时所说的降低页面层级，主要解决的就是这个问题；measure/layout/draw：view 渲染的三大流程，因为涉及到遍历和高频执行，所以这里涉及到的耗时问题均会被放大，比如我们会降不能在 draw 里面调用耗时函数，不能 new 对象等等；DisplayList 的更新：这里主要是 canvas 和 displaylist 的映射，一般不会存在卡顿问题，反而可能存在映射失败导致的显示问题；OpenGL 指令转换：这里主要是将 canvas 的命令转换为 OpenGL 的指令，一般不存在问题 。不过这里倒是有一个可以探索的点，会不会存在一类特殊的 canvas 指令，转换后的 OpenGL 指令消耗比较大，进而导致 GPU 的损耗？有了解的同学可以探讨一下；buffer 交换：这里主要指 OpenGL 指令集交换给 GPU，这个一般和指令的复杂度有关 。一个有意思的事儿是这里一度被我们作为线上采集 GPU 指标的数据源，但是由于多缓冲的因素数据准确度不够被放弃了；GPU 处理：顾名思义，这里是 GPU 对数据的处理，耗时主要和任务量和纹理复杂度有关 。这也就是我们降低 GPU 负载有助于降低卡顿的原因；layer 合成：这里主要是 layer 的 compose 的工作，一般接触不到 。偶尔发现 sf 的 vsync 信号被 delay 的情况，造成 buffer 供应不及时，暂时还不清楚原因；光栅化/Display：这里暂时忽略，底层系统行为；Buffer 切换：主要是屏幕的显示，这里 buffer 的数量也会影响帧的整体延迟，不过是系统行为，不能干预 。2.5.2 视频流除了上述的渲染流程引起的卡顿，还有一些其他的因素，典型的就是视频流 。
- 渲染卡顿：主要是 TextureView 渲染，textureview 跟随 window 共用一个 surface，每一帧均需要一起协同渲染并相互影响，UI 卡顿会造成视频流卡顿，视频流的卡顿有时候也会造成 UI 的卡顿；
- 解码：解码主要是将数据流解码为 surface 可消费的 buffer 数据，是除了网络外最重要的耗时点 。现在我们一般都会采用硬解，比软解的性能高很多 。但是帧的复杂度、编码算法的复杂度、分辨率等也会直接导致解码耗时被拉长；
- OpenGL 处理：有时会对解码完成的数据做二次处理，这个如果比较耗时会直接导致渲染卡顿；
- 网络：这个就不再赘述了，包括 DNS 节点优选、cdn 服务、GOP 配置等；
以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!
「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：
