02 Arquitectura del Proyecto - Marco de Comunicación IPC
IPC (Comunicación entre procesos) es omnipresente en el desarrollo de aplicaciones para Android. Por ejemplo, AlarmManager y InputMethodService que utilizamos son servicios proporcionados por el sistema y están ubicados en procesos diferentes. Si necesita utilizar estos servicios en su propio proceso de solicitud, se requiere comunicación con el IPC.
Además, también existe la posibilidad de comunicación de procesos en nuestros propios programas (especialmente en algunas aplicaciones grandes)
PQ: No iniciado sesión
WeChat: Después de un período de tiempo:
Escenario: Abra el servicio de posicionamiento en el Servicio. El Servicio está en un proceso independiente y necesita obtener el resultado de posicionamiento en el proceso principal de la APLICACIÓN u otras APLICACIONES. La APP obtiene resultados de posicionamiento.
El servicio proporciona métodos expuestos a otros procesos y proporciona la marca de anotación ServiceId. La implementación del servicio debe obtener el mismo ServiceId y la misma implementación del método. No es necesario que LocationManager herede la interfaz ILocationManager j, pero se recomienda garantizar la uniformidad de las firmas de los métodos. Se recomienda heredar. (De lo contrario, uno sería getLocation y el otro getLocation2 no sería divertido)
La ubicación está en el servicio y el resultado de la ubicación está en el registro LocationManager. Utilice el marco para registrar un LocationManager con el servicio.
No es necesario devolver objetos de Binder, lo que significa que los usuarios no necesitan escribir tediosos archivos AIDL sin que se les solicite.
El marco proporcionará com.enjoy.ipc.IPCService$IPCServiceX múltiples servicios reservados para comunicarse con otros procesos. Si una aplicación tiene múltiples procesos y necesita proporcionar servicios para cada proceso, puede usar diferentes servicios. Comunicación servicio + carpeta, pero el marco encapsulará y ocultará los detalles, lo que facilitará su uso.
Cuando obtengas el objeto resultado, podrás llamar al método remoto (llamada RPC) como si fuera un método local.
Simplificación de uso:
1. No es necesario definir su propia interfaz AIDL y no es necesario implementar la interfaz Parcelable cuando se usa JavaBean
2. No es necesario que el cliente use bindService directamente para obtener el objeto Binder;
El servidor necesita definir la interfaz de servicio expuesta (ILocationManager). Si el cliente usa otras aplicaciones, debe colocar la clase de interfaz en su. interfaz de código fuente propio (no es necesario implementarlo). Los métodos definidos en la interfaz los proporciona el servidor para que los utilicen otros procesos.
Todo el marco contiene interfaces tanto en el lado del servidor como en el del cliente.
El ServiceId y el objeto de clase correspondiente de la implementación del servicio se almacenan en caché en el proceso del servicio: ServiceTable, y se debe registrar una lista de todos los métodos en la implementación del servicio: MethodTable. Dado que puede haber varios métodos en un servicio, su estructura de datos es Map
Cuando el cliente necesita llamar al servicio, pasa el ServiceId, el MethodName y los parámetros necesarios para ejecutar el método al servidor, y el servidor utiliza la reflexión Method#invoke para buscar la tabla, lo que puede ser utilizado para ejecutar el método del servicio.
La solicitud del cliente se encapsula como un objeto Solicitud y la respuesta del servidor se encapsula como un objeto Respuesta
El servidor solo necesita exponer la interfaz de servicio para que la utilicen otros procesos. por lo que el servidor solo necesita llamar a la interfaz de registro del marco regiest Para registrar la implementación del servicio.
(Registre la implementación del servicio, no la interfaz del servicio)
Al registrarse, obtenga el ServiceId en la clase a través de la reflexión para registrar la tabla de servicios. Al utilizar la reflexión para obtener todos los métodos públicos de la clase, también se documentará la tabla de métodos.
Dado que el marco básicamente utiliza Binder para la comunicación, proporciona varios servicios reservados para comunicarse con otros procesos.
El servicio de comunicación devuelve un objeto de clase Binder generado por AIDL.
El cliente utiliza el método de envío para iniciar una solicitud al servicio.
El servidor recibe la solicitud e implementa:
El cliente necesita establecer una conexión con el servidor primero, por lo que el marco proporciona un método de conexión, que encapsula bindService internamente para lograr la conexión con el servidor Enlace del servicio de comunicación (IPCService).
Lo único a tener en cuenta es:
Una vez completado el enlace, el cliente puede obtener el objeto IIPCService proporcionado por el servicio de comunicación del lado del servidor y el cliente llama a IIPCService#send. para iniciar una solicitud.
Cuando necesitamos obtener la ubicación. Entonces deberíamos llamar a LocationManager.getDefault().getLocation(). Esta llamada requiere la ejecución de dos métodos de LocationManager: getDefault y getLocation.
Pero el objeto existe en el lado del servidor, entonces, ¿cómo lo obtiene el cliente?
Podemos utilizar proxies dinámicos para crear un objeto de interfaz de servicio (proxy) "falso" en el lado del cliente.
Cuando ejecutamos el método (getLocation) del objeto proxy, volveremos a llamar al método IPCInvocationHandler#invoke, en el cual el framework realizará una solicitud al servidor: IIPCService#send
Y la ubicación devuelta por getLocation registra la información de ubicación del objeto, que el servidor enviará mediante serialización json, por lo que el cliente solo necesita obtener el tipo de retorno del método aquí y deserializarlo.
RPC se refiere a llamar a una función en el servidor desde el cliente mediante el paso de parámetros y obtener el resultado devuelto, ocultando los detalles de comunicación subyacentes. Su forma de uso es llamar a la función remota como una función local.
Por ejemplo, si usamos Okhttp para realizar solicitudes de red:
Esto obviamente no es RPC.
Al usar Retrofit:
RPC: Llamamos a métodos XXX remotos como si fueran métodos locales.