预览卡顿的问题，首先第一想法就是看下帧率，帧率小，自然会卡顿。根据人眼视觉暂留原理，帧率小于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.084728Line 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 msLine 6161: M2386B3  11-23 16:44:28.652   464 17405 I gc05a2_sharkl2: 162, gc05a2_drv_calc_exposure: fps = 30.084728Line 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]73Line 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]71Line 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]70Line 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的低配版本，最开始的想法是问供应商有没有针对低配版的轻量级美颜算法库，得知没有后，平台建议在低配版本上通过拉频的方式提高性能：在打开美颜将频点提到最高，关闭美颜在恢复。尝试这个方案是有效的，但是拉频会涉及到功耗，所以这个方案也只能算一个备选方案吧。

本篇主要是想告诉大家，在遇到预览卡顿类的问题时，需要从哪些方面去排查，大方向找准，在针对具体问题场景去做优化。