Mecanismo IPC de Linux (3): Carpeta
Como se mencionó en el capítulo anterior, la comunicación entre procesos requiere soporte de espacio del kernel. Los mecanismos IPC tradicionales, como tuberías y sockets, son parte del kernel, por lo que es natural implementar la comunicación entre procesos a través del kernel. soporte No hay problema
Pero Binder no es parte del kernel del sistema Linux, entonces, ¿qué debemos hacer? Esto se debe al mecanismo del módulo cargable del kernel dinámico (LKM) de Linux.
De esta manera, el sistema Android puede ejecutarse en el espacio del kernel agregando dinámicamente un módulo del kernel, y los procesos del usuario utilizan este módulo del kernel como puente para lograr la comunicación.
Luego, en el sistema Android. , el usuario procesa ¿Cómo se implementa la comunicación a través de este módulo del kernel (controlador Binder)? Obviamente no es lo mismo que la comunicación IPC tradicional en el capítulo anterior, que requiere dos copias; de lo contrario, Binder no tendrá ninguna ventaja de rendimiento. >
El mapeo de memoria diseñado en el mecanismo Binder IPC se implementa a través de mmap (), que es un método de mapeo de memoria en el sistema operativo.
El mapeo de memoria puede reducir la cantidad de copias de datos. La interacción entre el espacio del usuario y el espacio del kernel también puede reflejarse directamente en el área de memoria mapeada y ser percibida por el otro espacio en el tiempo. Debido a esto, el mapeo de memoria puede proporcionar soporte para la comunicación entre procesos. /p>
Binder IPC se implementa en función del mapeo de memoria (mmap()), pero mmap() generalmente se usa en sistemas de archivos con medios físicos.
Por ejemplo, en un proceso El área de usuario. no puede interactuar directamente con dispositivos físicos. Si desea leer los datos del disco en el área de usuario del proceso, debe copiar dos veces (disco-gt; kernel space-gt; espacio de usuario). mmap() puede funcionar estableciendo un mapeo entre los medios físicos y el espacio del usuario, reduciendo la cantidad de copias de datos, usando lectura y escritura de memoria en lugar de lectura y escritura de E/S y mejorando la eficiencia de lectura de archivos. Binder no tiene medios físicos, por lo que el controlador de Binder usa mmap() no para mapear entre los medios físicos y el espacio del usuario, sino para crear un espacio de caché para la recepción de datos en el espacio del kernel.
Una comunicación IPC de Binder completa. El proceso generalmente se ve así:
Esto completa una comunicación entre procesos
Como se muestra a continuación:
Se presenta la comunicación subyacente de Binder IPC. eche un vistazo a cómo está diseñado el nivel de implementación
Una comunicación entre procesos completa debe incluir al menos dos procesos. Por lo general, llamamos a las dos partes de la comunicación el proceso del cliente (Cliente) y el Proceso del servidor (. Server), debido a la existencia del mecanismo de aislamiento de procesos, las partes de la comunicación deben utilizar Binder para lograrlo.
BInder se basa en la arquitectura C/S y se compone de una serie de componentes. Cliente, Servidor, ServiceManager, controlador Binder
El controlador Binder es como un enrutador y es el núcleo de toda la comunicación. El controlador es responsable de la comunicación entre procesos.
El establecimiento / transmisión de la comunicación de Binder, la gestión del recuento de referencias de Binder y una serie de soportes subyacentes, como la transmisión e interacción de paquetes de datos entre procesos.
La función de ServiceManager es convertir el nombre de Binder en caracteres. formulario en el nombre correspondiente en el Cliente. La referencia de Binder permite al Cliente obtener una referencia a la entidad de Binder a través del nombre de Binder.
Un Binder con un nombre registrado se denomina Binder de nombre real. , al igual que un sitio web, tiene su propia dirección de sitio web además de la dirección IP.
p>
El servidor crea Binder y le asigna un nombre que es legible y fácil de recordar en forma de caracteres. Envía la entidad BInder junto con el nombre al ServiceManager en forma de paquete de datos a través del controlador Binder y notifica al ServiceManager que registre un nombre. El Binder de "Zhang San" se encuentra en un determinado servidor. el nodo de entidad en el kernel y la referencia del ServiceManager a la entidad para este Binder que cruza el límite del proceso. Empaqueta el nombre y la referencia recién creada al ServiceManager, y el ServiceManager los recibe después de extraer los datos. La referencia se completa en la tabla de búsqueda.
ServiceManager es un proceso y el servidor es otro proceso. El servidor que registra BInder con ServiceManager debe implicar la comunicación entre procesos. Al implementar la comunicación entre procesos, también necesitamos usar inter. -La comunicación del proceso, que es como un requisito previo para que los huevos eclosionen, es encontrar una gallina para poner huevos primero. ¡La implementación de Binder es más inteligente, es decir, crear una gallina con anticipación para poner huevos también! Utilice la comunicación de Binder, ServiceManager es el lado del servidor y tiene su propia entidad de Binder. Otros procesos son Clientes. El registro, la consulta y la adquisición de Binder deben realizarse a través de la referencia de este Binder proporcionado por ServiceManager. nombre y no es necesario registrarlo. Cuando un proceso utiliza el comando BINDERSETCONTEXT_MGR para registrarse como ServiceManager, el controlador de Binder creará automáticamente una entidad de Binder para él (este es el pollo prefabricado). La referencia a esta entidad Binder se fija en 0 en todos los Clientes, sin necesidad de Obtenerla por otros medios. En otras palabras, si un Servidor quiere registrar su propio Binder con ServiceManager, debe comunicarse con el Binder de ServiceManager a través de este número de referencia 0. El Cliente mencionado aquí es relativo a ServiceManager. Un proceso o aplicación puede ser un Servidor que proporciona servicios, pero sigue siendo un Cliente para ServiceManager.
Después de que el Servidor registra el Binder con ServiceManager. El Cliente puede obtener la referencia de Binder por nombre. El Cliente también utiliza el número de referencia reservado 0 Solicitar acceso a un Binder del ServiceManager. Por ejemplo, el Cliente solicita acceder a una referencia de Binder llamada "Zhang San". ServiceManager recupera los datos de la solicitud del paquete de solicitud.
Saque el nombre de Binder, busque la entrada correspondiente en la tabla de búsqueda, saque la referencia de Binder correspondiente y envíela como respuesta al Cliente que inició la solicitud. Desde una perspectiva orientada a objetos, la entidad Binder en el Servidor ahora. tiene dos referencias: una está ubicada en ServiceManager y otra ubicada en el Cliente que inició la solicitud. Si más Clientes solicitan el Binder más adelante, habrá más referencias en el sistema apuntando a este Binder, al igual que un objeto en Java tiene múltiples. referencias
Hemos explicado claramente el mecanismo de implementación del Cliente y el Servidor utilizando el controlador Binder para completar la comunicación entre procesos, pero todavía hay un problema que debe aclararse, como cómo el proceso A quiere un. objeto en el proceso B que se implementará Bueno, después de todo, pertenecen a procesos diferentes y el proceso A no puede usar directamente el objeto en el proceso B.
Mencionamos anteriormente que el controlador Binder está involucrado en el proceso. de comunicación entre procesos, por lo que cuando los datos fluyen a través de Binder Al conducir, el controlador de Binder realizará una capa de conversión en los datos
Cuando obtengamos la referencia específica de Binder en el lado del servidor del ServiceManager. en el lado del cliente, primero ingresaremos el controlador de Binder. El controlador de Binder no devuelve la referencia de Binder del servidor real al cliente, sino que devuelve un objeto java proxy, que tiene la misma firma de método que la referencia de Binder del servidor. ProxyObject tiene los mismos métodos que la instancia de Binder del servidor, pero estos métodos no tienen las capacidades del lado del servidor. Estos métodos solo necesitan entregar los parámetros de solicitud al controlador de Binder. lo mismo que llamar directamente a los métodos en el servidor
Después de comprender lo anterior, podemos deducir aproximadamente el proceso de comunicación de Binder
1. Registre ServiceManager
2. Registrar el Servidor
3. El Cliente obtiene la referencia del Binder del Servidor
4. Comunicación Cliente y Servidor