1 前言
先復(fù)制一段來自于android官方文檔的文字
https://source.android.google.cn/devices/architecture/hidl/binder-ipc
一直以來，供應(yīng)商進程都使用 Binder 進程間通信 (IPC) 技術(shù)進行通信。在 Android 8 中，/dev/binder 設(shè)備節(jié)點成為框架進程的專有節(jié)點，這意味著供應(yīng)商進程無法再訪問此節(jié)點。供應(yīng)商進程可以訪問 /dev/hwbinder，但必須將其 AIDL 接口轉(zhuǎn)為使用 HIDL。對于想要繼續(xù)在供應(yīng)商進程之間使用 AIDL 接口的供應(yīng)商，Android 會按以下方式支持 Binder IPC。
Android 8 支持供供應(yīng)商服務(wù)使用的新 Binder 域，訪問此域需要使用 /dev/vndbinder（而非 /dev/binder）。添加 /dev/vndbinder 后，Android 現(xiàn)在擁有以下 3 個 IPC 域：
2 舉個例子
看了上面一段文字之后，可能很多人還是比較懵逼，我來舉一個例子：
假如手機中有如下3類進程
a.應(yīng)用進程：
Camera APP
手電筒 APP
b.框架進程：
System Server進程
c.供應(yīng)商進程：
Camera HAL進程
Light HAL進程
這些進程之間需要使用Binder機制跨進程通信，Android提供了三個Binder設(shè)備節(jié)點dev/binder，dev/hwbinder，dev/vndbinder，也就是Android系統(tǒng)同時提供了三個獨立運行的Binder通信模塊，Android團隊規(guī)定每類進程使用的這三個Binder通信模塊的規(guī)則如下圖：
3 三種Binder介紹以及之間的聯(lián)系
3.1 dev/binder
這個是我們最熟悉的Binder，App開發(fā)中，ActivityManagerService用的都是這個，Java繼承Binder，C++中繼承Bbbinder，然后通過servicemanager進程注冊實名Binder，然后通過已經(jīng)創(chuàng)建好的Binder接口傳遞匿名Binder對象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。
3.2 dev/vndbinder
其實dev/vndbinde和dev/binder使用方式基本一樣而且是共用一套Binder SDK，也是Java繼承Binder，C++中繼承Bbbinder，但是通過vndservicemanager進程注冊實名Binder，然后通過已經(jīng)創(chuàng)建好的Binder接口傳遞匿名Binder對象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。如何在使用同一套Binder SDK的代碼，最后訪問的設(shè)備節(jié)點變成dev/vndbinder，servicemanager變成vndservicemanager。
其實和簡單，只要在你這個進程初始化的時候執(zhí)行下面這個代碼
ProcessState::initWithDriver("/dev/vndbinder");
dev/binder和dev/vndbinder無法在一個進程中同時使用
細心的讀者肯定發(fā)現(xiàn)上面的圖中三類進程的任意一個進程無法同時使用dev/binder和dev/vndbinder，這一點不單是android官方約定，也是目前android binder sdk的限制，因為兩者都是共用Binder SDK，所以只能指定一個設(shè)備節(jié)點，要么dev/binder，要么dev/vndbinder
3.3 dev/hwbinder
那么dev/hwbinder是如何解決與dev/binder或dev/vndbinder之間的共存問題？有人肯定想到了，很簡單，我們把所有Binder SDK復(fù)制一套新的Hw Binder SDK，改名成dev/hwbinder，HwBinder，HwBbinder，hwservicemanager，HwProcessState，這樣子不就可以和dev/binder或dev/vndbinder共存了嘛？其實android團隊就會類似這樣子干的。
但是他們想hwbinder是為了規(guī)范hal層，畢竟hal層是操作硬件的，所以他們不應(yīng)該提供這么自由，這么麻煩的接口定義。
他們的目標有兩個：
1.不能那么自由，強制所有供應(yīng)商按照android官方定義的hal接口來實現(xiàn)
2.不能增加供應(yīng)商開發(fā)人員的學習成本，學習一套復(fù)雜的Hw Binder SDK
為了達成上述的兩個目標，android團隊想出了HIDL這個方案。
4 HIDL是什么
具體HIDL做了什么，我不細講了，簡單描述一下：
假如Android官方定義了一個ILight.hal的HAL層接口
Interface ILight {
void turnOn();
void turnOff();
}
通過編譯會自動生成如下兩個類LightServer和LightClient的java對象和c++對象。
供應(yīng)商只需要簡單的繼承LightServer，并實現(xiàn)turnOn和turnOff的抽象方法，就可以完成Light接口的實現(xiàn)，以及Light服務(wù)注冊到hwservicemanager的代碼。
需要使用ILight接口的進程，只需要調(diào)用sp<ILight> lightClient= ILight::tryGetService(這個方法是自動生成的，不是我們聲明的)就可以完成從hwservicemanager獲得Light服務(wù)的Proxy對象，調(diào)用lightClient的turnOn和turnOff接口就可以完成ILight的Binder接口調(diào)用。
HIDL與AIDL的區(qū)別
看了上面的文字描述，應(yīng)該明白了HIDL比AIDL做的事情更多：
AIDL在Server端串聯(lián)Interface和Binder或者Bbbinder，在Client端串聯(lián)Interface和BinderProxy或者Bpbinder
HIDL則是串聯(lián)Interface->Hw Binder SDK->dev/hwbinder
5 總結(jié)
為什么Android團隊要大費周章搞出那么多Binder，我覺得有以下幾個原因：
1.可以發(fā)現(xiàn)App不可能直接跨過FWK調(diào)用HAL層接口，F(xiàn)WK和HAL之間的接口也是安卓官方限定的，這樣子App的代碼和FWK的代碼可以快速的移植到一個新的平臺，這就是安卓的Project Treble計劃，把硬件HAL和安卓FWK，APP層剝離開，配合上mainline計劃，以后Android系統(tǒng)工程師能改的東西越來越少。
2.估計這個是Android團隊絞盡腦汁想出來的KPI，我猜的。
