预览卡顿的问题,首先第一想法就是看下帧率,帧率小,自然会卡顿。根据人眼视觉暂留原理,帧率小于24帧,人脸就会感知到卡顿。
帧率的概念在Camera中我们经常会提到,其实有3个帧率概念,从下往常看:
- sensro帧率
- AE帧率
- hal帧率
一般排查问题从底层往上看
sensor帧率:30,正常
Line 5988: M238607 11-23 16:44:28.527 464 17405 I gc05a2_sharkl2: 162, gc05a2_drv_calc_exposure: fps = 30.084728
Line 5989: M238608 11-23 16:44:28.527 464 17405 I gc05a2_sharkl2: 167, gc05a2_drv_calc_exposure: mode = 2, exposure_line = 1834, dummy_line= 16, frame_interval= 30 ms
Line 6161: M2386B3 11-23 16:44:28.652 464 17405 I gc05a2_sharkl2: 162, gc05a2_drv_calc_exposure: fps = 30.084728
Line 6162: M2386B4 11-23 16:44:28.652 464 17405 I gc05a2_sharkl2: 167, gc05a2_drv_calc_exposure: mode = 2, exposure_line = 1833, dummy_line= 205, frame_interval= 33 ms
AE帧率:30 正常
我们知道AE帧率会受环境亮度影响,亮度越低,帧率越低,但是本题的卡顿现象实在正常环境亮度下也会卡顿
Line 6159: M2386B1 11-23 16:44:28.652 464 17405 D Libae[Core]: 2019,aec_alg_status_printf:(auto):ae,0,unstb,face_unstb,unlock,50Hz,fps[8.33, 30.00]:30.00 cur-(s 1834(0.030001s),g 424,dmy 0),nxt:idx:239,(s 1833(0.030000s),g 411,dmy 205) bv:850,cur_l:(f:132.00, c:172,n:79.00),y_l:0,tar_l[71,75]73
Line 6217: M2386EA 11-23 16:44:28.667 464 17405 D Libae[Core]: 2019,aec_alg_status_printf:(auto):ae,1,unstb,face_unstb,unlock,50Hz,fps[8.33, 30.00]:30.00 cur-(s 1834(0.030001s),g 424,dmy 0),nxt:idx:238,(s 1833(0.030000s),g 399,dmy 205) bv:852,cur_l:(f:133.00, c:172,n:80.00),y_l:124,tar_l[69,73]71
Line 6352: M23876F 11-23 16:44:28.700 464 17405 D Libae[Core]: 2019,aec_alg_status_printf:(auto):ae,2,unstb,face_unstb,unlock,50Hz,fps[8.33, 30.00]:30.00 cur-(s 1834(0.030001s),g 424,dmy 0),nxt:idx:221,(s 1833(0.030000s),g 236,dmy 205) bv:852,cur_l:(f:133.00, c:173,n:80.00),y_l:124,tar_l[68,72]70
Line 6439: M2387C5 11-23 16:44:28.728 464 17405 D Libae[Core]: 2019,aec_alg_status_printf:(auto):ae,3,unstb,face_unstb,unlock,50Hz,fps[8.33, 30.00]:30.00 cur-(s 1833(0.030000s),g 411,dmy 205),nxt:idx:219,(s 1833(0.030000s),g 222,dmy 205) bv:857,cur_l:(f:133.00, c:173,n:80.00),y_l:126,tar_l[67,71]69
hal帧率
hal帧率有几种方式可以查看,比如过滤log中1s内 processCaptureRequest 的个数,或者cmr_prev中prev_set_preview_buffer的个数。我们以 processCaptureRequest 为例,看下打开美颜和关闭美颜下 1s内 processCaptureRequest 的个数。
结论如下:
hal打印 processCaptureRequest 的速度:
识别人脸:20次/s左右
不识别人脸:30次/s左右
本题的复现路径十分明确,同一环境下,同一时刻下,打开美颜就会卡顿,关闭美颜就明显流畅很多,也就能猜到大概率跟美颜算法有关了。
到这里我们看到确实是hal帧率偏慢,这时候我们可以抓trace看下更加详细的信息。
ps:trace是性能分析中常用的工具,但是我看trace比较少,对trace的理解比较浅
这是我抓到的一份打开美颜卡顿trace,可以看到在receivePreview的时候基本都在40几ms左右
而关闭美颜,没有卡顿的trace,在一次receivePreview的时候基本在10几ms左右
这里就与我们之前的猜想相符了,在receivePreview的时候,会跑美颜算法,导致了预览卡顿。
我们这个项目是2G的低配版本,最开始的想法是问供应商有没有针对低配版的轻量级美颜算法库,得知没有后,平台建议在低配版本上通过拉频的方式提高性能:在打开美颜将频点提到最高,关闭美颜在恢复。尝试这个方案是有效的,但是拉频会涉及到功耗,所以这个方案也只能算一个备选方案吧。
本篇主要是想告诉大家,在遇到预览卡顿类的问题时,需要从哪些方面去排查,大方向找准,在针对具体问题场景去做优化。