昨天發的那篇技術文之后，這篇文章我覺得可以給大家更加耳目一新，特別是因為其中的例子和白話文。

昨天文章如下

Android-你真的懂AIDL的oneway嘛？

以下是正文

---

1 前言

先復制一段來自于android官方文檔的文字
https://source.android.google.cn/devices/architecture/hidl/binder-ipc

一直以來，供應商進程都使用 Binder 進程間通信 (IPC) 技術進行通信。在 Android 8 中，/dev/binder 設備節點成為框架進程的專有節點，這意味著供應商進程無法再訪問此節點。供應商進程可以訪問 /dev/hwbinder，但必須將其 AIDL 接口轉為使用 HIDL。對于想要繼續在供應商進程之間使用 AIDL 接口的供應商，Android 會按以下方式支持 Binder IPC。

Android 8 支持供供應商服務使用的新 Binder 域，訪問此域需要使用 /dev/vndbinder（而非 /dev/binder）。添加 /dev/vndbinder 后，Android 現在擁有以下 3 個 IPC 域：

2 舉個例子

看了上面一段文字之后，可能很多人還是比較懵逼，我來舉一個例子：

假如手機中有如下3類進程

a.應用進程：

Camera APP
手電筒 APP

b.框架進程：

System Server進程

c.供應商進程：

Camera HAL進程
Light HAL進程

這些進程之間需要使用Binder機制跨進程通信，Android提供了三個Binder設備節點dev/binder，dev/hwbinder，dev/vndbinder，也就是Android系統同時提供了三個獨立運行的Binder通信模塊，Android團隊規定每類進程使用的這三個Binder通信模塊的規則如下圖：

3 三種Binder介紹以及之間的聯系

3.1 dev/binder

這個是我們最熟悉的Binder，App開發中，ActivityManagerService用的都是這個，Java繼承Binder，C++中繼承Bbbinder，然后通過servicemanager進程注冊實名Binder，然后通過已經創建好的Binder接口傳遞匿名Binder對象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。

3.2 dev/vndbinder

其實dev/vndbinde和dev/binder使用方式基本一樣而且是共用一套Binder SDK，也是Java繼承Binder，C++中繼承Bbbinder，但是通過vndservicemanager進程注冊實名Binder，然后通過已經創建好的Binder接口傳遞匿名Binder對象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。如何在使用同一套Binder SDK的代碼，最后訪問的設備節點變成dev/vndbinder，servicemanager變成vndservicemanager。

其實和簡單，只要在你這個進程初始化的時候執行下面這個代碼

ProcessState::initWithDriver("/dev/vndbinder");

dev/binder和dev/vndbinder無法在一個進程中同時使用

細心的讀者肯定發現上面的圖中三類進程的任意一個進程無法同時使用dev/binder和dev/vndbinder，這一點不單是android官方約定，也是目前android binder sdk的限制，因為兩者都是共用Binder SDK，所以只能指定一個設備節點，要么dev/binder，要么dev/vndbinder

3.3 dev/hwbinder

那么dev/hwbinder是如何解決與dev/binder或dev/vndbinder之間的共存問題？有人肯定想到了，很簡單，我們把所有Binder SDK復制一套新的Hw Binder SDK，改名成dev/hwbinder，HwBinder，HwBbinder，hwservicemanager，HwProcessState，這樣子不就可以和dev/binder或dev/vndbinder共存了嘛？其實android團隊就會類似這樣子干的。

但是他們想hwbinder是為了規范hal層，畢竟hal層是操作硬件的，所以他們不應該提供這么自由，這么麻煩的接口定義。
他們的目標有兩個：
1.不能那么自由，強制所有供應商按照android官方定義的hal接口來實現
2.不能增加供應商開發人員的學習成本，學習一套復雜的Hw Binder SDK
為了達成上述的兩個目標，android團隊想出了HIDL這個方案。

4 HIDL是什么

具體HIDL做了什么，我不細講了，簡單描述一下：
假如Android官方定義了一個ILight.hal的HAL層接口

Interface ILight {void turnOn();void turnOff(); }

通過編譯會自動生成如下兩個類LightServer和LightClient的java對象和c++對象。

供應商只需要簡單的繼承LightServer，并實現turnOn和turnOff的抽象方法，就可以完成Light接口的實現，以及Light服務注冊到hwservicemanager。

需要使用ILight接口的進程，只需要調用LightClient的turnOn和turnOff接口，就可以完成從hwservicemanager獲得Light服務的Proxy對象，以及ILight的接口調用。

HIDL與AIDL的區別

看了上面的文字描述，應該明白了HIDL比AIDL做的事情更多：
AIDL在Server端串聯Interface和Binder或者Bbbinder，在Client端串聯Interface和BinderProxy或者Bpbinder
HIDL則是串聯Interface->Hw Binder SDK->dev/hwbinder

5 總結

為什么Android團隊要大費周章搞出那么多Binder，我覺得有以下幾個原因：
1.降低各個層之間的耦合，方便Android系統的快速移植，升級，提升系統穩定性，所以以后Android系統工程師能改的東西越來越少。
2.估計這個是Android團隊絞盡腦汁想出來的KPI，我猜的。

總結

以上是生活随笔為你收集整理的binder，hwbinder，vndbinder之间的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。