1はじめに
まず、公式のAndroidドキュメント
https://source.android.google.cn/devices/architecture/hidl/binder-ipc からテキストをコピーします
歴史的に、サプライヤーのプロセスは、バインダーのプロセス間通信（IPC）テクノロジーを使用して通信してきました。Android 8では、/ dev /バインダーデバイスノードがフレームワークプロセスの排他ノードになります。つまり、ベンダープロセスはこのノードにアクセスできなくなります。ベンダープロセスは/ dev / hwbinderにアクセスできますが、HIDLを使用するにはAIDLインターフェイスを切り替える必要があります。ベンダープロセス間でAIDLインターフェイスを引き続き使用したいベンダーの場合、Androidは次のようにBinder IPCをサポートします。
Android 8は、ベンダーサービスの新しいバインダードメインをサポートしています。このドメインへのアクセスには、/ dev / vndbinderが必要です（/ dev /バインダーではありません）。/ dev / vndbinderを追加した後、Androidには次の3つのIPCドメインがあります。
2例を挙げてください
上記のテキストを読んだ後、多くの人々はまだより無知であるかもしれません。
携帯電話に以下の3種類の処理がある場合
a。申請プロセス：
カメラアプリ
懐中電灯アプリ
b。フレームワークプロセス：
システムサーバープロセス
c。サプライヤープロセス：
カメラHALプロセス
ライトHALプロセス
これらのプロセスは、バインダーメカニズムを使用してプロセス間で通信する必要があります。Androidは3つのバインダーデバイスノードdev /バインダー、dev / hwbinder、dev / vndbinderを提供します。つまり、Androidシステムは3つの独立して実行されるバインダー通信モジュールも提供します。Androidチーム各タイプのプロセスで使用される3つのバインダー通信モジュールを定義するルールは次のとおりです。
3 3つのバインダーとそれらの間の接続の概要
3.1 dev / binder
これは、私たちが最もよく知っているバインダーです。アプリ開発では、ActivityManagerServiceがこれを使用します。Javaはバインダーを継承し、C ++はBbbinderを継承します。次に、servicemanagerプロセスを通じて実名のバインダーを登録し、作成されたバインダーインターフェースを通じて匿名のバインダーオブジェクトを渡します。 BinderProxyまたはBpBinderに到達したら、Binderと通信できます。
3.2 dev / vndbinder
実際、dev / vndbindeとdev / inderは基本的に同じ方法で使用され、一連のBinder SDKを共有します。JavaはBinderを継承し、CbbはBbbinderを継承します。ただし、実際の名前Binderはvndservicemanagerプロセスを通じて登録され、匿名のBinderオブジェクトは作成されたBinderインターフェイスを介して渡されます。 BinderProxyまたはBpBinderを取得したら、Binderと通信できます。同じバインダーSDKコードのセットを使用する方法、最後にアクセスされたデバイスノードはdev / vndbinderになり、servicemanagerはvndservicemanagerになります。
実際にそして単純です、あなたがプロセスを初期化するときに次のコードを実行するだけです
ProcessState::initWithDriver("/dev/vndbinder");
Dev /バインダーとdev / vndbinderを同時に同じプロセスで使用することはできません
注意深い読者は、上の図の3つのタイプのプロセスのいずれも、dev / binderとdev / vndbinderを同時に使用できないことを理解する必要があります。これは、公式のAndroid契約であるだけでなく、現在のAndroidバインダーsdkの制限でもあります。 SDKの場合、指定できるデバイスノードは1つだけです。dev/ inderまたはdev / vndbinderのいずれかです。
3.3 dev / hwbinder
それでは、dev / hwbinderはどのようにしてdev /バインダまたはdev / vndbinderとの共存の問題を解決しますか？誰かがそれを考えたことがあるはずです。それは非常に簡単です。すべてのバインダーSDKをHwバインダーSDKの新しいセットにコピーし、dev / hwbinder、HwBinder、HwBbinder、hwservicemanager、HwProcessStateに名前を変更して、dev /バインダーまたはdev / vndbinderと共存できないようにしましたそうですか？実際、Androidチームはこのようなことをします。
しかし、彼らはhwbinderがhalレイヤーを標準化することであると考えており、結局、halレイヤーはハードウェアを操作するため、そのような自由で面倒なインターフェース定義を提供すべきではありません。
彼らの目標は二つある：
1。とても自由ではない、実装するためのアンドロイドHALインターフェースの正式な定義に従ってすべてのサプライヤーのための強制的な
2はHwのバインダーSDKの複雑なセットを学ぶために、ベンダーの開発を学習するコスト増やすことはできません
上記目的を達成するためには2つの目標で、AndroidチームはHIDLソリューションを考え出しました。
4 HIDLとは
HIDLが行ったことについては詳しく説明しません。簡単に説明し
ます。AndroidがILight.halのHALレイヤーインターフェイスを正式に定義している場合
-
Interface ILight { -
void turnOn(); -
void turnOff(); -
}
コンパイルは、次の2つのクラスLightServerおよびLightClientのJavaオブジェクトおよびC ++オブジェクトを自動的に生成します。
サプライヤーは、単にLightServerを継承し、turnOnおよびturnOffの抽象メソッドを実装して、Lightインターフェースの実装を完了し、hwservicemanagerにLightサービスを登録するだけで済みます。
ILightインターフェイスを使用する必要があるプロセスは、LightClientのturnOnおよびturnOffインターフェイスを呼び出して、hwservicemanagerおよびILightインターフェイス呼び出しからLightサービスを取得するProxyオブジェクトを完了するだけで済みます。
HIDLとAIDLの違い
上記のテキストの説明を読んだ後、HIDLはAIDLよりも多くのことを理解する必要が
あります。AIDLはサーバー側でインターフェイスとバインダーまたはBbbinder、クライアント側でインターフェイスとBinderProxyまたはBpbinder
HIDLを接続します。> dev / hwbinder
5まとめ
なぜ多くのバインダーを作成するのにAndroidチームが多くの時間を費やさなければならないのか、いくつかの理由があると思います：
1.さまざまなレイヤー間のカップリングを減らし、Androidシステムの迅速な移植を容易にし、アップグレードし、システムの安定性を向上させます。変更できるものはますます少なくなっています。
2.これは、Androidチームが頭を悩ませたKPIであると推定されています。
