Práctica de Kotlin Flow en el marco MVVM

Después de que el equipo de Google Android anunciara el modelo de vista de Jetpack, la arquitectura MVVM se ha convertido en una de las arquitecturas más populares para el desarrollo de Android. Como se muestra en la siguiente figura:

Sin embargo, en los primeros documentos oficiales de Google, su capa de Repositorio usa directamente LiveData, e incluso Jetpack Room también admite LiveData, y la interfaz puede devolver directamente datos de LiveData. Por lo tanto, durante mucho tiempo, varios blogs o marcos MVVM de código abierto también utilizaron LiveData directamente en la capa del Repositorio.

Aquí tendremos preguntas: ¿Por qué la capa Repositorio usa LiveData? (Porque según la documentación oficial, LiveData debería estar relacionado con componentes de la interfaz de usuario como Acvtivity y Fragment, y debe depender del Lifecycle. Es muy extraño colocarlo en la capa del Repositorio).

Entonces, ¿cuál es el enfoque correcto? A continuación se demostrará el marco MVVM basado en la práctica de LiveData, sus desventajas existentes y el marco MVVM basado en la práctica de Flow, y luego se presentará Flow para resolver los problemas de LiveData.

Primero, refine este diagrama de marco MVVM para observar los tipos de datos y las direcciones del flujo de datos entre cada nivel:

Luego, refinelo aún más y observe los detalles del diseño:

El siguiente es un ejemplo de solicitud de datos de red:

Capa UI:

Capa ViewModel:

Capa de repositorio:

La API LiveData es demasiado simple para manejar los muchos escenarios complejos de procesamiento de datos que pueden ocurrir en la capa del Repositorio. Se refleja principalmente en los siguientes tres aspectos:

En escenarios comerciales complejos, los datos a menudo se procesan varias veces mediante el cambio de subprocesos, similar a observeOn de RxJava y flowOn de Flow, pero LiveData no tiene esta capacidad. Por lo tanto, el cambio de subprocesos solo se puede realizar a través de corrutinas, y en la capa del Repositorio, solo puede personalizar repositoryScope y manejar la lógica de cancelación de corrutinas. Es decir:

LiveData es responsable de proporcionar capacidades de suscripción de datos para la interfaz de usuario, por lo que su suscripción de datos solo se puede realizar en el hilo principal. Aunque los datos se pueden publicar a través de postValue en hilos secundarios, también se puede llamar a postValue. rápido a corto plazo Dado que no hay procesamiento de contrapresión y solo se retienen los datos más recientes, puede ocurrir una pérdida de datos inesperada.

Flow tiene una estrategia completa de contrapresión que puede manejar varios escenarios de datos complejos que pueden ocurrir en la capa del Repositorio.

LiveData se basa en Lifecycle, tiene conocimiento del ciclo de vida y sigue el ciclo de vida de entidades como actividades y fragmentos. Para usarlo en escenarios que no son de interfaz de usuario, debe personalizar Lifecycle o usar LiveData#observerForever. (que causará riesgo de fuga). En el caso anterior, ViewModel necesita monitorear LiveData de la capa Repository, por lo que debe manejarse de manera especial para evitar pérdidas de memoria.

Por ejemplo:

El uso de Flow para reemplazar el uso de LiveData en la capa Repositorio implica principalmente modificaciones en las clases básicas de la capa ViewModel y la capa Repositorio, y la lógica modificada es más concisa y más fácil de leer. Además, la documentación oficial también se ha actualizado, con algunas restricciones en los escenarios de uso de LiveData, consulte: desarrollador.android.com/topic/libra…:

Dado que el diseño de la API es consistente, el método de uso no ha cambiado desde antes, por lo que se puede cambiar sin problemas. El único punto de cambio es que el tipo de datos devueltos de la capa del Repositorio cambia de LiveData a Flow:

En resumen, puede usar Flow para obtener datos en la capa del Repositorio, y Retrofit y Room tienen los suyos propios. Soporte de extensión de flujo. Conexión básicamente perfecta; la capa ViewModel recopila el flujo de la capa del Repositorio, realiza la conversión de datos, transfiere el modelo a VO y luego usa LiveData para actualizar la interfaz de usuario.