【MTK-Camera Capture、Preview request解析】

  Camera流程分析中最关键的是关于拍照、预览请求的处理以及流控的各种解析，从不同的request里面可以分析出大量的其他信息，对流需要做什么处理以及做了什么处理，这个是研究拍照、预览性能的必要经过。

1.通过Log对Camera流程check

• 06:21:22.435 应用层开始openCamera

• 06:21:22.471 Open前摄CameraDevice打开成功得到onOpen返回cameraProxy对应底层device
  
• 06:21:22.672 下发前摄开启预览所需功能对应的session

• 06:21:22.702 创建Camera前摄所需功能的session成功，且通过onConfigured返回CameraCaptureSessionProxy对应底层的CaptureSession

• 06:21:22.719 HAL接收到应用层下发的预览请求

• 06:21:25.737拍照动作下发:
  
• 06:21:25.784 HAL层接收到下发的capture Request
  
• 06:21:25.877 HAL层处理完拍照帧之后，提供预览帧数据流

• 06:21:26.020 拿到拍照之后的缩略图
  
• 06:21:26.074 拍照完成，UI恢复

• 06:21:28.225 拿到拍照之后的jpeg格式图片，且将拍照button恢复
  

2.拍照之后预览卡死2-3s问题check

  对之前项目中遇到的预览卡死现象进行分析，当然造成预览卡死的原因不仅仅这一种，肯定需要具体情况具体分析。

异常log分析：

  因为问题是出现在虚化模式拍照之后，预览卡死2-3s之后才会恢复，处理问题的第一反应是需要check底层对capture、preview request的相关处理进而定位问题出现的时间节点，查看log可以看出18:20:03进入虚化模式，18:20:06下发拍照request，18:20:09预览request才处理预览请求，预览卡死即发生在18:20:06-18:20:09这个过程中。

  问题发生的时间点找到了，但是定位问题、解决问题的过程总是充满曲折，之前项目单单处理这个问题就花费了好长时间。现在就不去讨论咋么排除、定位问题的了，直接check问题点。

  根据之前的分析发现，18:20:09、18:20:11俩次拍照之前的200ms左右时间都会进行一次configureStrean重新配流的操作，这个操作就会耗费2s+的时间，同时也是导致预览流上来慢的原因。

  下一步需要check为什么会在每一次发送拍照请求之后要重新配流的异常原因。

  定位到这边离破案就不远了，但是还是经过了一段较长时间的折磨才最终解决了问题，直接上答案。

  最后定位到预览和拍照下发request时候要处理的Metadata的数量不一致导致。

  18:20:03 时间点刚进入预览模式进行配流操作，下发metadata数量为7。

  18:20:05 时间点出出发拍照模式，因为处理的metadata数量不一致，要重新进行一次配流，进而出发reconfig的操作，导致耗时增加了2s+。

  下发capture request前后有触发reconfig是因为，app有下发的request中包含不同的session key导致（sessionkey不一致会导致hal层做reconfig）, app 下发session key（com.mediatek.control.capture.postviewsize）逻辑有误造成。

3.同一型号版本的衍生类拍照耗时有的较慢问题分析

  之前项目中有发现同一型号的衍生项目的俩台机型之前拍照的耗时差异比较大，客户对此提出疑问。对于系统代码处理流程而言基本是一致的不会产生较大差异，需要对不同型号手机的拍照流程进行分析才能找到造成耗时差异的原因。

• 耗时较长机型的拍照请求的处理分析：
• 下发拍照请求时间点 :

• 针对拍照请求进行的相关处理流程

耗时较短机型的拍照请求的处理分析:

  通过对俩款机型拍照之后request的分析，发现主要的耗时操作在于有一款进行了多帧处理，一款没有进行多帧降噪的处理，问题点定位到了，解决起来就会快很多。