相机系统框架

1.1 相机系统框架

Android平台上完整的相机系统是从应用程序层开始到内核层经历了整个Android的框架，而且相机系统还不是一个独立的系统，他与显示系统和音频系统有很密切的联系。不过，这次在卷1中讲述的相机系统的框架并非完整的相机系统，只是从应用程序框架层开始，到硬件抽象成接口为止的这一段内容。对应到Android的框架上也只占了两层半。见下图1-1所示：

    

大家对于这张图应该是再熟悉不过了，约定俗成，也不需要过多解释。本书（卷1）对相机系统的讲解只会涉及到应用程序框架层、系统运行库层和硬件抽象层。因此，通过本书应该可以了解的内容会有：

q       相机应用程序框架API的用法和工作过程

q       相机服务的能力、工作原理及实现

q       相机服务如何操作设备的接口规范

Android框架图可能太过于宽泛与抽象，对于需要深入的讲解相机系统来说，可能会忽略掉一些东西，比如说进程与进程间通信相关的内容等。

接下来的内容包括后续的章节分布，我们会把相机系统的这3层结构（后面章节简称为相机系统）分解的更细，目的是可以把相机系统讲解的更加清楚，让读者也能有更加具体化的认识。首先我们来讲解一下相机的这3层结构对应的进程分布情况，见下图1-2所示：

图1-2

      

从图1-2中可以看出，在相机系统中其实只有2个进程存在。其实更好的理解就是相机系统采用的是C/S模式。从大的来说，Camera App就是客户端， MediaServer就是服务端，他们中间是通过Binder进程间通信的。应用程序框架层的代码是运行在客户端的，而相机服务的代码和HAL的接口包括实现代码都是运行在服务端的。而且从服务端中还能知道，相机服务不是一个单独的进程，而是MediaServer进程中的一个模块而已。

至此，从一张静态的相机系统框架图，到活生生的进程结构，相机系统的层次架构已经开始明朗了。孤立的3层结构之间的联系也能够描述出来了，更详细的相机系统架构层次见图1-3所示，后续对相机系统的分析会按照这样一个层次结构逐层进行。

图1-3

从图1-2中清晰的把相机系统划分成了“应用程序框架层−相机API”、“Binder进程间通信模块/接口”、“相机服务端模块”、和“硬件接口访问模块/HAL接口”这4层。随着Android的版本发展，这4层中的内容或者说是实现方式都在发生变化，但是始终不变的是这4层的相机系统架构。接下来我们简要描述一下这4层的职责和功能。

 

1.1.1应用程序框架层−相机API

用于向上给应用程序开发提供基础的相机功能实现，一般以标准的Android SDK形式提供接口。由于相机系统框架整体采用的是C/S模式，因此，这一层就充当成客户端的角色。作为相机客户端，必须要做的就是与服务器端通信，这种通信的方式是没有固定的，具体的还是要看Android发布的版本，但是一般来说肯定用的是Binder进程间通信。然而，Binder的实现方式也有多样，可能是通过JNI然后在Native层实现进程间通信，也可以直接在Java层实现与服务端的进程间通信。总之，具体的行为要看具体的版本实现。

应用程序框架层−相机API的职责是，能够提供一套有效的应用程序开发接口，用于相机开发。他的功能是，封装对相机设备的操作，实现与相机模块的通讯，实现简单的相机客户端。

这一层的代码是依赖具体的版本实现，可能是Java与JNI的组合，也有可能是完全的Java代码实现。从目前Android发布的版本来看，提供了Camera V1和Camera V2两个版本的编程接口，而且这2个版本是完全独立的2套客户端实现方式。

 

1.1.2 Binder进程间通信模块

实现相机客户端与服务器端的通道，他们之间的通道是双向的，客户端利用此模块调用服务器的功能，同样服务器端也会使用此模块完成对客户端的通知。Binder进程间通信模块的职责是，利用进程间通信机制向两端提供各自需要的编程接口。他的功能是，实现跨进程的相机功能调用，是实现相机系统C/S模式的桥梁。

 

1.1.3相机服务端模块

管理和使用相机功能的模块，相机服务端模块是一个后台服务，寄宿在Media Server进程中，他提供用于客户端操作相机的接口。由于摄像头的特性是属于独占性的硬件设备，因此摄像头的真正拥有者应该是服务端而非客户端，客户端仅能够通过服务端操作相机设备而已，参数等信息都应该保存在服务端。由于服务端的特性是允许同时连接多个客户端，因此具体服务端能否支持需要依靠具体的实现，还有能否同时使用多个摄像头等这些详细的特性也是需要依靠具体的实现。

相机服务端模块的定义也仅仅只是管理相机和为客户端提供相机操作的能力，这个能力根据Android发布的版本不同也会有所变化。开发商可以根据需求修改服务端的能力，不过修改的力度必须遵从Google的兼容性定义，而且能保证CTS的通过。比如说，服务端的能力必须要确保同一个摄像头设备不能被多个客户端打开等。总括的来说，他应该至少包含2块功能：

1、以服务的形式管理相机设备，提供给客户端查询相机的能力，比如说，当前服务下面有多少个摄像头。

2、打开摄像头，提供对摄像头操作的代理，通过访问硬件接口直接操作硬件模块。

 

1.1.4硬件接口访问模块与硬件抽象层

上一小节讲过，相机服务端模块是需要直接访问硬件模块的，那么这样就避免不了直接访问Linux驱动。Android针对这种行为，提供了硬件抽象层，对于Linux驱动的封装，分成了2层，即运行在用内核空间的Linux内核驱动程序和运行在用户空间的HAL，这样一来，相机服务模块仅需要访问HAL接口即可。在AOSP源码发布的时候，各个硬件模块的HAL接口是预先定义好的，也就是说，他的HAL接口中已经预先定义了相机硬件模块所能支持的最大能力。相机服务端只需要针对这个接口编程即可。这样无论是对上（相机服务端）或是对下（摄像头硬件的参数/处理逻辑）都能达到模块化的管理。

为了能实现硬件抽象层对各个硬件访问接口的模块化管理，每个硬件都会自己的动态链接库，这个库的实现需要符合硬件抽象层模块编写规范，在内部，结构体hw_module_t用来描述硬件抽象层模块，而结构体hw_device_t则用来描述硬件设备，根据Android的版本不同，他们各自也有自己的版本来表示Android平台对相机硬件的支持能力。

至于Android引进硬件抽象层的原因有很多说法，比如说避免GPL版权问题，保护硬件厂商；或是提供Linux驱动更宽泛的访问能力；其实从开发人员的角度来看，提供HAL层最大的好处就是可以统一硬件的调用接口。

本卷针对于硬件接口访问模块和硬件抽象层的讲解只会停留在接口部分，即仅包含AOSP分布的代码，至于具体的硬件抽象层的实现，由于各个厂商不同，实现方式也大不相同，而且还会涉及到一些知识产权的问题，针对HAL的实现不会在本卷中讲解。