Sobre el Autor

Frank, I + D front-end de Ctrip, se centra en la optimización del rendimiento front-end, un código para múltiples terminales, construcción de ingeniería y otros campos.

1. Antecedentes comerciales

Con la popularidad de Internet móvil y los dispositivos inteligentes, los desarrolladores front-end necesitan utilizar tecnología isomórfica multiterminal para adaptarse a diferentes terminales (miniprogramas, aplicaciones y web). Existen diferencias obvias entre estos terminales, incluidos los motores de navegador, los sistemas operativos, los métodos de interacción y los lenguajes de codificación.

Estas diferencias plantean muchos desafíos a los desarrolladores de aplicaciones para el usuario. Por un lado, diferentes terminales utilizan diferentes motores de navegador y sistemas operativos, lo que da como resultado diferentes comportamientos interactivos y de visualización de páginas. Por otro lado, los lenguajes de codificación y las herramientas de desarrollo utilizados por diferentes terminales también son diferentes, lo que requiere que los desarrolladores tengan diferentes antecedentes técnicos y conocimientos para poder escribir múltiples códigos para adaptarse a diferentes terminales. Hacerlo no solo aumenta la carga de trabajo de desarrollo del personal de I+D y la dificultad de mantenimiento del código, sino que también puede hacer que los usuarios encuentren experiencias de usuario inconsistentes en diferentes dispositivos, lo que afecta la calidad del producto y la satisfacción del usuario.

Para resolver estos problemas, surgió la tecnología isomórfica multiterminal según lo requieren los tiempos. A través de tecnología isomorfa de múltiples terminales, los equipos públicos y de front-end de turismo cooperan en la exploración y práctica de múltiples terminales, y se adaptan y personalizan de manera flexible de acuerdo con las características de las diferentes terminales. Esto puede reducir los costos de desarrollo y la dificultad de mantenimiento, y mejorar la eficiencia del desarrollo y la reutilización del código. Al mismo tiempo, la tecnología isomórfica multiterminal también puede proporcionar una experiencia de usuario consistente: no importa qué dispositivo utilicen los usuarios para acceder a la aplicación, pueden obtener interfaces y funciones similares.

Estado de la industria

isomorfismo tripartito

2. Selección de tecnología isomórfica multiterminal.

Al seleccionar tecnologías isomórficas multiterminales, debemos considerar de manera integral las capacidades, el costo, el rendimiento, la versatilidad del lenguaje de código y el soporte de las tecnologías existentes entre terminales. Esto nos ayudará a elegir la solución técnica más adecuada. El siguiente es un análisis de las principales tecnologías cross-end actuales en el front-end:

	Híbrido	Reaccionar nativo	Aleteo	weex	tarot
Capacidades cruzadas	★★★★	★★	★★★	★★★	★★★★
costo	★★★★	★★	★★	★★	★★★
actuación	★	★★★	★★★★	★★★	★★★
Versatilidad del lenguaje de código	★★★★	★★★★	★★	★★★	★★★★
soporte ctrip	★★★	★★★★	★★★★	★	★★★★

Híbrido : utiliza el lenguaje JavaScript y admite la construcción rápida de aplicaciones multiterminal. Debido a que depende del contenedor Webview para ejecutarse, su experiencia de usuario y su rendimiento están sujetos a ciertas limitaciones. Esta limitación puede causar problemas como tiempos de respuesta de aplicaciones más lentos y tiempos de carga de páginas más prolongados. Es adecuado para escenarios donde los requisitos comerciales de tres extremos son relativamente altos, los costos de I + D son relativamente bajos y los requisitos de rendimiento no son altos, como las páginas de publicidad de marketing.

React Native : los componentes de React desarrollados utilizando lenguaje JavaScript, admiten la creación de aplicaciones y web, pero no admiten subprogramas nativos. La aplicación tiene un rendimiento y una experiencia de usuario cercanos a las aplicaciones nativas. Es adecuado para escenarios donde los requisitos de rendimiento de programas pequeños no son altos.

Flutter : utiliza el lenguaje Dart y su propio motor de renderizado, y el rango de soporte es el mismo que el de ReactNative. Funciona mejor que ReactNative en términos de velocidad de renderizado y experiencia de usuario. Debido a las restricciones de las reglas de la plataforma iOS, actualmente no es compatible con la compatibilidad con actualizaciones en caliente. Es adecuado para escenarios que tienen requisitos de alto rendimiento para aplicaciones y requisitos de bajo rendimiento para miniprogramas.

Weex : Un componente de Vue desarrollado usando lenguaje JavaScript. El rango de soporte y el rendimiento son los mismos que ReactNative, pero la actividad de la comunidad no es tan buena como ReactNative.

Taro : una solución abierta entre entornos y marcos que proporciona un conjunto unificado de sintaxis de desarrollo y especificaciones de componentes, lo que permite a los desarrolladores utilizar un conjunto de códigos para desarrollar aplicaciones nativas que se adaptan a diferentes plataformas. Es adecuado para escenarios con altos requisitos en tres terminales y alto rendimiento. Dado que el diseño fue diseñado originalmente para programas pequeños, las especificaciones no son amigables para ReactNative R&D.

Teniendo en cuenta que nuestro negocio tiene altos requisitos de rendimiento y multiterminales, combinado con las capacidades de reserva técnica del equipo existente, elegimos la solución de tecnología isomórfica multiterminal de Taro. En este artículo, nos centraremos en los problemas encontrados y las soluciones correspondientes después de que el equipo de front-end del evento de boletos del departamento de turismo y el equipo de tecnología inalámbrica pública cooperaran para integrar la pila de tecnología Taro con las tecnologías existentes.

3. Cómo integrar Taro con las tecnologías existentes

La tecnología isomórfica multiterminal proporcionada por Taro se puede utilizar directamente sin considerar la integración con la pila de tecnología existente. Si ya tiene un conjunto de soluciones técnicas, debe considerar cómo integrar Taro con tecnologías web o de aplicaciones existentes.

La solución cross-end de Taro es una solución basada en compilación estática. El producto final consiste en compilar el código fuente en código de destino y empaquetarlo en un archivo ejecutable. Este archivo no se puede integrar directamente en el marco del lado comercial (Ctrip) RN o Web, ni puede llamar directamente a los componentes comerciales proporcionados por Ctrip, como ciudades, calendarios, pagos, etc. Por lo tanto, los desarrolladores deben adaptar Taro antes de poder resolver el problema de la integración con los marcos existentes.

Como se muestra arriba, el principio central de Taro es reemplazar los componentes y API originales del pequeño programa con componentes y API adaptados a diferentes plataformas mediante la inyección de configuraciones personalizadas durante la compilación y la construcción, logrando así capacidades multiterminal. De esta forma, se puede utilizar el mismo código en el desarrollo empresarial para adaptarse a diferentes terminales, eliminando diferencias en el desarrollo multiterminal.

3.1 Aplicación integrada (integrada con la tecnología Ctrip React Native)

1) En el archivo de configuración de Taro, inyecte complementos personalizados

2) Realizar el reemplazo de alias a través de la configuración del paquete Metro (reemplazar la referencia taro original con la nueva ruta RN)

3) Suavizar los componentes y las API de Taro

Componente de texto

API de salto de página

Siga los pasos anteriores y combínelo con el andamio de ReactNative para que funcione.

3.2 Integración de la Web (integración con la tecnología Ctrip NFES)

La tecnología isomorfa de Taro está disponible en modos no SSR y SSR en el lado web. El modo SSR se basa en el marco NextJS y se admite proporcionando el complemento de compilación tarojs-plugin-platform-nextjs. Sin embargo, dado que este complemento de compilación no admite marcos web u otros marcos web basados en extensiones de tecnología NextJS, es necesario utilizar las capacidades de compilación abiertas en Taro scaffolding para reemplazar las API y las bibliotecas de componentes por otras que admitan el isomorfismo del lado del servidor mediante El complemento de Babel durante la construcción. versión, y al mismo tiempo genera el directorio y la configuración del proyecto que se adaptan al marco actual, de modo que Taro tenga la capacidad de convertir al marco web correspondiente. Consulte los siguientes pasos para obtener más detalles. :

1) Igual que RN, inyecta complementos H5 personalizados

2) Configuración del paquete a través de Webpack y realización de reemplazo de alias

3) Suavizar los componentes y las API de Taro

Componente de texto

API de salto de página

4) Ajuste el enrutamiento, el middleware y otras configuraciones del proyecto de acuerdo con su propio marco. El siguiente es un diagrama de ejemplo de Ctrip NFES.

Siga los pasos anteriores y combínelo con su propio andamio web para que funcione.

4. Práctica Técnica

Después de resolver el problema de integrar el marco multiterminal de Taro con las tecnologías existentes, es necesario mejorar aún más la riqueza de componentes y API, mejorar el rendimiento de las aplicaciones y resolver el problema de la adaptación de CSS para reducir los costos de desarrollo y mejorar la experiencia del usuario. Objetivo.

4.1 Biblioteca de componentes y API

1) Riqueza de componentes y API

La solución principal de la tecnología de isomorfismo multiterminal de Taro es lograr isomorfismo entre terminales suavizando las diferencias en las bibliotecas de componentes y las API, haciendo así que el rendimiento y la experiencia del usuario sean consistentes con las aplicaciones de un solo terminal desarrolladas de forma independiente. Sin embargo, la desventaja de este enfoque es que es necesario desarrollar bibliotecas de componentes y API en cada extremo para alinearse con el subprograma Taro, lo que requiere un gran costo inicial.

El diseño multiterminal de Taro ha tenido en cuenta la reducción del coste de inversión inicial del personal de I+D, por lo que proporciona más de 60 bibliotecas de componentes y API alineadas con el subprograma de Taro. Se ha demostrado en la práctica que ha satisfecho las necesidades empresariales más comunes.

Además de los componentes y API proporcionados, todavía es necesario desarrollar componentes de extensión y API orientados al negocio, como capas elásticas, plegado, calendario y componentes de selección de ciudad, así como pagos, inicio de sesión, etc. (como se muestra en la figura arriba). La mayoría de los componentes solo requieren un embalaje secundario en los componentes proporcionados oficialmente, y los costos de investigación y desarrollo no son elevados.

2) Componentes multiterminal y diferencias API

Puede haber algunas diferencias en los componentes multiterminal y las API en diferentes plataformas, que no se pueden solucionar por completo. Cada plataforma tiene sus propias características y limitaciones, por lo que al desarrollar aplicaciones multiterminal, estas diferencias deben adaptarse y manejarse.

Por ejemplo, existen diferencias entre diferentes plataformas en la implementación de animaciones. En ReactNative, solo puede usar el componente Animación para lograr efectos de animación. En el mini programa y en la Web, los estilos CSS se usan para lograr efectos de animación. Para mantener la coherencia de múltiples extremos tanto como sea posible, la implementación de la animación está encapsulada. en un componente unificado para que pueda usarse en diferentes plataformas. El componente de animación encapsulado se llama componente de animación en el lado RN, y la animación se implementa en el mini programa y en el lado web agregando estilos CSS a través de Js dentro del componente. Este método resuelve las diferencias en la implementación de la animación y permite a los desarrolladores utilizar una interfaz unificada para llamar efectos de animación sin prestar demasiada atención a los detalles de implementación específicos de diferentes plataformas.

Los problemas de aplanamiento anteriores se pueden resumir en las tres categorías siguientes:

Descripción de la situación	solución	Por ejemplo
Tanto A como B tienen esta función, pero la diferencia no es grande.	Suaviza las diferencias	entrada, salto de enrutamiento, etc.
Tanto los terminales A como B tienen esta función, pero son muy diferentes.	Suaviza las diferencias	Los componentes de animación están encapsulados en una API unificada.
El lado A tiene esta función pero el lado B no.	Degradar Diferencia Suave o Diferencia Suave	Suavizado de diferencias: cada extremo implementa cada extremo. Por ejemplo, RN usa Flatlist y otros extremos usan scrollview. Degradar y suavizar: algunos se muestran y otros no, por ejemplo, la barra de navegación principal no existe en el mini programa.

4.2 Adaptación CSS

El soporte cruzado de CSS es débil y está limitado por las limitaciones de la plataforma de ReactNative, por lo que el soporte no es amigable.

ReactNative no admite el anidamiento de estilos CSS. Solo puede dividir el estilo en varios objetos independientes y fusionarlos en un solo objeto mediante el método StyleSheet.flatten para establecer estilos independientes en un nodo jerárquico. Actualmente, el método multiterminal sólo se puede adaptar mediante suavizado diferencial, sacrificando la flexibilidad de CSS en otros terminales.

ReactNative no admite selectores de pseudoelementos en CSS. Como ::before y ::after porque no tiene elementos DOM y no admite estos selectores. Puede agregar nodos HTML para adaptarse a la escritura del selector.

El método de escritura anterior limita la eficiencia del desarrollo multiterminal, pero no afecta la realización funcional del producto. La mayoría de los demás problemas de estilo se pueden solucionar utilizando complementos de Babel (como rn-style-transformer).

Diferencias de atributos predeterminados de la plataforma

Atributos	ios-rn	android-rn	web	Applets
tamaño de fuente	14	dieciséis	dieciséis	dieciséis
color	#000	#777	#000	#000
margen	0	0	8	0
relleno	0	0	1	0

Las propiedades de la plataforma admiten diferencias

Atributos	ios-rn	android-rn	web	Applets
fondo	no apoyo	no apoyo	apoyo	apoyo
posición: fija	no apoyo	no apoyo	apoyo	apoyo
sangría de texto: número	no apoyo	no apoyo	apoyo	apoyo
discontinuo	no apoyo	no apoyo	apoyo	apoyo

4.3 Rendimiento

Debido a que Taro utiliza compilación estática para generar código de plataforma, su rendimiento es mejor que la compilación dinámica. El rendimiento en el lado de la aplicación es equivalente al de RN nativo, pero en el lado web, los nodos Dom serán reemplazados por componentes web y las capacidades de representación de los componentes web son inferiores a las de los componentes nativos. Por lo tanto, si hay una gran cantidad de componentes web durante el proceso de conversión, la representación de la página se ralentizará. En las condiciones de prueba, donde el modelo de computadora es MacBook Pro (14 pulgadas, 2021), el modelo de navegador es Chrome y la versión del navegador es 113.0.5672.63 (versión oficial) (arm64), taro-view-core (Ver) El componente es Por ejemplo, si el renderizado se repite 2000 veces, el consumo de tiempo total es de aproximadamente 123 ms. Si cambia a div y lo vuelve a renderizar 2000 veces, tomará aproximadamente 17 ms, que es aproximadamente 7 veces diferente. La captura de pantalla experimental es la siguiente:

El componente web lleva tiempo:

El div nativo lleva tiempo:

De los experimentos anteriores, se puede concluir que en lugar de utilizar directamente componentes como Vista y Texto proporcionados por Taro, envuelva una capa de componentes con funciones de Taro encima de los componentes web nativos.

5. Escenarios y costos aplicables

5.1 Ver isomorfismo de capa

De acuerdo con las necesidades de interacción y diseño del producto, se recomienda utilizar un conjunto de Vistas para aplicaciones, H5 y mini programas cuyos métodos de interacción sean más del 70% similares, y las diferencias se pueden realizar utilizando la extensión de archivo proporcionada por Proyecto Taro.

Dado que los métodos de interacción en el lado de la PC son bastante diferentes, generalmente es necesario escribir dos conjuntos de componentes de Vista, lo cual es más apropiado.

5.2 Escenarios aplicables para isomorfismo multiterminal

El isomorfismo multiterminal es adecuado para aplicaciones que necesitan proporcionar las mismas funciones en múltiples plataformas para mejorar la eficiencia del desarrollo y la experiencia del usuario.

No es adecuado para aplicaciones que tienen altos requisitos de rendimiento y dependen en gran medida de las características exclusivas de la plataforma, como juegos basados en lienzo. Para escenarios que no son aplicables y es necesario admitir múltiples plataformas, solo pueden lograr la suya propia. efectos.

5.3 Costo del isomorfismo multiterminal

Aunque la tecnología isomórfica multiterminal puede reducir los costos de desarrollo, todavía existen diferencias en estilos y API entre diferentes plataformas, lo que requiere que el personal de I + D se adapte y complemente. Para una comparación real de los costos de I+D en cada extremo, consulte la siguiente tabla:

	Costos de I+D	Después del isomorfismo multiterminal	Observación
Aplicación	1	0,2
H5	1	0,2
Applets	1	1.2	Primera plataforma desarrollada
ordenador personal	1	0,4
total	4	2.2

A medida que se acumula experiencia en desarrollo y se enriquecen los componentes, los costos de investigación y desarrollo y pruebas se reducirán aún más.

Costo de aprendizaje: el desarrollo isomórfico multiterminal requiere que los desarrolladores tengan capacidades y experiencia en desarrollo entre terminales, deben comprender las características y diferencias de cada plataforma y prestar atención al rendimiento, la mantenibilidad y la escalabilidad del código. Podemos mejorar sus habilidades y destrezas a través de una variedad de capacitación e intercambio.

Costo de prueba: en un modelo de desarrollo isomórfico de múltiples terminales, si un terminal se corrige accidentalmente, afectará a todos los terminales, por lo que el costo de prueba aumentará. Cuanto más amplio sea el alcance de las pruebas, mayor será el tiempo de prueba y, por tanto, el correspondiente aumento de los costes de las pruebas. Además, debido a las diferencias entre las distintas plataformas, los evaluadores deben tener la capacidad de realizar pruebas entre plataformas, lo que también impondrá requisitos más altos a las capacidades de I+D de los evaluadores. Para resolver estos problemas, se pueden popularizar UT (pruebas unitarias) y AT (pruebas automatizadas), lo que puede reducir los costos de las pruebas y mejorar la eficiencia de las pruebas.

Estabilidad de producción: debido a que la tecnología isomórfica multiterminal utiliza lógica de código unificada y encapsulación de componentes, una vez que ocurre un problema, varias plataformas se verán afectadas. Por lo tanto, se requieren pruebas rigurosas y controles de calidad durante el proceso de desarrollo para garantizar la estabilidad y confiabilidad del código.

6. Resumen y perspectivas

Este artículo presenta el uso de Taro para lograr isomorfismo multiterminal, reducir los costos de I + D y mejorar la experiencia del usuario en escenarios comerciales multiplataforma. Al utilizar el mismo lenguaje de desarrollo y marco de código, el código se puede reutilizar en diferentes fines para lograr el propósito de unificar la lógica empresarial.

Es previsible que en un futuro próximo surjan más soluciones, ya sea basadas en las necesidades comerciales o en la práctica técnica y la innovación, lo que facilitará el camino hacia el desarrollo de múltiples terminales. Al mismo tiempo, esta solución se convertirá en el principal marco multiterminal de la empresa.

[Lectura recomendada]

Cuenta pública “Tecnología Ctrip”

Compartir, comunicar, crecer

Información seca | Exploración y práctica multiterminal de Ctrip Taro