本文主要是介绍Android Camera API2.0下全新的Camera FW/HAL架构简述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前沿：
前面博文大多少总结的是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的架构简图
这篇关于Android Camera API2.0下全新的Camera FW/HAL架构简述的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
