Android Camera HAL3 -架构设计

其实从 APP 到 Google HAL 再到 Vendor HAL 的通用 interface，这些地方的架构都是包含在 Android 包里面的，基本上是有迹可循的，在开发的时候即使是什么都不没有提前去了解过，那也没关系，循着代码包里面的代码总是能够找到相关的通路的。但是有一个地方不同，那就是 Vendor HAL 的实现部分，因为这部分是 Camera 平台相关的内容，包含了大量的硬件设备，内核那边的架构基本上都是基于 V4L2 的扩展或者魔改，而 User space 这部分完全就是百家争鸣的状态，没有一个统一的标准来限定这部分应该怎么做，而且各家手机厂商系统繁杂的功能需求也导致了架构设计上的不统一。

由于这部分是有些涉密的，所以不会摆开了揉碎了去说，但是呢，毕竟天下之大，太阳底下没有新鲜事，一切的架构的设计与实现都是有演变过程的，也是有思想继承的，那种完全横空出世的玩意儿毕竟还是很少见的，除非是那种不世出的天才。从市面上各家已经有的开源 Camera HAL 部分的代码来看，很多的设计思想上面都是同源的（虽然从代码细节实现上来看是天差万别的），并且现有的很多其它完整的开源标准和软件代码都是已经实现好了的。

这篇文章呢就从几个主要的架构设计思想和原则上来简单介绍下可以用在 Camera vendor HAL 的实现方式，这部分得要是通用概述，不会详细的去探讨每一个实现的细节，因为这部分的知识太过繁杂庞大，也是整个 Camera HAL 最核心的部分，等到有需要的时候再借助开源代码来细究一下。有些公司呢，会要求你不说精通，但是至少要比较详细的掌握从 APP 到 Vendor HAL 的代码流程通路，当然呢这个是合理的也是无可厚非的，不过我个人觉得如果是想要做出一些特别的东西的话，还是得从 Vendor HAL 部分入手，这部分是平台相关部分最为重要，也是难度最高的部分，一个新的平台，这部分完全就是建功立业的试炼场。APP 到 Google HAL 呢，因为主动权在 Google 手里，当然也可以魔改，不过这部分我个人觉得毕竟发挥空间并不是非常的大，除非生态都自己玩（我看华为有这个趋势），大多数时候，这部分东西最多一个月就可以从不了解到上手出活，所以我倒是不是特别地关注这部分。

先来思考下设计 Camera vendor HAL 时候所面临的问题有哪些？

1. Camera 这个大的硬件里面有非常多的设备，虽然都是和图像处理有关的，但是各不相同，需要和谐的统一在一块。
2. 庞大繁杂的业务需求，并且差异也是蛮大的，各个用例特性不一，每个用例里面包含了很多的算法，如何去协调？不同用例之间的切换怎么做？
3. 因为我是在 SOC 厂，所以会有非常多的三方客户自定义需求，这部分怎么与内部固化用例进行兼容，如何做到利于客户扩展、增删、替换模块？
4. 如此庞大的一个业务逻辑应该基于数据流设计还是基于逻辑流设计，抑或是二者的杂糅？
5. 如何在这个系统当中优化内存的使用，加快速度的运行，如何减少处理延时？
6. 第三方 APP 怎么样去兼容？譬如 R 的第三方 APP 的 Multi camera 适配怎么做？

这个表细化到每一个部分列下去我可以写一个十几页 A4 纸的清单，有可能还不够，只看到上面的那几个是不是觉得还行吧，一个架构落地成型最主要的先要是基本功能逻辑，然后再是优化，但是当这个需求单列到你怀疑人生的时候会让你恨不得拿隔壁玛丽亚老太太的除草机薅光自己的头发，然后用烧火棍在脑门子上点出几个戒疤，裹上新洗的被单去往姑苏城外的皇觉市敲木鱼去。所幸的是这些问题在别的地方有人或多或少地已经帮你考虑过了，自己需要做的就是找到那些散落在不同地方的金子，把它变成自己的思想，再去设计实现。

说到架构设计，有来源参考的话，一个公司的十年经验大佬就可以一个人完成，但是一些新的东西，基本没有什么成型的架构参考，并且业务逻辑还特别繁杂庞大的时候，一个人的力量显然就不是很可行了，更多时候是一群杰出开发人员的头脑风暴，不懈努力，一遍遍的推演设计才能够做出来一个可用的架构。为什么说架构师牛逼呢，就是因为这玩意儿要考虑的东西实在是太多了，能把这团乱麻捋出来个头绪，还很好的实现出来本身就需要大量的经验积累，业务熟悉度以及优秀的脑瓜，虽然每个程序员都有个架构师梦，但是梦想照进现实的还是极少极少。

话说回来，问题那么多，那有没有现行的架构参考呢？那肯定是有的，Linux 内核的 V4L2，流媒体的 OpenMAX标准，Linux 的多媒体框架 Gstreamer（思想源于 Win 的 Direct show），多媒体编解码套件 FFmpeg 。。。等等等等。架构是非常地多，但是很多时候是无法直接地去用的，往往需要一番魔改才能用于自己的业务流。上面的各个架构都有自己的特点和注重点，搞清楚这些，就可以有的放矢的应用在自己的业务架构上面，下面就稍稍讨论下它们几个的特征点。

---

V4L2

这个前面是有一个系列的文章的，可以参考下这里：V4L2 框架介绍。

这个是 Linux 内核特有的一个视频处理框架，它的特点是基于硬件设备模块化的管理模式，有一点点类似 OpenMax 的组件化。它提供了基于每一个硬件的操作接口和套路，可以说是分散式的管理，如果要实现基于数据流的管道式管理更多时候需要自己加上去，这个框架更多的是关注于最底层的逻辑。

那我们 User space 也是要进行很多设备的管理，是不是这部分就可以参考 V4L2 的设计模式。但是业务逻辑的实现底层部分可以是这样的设计，没有问题，那更接近上层一点的部分还用这种设计的话就显得特别繁琐了，因为这部分是细化到每一个设备的管理上面去的，如果我每次创建一个新的业务逻辑流都要对每一个设备来一遍特定初始化管理操作的话就会有十分庞大的代码量了。

V4L2 说它是总线式的设计吧，它其实也提供了很多分散的模块控制接口，更准确一点的说法是主要实现部分是总线式的，辅以分散的分布式模块化控制。不过通常情况，为了代码逻辑清晰，更多地会采用总线式的设计，不然的话就要额外考虑很多的冲突处理等等了。

所以会有下面两种架构。

OpenMax 和 Gstreamer

OpenMax 是分为 IL、AL 等层次的，其中 IL 是可以作为我们 User space 的底层设计的[OpenMax IL]，AL 的话就是把底层的分散模块通过进一步的抽象来实现简洁的上层操作逻辑，使得更上层的调用者只需要关注一小部分就可以了，无需每次都亲自处理每一个底层模块。

OpenMax 的 IL 层设计其实和 V4L2 的 subdevice 部分十分地类似，都是有一个统一的子模块抽象，在运行时可以通过相关接口来进行分布式的控制。而 Gstreamer 的主要设计思路是管道式的，它把一个个的业务逻辑抽象成了一个个的管道，基于业务逻辑进行管理。

Gstreamer 的上层操作就显得特别的简洁，往往只需要几行代码就可以创建一个完整的业务逻辑流了，这部分你看着就会觉得它和 Google HAL3 的 request 设计非常像了，都是绝对的总线式设计思想，上层操作者不需要关注底层的实现细节，只需要传入自己关心的业务逻辑配置即可，底层会根据传入的参数自行去协商建立每一个子模块节点。

所以 Gstreamer 看起来就比较接近我们想要的设计了，那么上层的主体设计思想就可以参考 Gstreamer 的设计了，毕竟这部分和 Google HAL3 的设计有一定的和谐之处。

FFmpeg

这个算是完全的分散式子模块化的设计了，我们每次使用的时候都需要针对每一个模块进行特异的初始化，以区别实现我们的整个业务流逻辑功能。这个也是可以作为底层设计实现的参考的。FFmpeg 是可以整个整合到 Gstreamer 里面的。

这部分了解的不是非常的多，所以就止步于此了。

---

从上面来看，我们可能有这么两套基础参考方案，FFmpeg 作为底层设计参考，Gstreamer 作为上层设计参考；或者是 V4L2/OpenMax IL 作为底层实现，OpenMax AL 作为上层实现。还有一个就是，从整体的大的方面来看，它们几个似乎都是有异曲同工之妙，翻来覆去其实就那么几个最核心的思想，不过可以确定的就是，这几个框架已经足够用了，这么多的多媒体业务，完全可以用上面几种方案的有机结合来实现。

这篇文看起来貌似是有点水的，好像说了点什么，又好似什么都没说，但是我觉得是说了很多的，也许现在我也用不到它，但是提前多思考多积累是没有错的，时常多从更高的视角去看待自己所做的产品代码，对于自己的成长相信还是有很多帮助的。

---