通过 perfetto分析预览丢帧或者预览卡顿的问题。
- 看 cameraservice 进程， 找到 frame capture 这个tag, 这个tag是在
Camera3Device的sendRequestBatch中处理的， 预览也是走的这个流程。 这个tag的结束是在Camera3OutputUtil中的removeInflightRequestIfNeeded, 就是在底层处理完这个request之后。
这个tag的时长，就是 cameraservice发送到底层处理并返回image的总时长， 比如
image.png
上图中这一帧就处理了324ms， 当然这并不一定能说明预览卡，只能说明当前需要排队处理的request比较多。 这个 frame capture也有30ms就处理完的， 就不一一列举了。
frame capture有明显断层的， 这就可能发生预览卡顿了， 比如下面这两个图
-
当出现了这种情况之后， 我们就要看 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肯定主动停止了预览， 然后又开启了
请注意finishCameraStreamingOps这个有两个调用时机， 一个是 cameraIdle的时候， 一个是camera disconnect的时候。
- 如果说帧率有lag, 底层还甩锅说他们的帧率是达标的， 怎么办。
首先我们要在onDrawFrame的时候增加计数， 看一下我们绘制的帧率是多少(可以看一下patch).
然后在找底层要一下底层返回image的log, 高通一般是:
ReturnFrameworkResult, ProcessCaptureResult 或者 process_capture_result， 证明我们的onDrawFrame和底层返回的是匹配的就可以。
我们还可以通过如下的截图看到， 读取yuv格式的Image到byte数组的时候是CPU密集型的任务， 然后 从byte数组生成 YUVImage， 在用YUVImage compressJpeg的时候， 也是 CPU密集型的任务。
