在分析完是不是由App不下request導(dǎo)致的lag或者卡頓之后， 我們?cè)诳匆幌率遣皇莂pp不reqeustRender導(dǎo)致卡頓或者lag.
我們前面說(shuō)到可以通過(guò) 是不是有 onDrawFrame 或者 在onFrameAvailable增加log 中看有沒(méi)有新幀到來(lái)。 如果沒(méi)有這兩個(gè)log， 大概率說(shuō)明我們沒(méi)有繪制， 從而沒(méi)有消耗Image， 導(dǎo)致沒(méi)有辦法接受新幀了。
我們也可以通過(guò)perfetto來(lái)看， 只要看三個(gè)指標(biāo): cameraservice中的preview, 這個(gè)代表cameraservice是否給App上幀， 另兩個(gè)是App中的 SurfaceTexutre和SurfaceView， SurfaceTexture會(huì)顯示updateTexture的時(shí)間， SurfaceView中會(huì)顯示Buffer的數(shù)量， 先看一下正常情況：
正常情況下， preview中新的幀來(lái)了， 然后 SurfaceTexutre中有一個(gè)突起， 去updateTexture獲取這一幀?！∪缓蠼唤o SurfaceView 進(jìn)行渲染顯示， 這個(gè)時(shí)候SurfaceView顯示的Buffer數(shù)量就會(huì)變成２， 渲染顯示完成之后Buffer數(shù)量就會(huì)變成１。
所以我們可以看 preview中有新的幀過(guò)來(lái)之后， 看一下SurfaceTexture中是否有突起調(diào)用了updateTexture去獲取幀， 如果沒(méi)有， 那幾乎就是我們的問(wèn)題了。
請(qǐng)注意， 這個(gè) preview tag是我們自己加的， 在 Camera3OutputStream 的 queueBufferToConsumer的時(shí)候調(diào)用 dumpDropInfo 這個(gè)方法里面添加的, 調(diào)用了 trace.h 里面的方法增加的。
perfetto常用的SQL
我們最常用的就是三張表， 一個(gè) counter_track表， 一個(gè)是 counter表， 一個(gè)是 slice表
slice是代碼了一個(gè)事情發(fā)生的一段時(shí)間，我們通過(guò)Trace.java增加的trace就都是 slice.
Counter代表了持續(xù)不斷的事件， 但是事件的值可以不一樣， 我們?cè)赾ameraservice中加的 preview就是counter.
slice和counter都屬于track.
一般我們都是從 counter_track 表中 根據(jù)名字找到對(duì)應(yīng)的 track_id, 然后在根據(jù)這個(gè)track_id從 slice表或者counter表中獲得對(duì)應(yīng)track_id的所有數(shù)據(jù)。
