camera api1 和api2

一 cameraapi概述

Android5.0之后，增加了Cameraapi2接口，api2和api1在调用流程上差异很大，功能上api2提供了更加细致的控制功能，api1子系统被设计为具备高级控制功能的黑盒，能够发出请求，但无法控制图像的缓冲区和元数据，无法再帧层面控制传感器的特性，无法通过访问和修改元数据信息（如3A信息）对捕获的帧应用任何增强功能，重新设计api2旨在大幅提高应用程序控制摄像头子系统的能力，性能也有一定的提升。

二cameraAPI1 和API2流程对比

图（2.1）

2.1 Camera API1 主要类

Camera api1调用流程比较直观，也利于理解一些，应用程序实例化camera这一个类就可以控制摄像头子系统，

2.1.1 Camera，api1主要类。通过类的这些startPreview、takePicture、AutoFocus等标准的接口实现。

2.1.2 Parameters，参数设置，通过camera内部类Parameters操作实现，如设置帧率，设置图片格式，预览尺寸等

2.1.3 CameraInfo，元数据获取，通过camera内部类CameraInfo实现，这里只能获取不能修改。

2.2 Camera API2 主要类

Camera api2在应用层的调用要复杂一些，定义的类也比较多，这也说明对摄像头子系统控制的更加细腻了。

2.2.1 CameraManager：摄像头管理器。这是一个全新的系统管理器，专门用于检测系统摄像头、打开系统摄像头。除此之外，调用CameraManager的getCameraCharacteristics(String)方法即可获取指定摄像头的相关特性。

2.2.2 CameraCharacteristics：摄像头特性。该对象通过CameraManager来获取，用于描述特定摄像头所支持的各种特性。

2.2.3 CameraDevice：代表系统摄像头。该类的功能类似于早期的Camera类。

2.2.4 CameraCaptureSession：这是一个非常重要的API，当程序需要预览、拍照时，都需要先通过该类的实例创建Session。而且不管预览还是拍照，也都是由该对象的方法进行控制的，其中控制预览的方法为setRepeatingRequest()；控制拍照的方法为capture()。

为了监听CameraCaptureSession的创建过程，以及监听CameraCaptureSession的拍照过程，Camera v2 API为CameraCaptureSession提供了StateCallback、CaptureCallback等内部类。

2.2.5 CameraRequest和CameraRequest.Builder：当程序调用setRepeatingRequest()方法进行预览时，或调用capture()方法进行拍照时，都需要传入CameraRequest参数。CameraRequest代表了一次捕获请求，用于描述捕获图片的各种参数设置，比如对焦模式、曝光模式……总之，程序需要对照片所做的各种控制，都通过CameraRequest参数进行设置。CameraRequest.Builder则负责生成CameraRequest对象

2.3不同空间主要的通信方式

2.3.1 Api1 ，应用程序层直接调用Camera对象，java层camera对象通过JNI进入C++空间，C++层会实例化C++层camera对象，此层的camera对象实际上是一个binder对象，这个binder对象会被传送到CameraService中保存起来，和cameraClient对象保持一一对应关系。

2.3.2 Api2，大量使用了AIDL技术，AIDL是Android Java层实现C/S架构的一种方式，在Native Binder机制的帮助下，在Java层camera直接也cameraservice建立一种进程间通信。在Camera API2.0下可以看到大量的ADIL处理方式在Java层中出现，替代之前API1.0下都需要进入了Native层来完成通信，理论上性能会提升一些

 

（图2.2）

Binder业务模型：

Android系统中大量使用了Binder这种夸进程通信机制，想要彻底的了解需要长期的历练。这里简单阐述binder业务模型，binder功能类似TCP/IP协议，在系统中负责夸进程的通信。

1 binder基于C/S模型，由客户端，服务端，binder驱动组成，分业务层和传输层

2 binder夸进程通信，每次通信数据量有限，每次最大25kb，不宜传输大量数据

3 binder架构提供了业务和通信binder互相转换的接口，业务层夸进程通信时需要将业务转换成binder对象，通信到达另一端是又把binder转换成具体的业务接口，这样完成一次通信

2.4对CameraService影响

对于CameraService而言，无论是哪种架构或者方式，都是应该满足下面的几个过程：

2.4.1  CameraService启动；

2.4.2 一个Client端通过CameraService Proxy连接到CameraService，并获得一个CameraClient Proxy。后续通过CameraClient Proxy直接和CameraService来交互。

2.4.3 Client要提供Callback实体接口到Service端，即每个Service端的CameraClient都需要一个Callback Proxy来完成数据、消息的Callback

 

 

 

 

三Camera api2操作模型

 

（3.1）

 

3.1 重新设计Android Camera 2.0 API旨在大幅提高应用程序控制摄像头子系统的能力。

3.2应用程序框架向摄像头子系统请求一帧图像，摄像头子系统将请求结果与相关元数据信息（如色彩空间）一起返回到输出流；同时为每个结果数据流生成镜头阴影信息。

3.3应用程序对整个摄像头管道的控制能力得到提升。每个拍摄请求会产生一个带有拍摄元数据的结果对象和一些图像数据缓 冲区。

3.4元数据信息有助于应用程序了解摄像头管道的当前状态（3A和ISP状态）以对缓冲区进行相关处理