Si haces desarrollo híbrido, ¿cuál deberías aprender, Uniapp o Flutter?

Este artículo fue compartido por Qi Qing del equipo técnico de Alibaba Xianyu. Esta vez ha habido modificaciones y cambios. Gracias al autor por su intercambio técnico. 1. Descripción general del contenido

Este artículo resume las prácticas técnicas del equipo técnico de Xianyu de Alibaba en el uso de Flutter para llevar a cabo la transformación cruzada móvil de Xianyu IM. El artículo compara el Flutter tradicional nativo y el actual. final Vale la pena aprender de las diferencias en algunas implementaciones técnicas importantes de las soluciones, así como de las características de implementación técnica específicas de la tecnología Flutter. Es digno de aprendizaje y referencia por parte de pares técnicos que también están preparados para usar Flutter para desarrollar mensajería instantánea.

Aprendizaje e intercambio: - Artículo sobre desarrollo de mensajería instantánea móvil: "Suficiente para principiantes: desarrolle mensajería instantánea móvil desde cero"

- Código fuente del marco de mensajería instantánea de código abierto: /JackJiang2011/MobileIMSDK

(Este artículo se publicó simultáneamente: /)thread-3615-1-1.html) 2. Estado actual de Xianyu IM

El marco móvil de Xianyu IM se construyó entre 2016 y 2017 Durante este período, muchas actualizaciones iterativas llevaron a la acumulación de equipaje histórico. Más tarde, la interfaz de mensajería instantánea experimentó Flutter, lo que hizo que la arquitectura del cliente se volviera cada vez más compleja.

Desde una perspectiva de desarrollo, la arquitectura actual. del terminal móvil Xianyu IM se resume de la siguiente manera: 1) Baja eficiencia de I + D: la arquitectura actual involucra código lógico de doble extremo de Android/iOS y código de UI de Flutter. El problema de posicionamiento solo puede encontrar la capa lógica nativa desde la etapa de la tabla de UI de Flutter. 2. Capa lógica local; 2) El nivel de arquitectura no está claro: la arquitectura Las capas en el diseño no están claras y la lógica empresarial se mezcla en la capa lógica central, lo que genera un alto riesgo de cambios de código; : La fuente de datos principal se almacena en la memoria local y debe serializarse a través del complemento Flutter y cargarse al final de Flutter. El rendimiento es deficiente cuando la cantidad de datos es grande.

Desde el nivel del producto. , resumimos los principales problemas existentes en la arquitectura actual del terminal móvil Xianyu IM de la siguiente manera: 1) Dificultad para localizar el problema: comentarios de la opinión pública en línea Los problemas son muy extraños y la prueba nunca puede reproducir los escenarios relevantes. y solo puedo adivinar la naturaleza del problema según el fenómeno 2) Dificultades: debido a la inestabilidad de la arquitectura, los problemas se repiten. Los problemas actuales incluyen: no leer, no leer Leer, no leer, no leer, no leer; , no leído, etc. Los problemas incluyen principalmente el conteo de puntos rojos no leídos, la máquina de gama baja iPhone5C y problemas de envío de multimedia; 3) Grandes diferencias entre Android e iOS Los códigos lógicos de los terminales son bastante diferentes, incluida la lógica oculta. Las causas fundamentales de los problemas en ambos lados son diferentes, y las soluciones también son diferentes 3. Soluciones móviles entre terminales en la industria

Para resolver los puntos débiles técnicos actuales de la mensajería instantánea, Xianyu lanzó el. Proyecto de actualización de la arquitectura de mensajería instantánea de este año, que se centra en resolver los puntos débiles de la coherencia de doble extremo entre el cliente Android e iOS. La visión inicial es lograr una arquitectura lógica unificada de Android/iOS en toda la industria. La consistencia entre extremos actual de la industria. Las soluciones se pueden dividir inicialmente en las siguientes categorías:

Las soluciones entre extremos a nivel de GUI incluyen Weex, ReactNative, H5, Uni-APP, etc. Requiere puente de almacenamiento en modo nativo.

Las soluciones cruzadas a nivel lógico incluyen C/C y otros lenguajes que no tienen nada que ver con el magnetismo de la máquina virtual. Por supuesto, el lenguaje ensamblador también es factible. /p>

Además, las dos arquitecturas que no tienen nada que ver con la arquitectura anterior son Flutter y KMM (la arquitectura similar a Flutter de Google basada en Kotlin), en la que Flutter ejecuta un DartVM específico que monta datos de memoria en su. propia zona de aislamiento.

Teniendo en cuenta que Idlefish es un explorador de fronteras de Flutter, este programa prioriza el uso de Flutter.

Sin embargo, en comparación con Android, el aislamiento de Flutter se parece más al concepto de un proceso (la implementación subyacente no utiliza un modelo de proceso, este último ejecuta varios subprocesos de Dalvik VM *** de Android en el mismo escenario de proceso, compartiendo una única memoria). Heap, mientras que la operación Isolate de DartVM aísla sus respectivos Heaps, por lo que la forma de comunicarse entre sí es más engorrosa (sujeta al proceso de serialización y deserialización).

El modelo completo se muestra en la siguiente figura:

Si implementa una aplicación Flutter de acuerdo con la arquitectura híbrida oficial, puede abrir múltiples FlutterAcitivty/FlutterController y luego puede generar múltiples motoresEsto equivale a la existencia de múltiples aislados, y la comunicación aislada es similar a la comunicación de procesos. La comunicación aislada es similar a la comunicación de proceso (similar a sockets o AIDL). Se basa en el concepto de diseño de Xianyu FlutterBoost. La arquitectura FlutterIM permite disfrutar de varias páginas de Engine, por lo que el modelo de memoria naturalmente lo admitirá.

El diagrama esquemático es el siguiente: 4. Diseño de arquitectura basado en Flutter de Xianyu IM

4.1 Comparación de arquitecturas antiguas y nuevas

Como se muestra en la figura A continuación: Esta es una solución de arquitectura antigua. El problema central se concentra principalmente en la mala abstracción de la lógica nativa. La capa lógica también está diseñada con concurrencia de subprocesos múltiples, lo que duplica el problema de la interacción de Android/iOS/Flutter. y los costos de mantenimiento son altos, el acoplamiento de la capa central es serio y no existe el concepto de plug-and-play.

Combinado con cuestiones arquitectónicas históricas, ha evolucionado el siguiente nuevo diseño arquitectónico:

Como se muestra en la figura anterior, la arquitectura de arriba a abajo es: 1) capa empresarial 2) Capa de distribución; 3) capa lógica; 4) capa de fuente de datos.

La capa de origen de datos proviene de solicitudes push o de red. Estas solicitudes se encapsulan en la capa nativa. Los datos del protocolo de mensajes se cargan en la capa lógica central en el lado de Flutter a través del complemento Flutter. Una vez completado el procesamiento, se convierte en la entidad Entidad de Flutter DB. La entidad monta algunas entidades de protocolo de mensajes.

La capa lógica central aplana y empaqueta datos complejos y los monta en los datos del modelo de memoria de sesión o en los datos del modelo de memoria de mensajes en la capa de distribución y, finalmente, los distribuye a la empresa a través de la lógica de suscripción en modo observador.

El objetivo de Flutter IM es transformar la capa lógica y la capa de distribución para aislar la lógica central y el modelo de datos a nivel empresarial de IM para lograr la encapsulación. La capa lógica central interactúa con la base de datos y encapsula los datos en moduleData de la capa de distribución, que luego se distribuye al modelo de datos de la capa empresarial a través de suscripciones.

Además, DB también es una dependencia clave en el modelo de mensajería instantánea. El autor ha desarrollado una solución de encapsulación integral para la administración de bases de datos DB para lograr un marco de administración Flutter DB liviano y de alto rendimiento.

Modelo de almacenamiento de base de datos 4.2

El almacenamiento de base de datos de la arquitectura Flutter IM se basa en complementos de bases de datos, y el complemento principal es Sqflite.

El modelo de almacenamiento es el siguiente:

El modelo de almacenamiento de base de datos basado en el complemento Sqflite tiene dos colas de espera. Hay dos colas de espera: una es la cola de ejecución síncrona de la capa Flutter y la otra es la cola de ejecución de subprocesos de la capa local;

El mecanismo de implementación de Android es HandlerThread, por lo que la lectura/escritura de Consulta/Guardado se realiza en la misma cola de subprocesos, lo que resulta en un tiempo de respuesta lento y una fácil acumulación de DB SQL. Además, hay una falta de. modelo de almacenamiento en caché.

Así que personalicé el siguiente plan de mejora:

El lado de Flutter está diseñado para obtener primero la consulta de clave principal de la tabla desde la capa Entity Cache. la consulta se realiza a través del complemento Sqflite.

Al mismo tiempo, el complemento Sqflite se transformará para admitir operaciones sincrónicas y asincrónicas. El lado nativo correspondiente también tendrá una cola de subprocesos sincrónica y una cola de subprocesos asincrónica para garantizar el rendimiento de los datos. Sin embargo, se recomienda utilizar consultas asincrónicas para que sean más seguras, principalmente porque existe el temor de que varios modelos de elementos de datos idénticos ingresen al grupo de subprocesos asincrónicos al mismo tiempo y no se pueda garantizar de manera efectiva el orden de almacenamiento.

4.3 Programa de base de datos ORM

La arquitectura IM depende en gran medida de la base de datos DB y la industria no tiene un programa de administración ORM de base de datos completo. Consulte OrmLite/GreenDao de Android, el autor que diseñé. Yo mismo soy un programa de gestión de bases de datos Flutter ORM.

La idea central es la siguiente:

Dado que Flutter no admite la reflexión, no se puede operar directamente como la base de datos de código abierto de Android. En cambio, Entity y Orm Entity están vinculados a través de APT. Un cuerpo que opera OrmEntity es una Entidad operativa, y todo el diseño del estilo del código es muy similar a OrmLite.

El código de referencia es el siguiente:

4.4 Modelo de datos de memoria de mensajería instantánea

La arquitectura móvil de mensajería instantánea basada en Flutter se divide en dos granularidades: sesión y mensaje en el modelo de datos de memoria: 1) El modelo de datos de memoria de sesión se delega a SessionModuleData: los datos de memoria de sesión tienen un nodo raíz RootNotice y luego monta la colección de nodos secundarios de PSessionMessageNotice (donde PSessionMessageNotice es el modelo de tabla de base de datos de sesión mapeado por el ORM) . 2) El modelo de datos de la memoria de mensajes se delega a MessageModuleData: los datos de la memoria de mensajes serán administrados por el contenedor MessageConatiner, que monta internamente la colección de mensajes PMessage (PMessage es el modelo de tabla de base de datos de mensajes mapeado ORM) de la sesión.

Basado en el contenido de la sección anterior, PSessionMessageNotice diseñó un caché OrmEnitity. Teniendo en cuenta el número limitado de sesiones en mensajería instantánea, PSessionMessageNotice se almacenará en caché directamente en el caché.

La ventaja de este enfoque es que los objetos en el caché son los mismos dondequiera que obtenga datos de la sesión, lo que facilita garantizar la coherencia de los datos en múltiples lecturas y escrituras. Dado que la cantidad de PSessionMessageNotice puede ser infinitamente especial, la memoria cargada en MessageContainer se administrará aquí. Al salir de la sesión, se verificará la cantidad de contenedores en la colección PMessage. La reducción adecuada puede reducir la sobrecarga de memoria.

El modelo se muestra en la siguiente figura:

4.5 Solución de gestión de estado

La solución de gestión de estado de la arquitectura móvil de mensajería instantánea basada en Flutter es relativamente simple. Se basa en la fuente de datos. La dimensión Sesión/Mensaje se implementa mediante la distribución de suscripción del modo observador. La arquitectura es similar a la gestión del estado a nivel de página, ya sea que utilice fish-redux, ScopeModel o proveedor. Casi nunca tiene un gran impacto en la superficie. El núcleo aún es necesario para conservar la abstracción plug-and-play.

La arquitectura es la siguiente:

4.6 Escenario del modelo de sincronización de mensajería instantánea

El modelo de sincronización de mensajes más avanzado actual:

Como se muestra arriba Existen modelos de concurrencia de subprocesos múltiples, como subproceso ACCS/subproceso principal/subproceso de región. Los subprocesos regionales y otros escenarios de concurrencia de subprocesos múltiples conducen fácilmente a problemas de alta concurrencia de subprocesos múltiples.

La solución nativa de aislamiento de sincronización de solicitudes de red y push utiliza el mecanismo de bloqueo Lock y se procesa mediante reducción de colas y otros métodos. El proceso es engorroso y propenso a errores. En términos generales, Region Version Gap se utiliza para determinar si existen vulnerabilidades de dominio y luego se realiza la sincronización del dominio para complementar los datos.

El modelo de sincronización mejorado es el siguiente:

Como se muestra en la figura anterior, en el escenario natural de subprocesos múltiples en el lado de Flutter, el bit de marca se implementa a través de un proceso sincrónico y Método asincrónico similar a la cola de mensajes del controlador. La conversión hace que la arquitectura sea mucho más clara y simple, evitando la sobrecarga de sincronización causada por el bloqueo. 5. Progreso de la transformación y comparación de rendimiento

1) Para el nivel arquitectónico:

En la arquitectura de mensajería instantánea basada en Flutter, la atención se centra en unificar las diferencias lógicas en ambos extremos en el mismo Código Dart, borrando completamente Se corrigieron diferencias en el código de Android/iOS.

Los beneficios son obvios: 1) Reducir a la mitad el costo de desarrollo y mantenimiento, la regresión de pruebas y la aceptación visual, lo que mejora en gran medida la eficiencia de I+D 2) Reconstruir y superponer la arquitectura para lograr una arquitectura desacoplada y enchufable; -play La arquitectura de mensajería instantánea utilizada; 3) Al mismo tiempo, Native lanza un programa de transformación de procesamiento de serialización para transferencia de referencia de Flutter para datos masivos en el lado de Flutter para resolver el problema del retraso del chat privado en escenarios de prueba extremos.

2) Para la opinión pública en línea: 1) Los métodos de registro grupal UT y TLog se han complementado para hacerlos rastreables y rastreables 2) Centrarse en resolver muchas dificultades existentes, como la arquitectura del iphone5C; el lado de Flutter; 3) Problemas como el conteo de puntos rojos no leídos también se están actualizando en el modelo de arquitectura. Además, el módulo de envío de audio y video multimedia también se ha modificado y actualizado.

3) Comparación de datos de rendimiento:

Cuando la capa lógica y la capa UI de la arquitectura IM se cambian a Flutter, la comparación preliminar con el modelo de arquitectura original muestra que el nivel general de memoria es lo mismo.

Entre ellos: 1) La arquitectura de prueba Xiaomi 9 tiene una reducción de memoria de 40 M, una reducción del consumo de energía de 4 mah y una reducción de CPU de 1 en el escenario de chat privado 2) En el escenario de prueba extremo; , los datos de memoria de la nueva arquitectura son mejores que los de la arquitectura anterior. Mejora significativa (principalmente debido al escenario en el que ambas interfaces usan Flutter, cambio de página 6. Future Outlook

JS no es seguro entre terminales. Y el costo entre terminales de C es un poco alto, Flutter será una mejor opción. El propósito fundamental de la actualización de la arquitectura FlutterIM de Xianyu no es actualizar Flutter, sino debido a la pesada carga histórica, los altos costos de mantenimiento a nivel de código, pobre La escalabilidad de los nuevos servicios, la proporción de mano de obra descoordinada y la retroalimentación constante de la opinión pública sobre temas difíciles nos han obligado a explorar nuevas opciones.

Después de que el escenario comercial ultracomplejo de Xianyu IM haya verificado el cruce lógico. viabilidad del modelo Flutter, Xianyu siempre mantendrá la exploración de vanguardia en el camino de Flutter y, en última instancia, retroalimentará el ecosistema.

En resumen, el proceso de exploración radica en su coraje para dar el primer paso. , y luego seguirás haciendo descubrimientos sorprendentes.

(Enlace original: Haga clic aquí para ingresar, esta vez hay modificaciones y cambios)

Apéndice: Resumen de más artículos [1] Más artículos compartidos por el equipo de Alibaba:

"Compartir tecnología Alibaba DingTalk: el rey de la mensajería instantánea empresarial: arquitectura backend de DingTalk"

"Sincronización y almacenamiento de información de chat en sistemas de mensajería instantánea modernos"

"Alibaba DingTalk DingTalk Technology Sharing: Soluciones tecnológicas de bases de datos DingTalk de Alibaba durante 10 años"

"Alibaba DingTalk Technology Sharing: el arduo camino de Alibaba hacia el crecimiento en su base de datos financiera de desarrollo propio OceanBase"

"OpenIM: Una nueva forma de crear bases de datos de código abierto seguras, confiables y escalables para empresas. OpenIM: Intercambio de prácticas técnicas para crear servicios de mensajería instantánea seguros y confiables"

"DingTalk - Desafíos técnicos de una nueva generación de plataformas OA empresariales basadas en tecnología de mensajería instantánea (Video PPT) [Descarga de archivo adjunto]"

"La cristalización de la tecnología Ali: Manual de desarrollo de Java de Alibaba (procedimientos) - Edición Huashan" [Descarga del archivo adjunto]"

"La cristalización de la tecnología Ali: "Manual de desarrollo de Java de Alibaba (procedimientos) ) Edición Huashan [Descarga del archivo adjunto] 》

《Última versión: "Manual de desarrollo de Java de Alibaba (protocolo)" [Descarga del archivo adjunto]"

"El autor habla sobre "Desarrollo de Java de Alibaba Manual (Protocolo)" La historia detrás"

La historia detrás del "Manual de desarrollo de Android (Protocolo) de Alibaba"

La historia detrás del "Manual de desarrollo de Android (Protocolo) de Alibaba"

La historia detrás del "Manual de desarrollo de Android de Alibaba (Protocolo)"