Android中AIDL和HIDL的区别

在Android中，AIDL（Android Interface Definition Language）和 HIDL（HAL Interface Definition Language）是两种用于定义跨进程通信接口的语言。AIDL 是 Android 系统最早支持的 IPC（进程间通信）机制，而 HIDL 是从 Android 8.0 开始引入，用于 HAL（Hardware Abstraction Layer）模块的接口定义。

随着 Android 的发展，Google 决定从 Android 11 开始将新的 HAL 统

一使用 AIDL 接口，而逐步放弃 HIDL。这种转变背后的原因涉及技术复杂度、性能、开发效率和生态统一性等多个方面。

1. AIDL 和 HIDL 的主要区别

1.1AIDL（Android Interface Definition Language）

用于 Android 系统中 App 层到 Framework 层之间的通信，也可以用于 Service 和 Client 的进程间通信。AIDL 使用 Binder 内核驱动程序进行调用。

AIDL 可以在 Android 中的任何进程之间使用：在平台组件之间使用或在应用之间使用均可。

他的主要的特点是：

语言支持：支持 Java、C++ 和 Kotlin，最初主要服务于 App 层（Java 环境）。
运行时绑定：通过 binder 驱动直接实现进程间通信，适合轻量的高频接口调用。
AIDL 文件编译：通过工具生成 Stub 和 Proxy 代码，封装了序列化和反序列化逻辑，开发者只需实现核心逻辑。

1.2 HIDL（Hardware Interface Definition Language）

HIDL 旨在用于进程间通信 (IPC)。使用 HDL 创建的 HAL 称为绑定式 HAL，因为它们可以使用 Binder 进程间通信 (IPC) 调用与其他架构层进行通信。绑定式 HAL 在独立于使用它们的客户端的进程中运行。对于必须与进程相关联的代码库，还可以使用透传模式（在 Java 中不受支持）。

HIDL 可指定数据结构和方法签名，这些内容会整理归类到接口（与类相似）中，而接口会汇集到软件包中。尽管 HIDL 具有一系列不同的关键字，但 C++ 和 Java程序员对 HIDL 的语法并不陌生。此外，HIDL 还使用 Java 样式的注解。

他的主要的特点是：

使用场景：专为 HAL 设计，用于定义硬件抽象层和 Framework 层之间的接口。
语言支持：主要支持 C++，不直接支持 Java。
静态绑定：HIDL 在编译时生成接口代码，运行时通过 hwservicemanager 注册和发现服务。
接口版本化：支持接口的向前兼容和向后兼容，可以在同一个系统中并存多个版本的 HAL 模块。
复杂性：HIDL 引入了较复杂的构建工具链（如 HIDL 编译器）和运行时管理机制。

2. Google 放弃 HIDL，统一使用 AIDL 的原因

2.1 简化开发和维护

减少学习成本：
HIDL 的学习曲线较陡，开发者需要熟悉 HIDL 特有的语法和工具链，而 AIDL 更加简单直观，开发者容易上手。
统一接口开发方式
将 HAL 和应用层接口统一为 AIDL，减少了系统中不同接口定义语言的种类，便于开发者在不同层级使用相同的工具和模式。

2.2 降低系统复杂性

HIDL 的工具链和运行时机制引入了额外的复杂性，比如 hwservicemanager 和接口的版本化管理，而 AIDL 的实现相对简单，使用单一的 binder 机制即可满足需求。

2.3 性能优化

AIDL 在轻量通信场景下性能优于 HIDL：

序列化和反序列化效率高：AIDL 的传输格式更加精简。
运行时绑定更灵活：无需像 HIDL 那样依赖 hwservicemanager，可以减少通信开销。

对于大多数硬件接口调用场景，AIDL 的性能足以满足需求，HIDL 的版本管理和静态绑定机制显得多余。

2.4 推动 Kotlin 和 Rust 的生态

AIDL 逐步扩展了对 Kotlin 和 Rust 的支持（尤其是在安全性上），这是 Google 推动现代语言生态的重要一步。相比之下，HIDL 偏向 C++，缺乏对新语言的良好支持。

2.5 接口版本化的简化

尽管 HIDL 的多版本支持机制强大，但实际使用中却增加了维护成本。AIDL 的接口版本化从 Android 10 开始进行了改进，通过 stable AIDL 提供了更简洁的方式来处理接口的向前和向后兼容性问题。

3.举例说明

就拿音频举例，AIDL 实现与 HIDL 音频 HAL 实现之间的区别：

在 AIDL 音频核心 HAL 中，引入了新的 IConfig 接口，替代了 HIDL HAL 中通过 XML 文件定义的系统级参数。这些参数现在由框架直接从 Core HAL 读取，而不再依赖供应商提供的配置文件。例如，用于显示给用户以便控制的环绕声格式列表，现由 IConfig.getSurroundSoundConfig 方法直接提供。
在 AIDL 音效 HAL 中，原先在 HIDL 音效 HAL 的 XML 文件中定义的 effectProxy 相关逻辑已迁移到音频框架中。框架通过调用 IFactory.queryEffects 方法获取系统中所有效果实例的列表，并使用 IFactory.queryProcessing 方法查询所有效果处理信息。
为了避免“设备”一词在描述音频设备类型时可能产生的歧义，HIDL 音频 HAL 中的 IDevice 接口在 AIDL 音频 HAL 中被重新命名为 IModule。
此外，IPrimaryDevice 接口已被移除并由新的机制替代。现在，系统会将当前音频模式和屏幕旋转方向的更新发送到每个 IModule 实例。而涉及蓝牙同步音频连接（如 BT SCO）和免提配置文件（HFP）的参数，则由独立的 IBluetooth 接口管理。与电话相关的控制由专用的 ITelephony 接口提供支持。这两个接口的实例都可以通过 IModule 接口的主实例来获取。更多细节可参见核心 HAL 与相关功能的对比表。
与此同时，为了避免冗余，AIDL 音频 HAL 中移除了 IDevicesFactory 接口。HAL 模块（即 IModule 的实例）现在直接以其名称在 Service Manager 中注册，例如 bluetooth 或 r_submix。唯一的例外是主模块（primary module），它仍然以 default 作为实例名称进行注册。

4.接口映射内容：

所有 HIDL 接口都在 android.hardware.audio@N.M 软件包中，其中 N.M 表示 Major.Minor 版本。所有 AIDL 接口都在 android.hardware.audio.core 软件包中。

HIDL API 接口和配置文件	AIDL API接口
IDevicesFactory	在 ServiceManager注册 IModule。
IDevice	IModule
IPrimaryDevice	ITelephony / IBluetooth
IStream /IStreamIn / IStreamOut	StreamDescriptor /IStreamIn / IStreamCommon / IStreamOut
audio_policy_configuration.xml / audio_policy_engine_configuration.xml	IConfig / IModule
可配置的音频政策文件	在 Android 14 中使用HbL妥现。