app卡顿原因

•  绘制任务太重，绘制一帧内容耗时不能保证在16ms内完成。
•  主线程太忙，导致 VSync 信号来时还没准备好数据导致丢包。

那为啥是 16ms 呢？系统是怎么保证的呢？

Android 的显示过程可以简单概括为：应用层负责绘制，系统层负责渲染。应用层把经过测量、布局、绘制后的 surface 缓存数据，通过进程间通信传递到系统层服务，系统层中的 SuraceFlinger 把数据再渲染到显示屏幕上，通过 Android 的 VSYNC 刷新机制来刷新数据。

 

这里的跨进程通信是使用的匿名共享内存 SharedClient，每个应用程序和SurfaceFlinger 都会创建一个 SharedClient，每个 SharedClient 又最多可创建31个 SharedBufferStack，而每个 SharedBufferStack 又对应着该应用程序的一个窗口。每个 SharedBufferStack 中又会包含2个或3个缓冲区，CPU/GUP 计算并渲染的数据就是来自这里，之后显示到对应窗口，下面会具体说。

总结起来就是：应用层绘制到缓存区，SurfaceFlinger 把缓存区数据渲染到屏幕，由于是两个不同进程，所以使用 Android 的匿名共享内存 SharedClient。

 

当 CPU/GPU 的处理时间超过 16ms 时，第一个 VSync 就已经到来，但缓冲区 B 的数据还没有准备好，这样就只能继续显示之前的 A 数据，从而导致丢帧现象，而后面 B 完成后，又因为没有 VSync 信号，所以 CPU/GPU 只能等待下一个 VSync 信号的来临才能继续处理下一个数据，这就导致了中间有一大段时间被浪费掉了。

所以三缓冲技术来了，来看下图：

从图中可以看出，当 B 缓冲未准备好数据时，而 VSync 信号又来临了，C 缓冲区会接着处理下一帧数据，从而避免了 CPU/GPU 的浪费。但这不会解决丢帧的问题，所以这就要求我们不能让主线程“太忙”了，要避免任何有阻塞主线程的事情。

本章完，下节介绍一些优化手段和实际监控方案。