¿Cuáles son los cuatro componentes principales de Android? Por favor, hable sobre su comprensión de ellos.
Actividad
Para hacer un programa completo de Android, si no quieres usar Actividad, es realmente difícil, a menos que quieras volverte colorido y loco. Debido a que la Actividad es la ventana a través de la cual los programas de Android interactúan con los usuarios, en mi opinión, desde esta perspectiva, la Actividad de Android es especialmente como una página de sitio web.
La actividad, entre los cuatro componentes, es sin duda el más complejo en estos días, si algo está vinculado a la interfaz, ¿no podemos simplificarlo? ¿Cuánto tiempo lleva construir una aplicación de forma independiente? , se puede calcular claramente. Desde una perspectiva visual, Actividad ocupa la ventana actual, responde a todos los eventos de la ventana y tiene controles, menús y otros elementos de la interfaz. Desde la perspectiva de la lógica interna, la Actividad necesita mantener el estado de cada interfaz, necesita mucha persistencia y necesita gestionar adecuadamente el ciclo de vida y algunos saltos lógicos. Los desarrolladores necesitan derivar una subclase de Actividad y luego trabajar en las cosas anteriores. Para obtener más detalles sobre la Actividad, consulte reference/android/app/Activity.html, seguido de un análisis más detallado.
Servicio
El servicio, desde el punto de vista más sencillo, es una Actividad sin interfaces. Están más cerca de muchos conceptos de Android y ambos encapsulan la lógica funcional completa. No aparece en público, pero silenciosamente brinda un sólido respaldo.
Pero mirándolo desde otra perspectiva, el Servicio en Android es algo similar a lo que solemos llamar servicios de Windows, servicios Web en segundo plano, etc. Suelen ejecutarse en segundo plano durante mucho tiempo, acepte la parte superior -Instrucciones de nivel y completar tareas relacionadas. En términos del modo de ejecución, la Actividad salta de uno a otro, bueno..., es un poco como un diálogo modal (tal vez incluso como una página web...), dada una entrada (o ninguna entrada...) ), luego déjelo ejecutar independientemente y devuelva la salida (igual o no igual...) cuando salga.
El servicio no es así. Está esperando a que la capa superior se conecte a él y luego genera una comunicación persistente y persistente. Parece que no hay cambios. pero se comunica en secreto con el Servicio sin saber cuánto tiene de correcto.
Pero es diferente del Servicio general. Como los cuatro componentes principales, el Servicio de Android tiene un modelo de proceso configurable, y la persona que llama y el editor pueden elegir ejecutarlo en el mismo proceso. Los componentes aún se ejecutan en diferentes. procesos. Esta frase se puede grabar en el cerebro con un cortaúñas y resalta las características del tiempo de ejecución de Android. Si desea que el servicio se ejecute en un proceso diferente de la persona que llama, es necesario utilizar el mecanismo RPC proporcionado por Android para implementar una estrategia de comunicación entre procesos para él.
La implementación RPC de Android se muestra en la imagen de arriba (también extraída del SDK...), y no tiene nada de especial. La implementación de RPC se basa en el patrón de proxy, en el que tanto el llamador como el servidor generarán una clase de proxy que realizará algunas operaciones de serialización y deserialización, permitiendo que tanto el llamador como el servidor usen RPC como si fuera una interfaz local. .
La clase utilizada para la serialización de datos en Android es Parcel, consulte:/ Esta clase encapsula los detalles de la serialización y proporciona una interfaz de acceso totalmente orientada a objetos al mundo exterior. Android afirma que La implementación de. La interfaz es muy eficiente.
También existe AIDL (lenguaje de definición de interfaz de Android, lenguaje de definición de interfaz de Android), que es un lenguaje de definición de interfaz para la interfaz RPC del servicio, puede usar AIDL para describirlo, por lo que ADT puede ayudar. ¡Generar automáticamente un conjunto completo de clases que deben usarse en el modo proxy es un trabajo duro y muy agotador que se escribe sin pensar! ADT puede ayudarlo a generar automáticamente un conjunto completo de clases necesarias para el modo proxy. Para obtener más información, puede consultar: guía/desarrollo/herramientas/aidl.html. Si está interesado, también puede encontrar información sobre otras implementaciones de PRC y echar un vistazo.
En cuanto a la implementación del servicio, también se recomienda encarecidamente que eche un vistazo a la implementación de RemoteService en la muestra de demostración de API. Muestra lo que se debe hacer para implementar completamente un Servicio: es decir, definir la Intención que debe aceptarse, proporcionar una interfaz sincrónica o asincrónica y, después de vincularla a la capa superior, comunicarse a través de estas interfaces (muchas veces RPC. ..). Si los datos y los objetos de la interfaz de devolución de llamada utilizados en la interfaz RPC no son implementaciones estándar del sistema (el sistema se puede serializar), entonces debe personalizar Aidl. Todo se expresa en este ejemplo y es muy recomendable.
Desde una perspectiva de implementación, lo más especial del Servicio es la implementación de estos RPC. Otro contenido estará cerca de algunas implementaciones de Actividad y es posible que no se detalle una por una.
Receptor de transmisión
En la práctica, a menudo necesitamos esperar a que el sistema u otras aplicaciones emitan instrucciones para iluminar una baliza y señalar la dirección de nuestras aplicaciones. Y en muchas plataformas, esta espera puede resultar costosa.
Por ejemplo, en Symbian, si estabas esperando que una llamada entrante mostrara a dónde pertenece, tendrías que dejar que tu aplicación entre y se inicie, oculte íconos y elementos de tareas, y permanezca en segundo plano. , monitorear eventos y esperar la oportunidad fugaz. Esto es algo muy problemático. No solo consumirá recursos del sistema en vano, sino que también dejará una reputación de software fraudulento. Es realmente un ejemplo positivo de traicionar al país y buscar la gloria.
En Android, hemos considerado una amplia gama de estas necesidades y hemos creado componentes como receptores de transmisión. Cada receptor de transmisión puede recibir uno o más tipos de Intents como eventos desencadenantes (para aquellos de ustedes que no conocen los Intents, lo descubrirán más adelante...). Cuando ocurra tal evento, el sistema será responsable de despertar o enviar información al receptor de transmisión para su procesamiento. Antes y después de esto, no importa si el receptor de transmisión está funcionando o no, y qué tan verde esté se vuelve irrelevante.
Este mecanismo de implementación obviamente se basa en un método de registro. Broadcast Receiver se caracterizará y registrará en el sistema según el momento del registro, y se puede dividir en dos categorías. y taponamiento en frío. La llamada inserción en frío consiste en escribir la información del receptor de transmisión en el archivo de configuración (¿el contenido específico del archivo de configuración? Te lo contaré más adelante...). Este patrón es adecuado para situaciones en las que el sistema será responsable de notificar a los receptores de transmisión cuando ocurran eventos relevantes. Ciertos modos de eventos -> transmisión de notificaciones -> iniciar aplicaciones de procesamiento relacionadas. Por ejemplo, monitorear llamadas entrantes, correos electrónicos, mensajes de texto, etc. pertenecen a este modo. La conexión en caliente, como sugiere el nombre, la conexión y desconexión es manejada por la propia aplicación. Generalmente se registra a través de RegisterReceiver en el evento OnResume y se cancela en OnPause y otros eventos. puede estar atento a los eventos relevantes en cualquier momento. Por ejemplo, es posible que un buen software de diccionario (como el Diccionario Youdao...) deba prestar atención a los cambios en el estado de la red durante el funcionamiento, de modo que la búsqueda de palabras en la red se pueda utilizar primero cuando la red sea barata y, en otros casos, la primera búsqueda. la palabra a través del diccionario de sinónimos local, para equilibrar el dinero de bolsillo y la experiencia de uso, y lograr el efecto de matar dos pájaros de un tiro. (Tenga en cuenta que el diccionario Youdao real tiene esta función, pero no se implementa a través de un receptor de transmisión, solo para dar un ejemplo...). A continuación se muestra un ejemplo de un receptor de transmisión.
Y para un oyente así, solo necesita mantenerlo en buenas condiciones de funcionamiento y no ejecutarlo cuando se esté ejecutando. Ya sea que Skynet cambie o no, no tiene nada que ver conmigo. Este patrón se reduce a: iniciar la aplicación -> escuchar eventos -> manejar eventos a medida que ocurren.
Además de los distintos modos disponibles para quien recibe el mensaje, el remitente también tiene una opción importante. Generalmente, hay dos tipos de remitentes, uno es el sistema en sí, al que llamamos mensajes de transmisión del sistema. Puede encontrar los detalles de los mensajes relacionados en la operación de transmisión estándar en referencia/android/content/Intent.html. Además del sistema, las aplicaciones personalizadas también pueden entregar mensajes de transmisión a través de la interfaz Context.sendBroadcast o Context.sendOrderedBroadcast. El primero se denomina transmisión normal. Todos los receptores que prestan atención al mensaje tienen la oportunidad de obtenerlo y procesarlo. Esta última se denomina emisión ordinaria, y todos los Receptores tienen la posibilidad de obtenerla y procesarla; Existe la posibilidad de obtener y procesar; esto último se llama transmisión ordenada. Como sugiere el nombre, los destinatarios deben clasificarse por antigüedad. Los que están detrás solo pueden comer las sobras del frente. Solo comen las sobras, y los que están detrás solo pueden beber el viento del noroeste.
Cuando un receptor de transmisión recibe un mensaje relevante, generalmente realiza un procesamiento simple y luego lo convierte en una notificación (Notificación), tono de llamada (Ringing), vibración (Vibration) o inicia una actividad (Activity ) para una mayor interacción y procesamiento. Por lo tanto, aunque toda la lógica de Broadcast no es complicada, es bastante práctica y excelente. Unifica el modelo de transmisión de eventos de Android y eclipsa a muchas plataformas. Para obtener más información sobre los receptores de transmisión, consulte /reference/android/content/BroadcastReceiver.html.
Proveedor de contenido
¡Parece que el proveedor de contenido está relacionado con datos! Sí, esta es la solución proporcionada por Android para acceder a datos de aplicaciones de terceros. En Android, la protección de datos es muy estricta, a excepción de los datos de la tarjeta SD, la base de datos, los archivos, etc. que posee una aplicación no permiten acceder directamente a otros contenidos. Pero a veces, la comunicación es necesaria, que no sólo es necesaria. Muy importante para terceros, pero también muy importante para la propia aplicación.
Por ejemplo, una aplicación de gestión de contactos. Si no permite que aplicaciones de terceros agreguen, eliminen y verifiquen su base de datos de contactos, toda la aplicación pierde escalabilidad y es probable que otras aplicaciones la abandonen, que luego se ejecutan por sí solas.
Andorid realmente no convierte cada aplicación en una isla, sino que prepara una ventana para todas las aplicaciones. Este es el proveedor de contenido. Las aplicaciones que quieran proporcionar datos al mundo exterior pueden derivar la clase ContentProvider para encapsularlas. En un proveedor de contenido, cada proveedor de contenido utiliza una uri para proporcionar datos al mundo exterior. Cada proveedor de contenido se identifica mediante una URI, como content://com.xxxxxx. Todo parece REST, pero en realidad es más flexible que REST. Similar a REST, uri puede ser de dos tipos, uno con id y otro con lista
Los implementadores no necesitan seguir este patrón, puedes devolver datos para uri con id. Las listas están bien siempre que el La persona que llama entiende esto, por lo que no hay necesidad de exigir REST.
Además, el proveedor de contenido no solo puede usar uri como REST, sino que también acepta parámetros como proyección, selección, ordenar por, etc., de modo que la proyección, selección y clasificación se puedan realizar como una base de datos.
Los resultados de la consulta se devolverán en forma de cursor (consulte: referencia/android/database/Cursor.html) y la persona que llama puede mover el cursor para acceder a los datos de cada columna.
El proveedor de contenido protege los detalles del almacenamiento de datos internos y proporciona el modelo de interfaz unificada mencionado anteriormente hacia el exterior. Este nivel de abstracción simplifica enormemente la escritura de aplicaciones de capa superior y también proporciona métodos de integración de datos más convenientes.
Dentro de Content Provider, se implementan bases de datos de uso común. Android proporciona un potente soporte para Sqlite, pero muchas veces también puede encapsular archivos u otros datos mixtos.
En Android, se utiliza un ContentResolver para iniciar la ubicación y el acceso de un proveedor de contenido. Sin embargo, sólo proporciona una interfaz para sincronizar los proveedores de contenido a los que accede. Pero, por lo general, lo que el proveedor de contenido necesita acceder puede ser una gran fuente de datos, como una base de datos, y la eficiencia no es lo suficientemente rápida, lo que provocará congestión en el hilo de llamada. Por lo tanto, Android proporciona AsyncQueryHandler (ver: referencia/android/content/AsyncQueryHandler.html) para ayudar a implementar el acceso asincrónico a los proveedores de contenido.
Entre los componentes principales, el servicio es un escenario de aplicación que requiere mucho tiempo y tiende a proporcionar acceso asincrónico, mientras que el proveedor de contenido proporciona acceso sincrónico acordado sin considerar la eficiencia. Creo que esto sigue el principio de diseño orientado a escenarios, porque el Proveedor de contenido solo proporciona acceso a datos y no puede determinar el escenario de uso específico y cómo se utilizarán sus datos. En contraste, la lógica contenida en el Servicio es más compleja y completa; Y puede elegir Escenarios donde se usa una determinada interfaz la mayor parte del tiempo para determinar si la interfaz más relevante es sincrónica o asincrónica. Esto simplifica la lógica de las llamadas de nivel superior.