Evolución de la arquitectura de la aplicación móvil Ele.me
En los primeros días del desarrollo comercial de Ele.me, la aplicación móvil pasó por una etapa desde cero. Para conectarse rápidamente y apoderarse del mercado, la arquitectura MVC del desarrollo de aplicaciones móviles tradicionales se ha convertido en la primera opción para ideas "breves, planas y rápidas":
Arquitectura MVC
Esta arquitectura es popular porque es simple, clara y fácil de desarrollar. Aceptada por la mayoría de la gente.
En la arquitectura MVC, la capa Controlador es responsable de la implementación de las principales funciones lógicas en toda la APLICACIÓN; la capa Modelo es responsable de la descripción de la estructura de datos y la función de persistencia de datos; la capa Ver, como capa de presentación, es responsable de representar toda la interfaz de usuario de la APLICACIÓN. La división del trabajo es clara y concisa. Además, Apple admite esta arquitectura del sistema en la capa del marco del lenguaje, por lo que es muy adecuada para el desarrollo de inicio de aplicaciones.
Sin embargo, en las últimas etapas de desarrollo, esta arquitectura hará que la capa del Controlador sea enorme debido a su acoplamiento ultra alto, que siempre ha sido criticado por la gente. El MVC final ha pasado de Model-View-Controller a Massive-View-Controller.
2
Módulo
Desacoplado
La arquitectura MVC "corta, plana y rápida" puede cumplir con la rápida iteración de desarrollo de Ele. me aplicación móvil en la etapa inicial, pero a medida que la cantidad de código continúa aumentando, la capa de controlador inflada está emergiendo gradualmente y, en términos de negocios, la aplicación móvil Ele.me también se ha desarrollado desde una sola aplicación hasta un patrón de múltiples aplicaciones; yendo de la mano. En este momento, reducir el acoplamiento y reutilizar los módulos existentes se ha convertido en la máxima prioridad de la arquitectura.
En la arquitectura, el primer requisito para la reutilización de módulos es la componenteización funcional del código. La componenteización significa que el código con funciones independientes se abstrae y se elimina del sistema, y luego se vuelve a insertar en el sistema original en forma de "complementos". Los componentes funcionales eliminados de esta manera pueden ser utilizados por otras aplicaciones, lo que reduce el acoplamiento entre módulos en el sistema y también mejora la reutilización del código entre aplicaciones.
Ele.me Mobile tiene dos definiciones de componentes: componentes públicos y componentes comerciales. Los componentes públicos se refieren a algunos SDK bien encapsulados, incluidos algunos componentes de terceros y componentes utilizados internamente. Por ejemplo, los representantes de este tipo de componentes son el SDK de red más famoso, AFNetworking en iOS y OKHttp en Android. Los componentes comerciales se definen como un todo que incluye una serie de funciones comerciales, como componentes comerciales de inicio de sesión y componentes comerciales de registro, que son representantes típicos de dichos componentes.
Para los componentes públicos, Ele.me Mobile adopta un método de gestión versionado, y esta ya ha sido una solución relativamente madura en las plataformas iOS y Android. Por ejemplo, para la plataforma iOS, CocoaPods se ha convertido básicamente en el estándar para la gestión de componentes de código, y Gradle también es una solución muy madura y robusta; Otra razón para utilizar las herramientas de gestión anteriores es que, para el desarrollo empresarial, el código también es un secreto comercial. A efectos de confidencialidad, se ha hecho necesario apoyar el establecimiento de servidores privados en la intranet. Las herramientas de gestión anteriores pueden respaldar bien estas operaciones.
Para la componenteización del negocio, adoptamos un mecanismo de registro de módulo comercial para lograr el propósito de desacoplamiento. Cada módulo comercial proporciona las interfaces comerciales correspondientes con el mundo exterior y, al mismo tiempo, registra el esquema de su propio módulo en el sistema Excalibur cuando se inicia el sistema (Excalibur es un sistema utilizado por Ele.me Mobile para guardar el mapeo entre el esquema y módulos, y también puede realizar clases basadas en el retorno de reflexión del esquema). Cuando otros módulos comerciales dependen de este módulo comercial, las instancias relevantes se obtienen del sistema Excalibur y se llaman las interfaces correspondientes para implementar la llamada, logrando así el propósito de desacoplar entre módulos comerciales.
Dentro del componente empresarial, es decir, el módulo empresarial, se pueden implementar diferentes arquitecturas de código según las preferencias de los distintos desarrolladores. Por ejemplo, los MVVM, MVP, etc. que se analizan actualmente se pueden realizar dentro del módulo sin afectar la arquitectura general del sistema.
La arquitectura en este momento se parece más a esto:
Arquitectura EMC
Arquitectura E (Excalibur) M (Módulos) C (Común) con alto El principal Las características son convergencia y bajo acoplamiento, y el punto de partida es la programación orientada a interfaz, que reduce la conexión entre módulos.
Otro beneficio importante de esta arquitectura es que resuelve el problema de compatibilidad de diferentes versiones del sistema. Aquí tomamos WebView en la plataforma iOS como ejemplo para ilustrar. Apple ha proporcionado un mejor marco de soporte web: WebKit a partir del sistema iOS8, pero no es compatible con el sistema iOS7, lo que provoca un bloqueo. Con este tipo de arquitectura, aún puede registrar y usar WebView tradicional para representar páginas web en sistemas iOS7 y registrar WebKit como kernel para representar páginas web en sistemas iOS8 y superiores. No solo evita el estricto mecanismo de revisión de Apple, sino que también logra el propósito de la carga dinámica.
3Hybrid
Existen dos rutas diferentes para el desarrollo de aplicaciones móviles, NativeAPP y Web APP. La diferencia entre estas dos rutas es similar a la arquitectura C/S y la arquitectura B/S al desarrollar aplicaciones en la era de las PC.
De lo que hablamos anteriormente son todas las aplicaciones nativas típicas, es decir, todos los programas se procesan mediante componentes locales. Las ventajas de este tipo de aplicación son obvias, como una velocidad de renderizado rápida y una buena experiencia de usuario, y las desventajas también son muy destacadas: si ocurre un error, debe esperar a que el siguiente usuario actualice la aplicación antes de poder repararla;
Las ventajas de la aplicación web resultan ser las desventajas de la aplicación nativa. Todas sus páginas están escritas en H5 y almacenadas en el lado del servidor. La última página se solicita al servidor cada vez que se representa la página. Una vez que hay un error en la página, se puede solucionar inmediatamente actualizando el lado del servidor. Sin embargo, sus desventajas también son fáciles de ver: cada vez que la página necesita solicitar el servidor, el tiempo de espera durante el procesamiento es demasiado largo, lo que resulta en una experiencia de usuario imperfecta, y el rendimiento es 1-2 órdenes de magnitud más lento que el nativo. APP; al mismo tiempo, resultará en un mayor consumo de tráfico de usuarios. Otra desventaja es que resulta inconveniente para la aplicación web llamar a dispositivos de hardware locales en el terminal móvil. Sin embargo, existen soluciones correspondientes a estas deficiencias. Por ejemplo, PhoneGap empaqueta las páginas web localmente con anticipación para reducir el tiempo de solicitud de la red y también proporciona una serie de complementos para acceder a los dispositivos de hardware locales. Sin embargo, a pesar de esto, todavía existe una cierta brecha en la velocidad de renderizado.
La APP híbrida es una solución que combina las ventajas y desventajas de ambas. La opinión de Ele.me Mobile sobre estos dos tipos de aplicaciones es que los módulos puramente de visualización son más adecuados para usar páginas web para lograr propósitos de representación, mientras que los módulos con más capacidades de manipulación de datos y representación de animaciones son más adecuados para usar el método nativo.