Interpretación completa de los cuatro componentes principales de Android

"¿Cómo debo diseñar mi aplicación? ¿Qué patrón de arquitectura debo adoptar? ¿Necesito usar bus de eventos?"

A menudo vemos a los desarrolladores de la plataforma Android haciendo preguntas sobre los patrones de diseño y las arquitecturas que se utilizan en las aplicaciones. Pero es probable que la respuesta te sorprenda, es decir, nosotros (nos referimos al Equipo de la Plataforma de Android) no tenemos una visión clara sobre esto, e incluso se puede decir que no tenemos ninguna visión.

¿Debería utilizar MVC o MVP o MVVM? No sé. De hecho, solo conocí MVC cuando estaba en la escuela, y los otros patrones arquitectónicos se escribieron aquí después de que hice una búsqueda temporal en Google.

Esto puede resultar sorprendente, porque Android les da a las personas la sensación de que tiene una visión muy sólida sobre cómo escribir aplicaciones. Esta visión se refleja en algunos conceptos de alto nivel, como sus API de Java y cuatro componentes principales. Estas cosas se parecen a la Forma a marco de desarrollo de aplicaciones típico, díganos a los desarrolladores, debe implementar sus funciones de esta manera. Pero la realidad es que este no es el caso en absoluto.

Podemos llamar a las API centrales de Android (API centrales) el "marco del sistema", y la función principal de las API de la plataforma es definir cómo la aplicación debe interactuar con el sistema operativo, y no tiene nada que ver con la lógica operativa interna de la aplicación.

Comprensión personal : simplemente puede considerar las API centrales como el kernel del sistema operativo y las API de la plataforma como el marco de Android que solemos decir.

Es decir, para las API de plataforma, las funciones y funciones de las API de plataforma a menudo son inconsistentes desde la perspectiva de los desarrolladores y desde la perspectiva de los sistemas operativos, lo que puede confundir fácilmente a las personas en su uso.

Por ejemplo, consideremos cómo el sistema operativo define "cómo ejecutar una aplicación". En un sistema clásico, lo más básico es requerir que la APP incluya un método principal, que defina cómo ejecutarla:

int main(...){
//我的APP从这里开始运行
}

Comprensión personal : la idea central de este artículo es explicar que los llamados cuatro componentes principales solo permiten que su APLICACIÓN le diga al sistema operativo cómo ejecutarla, y no tiene nada que ver con cómo diseñar su propia APLICACIÓN. Las aplicaciones tradicionales usan un método principal para decirle al sistema operativo: "Oye amigo, el método principal es mi entrada, por favor empieza a ejecutarme desde este método". Android te ofrece cuatro opciones, cada componente es para el sistema operativo. Una especie de entrada a ejecute su aplicación.

Bueno, el sistema operativo está a punto de ejecutar su APLICACIÓN, por lo que llama a su método principal, y luego su aplicación comienza a ejecutarse, puede hacer lo que quiera, hasta que crea que ha completado la tarea. Tenga en cuenta que el requisito para que defina el método principal aquí no es que usted haga nada o complete una función llamada main. La función principal del método principal es solo proporcionar un punto de entrada para que la aplicación se ejecute.

Pero en el mundo de Android, decidimos que no queremos un método principal claro como la entrada de la APP. Porque necesitamos darle al sistema más control sobre cómo se ejecuta la aplicación. En 我们希望构建一个这样的系统，在该系统中，用户永远不需要考虑开启和停止一个APP，而把这些事交给系统去管理particular ,. Por lo tanto, el sistema necesita saber más sobre el funcionamiento interno de cada APLICACIÓN para poder iniciar la APLICACIÓN de una manera definida cuando sea necesario, incluso si la APLICACIÓN no se está ejecutando en ese momento.

Comprensión personal : el funcionamiento interno de cada aplicación que este sistema necesita comprender es en realidad el contenido del archivo Manifest.xml.

Para lograr esto, descomponemos el método principal de una aplicación en varias formas con las que el sistema puede interactuar. Se trata de varias formas Activity, BroadcastReceiver, Servicey ContentProviderlas API, la mayoría de los desarrolladores de Android están familiarizados con ellos.

这些类好像在告诉你，你的APP内部应当怎样工作，但这是一种误解！事实上，这些类只是定义你的APP需要怎样与系统交互（以及系统怎样协调你的APP与其他APP进行交互）。这种与系统的交互一旦开始，系统就不再关心你的APP内部是怎样运行了。

Para ilustrar mejor este punto, veamos brevemente qué significan estas API para el sistema Android.

Actividad

Este es el punto de entrada para que una aplicación interactúe con los usuarios. Desde la perspectiva del sistema, las acciones clave de interacción proporcionadas por el sistema para Actividad son:

1. Lleve un registro de lo que le preocupa al usuario actualmente (es decir, lo que se muestra en la pantalla) para asegurarse de que el proceso actual siga ejecutándose.

   Comprensión personal : aquí, el autor en realidad quiere decir que cuando el sistema inicia su aplicación desde la Actividad, entre los estados de inicio y parada de la Actividad, el sistema se asegurará de que la Actividad siempre ocupe la pantalla del dispositivo y que su aplicación El sistema nunca lo matará. Esta es una especie de promesa (solo una promesa) que el sistema le da a su APLICACIÓN cuando inicia su propia APLICACIÓN desde Actividad.

2. Conozca los procesos que se han utilizado anteriormente, estos procesos contienen las actividades detenidas a las que el usuario puede volver, y por lo tanto otorgan a estos procesos una mayor prioridad.

3. Ayude a la aplicación a manejar la situación en la que se mata el proceso, para que el usuario pueda volver a las actividades anteriores y estas actividades puedan cargar su estado anterior.

   Comprensión personal : obviamente, este estado del sistema prometió capacidades de recuperación, es confiar en Activitylos métodos onSaveInstanceStatey onRestoreInstanceState, es decir, desea mantenerlo que desea guardar en el proceso de ser eliminado en el estado de actividad del método Guardar, entonces usted puede obtener estos estados en el método Restaurar para restaurar la Actividad. Cuando haga esto, el resto es asunto del sistema, el sistema prometerá que si el proceso en el que su Actividad se cancela debido a la presión de la memoria, cuando regrese, el sistema reconstruirá su proceso de aplicación y lo ayudará a restaurar el estado de la actividad anterior.

4. Proporcionar una forma de flujo de usuarios entre diferentes aplicaciones, por supuesto, esto depende del sistema a coordinar. El ejemplo más clásico es la realización de la función de compartir.

Para Activity, lo que no le importa al sistema es:

Una vez que el sistema ingresa a la IU de la APLICACIÓN desde la entrada de la Actividad, el sistema ya no se preocupará por la organización de la lógica interna de la Actividad. Puede poner toda la lógica de la aplicación en esta actividad. Por ejemplo, puede cambiar manualmente sus vistas, usar fragmentos u otros marcos, o puede dividir la lógica de su aplicación en actividades internas adicionales. También puede usar los tres al mismo tiempo (refiriéndose a cambiar vistas, usar fragemnts y dividirlos en actividades adicionales). El sistema no se preocupa por estas cosas, siempre y cuando siga el acuerdo entre la Actividad y el sistema (inícielo en un estado apropiado y guarde / restaure su estado correctamente).

Receptor de radiodifusión

Este es un mecanismo que permite que el sistema pase eventos a la APLICACIÓN además del flujo normal de usuarios. Más importante aún, debido a que esta es la entrada a otra APLICACIÓN bien definida, el sistema puede enviar transmisiones a la APLICACIÓN incluso si la APLICACIÓN no se está ejecutando. Entonces, por ejemplo, una APLICACIÓN puede programar una alarma por adelantado para notificar al usuario de un evento próximo. Al pasar la alarma a un BroadcastReceiver de la APLICACIÓN, la APLICACIÓN no necesita ejecutarse antes de que ocurra la alarma.

Para BroadcastReceiver, lo que no le importa al sistema es:

在APP内部分发事件Es un BroadcastReceiver y recibir evento totalmente diferentes cosas, si se está utilizando algún tipo de marco EventBus, implementar su propio sistema de devolución de llamada, o cualquier otro método ...你都没有理由使用系统的广播机制，因为你并不是在App之间分发事件 .

De hecho, hay una buena razón para no usar el mecanismo de transmisión del sistema, que traerá muchas cargas innecesarias, y el uso del mecanismo de transmisión global para implementar la distribución de eventos dentro de la APLICACIÓN causará muchos problemas de seguridad.

Por supuesto, también proporcionamos una clase de conveniencia LocalBroadcastManager, que implementa un sistema de distribución de intención pura, y su API es muy similar a la API BroadcastReceiver del sistema, puede usarla si lo desea. 但再次强调，你没有理由在仅仅发生在APP中的事情上使用BroadcastReceiver机制.

Servicio

Cuando se requiere que la APLICACIÓN se ejecute en segundo plano por varias razones, el Servicio es una de esas entradas. Hay dos Servicios semánticamente distintos (uno es Servicio iniciado, el otro es Servicio vinculado) para indicarle al sistema cómo administrar una APLICACIÓN.

El servicio iniciado es equivalente a que su APLICACIÓN le diga al sistema por alguna razón: "Hermano mayor, tengo algo que hacer, déjeme correr hasta que le diga que he terminado". El Servicio representa la APLICACIÓN, y el sistema solo habla con la APLICACIÓN) La "cosa" aquí puede ser sincronizar datos en segundo plano o reproducir música después de que el usuario abandona la APLICACIÓN.

Al mismo tiempo, existen dos tipos de Servicio iniciado, uno es perceptible por los usuarios y el otro no es perceptible por los usuarios. Estos dos servicios iniciados diferentes permitirán que el sistema adopte diferentes métodos de gestión para ellos.

1. El servicio que reproduce música es directamente perceptible por el usuario, por lo que el Servicio le dirá al sistema: "Quiero estar en primer plano y colgar una notificación en la barra de notificaciones para que el usuario pueda sentir mi presencia". En este caso , el sistema Sabiendo que debe hacer sus mejores esfuerzos para asegurar el funcionamiento de este proceso de servicio, porque si este proceso deja de funcionar, el usuario no estará satisfecho.
2. Otro servicio en segundo plano no es percibido directamente por los usuarios, por lo que el sistema puede manejar el proceso de este servicio de manera más flexible. Cuando el sistema necesita RAM con urgencia para garantizar el funcionamiento normal de las cosas inmediatas del usuario, el sistema puede permitir que se elimine el proceso (luego, el Servicio se puede iniciar más tarde cuando sea posible).

El Servicio Bound se ejecuta porque otras aplicaciones o sistemas lo usan. Por lo general, el Servicio proporcionará una API a otros procesos. En este caso, el sistema sabe que existe una dependencia entre los dos procesos. Por lo tanto, si el proceso A está vinculado a un servicio en el proceso B, el sistema sabrá que debe garantizar el funcionamiento normal del proceso B y sus servicios para el proceso A. Además, si el proceso A es el proceso que le preocupa al usuario actualmente, el sistema sabrá que el proceso B es también el proceso que le preocupa al usuario.

Debido a la flexibilidad del Servicio (tanto bueno como malo), el Servicio se ha convertido en un bloque de construcción muy útil en varios tipos de sistemas. Los fondos de pantalla en tiempo real, los escuchas de notificaciones y muchas otras funciones principales del sistema se crean como servicios y, cuando necesitan ejecutarse, el sistema los vincula.

Para el servicio, lo que no le importa al sistema es:

A Android no le importan las cosas en su APLICACIÓN que no afectan la forma en que trata su proceso, por lo que no hay razón para usar el Servicio en estas situaciones. Por ejemplo, si desea descargar datos para su interfaz de usuario en segundo plano, no debe usar el Servicio para hacer esto. Al hacer estas cosas, es muy importante no decirle al sistema que mantenga su proceso en ejecución. Porque es realmente innecesario ! ! Hacerlo también le da al sistema más libertad para administrar su proceso con el fin de coordinarse con lo que está haciendo el usuario ( 注：可以让系统在内存紧急的情况下，杀死你的进程，优先保证用户正在做的事情，这里忍不住吐槽一句：每个APP肯定都会觉得自己是最重要的哈，Google开发Android的人也是典型的理想主义！)

Si simplemente inicia un hilo en segundo plano para descargar datos (u otros métodos que no son el Servicio), obtendrá el resultado que desea: si el usuario está en su IU, el sistema se asegurará de que su proceso se esté ejecutando. nunca ser interrumpido. Cuando el usuario abandona su interfaz de usuario, su proceso aún se mantendrá (en caché) para que pueda continuar descargando datos, siempre que la RAM no tenga prisa.

Del mismo modo, para conectar diferentes partes de su APLICACIÓN, no tiene ninguna razón para vincular el Servicio en el mismo proceso. No hay ningún daño obvio al hacerlo, porque el sistema verá que el proceso tiene una dependencia de sí mismo, ignorará esta dependencia y aún tratará su APP como un proceso normal. Pero esto es realmente innecesario para usted y el sistema. Como alternativa, puede usar singletons u otros patrones en proceso para conectar partes de su aplicación.

Proveedor de contenido

Finalmente, ContentProvider es un método dedicado que se utiliza para exponer los datos de su aplicación a otros lugares. La gente suele pensar en ellos como una abstracción de la base de datos, porque hay muchas API y bibliotecas de soporte que usan ContentProvider de esta manera. Pero desde la perspectiva del diseño del sistema, esta no es la intención original de ContentProvider.

Para el sistema, ContentProvider es en realidad un punto de entrada para obtener elementos de datos con nombre público (elementos de datos) dentro de una aplicación, y cada elemento de datos se identifica mediante un esquema de URI. De esta manera, la APLICACIÓN puede decidir cómo mapear sus propios elementos de datos a un esquema de URI y cómo exponer este esquema de URI a otras APLICACIONES o sistemas, de modo que la APLICACIÓN o el sistema pueda usar este esquema de URI para obtener sus propios datos internos. . Esto permitirá que el sistema administre su APLICACIÓN de formas muy singulares:

1. Exponer el esquema de URI no requiere que su APLICACIÓN siga ejecutándose, por lo que incluso si su APLICACIÓN no se está ejecutando, estos esquemas de URI pueden estar expuestos a cualquier aplicación y sistema. Solo cuando alguien le dice al sistema: "Por favor, dame los datos representados por este URI", el sistema dejará que tu APP se ejecute y te preguntará por los elementos de datos correspondientes al URI y se los devolverá al solicitante.
2. Estos URI también proporcionan un importante modelo de seguridad detallado. Por ejemplo, su aplicación puede colocar un URI que representa una imagen en su aplicación en el portapapeles, pero mantener su ContendProvider bloqueado, para que nadie pueda obtenerlo libremente. Cuando otra APP obtiene esta URI del portapapeles y solicita al sistema que obtenga la imagen correspondiente, el sistema puede darle un "permiso URI" temporal para que solo pueda obtener la imagen correspondiente a la URI, su APP El resto del contenido es seguro.

Para ContentProvider, lo que no le importa al sistema es:

Detrás de un ContentProvider, al sistema no le importa cómo su aplicación administra sus datos; si no necesita los datos estructurados en la base de datos SQLite, no necesita usar SQLite. Por ejemplo, la clase auxiliar FileProvider permite que los archivos originales en su APLICACIÓN se obtengan fácilmente a través de ContentProvider.

De manera similar, si no planea revelar los datos en su aplicación para que otros los usen, no necesita implementar ContentProvider. Este es el caso, porque existen muchos métodos convenientes en ContentProvider. Estos métodos le permiten almacenar fácilmente datos en la base de datos SQLite y completar elementos de la interfaz de usuario como ListView con estos datos. Pero si estos métodos le hacen sentir que es difícil hacer realidad sus propias ideas, no necesita usarlos. Siéntase libre de elegir un modelo de datos que sea adecuado para su APLICACIÓN.