在分析完是不是由App不下request导致的lag或者卡顿之后， 我们在看一下是不是app不reqeustRender导致卡顿或者lag.
我们前面说到可以通过 是不是有 onDrawFrame 或者 在onFrameAvailable增加log 中看有没有新帧到来。 如果没有这两个log， 大概率说明我们没有绘制， 从而没有消耗Image， 导致没有办法接受新帧了。
我们也可以通过perfetto来看， 只要看三个指标: cameraservice中的preview, 这个代表cameraservice是否给App上帧， 另两个是App中的 SurfaceTexutre和SurfaceView， SurfaceTexture会显示updateTexture的时间， SurfaceView中会显示Buffer的数量， 先看一下正常情况：
image.png
正常情况下， preview中新的帧来了， 然后 SurfaceTexutre中有一个突起， 去updateTexture获取这一帧。 然后交给 SurfaceView 进行渲染显示， 这个时候SurfaceView显示的Buffer数量就会变成２， 渲染显示完成之后Buffer数量就会变成１。
所以我们可以看 preview中有新的帧过来之后， 看一下SurfaceTexture中是否有突起调用了updateTexture去获取帧， 如果没有， 那几乎就是我们的问题了。
请注意， 这个 preview tag是我们自己加的， 在 Camera3OutputStream 的 queueBufferToConsumer的时候调用 dumpDropInfo 这个方法里面添加的, 调用了 trace.h 里面的方法增加的。
perfetto常用的SQL
我们最常用的就是三张表， 一个 counter_track表， 一个是 counter表， 一个是 slice表
slice是代码了一个事情发生的一段时间，我们通过Trace.java增加的trace就都是 slice.
Counter代表了持续不断的事件， 但是事件的值可以不一样， 我们在cameraservice中加的 preview就是counter.
slice和counter都属于track.
一般我们都是从 counter_track 表中 根据名字找到对应的 track_id, 然后在根据这个track_id从 slice表或者counter表中获得对应track_id的所有数据。
网友评论