深入理解Android相机体系结构之十

安卓相机架构总结

Android 相机体系庞大且复杂，在我刚开始接触到该框架的时候，如盲人摸象一般，一点一点地在代码的世界中探索，在很长的一段时间内，都只能局限于某一个特定的区域，而且在解决问题的过程中，虽然通过对代码的深入梳理，最终都会顺利解决难题，但是到最后依然缺乏一个对于整个框架的理解，正如管中窥豹一般，只见细节而无法把握全貌。但是进入现在的公司之后，通过与相机前辈的沟通，我发现框架思维能力尤为重要，针对整个框架结构需要做到掌控全局，这样在遇到问题的时候便可以迅速定位，此时再进行代码层面的深入研究，发现问题根源，进而达到最终解决问题的目的。

Android相机体系随处可见接口与实现相分离的设计思想，而之前提及的对于体系结构的梳理正是按照其接口的逻辑定义来完成，再结合其接口具体实现，进而完善整个框架体系的代码地图的构建，而在本人六年多的相机开发过程中，经历了多次的Android 相机的框架调整，接口演变，接下来以个人经历为主线，简单为整个相机架构做一个总结。

起初，首先接触到的相机框架部分便是驱动，那时接触的是高通MSM8953平台，该平台还是采用的QCamera & MM-Camera框架，底层驱动并没有负责复杂业务逻辑控制，而是主要用于控制上下电，以及数据流的开启以及停止等，并且依然使用的是vb2进行图像帧缓冲区的管理，但是现如今的7150，其驱动部分俨然发生了翻天覆地的变化，高通为了配合UMD的业务处理，为驱动设计了一套KMD的框架，包含了复杂的业务处理流程，并且数据的管理也摒弃了vb2，采用了新的管理手段，赋予了驱动更多的职能。

之后由于工作需要，进一步将工作重心过渡到Camera HAL层，开发的平台依然是8953平台上，当时采用还是QCamera & MM-Camera框架，在该平台上见证了HAL接口的演变，首先接触最多的便是HAL1接口，该接口使用起来比较简单，通过几个特定接口分别实现预览、拍照以及录像的功能，此时，谷歌已经意识到该接口具有一定的局限，所以自然而然地进行接口的升级，提出了HAL2接口，但是由于接口定义存在问题，所有很快谷歌便摒弃了该接口，迅速推出HAL3接口，并且一直沿用至今。HAL3接口相比于HAL1，优势明显，通过将所有的采集流程高度抽象为一个统一逻辑，所有的场景都可以通过这一统一逻辑进行扩展，使该接口具有很强的灵活性和扩展性，所以通过这几代HAL接口的演变，不难得出一个结论，那便是接口的定义需要高度抽象，而抽象的目的就是为了更好的灵活性和可扩展性，就单单这一点而言，HAL3接口可以说是成功的。

在后续HAL层的开发过程中，也见证了HIDL接口的诞生，在进行Android 8.0系统的升级过程中，发现谷歌将Camera Hal Module从Camera Service 解耦出来，放入一个独立的进程Camera Provider中进行管理，而该进程负责向外暴露HIDL接口，对内完成对其的实现，并且开始针对system分区以及vendor分区进行了严格的权限控制，该目的显而易见，那边是将平台厂商的实现与谷歌Framework相分离，这样便可以进行快速的迭代升级。

进入现在的公司之后，工作内容进一步扩大，涉及到了App部分，而这部分在之前也有所接触，但是并不深入，那个时候还是使用Camera Api v1接口，其定义和HAL1类似，但为了增加其灵活性和扩展性，之后谷歌提出了Camera Api v2接口，现在主要接触的便是该接口，通过简单的几个控制语句便可以实现图像的采集，使用起来比较简单，进一步降低了开发者的门槛，这也从侧面体现出了该接口定义的巧妙。同时，对于Camera Api v2的实现，是通过Camera Framework来完成的，而该层也有着一次不小的演变，刚开始Framework层并不是直接通过AIDL接口与Camera Service进行通信，而是通过一个JNI层来完成从Java到Native的转换，而Native部分作为客户端，保持对Service的通信。这种设计，很显然会比较臃肿，并且代码难以维护，所以之后由于AIDL接口的提出，谷歌直接将其加入到相机框架中，用于保持Framework与Service的通信，进而摈弃了JNI层，进一步减少了不必要的层级结构，保持了整个体系简洁性。

整个相机体系，经历了多次的发展，最终形成了而今的框架结构，一路走来，不难发现都是对于接口的升级，而其升级主要是更新其逻辑定义，完善其具体实现。