La relación entre binder, hwbinder, vndbinder en Android

1 Introducción

Primero copie un fragmento de texto del documento oficial de Android
https://source.android.google.cn/devices/architecture/hidl/binder-ipc

Históricamente, los procesos de los proveedores han utilizado la tecnología de comunicación entre procesos Binder (IPC) para comunicarse. En Android 8, el nodo del dispositivo / dev / binder se convierte en el nodo exclusivo del proceso del marco, lo que significa que el proceso del proveedor ya no puede acceder a este nodo. Los procesos del proveedor pueden acceder a / dev / hwbinder, pero deben cambiar su interfaz AIDL para usar HIDL. Para los proveedores que desean continuar utilizando la interfaz AIDL entre los procesos del proveedor, Android admitirá Binder IPC de la siguiente manera.

Android 8 admite un nuevo dominio de Binder para servicios de proveedores. El acceso a este dominio requiere / dev / vndbinder (no / dev / binder). Después de agregar / dev / vndbinder, Android ahora tiene los siguientes 3 dominios IPC:

2 Da un ejemplo

Después de leer el texto anterior, muchas personas aún pueden ser más ignorantes. Permítanme dar un ejemplo:

Si hay los siguientes 3 tipos de procesos en el teléfono móvil

a. Proceso de solicitud:

Aplicación de la cámara Aplicación de la
linterna

b. Proceso marco:

Proceso del servidor del sistema

c. Proceso del proveedor:

Proceso de cámara HAL Proceso de
luz HAL

Estos procesos deben utilizar el mecanismo Binder para comunicarse entre procesos. Android proporciona tres nodos de dispositivo Binder dev / binder, dev / hwbinder, dev / vndbinder, lo que significa que el sistema Android también proporciona tres módulos de comunicación Binder que se ejecutan independientemente. Las reglas que definen los tres módulos de comunicación Binder utilizados por cada tipo de proceso son las siguientes:

3 Introducción a los tres Binders y las conexiones entre ellos.

3.1 dev / aglutinante

Este es el Binder con el que estamos más familiarizados. En el desarrollo de aplicaciones, ActivityManagerService usa esto. Java hereda Binder y C ++ hereda Bbbinder. Luego registre el nombre real Binder a través del proceso servicemanager, y luego pase el objeto anónimo Binder a través de la interfaz Binder que se ha creado Después de llegar a BinderProxy o BpBinder, puede comunicarse con Binder.

3.2 dev / vndbinder

De hecho, dev / vndbinde y dev / binder se usan básicamente de la misma manera y comparten un conjunto de Binder SDK. Java hereda Binder y Cbb hereda Bbbinder. Sin embargo, el nombre real Binder se registra a través del proceso vndservicemanager, y luego el objeto anónimo Binder se pasa a través de la interfaz Binder que se ha creado. Después de obtener BinderProxy o BpBinder, puede comunicarse con Binder. Cómo utilizar el mismo conjunto de código Binder SDK, el último nodo del dispositivo al que se accede se convierte en dev / vndbinder y servicemanager se convierte en vndservicemanager.

En realidad y simple, simplemente ejecute el siguiente código cuando inicialice el proceso

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

Dev / binder y dev / vndbinder no se pueden usar en el mismo proceso al mismo tiempo

Los lectores atentos deben descubrir que ninguno de los tres tipos de procesos en la figura anterior no puede usar dev / binder y dev / vndbinder al mismo tiempo. Esto no es solo un acuerdo oficial de Android, sino también una limitación del SDK actual de Android Binder, porque ambos son Binder compartidos SDK, por lo que solo se puede especificar un nodo de dispositivo, dev / binder o dev / vndbinder

3.3 dev / hwbinder

Entonces, ¿cómo resuelve dev / hwbinder el problema de la coexistencia con dev / binder o dev / vndbinder? Alguien debe haberlo pensado. Es muy simple. Copiamos todos los SDK de Binder a un nuevo conjunto de SDK de Hw Binder y le cambiamos el nombre a dev / hwbinder, HwBinder, HwBbinder, hwservicemanager, HwProcessState, para que no pueda coexistir con dev / binder o dev / vndbinder Es? De hecho, el equipo de Android hará algo como esto.

Pero piensan que hwbinder es estandarizar la capa hal. Después de todo, la capa hal opera hardware, por lo que no deberían proporcionar definiciones de interfaz libres y problemáticas.
Tienen dos objetivos:
1. No puede ser tan libre, lo que obliga a todos los proveedores a implementar de acuerdo con la interfaz oficial hal definida por Android
2. No puede aumentar el costo de aprendizaje de los desarrolladores de proveedores, aprender un conjunto complejo de Hw Binder SDK
para lograr lo anterior Con dos objetivos, el equipo de Android ideó la solución HIDL.

4 ¿Qué es HIDL?

No entraré en detalles sobre lo que HIDL ha hecho. Permítanme describir brevemente:
si Android define oficialmente una interfaz de capa HAL de ILight.hal

 
  1. Interface ILight {

  2. void turnOn();

  3. void turnOff();

  4. }

La compilación generará automáticamente objetos java y objetos c ++ de las siguientes dos clases LightServer y LightClient.

El proveedor solo necesita simplemente heredar LightServer e implementar los métodos abstractos de TurnOn y TurnOff para completar la implementación de la interfaz Light y registrar el servicio Light en hwservicemanager.

Los procesos que necesitan utilizar la interfaz ILight solo necesitan llamar a las interfaces turnOn y turnOff del LightClient para completar el objeto Proxy que obtiene el servicio Light de hwservicemanager y la llamada de la interfaz ILight.

La diferencia entre HIDL y AIDL

Después de leer la descripción de texto anterior, debe entenderse que HIDL hace más que AIDL:
AIDL conecta la interfaz y Binder o Bbbinder en el lado del servidor, y la interfaz y BinderProxy o Bpbinder
HIDL en el lado del cliente conecta la interfaz-> Hw Binder SDK- > dev / hwbinder

5 Resumen

¿Por qué el equipo de Android tiene que pasar tanto tiempo para crear tantos Binders? Creo que hay varias razones:
1. Reducir el acoplamiento entre las diversas capas, facilitar el trasplante rápido del sistema Android, actualizar, mejorar la estabilidad del sistema, para que los ingenieros del sistema Android en el futuro Cada vez hay menos cosas que se pueden cambiar.
2. Se estima que este es el KPI que el equipo de Android se ha destrozado, supongo.

Publicado 766 artículos originales · elogiados 474 · 2.54 millones de visitas

Supongo que te gusta

Origin blog.csdn.net/u010164190/article/details/105511541
Recomendado
Clasificación