为什么会存在这三种 Binder？
Android 8.0 重新设计了 Android 系统框架，引入 Treble 机制。在新的架构中，引入了 HAL 接口定义语言（HIDL），提供了独立的供应商分区（vendor），以及供应商原生开发套件 (VNDK)。通过这些新技术，可以将系统框架与供应商实现分隔开来，使得用户可以独立替换分区镜像，以便制造商能够更轻松、更快速地更新 Android 系统。
Treble 的引进，使得 system 和 vendor 分区间无法直接访问，导致原有的 Binder 机制不能继续使用。因此将 Binder 拆分为 Binder、HwBinder 和 VndBinder，用于在 system/system、system/vendor 和 vendor/vendor 之间进行进程间通信。三种 Binder 的使用如下图所示，
三种 Binder 使用的资源有什么不同？
这个问题的答案已经在上图中，可以归结为以下几点：
为什么会引入 HwBinder？
HwBinder 引入的本质还是 Treble 机制的使用，这使得 system 和 vendor 分区相互隔离。在 Android 8.0 之前，Android HAL 与系统框架是紧耦合的，它们打包在一个镜像里。HAL只是一个个的so库，framework 通过打开动态库来调用 HAL。 为了适配 HwBinder，Android 8.0 同时引入了 HIDL，用于建立 framework 和 HAL 间的通信。
经过这个改变后，HAL 可以同时服务于 system 和 vendor。而 HAL 的实现位于 vendor 分区，通过 HwBinder 可以确保 system 和 vendor 独立升级，而不会影响 HAL 的调用。
三种 Binder 在驱动实现上有什么不同？
三种 Binder 除了设备节点不同以外，驱动实现是相同的。
- 1、Legacy HAL：是传统的HAL方式，所有的HAL都是编译成so文件，动态链接到各个Framework service当中
- 2、Passthrough：该模式是为了兼容旧版的 HAL，旧版 HAL 实现仍以动态库的方式提供，只是 binder service 链接了动态库 HAL 实现，即 binder service 通过 hw_get_module 链接了旧版的 hal 实现，而用户端通过与 binder service IPC 通信，间接实现了与旧版 HAL 的交互。官网上明确属于passthrough模式的HAL：
- 3/4、Binderized：HAL 与 用户调用在不同的进程中，HAL 被写成 binder service，而用户接口如 frameworks 作为 binder client 通过 IPC 机制实现跨进程接口调用
在Android O之前，Framework中各个服务与Hal层交互，都是在同一个进程，通过dlopen可以直接加载相关so文件，这种模式会导致Framework文件和Hal文件在同一个分区下边，即system分区。
在Android O之后，系统各个服务与Hal层的交互采用跨进程调用binder的形式进行，这样Framework还在system分区，Vendor的Hal层代码，则会移动到Vendor分区，这样能进行分开升级，减低了代码耦合度。
