前沿：

前面博文大多少总结的是Camera HAL1到HAL3的系统架构，但这些架构对于Camera APP开发来说依旧还是处于Camera API1.0的标准。而随着Camera3、HAL3.0等的不断更新，Google先是在Framework中更改了整个架构从而去匹配Camera API1.0的处理逻辑，随着时间的推移，Google直接对Camera API进行了全新的升级，去除了原先的Camera.java的相关接口，取而代之的是设计了Camera API2来完全匹配之前设计的Camera3以及HAL3，这样的好处是整个架构看起来会更简单。

本文主要简单的说明一下API2.0下Camera在Framewrok层中的处理逻辑，以及对比之前API1.0下他放弃了什么，同时增加了什么？

 

1. 全新的Camera API2.0

在API2.0中你再也看不得之前的startPreview、takePicture、AutoFocus等标准的操作接口，取而代之的是出现了大量涉及到CaptureRequest/CaptureResult相关的API，Google 在API Level21中即Android5.0版本中开始使用，并deprecate旧的Camera.java相关的接口。

/

 

2. AIDL技术在CameraService中的出现

AIDL是Android Java层实现C/S架构的一种方式，在Native Binder机制的帮助下，在Java层直接建立一种进程间通信。在Camera API2.0下可以看到大量的ADIL处理方式在Java层中出现，替代之前API1.0下都需要进入了Native层来完成通信。

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

（1）CameraService启动；

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

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

无论Android怎么升级，Camera模块基本都处于这种工作模式下，只是具体的实现方式不同而已。此外，上面所提的到C/S架构基本都是通过Binder IPC来实现的。

 

传统的CameraService架构是在API1.0下请求Service在客户端创建一个Camera，是一种很明显的C++层的C/S架构，但在API2.0的架构下原先在Client层的Camera直接是交由Java层CameraDevice来维护，通过AIDL的处理方式实现接口ICameraDeviceUser，在Java层维护一个Camera proxy，好处很明显是响应的速度会更快一些：

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
interface ICameraDeviceUser
{
     /**
      * Keep up-to-date with frameworks/av/include/camera/camera2/ICameraDeviceUser.h
      */
     void disconnect();
 
     // ints here are status_t
 
     // non-negative value is the requestId. negative value is status_t
     int submitRequest(in CaptureRequest request, boolean streaming);
 
     int cancelRequest( int requestId);
 
     int deleteStream( int streamId);
 
     // non-negative value is the stream ID. negative value is status_t
     int createStream( int width, int height, int format, in Surface surface);
 
     int createDefaultRequest( int templateId, out CameraMetadataNative request);
 
     int getCameraInfo(out CameraMetadataNative info);
 
     int waitUntilIdle();
 
     int flush();
}

 

同样的我们看到CameraSevice在Android Java层处的ICameraService.AIDL文件：

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
interface ICameraService
{
     /**
      * Keep up-to-date with frameworks/av/include/camera/ICameraService.h
      */
     int getNumberOfCameras();
 
     // rest of 'int' return values in this file are actually status_t
 
     int getCameraInfo( int cameraId, out CameraInfo info);
 
     int connect(ICameraClient client, int cameraId,
                     String clientPackageName,
                     int clientUid,
                     // Container for an ICamera object
                     out BinderHolder device);
 
     int connectPro(IProCameraCallbacks callbacks, int cameraId,
                               String clientPackageName,
                               int clientUid,
                               // Container for an IProCameraUser object
                               out BinderHolder device);
 
     int connectDevice(ICameraDeviceCallbacks callbacks, int cameraId,
                               String clientPackageName,
                               int clientUid,
                               // Container for an ICameraDeviceUser object
                               out BinderHolder device);
 
     int addListener(ICameraServiceListener listener);
     int removeListener(ICameraServiceListener listener);
 
     int getCameraCharacteristics( int cameraId, out CameraMetadataNative info);
}

 

 

3.Camera2Client消失，CameraDeviceClient出世

CameraDeviceClient可以说是替代了原先API1.0下升级后的Camera2Client，此外在API2.0下是不允许Camera HAL Module 版本号为CAMERA_DEVICE_API_VERSION_1_0的，至于选择使用的是Camera2Device还是Camera3Device来连接HAL3主要通过HAL的CAMERA_DEVICE_API_VERSION来指定。此外HAL中的VERSION必须要在CAMERA_DEVICE_API_VERSION_2_0以上才允许建立CameraDeviceClient。

 

4. Native消失了的各种Stream创建者

在之前的博文中，一直都在重点强调Camera2Client下出现了各种，目前看来这些只能停留在API1.0的世界里面了，随着时间的推移Android版本的升级也许会慢慢的消逝，也就直接告诉我们HAL1.0的CameraHardwareInterface的实现方式将不复存在，当然一切还得取决于厂商的实现方式。

在这里要重点说明的是在Camera2Client下出现了CallbackProcessor、FrameProcessor、StreamingProcessor等模块，每个模块负责处理不同的业务以及相关底层视频图像数据的处理与回调，其中对于数据的处理通过建立CPUConsumer与Surface的架构，更多的是以一种Consumer的角度实现对Buffer的queue与dequeue相关的操作，最终实现Camera3Device标准下的处理逻辑。

而在API2中在Framework层中，这些模块将不再被使用，代替他们的是在Android5.0中的Java层中出现的各种Consumer，类似与Preview模式下的SurfaceFlinger在Java层中的surfaceview，这种模式是通过建立不同类型的Consumer，然后在Native层建立一个BufferQueue，并将这个BufferQueue的IGraphicBufferConsumer用于构建CPUConsumer，将IGraphicBufferProducer通过createStream给CameraDevice增加一个Stream。

当然本质上看起来两者实现方式的机制是一样的，都是需要create一个Stream，然后Stream需要对应的ANativeWindow类型的Surface，用于从HAL3中获取数据，一旦获取数据后和这个Surface绑定的Consumer就可以通过OnFrameAvailable()来接收处理buffer。下面的接口说明了在API2下对于不同数据处理模块只需要get一个Surface后通过AIDL实现方式就可以创建一个stream接口，用于数据的接收。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
status_t CameraDeviceClient::createStream( int width, int height, int format,
                       const sp<igraphicbufferproducer>& bufferProducer)
{
     ATRACE_CALL();
     ALOGV(%s (w = %d, h = %d, f = 0x%x), __FUNCTION__, width, height, format);
 
     status_t res;
     if ( (res = checkPid(__FUNCTION__) ) != OK) return res;
 
     Mutex::Autolock icl(mBinderSerializationLock);
 
     if (bufferProducer == NULL) {
         ALOGE(%s: bufferProducer must not be null , __FUNCTION__);
         return BAD_VALUE;
     }
     if (!mDevice.get()) return DEAD_OBJECT;
 
     // Don't create multiple streams for the same target surface
     {
         ssize_t index = mStreamMap.indexOfKey(bufferProducer->asBinder());
         if (index != NAME_NOT_FOUND) {
             ALOGW(%s: Camera %d: Buffer producer already has a stream for it
                   (ID %zd),
                   __FUNCTION__, mCameraId, index);
             return ALREADY_EXISTS;
         }
     }
 
    .............
 
     int32_t disallowedFlags = GraphicBuffer::USAGE_HW_VIDEO_ENCODER |
                               GRALLOC_USAGE_RENDERSCRIPT;
     int32_t allowedFlags = GraphicBuffer::USAGE_SW_READ_MASK |
                            GraphicBuffer::USAGE_HW_TEXTURE |
                            GraphicBuffer::USAGE_HW_COMPOSER;
     bool flexibleConsumer = (consumerUsage & disallowedFlags) == 0 &&
             (consumerUsage & allowedFlags) != 0 ;
 
     sp<ibinder> binder;
     sp anw;
     if (bufferProducer != 0 ) {
         binder = bufferProducer->asBinder();
         anw = new Surface(bufferProducer, useAsync); //创新一个本地的surface，用于Product
     }
 
     // TODO: remove w,h,f since we are ignoring them
    ..........
     res = mDevice->createStream(anw, width, height, format, &streamId); //创建stream
 
     
     return res;
}
</anativewindow></ibinder></igraphicbufferproducer>

在API2.0下可以看到在Android Java层中提供了不同的Module来处理不同的视频图像数据，这个过程是很类似与Camera2Client下的各种Processor模块的，只是后者是将数据处理打包后再返回到APP中，而前者是直接由Java层的不同模块来异步的响应并直接处理不同类型数据流的到来，如PREVIEW、RRCORD、STILL_CAPTURE、VIDEO_SNAPSHOT、ZERO_SHUTTER_LAG等不同模式的数据流将由MediaRecoder、SurfaceView、ImageReader等来直接处理，总体来说效率会更佳。

5. FrameProcessorBase依然存在 该类在旧版本中被FrameProcessor用来处理3A相关的信息，主要是Callback每一帧的ExtraResult到APP，也就是3A相关的数据信息。这也是在API1和API2中唯一都需要手动CallBack的模块，其余的数据流都是被上述提到的模块自动处理，其中实现的方式如2小节(3)所描述，其中采用ICameraDeviceCallbacks将每一视频帧数据回传：
?
1
2
3
4
5
6
7
8
9
10
11
interface ICameraDeviceCallbacks
{
     /**
      * Keep up-to-date with frameworks/av/include/camera/camera2/ICameraDeviceCallbacks.h
      */
 
     oneway void onCameraError( int errorCode);
     oneway void onCameraIdle();
     oneway void onCaptureStarted( int requestId, long timestamp);
     oneway void onResultReceived( int requestId, in CameraMetadataNative result);
}


6 小结，整个API2下Camera3的架构简图
/

 

 

Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods