拍照算法影响预览导致卡顿的分析流程和trace简析

MTK trace的分析小结：
拍照的算法集成中导致在算法处理过程中预览卡顿；
分析过程与步骤：
1、首先看一下拍照的CPU loading，通过安装对应的测试CPU loading的apk测试在拍照过程中loading 并不高，为此可以首先排除在算法处理过程中并不是因为CPU loading过高造成的预览卡顿；
2、测试一下每次拍照的们Memory是否正常，看一看是不是算法内部有没存泄漏的问题（实际就存在的现象并不需要此步骤的测试，如果是一直拍照越来越卡的过程中可以试一下，而本问题并不是越拍越卡，而是每次拍照过程中都卡）；
3、分析log，首先分析拍照过程中的fps,此处通过搜寻关键词是frame timer关键词来检索帧率，次关键词可以看到每一帧数据在在不同阶段占用的时间；
Line 40561: 09-02 12:00:39.982 705 14030 D MtkCam/StreamingPipe/Timer: [print]Frame timer [# 122/ 0][t 417][io 0][tof 0/ 0][d 0/ 0][a 43/ 1/ 41][p2nr 0/ 0/ 0][vnr 0/ 0][am 0][b 0/ 0][tpi( 1/ 0)/( 0/ 0)/( 0/ 0)][vmdp363][h 0/ 0/ 0][e 0][r 0/ 0][f 0/ 0][w 0/ 0/ 0][disp 0/ 0][async 0/ 0][p2sm 0/ 0/ 0][fps7.96/7.96/ 5/ 30]
从这个log中可以看到在此次预览的帧率只有fps7.96，[t 417]为总共这帧数据的还在占用时间，而MDP的时间占用为363 [vmdp363]，从这个log数据可以看出是算法的内部的操作阻塞了MDP的处理；但是多次的拍照（每次都是预览卡顿）并不是每次都能抓到类似的帧率很低的数据，有时帧率显示正常但是预览一直卡顿，多以在此并不能确认预览的卡顿真是是因为MDP阻塞造成的；
4、抓取trace来分析；
首先需要抓取到一次拍照的获取全部帧的一个过程，抓取trace过程中时间要快，按下拍照键预览起来后马上停止，因为时间久的话后面的预览的trace会覆盖掉前面的数据；使用的是MTK提供的ftrace来抓取的；如果确认本次拍照是否抓取数据可以从关键词 intent：2来判断，2代表的是拍照，1是预览；这比较直接简单的知道是否取到了所有的拍照帧；
另外我发现可以从其他的trace获取获取信息；

![这个拍照的有[CaptureNode::queue]关键词且本次拍照的是多帧的8帧的算法，看下capture node是否有queue出八帧数据(https://img-blog.csdnimg.cn/20200915202843952.png#pic_center)
从此处可以往后看，因为后面的是拍照后面的预览帧数据，首先也是全局去看一下预览的帧的数据那个地方有差异；比如此题中


以上只是我目前的分析状态，后续进展会再更新；
··根据MTK给出的分析解析，继续上次关于trace的分析，找到更好根据trace来找问题点的方式；··
1、关于预览卡顿可以从APP的trace中去分析更直观一点；通过APP中的trace surficeTexture的数据回显来看比较方便；

将此处空隙大的回显处选中查看此过程中的具体都有哪些操作；
2、另外可以从camsaerahalserver 进程中的APPMgr的数据的callback来和上面的surfaceTeture来对应分析