从Systrace看抖音Android Camera Bufferqueue渲染

网上大部分Systrace性能分析讲解BufferQueue都是从app走Choreographer 的角度来分析，但是最近开始分析一个抖音直播卡顿的问题发现走的流程有所差别，在此记录一下。

从Systrace的角度来看如下：

 Choreographer 放大如下：

可以看到 Choreographer的工作非常简单，UIThread未做draw等操作，就是简单的做了一个动画，而且每一帧都很均匀，也符合vsync信号，所以我们不能仅仅依据UI线程里的Frame表现就来推断一个应用是否卡顿。就比如我们这里显示的全都是绿帧。有一些游戏应用，和自己渲染的app会绕过这个流程。

判断卡顿关键还是要看SurfaceFlinger的合成表现，因为在安卓的平台最终都需要走SurfaceFlinger来进行最终的合成。

本次卡顿SurfaceFlinger的表现如下：

 

可以看到间隔的有收到message之后啥动作也没做的情况，因为没有图形合成，这时候给用户看到的就是卡顿的现象，其实这里是掉帧发生。

接下来就是要分析为何会有掉帧现象的发生，从SurfaceFlinger的BufferQueue消耗图形来看如下：

可以看到 这里的BufferQueue未及时提供，所有导致了后面SurfaceFlinger无法合成，所以此帧丢失。

从名字我们可以得知这个BufferQueue是由

提供，并且我们放大onMessageReceived如下：

 第一个onMessage通过acquireBuffer消耗了这个buffer，