De acuerdo con las capas de MVC, la Actividad y el Fragmento (en lo sucesivo, Actividad) deben pertenecer a la capa Vista, utilizada para mostrar la interfaz de IU y recibir información del usuario, además de soportar parte del trabajo del ciclo de vida. La actividad juega un papel muy importante en el desarrollo de Android, especialmente la función de ciclo de vida de TA, por lo que cuando desarrollamos, a menudo escribimos alguna lógica comercial directamente en Activity. Esto es muy intuitivo y conveniente. El precio es que Activity se volverá cada vez más hinchado ., Es común tener más de 1000 líneas de código, y si se trata de alguna lógica comercial general (como el inicio de sesión del usuario), escribir en una Actividad específica significa que esta lógica no se puede reutilizar. Si tiene experiencia en la refactorización de código, definitivamente tendrá preocupaciones cuando vea más de 1000 líneas de clases. Por lo tanto, Activity no solo asume el rol de View, sino que también asume parte del rol de Controller, por lo que V y C están acoplados. Aunque esto es conveniente de escribir, es difícil de mantener si se ajusta el negocio. class para encontrar el código de lógica de negocios también será muy doloroso, por lo que parece necesario extraer la Vista y el Controlador de la Actividad, y este es el trabajo del modo MVP.
1. La idea central de mvp
MVP abstrae la lógica de la IU en la Actividad en la interfaz de Vista y abstrae la lógica de negocio en la interfaz del Presentador. La clase Modelo sigue siendo el Modelo original. Este es el modo MVP En este caso, la actividad de la Actividad es simple, solo se usa para responder al ciclo de vida, y otras tareas se lanzan al Presentador para completar. Como se puede ver en la figura anterior, Presenter es un puente entre Model y View. Para simplificar la estructura, View no puede operar directamente en Model. Esta es también la mayor diferencia entre MVP y MVC.
2. Una breve descripción de mvp
El trabajo realizado en esta capa del modelo de MVP es la realización de un procesamiento lógico de negocios específico, que se acompaña del procesamiento de varios datos en el programa, y los más complicados obviamente necesitan implementar una interfaz para desacoplar.
La
capa Ver de MVP es muy delgada y liviana, que se encarga de mostrar datos y proporcionar una interfaz amigable para interactuar con los usuarios. La actividad y el fragmento en MVP se reflejan en esta capa. La actividad generalmente realiza un trabajo de carga de las vistas de la interfaz de usuario, configura el monitoreo y luego se entrega al presentador para que lo maneje, por lo que también debe contener una referencia al presentador correspondiente. Por ejemplo, la Acionbar (barra de herramientas) está oculta o se muestra cuando la lista se desplaza en la Actividad. Dicha lógica de la interfaz de usuario también debe estar en esta capa. Además, al hacer algunos juicios sobre los datos ingresados en la Vista, por ejemplo, los datos de entrada de EditText, si se trata de un juicio simple no vacío, se pueden utilizar como la lógica de la capa de Vista, y cuando es más complejo Se requiere una comparación de los datos de EditText, como cuando la base de datos obtiene datos locales para su juicio, obviamente debe pasar por la capa de modelo para regresar, por lo que estos detalles deben ser sopesados por usted mismo.
La
capa Presenter Presenter de MVP maneja la distribución de varias lógicas del programa. Después de recibir comandos de retroalimentación, comandos de tiempo, comandos del sistema y otras instrucciones en la interfaz de usuario de la capa Ver, la lógica de procesamiento de distribución se transfiere a la capa Modelo para operaciones comerciales específicas .
3. El papel de mvp
Estudio preliminar sobre MVC, MVP, MVVM (1) -Existen explicaciones específicas sobre los conceptos básicos , aquí hay un punto importante.
Extraiga la lógica empresarial en el presentador para evitar subprocesos en segundo plano que hagan referencia a la actividad, lo que hace que los recursos de la actividad no sean reciclados por el sistema, provocando pérdidas de memoria y OOM.
La principal razón de la aplicación OOM de Android es la pérdida de memoria que hace que la memoria de la aplicación sea insuficiente. Una de las dos causas principales de pérdida de memoria es la pérdida de actividad (la otra razón es la pérdida de mapa de bits).
Una función poderosa de Java es el mecanismo de reciclaje de memoria de su máquina virtual, esta función permite a los usuarios de Java diseñar su código sin tener que considerar el reciclaje de objetos como los usuarios de C ++. Sin embargo, a los usuarios de Java siempre les gusta escribir muchos objetos de forma casual y luego imaginar que la máquina virtual puede ayudarlos a manejar el trabajo de recuperación de memoria. Sin embargo, cuando la máquina virtual recupera memoria, solo recupera aquellos objetos a los que no se hace referencia y los objetos referenciados no se pueden reclamar porque aún se pueden llamar.
La actividad tiene un ciclo de vida. El usuario puede cambiar de Actividad en cualquier momento. Cuando la memoria de la APP no es suficiente, el sistema recuperará los recursos de la Actividad en segundo plano para evitar OOM.
Con el modo MV tradicional, muchas tareas y operaciones asincrónicas en la interfaz de usuario se colocan en la actividad. Por ejemplo, puede descargar una imagen de la red y cargar la imagen en ImageView de la actividad en la devolución de llamada de una descarga exitosa, Tareas asincrónicas Mantenga una referencia a la Actividad. De esta manera, incluso si la actividad se ha cambiado a un segundo plano (se ha ejecutado onDestroy), estas tareas asincrónicas aún conservan una referencia a la instancia de actividad, por lo que el sistema no puede reclamar esta instancia de actividad y el resultado es una pérdida de actividad. En los componentes de Android, los objetos de actividad tienden a ocupar la mayor cantidad de memoria en el montón (Java Heap), por lo que el sistema dará prioridad a la recuperación de los objetos de actividad. Si hay una pérdida de actividad, es fácil para la aplicación a OOM debido a la memoria insuficiente.
Usando el modo MVP, siempre que la referencia de la tarea asincrónica a la Actividad esté separada en el onDestroy de la Actividad actual, se puede evitar la pérdida de actividad.
4. Ejemplos de código mvp
4.1 Estructura jerárquica
4.2 Ejemplo de código
Para lograr la capa de vista, se debe implementar la interfaz de devolución de llamada y el controlador (mLoginHelper) correspondiente a la capa P
Implementación de la capa P, interfaces personalizadas relacionadas con la lógica empresarial e implementación de la lógica empresarial específica del ayudante
Implementación de la capa modelo, definiendo beans
Llamando a la capa de vista y asuntos que requieren atención
5. Resumen
Lo más problemático de mvp es que necesita definir varias interfaces de vista y presentadores correspondientes. Pero esto también tiene la ventaja de que el código se ve más claro, al menos la actividad es básicamente la implementación de la interfaz de usuario relacionada, y el procesamiento de la lógica empresarial se coloca en el presentador. Se reduce el grado de acoplamiento. ¡Es realmente conveniente mejorar más tarde!
Este es solo un proyecto que practiqué y todavía lo estoy mejorando.Las llamadas relacionadas con la capa de red pueden requerir la implementación de un método adicional para la llamada del presentador. También hay un modelo que no utilicé, se procesa directamente mediante sharepreference, y continuaré mejorándolo y optimizándolo a continuación.