systrace分析 之 问题初步定位

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 方式进一步处理