1. 什么是卡顿希望本文可以带给大家一个相对全局的视角看待卡顿问题，认识到卡顿是什么、卡顿的成因、卡顿的分类、卡顿的优化和一些经验积累，有的放矢地解决 App 流畅性问题。接下来会从以下五个方面进行讲述：
✦什么是卡顿
✦为什么会发生卡顿
✦如何评价卡顿
✦如何优化卡顿
✦加入我们
卡顿，顾名思义就是用户体感界面不流畅。我们知道手机的屏幕画面是按照一定频率来刷新的，理论上讲，24 帧的画面更新就能让人眼感觉是连贯的。但是实际上，这个只是针对普通的视频而言。对于一些强交互或者较为敏感的场景来说，比如游戏，起码需要 60 帧，30 帧的游戏会让人感觉不适；位移或者大幅度动画 30 帧会有明显顿挫感；跟手动画如果能到 90 帧甚至 120 帧，会让人感觉十分细腻，这也是近来厂商主打高刷牌的原因。
对于用户来说，从体感角度大致可以将卡顿分为以下几类：
这些体验对于用户可以说是非常糟糕的，甚至会引起感官的烦躁，进而导致用户不愿意继续停留在我们的 App。可以说，流畅的体验对于用户来说至关重要。
2. 为什么会发生卡顿用户体感的卡顿问题原因很多，且常常是一个复合型的问题，为了聚焦，这里暂只考虑真正意义上的掉帧卡顿。
2.1 绕不开的 VSYNC我们通常会说，屏幕的刷新率是 60 帧，需要在 16ms 内做完所有的操作才不会造成卡顿。但是这里需要明确几个基本问题：
- 为什么是 16ms？
- 16ms 内都需要完成什么？
- 系统如何尽力保证任务在 16ms 内完成？
- 16ms 内没有完成，一定会造成卡顿吗？
这里先回答第一个问题：为什么是 16ms。早期的 Android 是没有 vsync 机制的，CPU 和 GPU 的配合也比较混乱，这也造成著名的 tearing 问题，即 CPU/GPU 直接更新正在显示的屏幕 buffer 造成画面撕裂。后续 Android 引入了双缓冲机制，但是 buffer 的切换也需要一个比较合适的时机，也就是屏幕扫描完上一帧后的时机，这也就是引入 vsync 的原因。
早先一般的屏幕刷新率是 60FPS，所以每个 vsync 信号的间隔也是 16ms，不过随着技术的更迭以及厂商对于流畅性的追求，越来越多 90fps 和 120fps 的手机面世，相对应的间隔也就变成了 11ms 和 8ms。
那既然有了 VSYNC，谁在消费 VSYNC？其实 Android 的 VSYNC 消费者有两个，也就对应两类 VSYNC 信号，分别是 VSYNC-app 和 VSYNC-sf，所对应的也是上层 view 绘制和 surfaceFlinger 的合成，具体的我们接下来详细说。
这里还有一些比较有意思的点，有些厂商会有 vsync offset 的设计，App 和 sf 的 vsync 信号之间是有偏移量的，这也在一定程度上使得 App 和 sf 的协同效应更好。
2.2 View 颠沛流离的一生在讲下一 part 之前先引入一个话题：
一个 view 究竟是如何显示在屏幕上的？
我们一般都比较了解 view 渲染的三大流程，但是 view 的渲染远不止于此：
此处以一个通用的硬件加速流程来表征
- Vsync 调度：很多同学的一个认知误区在于认为 vsync 是每 16ms 都会有的，但是其实 vsync 是需要调度的，没有调度就不会有回调；
- 消息调度：主要是 doframe 的消息调度，如果消息被阻塞，会直接造成卡顿；
- input 处理：触摸事件的处理；
- 动画处理：animator 动画执行和渲染；
- view 处理：主要是 view 相关的遍历和三大流程；
- measure、layout、draw：view 三大流程的执行；
- DisplayList 更新：view 硬件加速后的 draw op；
- OpenGL 指令转换：绘制指令转换为 OpenGL 指令；
- 指令 buffer 交换：OpenGL 的指令交换到 GPU 内部执行；
- GPU 处理：GPU 对数据的处理过程；
- layer 合成：surface buffer 合成屏幕显示 buffer 的流程；
- 光栅化：将矢量图转换为位图；
- Display：显示控制；
- buffer 切换：切换屏幕显示的帧 buffer；
Google 将这个过程划分为：其他时间/VSync 延迟、输入处理、动画、测量/布局、绘制、同步和上传、命令问题、交换缓冲区。也就是我们常用的 GPU 严格模式，其实道理是一样的。到这里，我们也就回答出来了第二个问题：16ms 内都需要完成什么？
准确地说，这里仍可以进一步细化：16ms 内完成 APP 侧数据的生产；16ms 内完成 sf layer 的合成
