2、systrace分析 之 问题初步定位
- 1、找到问题点
- 2、有buffer，SF却什么没有取
- 2.1、GPU 处理时间长导致
- 2.2、区分HWC release 是否有异常：
- 2.3、SF 异常导致
- 2.4、SF 自身处理时间长
- 2.5、RenderThread处理时间长
- 3、案例分享
1、找到问题点
2、有buffer，SF却什么没有取
有tx buffer但sf 却什么都没有取，可以往下继续check 出帧process 的render thread 和 GPU complation /hwc complation的状态。
2.1 GPU 处理时间长
如下示例中，buffer TX 中有两个buffer，但SF 却没有去取，往下看，是前一帧的 waiting for GPU completion 在vsync-sf来的时候都没有完成。所以需要请GPU 进一步确认。
2.3、区分HWC release 是否有异常：
首先，需要先了解下HWC和GPU之间的fence是怎么样的一个过程？
. GPU拿的是acquireFence HWC拿的是releaseFence， GPU是绘图，HWC是合成显示，这两个是互相等待的关系，
. 要GPU画完这块buffer acquireFence放掉，SF才能拿去合成显示，
. 要driver完成合成显示，放掉releaseFence，GPU才能拿这块buffer去绘制，
. 如果此时可用的buffer不止一块，可以一边合成一边绘制下一张，但是如果下一张画完了当前帧的releaseFence没有放掉，当前帧合成还没完成，
就必须等待releaseFence放掉才能合下一帧
下图是两个案例，因为wait PreFence 和waiting for HWC release 的时间是平行的，所以第一例中，虽然没有HWC release的信息，但是也可以从wait PreFence 的时间来估算HWC 那边的时间。
2.3、SF 异常导致
如下surfaceflinger空缺点，上面对应的bufferTX 中有buffer，但VSYNC-SF 过来后，SurfaceFlinger却没有去取，检查测试app “android.settings”, 也没有GPU completion 时间长的问题，所以该部分可以请SurfaceFlinger的owner 进一步确认为何不取buffer。
2.4 SF 自身处理时间长
如下图中(120hz的刷新率，所以1 vsync = 8.333ms)，整个surfaceflinger 的UI thread 看起来很忙，无空闲时间。则直接进一步check SurfaceFlinger
2.5、RenderThread 处理时间长
如下实例中确认有tx buffer，但SF 没有去取是因为当前帧的GPU 合成还没有做完。
但是GPU合成没有做完的原因是因为RenderThread 前期处理时间是太长，queuebuffer trigger 的太晚。所以需要进一步确认 RenderThread处理时间长的原因
3、案例分享
如下图中，虽然Frames有很多黄灯的地方，但是SurfaceFlinger只有三个空缺点，所以只需要check 那三个空缺点掉帧的原因就好。
该案例为120hz的刷新率，所以1 vsync = 8.333ms
从图中UI thread 和 RenderThread的duration时间来看，都是UI Thread 的animation 时间较长导致。所以可以按照UI Thread 的check 方式进一步处理