[Android] android架构中对于硬件封装的演化(HAL/HIDL/AIDL)

前言：

Android 架构在硬件封装上经历了 3 个阶段，2次大演化。分别是 HAL 阶段，HIDL 阶段和 AIDL 阶段。

HAL 阶段：[?，8.0）

这个阶段中，HAL 为底层硬件的抽象层，或者说 Wrapper 层/Helper层，HAL层的所有对象都是 .so动态库，这些动态库的最主要行为就是包装对硬件设备的访问逻辑。比如如果一个硬件的驱动为 /dev/device0，那么针对这个device的 HAL 层对象就是对 /dev/device0 的访问。

HAL的子阶段

其实HAL阶段分为两个子阶段，分别为旧HAL(Legacy HAL) 和新HAL(Conventional HAL)，这两个子阶段只是代码结构上有差异，并没有架构上的区别，依旧是通过 .so 包装对设备的访问。

旧HAL更加面向过程一点，使用者(APP/JNI/Native)需要明确知道自己需要使用哪个 HAL .so 对象来访问具的设备。

详情参考：Legacy HAL - Code Inside Out

新HAL则封装了一个管理层，使用者只需要告诉管理层自己需要访问什么设备即可，管理层会返回对应的封装对象，这样使用者就不再需要记具体的 HAL .so 对象名字了。

详情参考：Conventional HAL - Code Inside Out

HIDL阶段：[8.0,10.0]

HIDL阶段时，android开始抛弃使用者直接通过 .so 文件访问硬件的方法，转而使用 service 的思想，使用者将通过 IPC 的方式访问某个代理了硬件功能的 service 服务。从某种程度上来说是对新HAL的进一步完善，从新HAL开始，android就已经有了将所有HAL包装掩盖的势头，试图通过某个管理对象来实现统一的管理。

但是从某种意义上来说，多了一层IPC就意味着一层性能的消耗，不过只要不是频繁的进行IPC交互，Android Binder还是能够提供一定程度的性能保障。

详情参考：HAL Interface Definition Language - Code Inside Out

这个阶段虽然只持续了两个版本，但是他引入的 HAL 层 Service 化的思想将一直延续下去，可以说是一个分水岭。

AIDL阶段：(10.0，now]

由于HIDL的种种问题，10.0是HIDL存在的最后一个版本，从11.0开始，所有IPC接口定义都使用AIDL来完成。但是这个阶段依旧延续了 HIDL 阶段的框架思想 —— “把硬件包装到一个具备Binder 服务端的Service中，使用者通过Binder IPC/RPC 与服务交互，进而与硬件交互”。