预览卡顿丢帧的问题

通过　perfetto分析预览丢帧或者预览卡顿的问题。

1. 看　cameraservice　进程，　找到 frame capture 这个tag, 这个tag是在　Camera3Device的sendRequestBatch中处理的，　预览也是走的这个流程。　这个tag的结束是在Camera3OutputUtil中的removeInflightRequestIfNeeded, 就是在底层处理完这个request之后。
   这个tag的时长，就是　cameraservice发送到底层处理并返回image的总时长，　比如
   
   image.png
   
   上图中这一帧就处理了324ms，　当然这并不一定能说明预览卡，只能说明当前需要排队处理的request比较多。　这个　frame capture也有30ms就处理完的，　就不一一列举了。

frame capture有明显断层的，　这就可能发生预览卡顿了，　比如下面这两个图

image.png

image.png

2. 当出现了这种情况之后，　我们就要看　cameraservice的　C3Dev-ReqQueu这个线程对应的时间点是不是有request下发，　这个是Queue里面的Request是App给的。　如下图

   
   
   image.png

我们可以看到，　在预览卡顿的时候，　App有一段时间就没有给底层下发request.

因为App的预览流是repeating的，　所以这段时间之内，　我们应该是调用了stopReating，　abortCapture等方法。

C3Dev-id-ReqQueu这种是对应cameraid的requestThread打印的。在Camera3Device中可以看到。

尤其是我们放大观察，　发现我们在waitForNextRequest的时候，　还调用了finishCameraStreamingOps, 过了一段时间又调用startCameraStreamingOps, 说明App肯定主动停止了预览，　然后又开启了

image.png

请注意finishCameraStreamingOps这个有两个调用时机，　一个是　cameraIdle的时候，　一个是camera disconnect的时候。

3. 如果说帧率有lag, 底层还甩锅说他们的帧率是达标的，　怎么办。

首先我们要在onDrawFrame的时候增加计数，　看一下我们绘制的帧率是多少(可以看一下patch).
然后在找底层要一下底层返回image的log, 高通一般是:
ReturnFrameworkResult, ProcessCaptureResult 或者　process_capture_result，　证明我们的onDrawFrame和底层返回的是匹配的就可以。

我们还可以通过如下的截图看到，　读取yuv格式的Image到byte数组的时候是CPU密集型的任务，　然后　从byte数组生成　YUVImage，　在用YUVImage　compressJpeg的时候，　也是　CPU密集型的任务。

image.png