View 的视觉效果正是通过这一整条复杂的链路一步步展示出来的，有了这个前提，那就可以得出一个结论：上述任意链路发生卡顿，均会造成卡顿。

我们再回到 Vsync 的话题，消费 Vsync 的双方分别是 App 和 sf，其中 App 代表的是生产者，sf 代表的是消费者，两者交付的中间产物则是 surface buffer。

再具体一点，生产者大致可以分为两类，一类是以 window 为代表的页面，也就是我们平时所看到的 view 树这一套；另一类是以视频流为代表的可以直接和 surface 完成数据交换的来源，比如相机预览等。

对于一般的生产者和消费者模式，我们知道会存在相互阻塞的问题。比如生产者速度快但是消费者速度慢，亦或是生产者速度慢消费者速度快，都会导致整体速度慢且造成资源浪费。所以 Vsync 的协同以及双缓冲甚至三缓冲的作用就体现出来了。

思考一个问题：是否缓冲的个数越多越好？过多的缓冲会造成什么问题？

答案是会造成另一个严重的问题：lag，响应延迟

这里结合 view 的一生，我们可以把两个流程合在一起，让我们的视角再高一层：

这里我们来回答第三个问题，从系统的渲染架构上来说，机制上的保护主要有几方面：

1. Vsync 机制的协同；
2. 多缓冲设计；
3. surface 的提供；
4. 同步屏障的保护；
5. 硬件绘制的支持；
6. 渲染线程的支持；
7. GPU 合成加速；

这些机制上的保护在系统层面最大程度地保障了 App 体验的流畅性，但是并不能帮我们彻底解决卡顿。为了提供更加流畅的体验，一方面，我们可以加强系统的机制保护，比如 FWatchDog；另一方面，需要我们从 App 的角度入手，治理应用内的卡顿问题。

经过上面的讨论，我们得出一个卡顿分析的核心理论支撑：渲染机制中的任何流转过程发生异常，均会造成卡顿。

那么接下来，我们逐个分析，看看都会有哪些原因可能造成卡顿。

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 的数量也会影响帧的整体延迟，不过是系统行为，不能干预。

除了上述的渲染流程引起的卡顿，还有一些其他的因素，典型的就是视频流。

1. 渲染卡顿：主要是 TextureView 渲染，textureview 跟随 window 共用一个 surface，每一帧均需要一起协同渲染并相互影响，UI 卡顿会造成视频流卡顿，视频流的卡顿有时候也会造成 UI 的卡顿；
2. 解码：解码主要是将数据流解码为 surface 可消费的 buffer 数据，是除了网络外最重要的耗时点。现在我们一般都会采用硬解，比软解的性能高很多。但是帧的复杂度、编码算法的复杂度、分辨率等也会直接导致解码耗时被拉长；
3. OpenGL 处理：有时会对解码完成的数据做二次处理，这个如果比较耗时会直接导致渲染卡顿；
4. 网络：这个就不再赘述了，包括 DNS 节点优选、cdn 服务、GOP 配置等；
5. 推流异常：这个属于数据源出了问题，这里暂时以用户侧的视角为主，暂不讨论。

2.5.3 系统负载

1. 内存：内存的吃紧会直接导致 GC 的增加甚至 ANR，是造成卡顿的一个不可忽视的因素；
2. CPU：CPU 对卡顿的影响主要在于线程调度慢、任务执行的慢和资源竞争，比如降频会直接导致应用卡顿；
3. GPU：GPU 的影响见渲染流程，但是其实还会间接影响到功耗和发热；
4. 功耗/发热：功耗和发热一般是不分家的，高功耗会引起高发热，进而会引起系统保护，比如降频、热缓解等，间接的导致卡顿。

我们此处再整体整理并归类，为了更完备一些，这里将推流也放了上来。在一定程度上，我们遇到的所有卡顿问题，均能在这里找到理论依据，这也是指导我们优化卡顿问题的理论支撑。

Diggo 是字节自研的一个开放的开发调试工具平台，是一个集「评价、分析、调试」为一体的，一站式工具平台。内置性能测评、界面分析、卡顿分析、内存分析、崩溃分析、即时调试等基础分析能力，可为产品开发阶段提供强大助力。

这里主要针对 UI 卡顿和 UI/流相互影响打来的卡顿。

对于 UI 卡顿来说，我们手握卡顿优化的 8 板大斧子，所向披靡：

1. 下线代码；
2. 减少执行次数；
3. 异步；
4. 打散；
5. 预热；
6. 复用；
7. 方案优化；
8. 硬件加速；

总体思路就是「能不干就不干、能少干就少干、能早点干就早点儿干、能晚点儿干就晚点儿干、能让别人干就让别人干、能干完一次当 10 次就只干一次，实在不行，再考虑自己大干一场」。

这里例举出一些常见的优化思路，注意这一定也不可能是全部，如果有其他好的优化思路，我们可以一起交流。