SwiftUI VS Flutter

Prefacio

Creo que cada desarrollador que vea SwiftUI asociará inmediatamente este nuevo marco de interfaz de usuario con Flutter. Sí, tienen demasiadas similitudes, sintaxis de declaración similar, actualizaciones en caliente en tiempo real, multiplataforma (SwiftUI solo cruza las plataformas de Apple), etc., lo que hace que el círculo de desarrollo móvil que envidia la explosión de la tecnología front-end también sea animado. . Entonces, ¿cuáles son las similitudes y diferencias entre SwiftUI y Flutter? ¿Cuáles son sus ventajas y desventajas? Y, por último, solo en términos de dirección técnica, ¿quién es el ganador de la futura solución multiplataforma?

Idioma

Es un hecho indiscutible que los lenguajes informáticos modernos se están volviendo cada vez más similares, porque los objetivos básicos de cada idioma son los mismos: simplicidad, flexibilidad, seguridad y alto rendimiento. Al mismo tiempo, las excelentes características de varios idiomas se utilizan como referencia mutua, lo que reduce aún más la brecha entre varios idiomas.

Swift y Dart son, respectivamente, los únicos idiomas oficiales de estos dos marcos de interfaz de usuario. La diferencia gramatical es realmente muy pequeña. También hay muchos artículos en Internet para comparar los pros y los contras de estos dos idiomas. Mi experiencia es similar a la de la mayoría de la gente, por ahora Swift y Dart tienen sus propias ventajas y desventajas.

Swift es más conciso que Dart. Swift en sí es mucho más limpio que Dart en el nivel gramatical, por ejemplo, no es necesario agregar un ;punto y coma al final de una oración . Esto es especialmente obvio cuando se escribe SwiftUI y Flutter directamente. Sin embargo, este problema no es todo causado por el nivel de idioma, sino también relacionado con el diseño de estos dos marcos de interfaz de usuario.

ForEach(userData.landmarks) { landmark in
	NavigationButton( destination: LandmarkDetail(landmark: landmark)) {
    LandmarkRow(landmark: landmark)
  }
}
复制代码

SliverList(
  delegate: SliverChildBuilderDelegate(
    (context, index) {
      final landmark = landmarks[index];
      return LandmarkCell(
        landmark: landmark,
        onTap: () {
          Navigator.push(
            context,
            CupertinoPageRoute(
              builder: (context) => LandmarkDetail(
                landmark: landmark,
              ),
            ),
          );
        },
      );
    },
    childCount: landmarks.length,
  ),
),
复制代码

Ambos implementan una página de lista en la que se puede hacer clic y ambos llaman a una celda personalizada.

Swift es más estricto que Dart y será más seguro desde cierto punto de vista.Por supuesto, depende de las personas para encontrar la raíz de la seguridad.
Swift no tenía await / async en el quinto año de su lanzamiento, aunque ha habido propuestas, no se han implementado. Sin embargo, no hay opciones en Dart. Solo se puede decir que la absorción mutua de los dos no es suficiente.
Tecnología negra de Dart: admite tanto AOT como JIT, que también dota a Flutter con funciones de recarga en caliente a nivel web, y es un arma poderosa para Flutter contra SwiftUI.
Tanto Swift como Dart son lenguajes de código abierto. Apple está abierto a Swift sin precedentes, ahora Swift puede haberse quedado sin macOS, también ha habido en la comunidad, como el marco de back-end para Vaporuna serie de cosas interesantes, etc., se convertirá en Tensorflowuno de los idiomas oficiales. Todo esto amplía enormemente los escenarios de uso de Swift. Sin embargo, Dart es obviamente más rápido que Swift en términos de jugabilidad. Algunas empresas han puesto el marco de back-end desarrollado con él en el entorno de producción, y el marco web de Google AngularDart(no Flutter Web) también se ha estado ejecutando de forma estable en algunos servicios durante mucho tiempo. Por no hablar de correr en iOS Android macOS Windows Web con la ayuda de Flutter, se puede describir por la forma en que lo miras.

El diseño de un lenguaje afecta la popularidad de un framework.He escuchado a innumerables desarrolladores de Flutter quejarse del interminable problema de anidamiento de Dark. Aunque Dark es más jugable, en lo que respecta a un marco de interfaz de usuario único, personalmente creo que Swift tiene una experiencia de uso significativamente mejor que Dart.

gramática

Tanto SwiftUI como Flutter usan sintaxis declarativa y sus respectivos DSL para describir la IU sin excepción. Su ventaja es que puede ver la estructura real de la IU a partir de la estructura del código de un vistazo y evitar los códigos lógicos repetidos. SwiftUI utiliza la vinculación de datos y la gestión de estado para reemplazar la lógica de control compleja original, y DSL hace que la estructura del código sea altamente consistente con la jerarquía de la UI.

VStack {
    MapView()
        .edgesIgnoringSafeArea(.top)
        .frame(height: 300)

    CircleImage()
        .offset(y: -130)
        .padding(.bottom, -130)

    VStack(alignment: .leading) {
        Text("Turtle Rock")
            .font(.title)
        HStack(alignment: .top) {
            Text("Joshua Tree National Park")
                .font(.subheadline)
            Spacer()
            Text("California")
                .font(.subheadline)
        }
    }
    .padding()

    Spacer()
}
复制代码

Arriba hay un LandMark de demostración de SwiftUI que apareció en WWDC. Incluso si no ha aprendido la sintaxis de SwiftUI, si lee un poco el código anterior, puede encontrar que tiene una correspondencia uno a uno con la interfaz de usuario en la imagen. Ésta es la ventaja de la sintaxis declarativa. Sin embargo, al escribir código, los sentimientos de Flutter y Swift son muy diferentes, el más obvio es: Flutter es mucho más complicado que SwiftUI. ¿Cuánto código se debe escribir para lograr el efecto anterior con Flutter? No puedo pegarlo demasiado, de lo contrario, la mitad de mis artículos serán código Dart. Pero aquí hay una persona que escribió una versión Flutter de LandMarks imitando la demostración , puede consultarla.

Por qué también es una sintaxis declarativa, Fluter es mucho más complicado que SwiftUI. En realidad, esto refleja las diferentes ideas de Apple y Google al diseñar estos dos marcos de interfaz de usuario, e incluso representa las diferentes culturas de las dos empresas. Los desarrolladores que tienen un poco de conocimiento de iOS y Android saben que el desarrollo de iOS es mucho más fácil que el de Android. En términos de configurar solo el entorno de desarrollo, iOS puede comenzar a escribir código un día antes que Android. Sin mencionar marcos complicados, compatibilidad caótica de plataformas y documentos entrecortados.

Apple trata a los desarrolladores como si fueran novatos, haciendo todo lo posible para simplificar el proceso de desarrollo, reducir la carga de trabajo en el desarrollo e incluso hacer que el desarrollo sea algo elegante, desde la apariencia y el diseño de funciones de Xcode. Esto es cierto desde la API del sistema hasta el lenguaje Swift. Cuando Google trata a los desarrolladores, es más como un geek, dando mucho trabajo y creación a los desarrolladores, permitiéndoles crear cosas interesantes libremente. Pero, en consecuencia, su umbral también es muy alto, y la fragmentación y la incontrolabilidad provocadas por la libertad también conducirán a una disminución de la eficiencia del desarrollo.

Al diseñar la API de SwiftUI, Apple oculta una gran cantidad de detalles internos, lo que permite a los desarrolladores llamar al menor código posible para lograr el efecto correspondiente. Los desarrolladores no necesitan reescribir el método de inicialización no requiere el uso return, no necesitan preocuparse por el contextcontexto, no debería ser necesario preocuparse por un StatefulWidgetaún StatelessWidgetmás no es necesario preocuparse por el diseño de materiales o el estilo iOS. Apple puede hacer todo por ti internamente. Todo lo que necesitas hacer es decirle al compilador qué controles necesitas, cuáles son, dónde deberían estar y nada más. Si la gramática declarativa que Flutter aporta al desarrollo móvil brilla en los ojos de todos, entonces la aparición de SwiftUI es para decirles a todos (incluido Flutter) cuál es la gramática declarativa real.

Actualización en vivo

La característica más importante de SwiftUI es la tan esperada recarga en caliente, que es una actualización en tiempo real. La altísima eficiencia de desarrollo de la web siempre ha sido una habilidad de ensueño del terminal móvil, la aparición de RN ha hecho que todos los desarrolladores móviles vean esta posibilidad por primera vez, aunque ahora tiene sus propios problemas. Como una extensión de la tecnología Web, Flutter hereda una gran cantidad de características de la tecnología Web, y la recarga en caliente parece ser una habilidad útil. Sin embargo, si SwiftUI quiere conseguir una actualización en tiempo real similar a la de la Web, las dificultades que tiene que afrontar son mucho más complicadas. Desde mi experiencia actual, también ilustra completamente este punto.

La vista previa en tiempo real de SwiftUI se divide en vista previa estática y vista previa dinámica. La vista previa estática se muestra de forma predeterminada, que es rápida y admite métodos de escritura de código y visualización. Sin embargo, no responde a ningún evento y no puede desplazarse ni saltar páginas. Si necesita depuración dinámica, debe cambiar a la vista previa dinámica. La vista previa dinámica debe pasar un período de tiempo de compilación, y luego puede responder a los cambios de la interfaz de usuario en tiempo real en una forma completamente dinámica, y se puede depurar en tiempo real en una máquina real. Sin embargo, todavía existen muchas restricciones en la vista previa dinámica, y es imposible lograr el tipo de Flutter que solo necesita compilarse una vez, y luego toda la aplicación se puede actualizar dinámicamente.

¿Por qué hay una vista previa estática y una vista previa dinámica? Creo que Apple definitivamente no complicaría este problema si no fuera por algunas consideraciones de problemas (problemas de rendimiento, errores difíciles). Solo se puede decir que la recarga en caliente actual de la versión deshabilitada es el mejor efecto que Apple nos puede dar. Por esta razón, la llamada actualización en tiempo real de SwiftUI todavía está en pediatría desde la Web y Flutter. La depuración estática de la interfaz de usuario se puede lograr a través de StoryBoard, pero la vista previa dinámica realmente práctica tiene ciertas limitaciones. Sin embargo, SwiftUI aún se encuentra en la etapa de prueba y aún no es posible llegar a una conclusión final sobre su desempeño.

actuación

Google afirma que uno de los objetivos de Flutter es la suavidad (60 Hz). Hasta ahora, lo logra en la mayoría de los escenarios. Sin embargo, según mi prueba (esto está actualmente en versión beta), las escenas como las transiciones de página y las animaciones de control todavía tienen cierta presión para ejecutarse a 60 Hz. He estado siguiendo el proyecto Flutter y también estamos intentando reescribir algunos módulos con Flutter internamente. Pero lo que he experimentado hasta ahora, el Flutter actual, solo se puede decir que está muy cerca de la fluidez de la plataforma nativa. Sin embargo, incluso si Flutter puede lograr la fluidez nativa del sistema, todavía no puede evitar el problema de la pérdida de rendimiento. Los marcos de interfaz de usuario nativos de iOS (incluido SwiftUI) se construyen sobre Metal, y Metal usa las GPU de manera mucho más eficiente que OpenGL. Los resultados obtenidos también mostraron en mi prueba que la misma representación y animación de la página, la utilización de CPU y GPU de Flutter es mayor que el marco de interfaz de usuario nativo de iOS. El consumo de alto rendimiento significa una alta generación de calor y una baja duración de la batería del equipo. Esto es especialmente grave en los dispositivos móviles.

A diferencia de SwiftIU, Apple parece haber copiado todos los controles nativos del sistema. En principio, no habrá mejora de rendimiento, pero no te dejes engañar por tus ojos. Apple jugó un gran juego donde no puedes verlo.

Las dos imágenes anteriores son las etiquetas de SwiftUI e iOS renderizadas de forma nativa, las cuales se ejecutan en la plataforma iOS y se ven exactamente iguales, pero detrás de ellas hay dos cosas completamente diferentes. Descubrimos que el texto en SwiftUI ya no es un control nativo del sistema iOS, sino un nuevo tipo llamado Text. En realidad, es un nuevo control heredado de UIView, el nombre completo es DisplayList.ViewUpdater.Platform.CGDrawingView. Observe la ventana de propiedades a la derecha y descubra que los dos controles tienen propiedades completamente diferentes. UILabelTiene atributos complejos para controlar estilos, interacciones, etc. Y Texttendrá un aspecto mucho más ágil.

Hay rumores de que algunos de los controles de SwiftUI han abandonado el marco de interfaz de usuario nativo del sistema y, en su lugar, utilizan directamente el nivel inferior, y también se representan en Core Animation, Core Graphics y Core Text más comunes en el ecosistema de Apple. Aún no conozco si el marco subyacente se usa directamente para una representación eficiente, pero lo que es seguro es que Apple está eliminando SwiftUI del marco de interfaz de usuario original, perdiendo la pesada carga histórica. Esto seguramente traerá muchos beneficios, como mayores grados de libertad, mejor rendimiento y, en el verdadero sentido: multiplataforma.

Multiplataforma?

Mucha gente puede decir que SwiftUI y Flutter no se pueden comparar juntos, y SwiftUI no es verdaderamente multiplataforma. Así es, SwiftUI actualmente abarca solo el propio ecosistema de Apple, incluido iOS (iPadOS) macOS watchOS tvOS, y el vecino Flutter ya se cansó del terminal móvil y comenzó a migrar a Windows macOS y la Web. Sin embargo, no puede negar que SwiftUI ha logrado Escribir una vez, usar en cualquier lugar en una plataforma de sistema completamente diferente. Además, la idea detrás de esto es completamente diferente.

SwiftUI no está básicamente construyendo UI, sino describiendo UI. ¿Cuál es la diferencia entre los dos? Al construir la IU, tendrás claro el tipo de cada control, incluso para la plataforma. Por ejemplo, en un marco de interfaz de usuario nativo, si necesita un cuadro de entrada, debe elegir si usar UITextFiled (iOS) o NSTextFiled (macOS) según las diferentes plataformas, y estos dos cuadros de entrada tienen diferentes atributos, apariencias y características. En Flutter, no es necesario que consideres los tipos de controles en las diferentes plataformas, pero debes considerar el estilo de los controles. Se proporcionan los controles oficiales de Android que se ajustan a Material Design y los controles de iOS que se ajustan al estilo de iOS. Muchas de sus características también son inconsistentes, todas las cuales dan construcción de interfaz de usuario Aporta una lógica y una carga de trabajo más complejas.

Y SwiftUI es más como una plantilla web, solo describe la interfaz de usuario, y el aspecto del control y las características que tiene se implementarán de acuerdo con las condiciones locales de acuerdo con la plataforma compilada, y es automático. Es como poner una plantilla, un tema en la Web.

Código izquierda describe una forma que contiene algunos controles sencillos, incluyendo Picker, Toggle, Stepper, Button. Si ponemos el código intacto en el proyecto macOS, se verá así.

Verá que con el mismo código, la interfaz de usuario mostrada es completamente diferente, pero el contenido expresado por la interfaz de usuario es exactamente el mismo. Lo que es más fascinante es que Pickereste control de "selección de lista de elementos únicos" se traduce en una página de selección en iOS. Al hacer clic en la celda, se mostrarán todas las opciones seleccionables, y al hacer clic en la opción, se volverá a la página anterior y se seleccionará. El contenido se muestra en la celda correspondiente. En macOS, Pickerse traducirá en una lista desplegable común en nuestro sistema operativo de escritorio. Este tipo de transformación es increíble, solo puedo describirlo como Wow, Awesome y Amazing. Porque está totalmente en línea con el lenguaje de diseño de la plataforma y los hábitos de los usuarios, y al mismo tiempo reduce en gran medida la dificultad de desarrollo y adaptación. Sin embargo, SwiftUI puede hacer mucho más que eso.

Así es, no solo iOS y macOS, sino también en tvOS y watchOS, SwiftUI también mostrará todos los controles de la manera que mejor se adapte al lenguaje y la interacción de diseño de la plataforma. Además, también obtendrá automáticamente una gran cantidad de funciones del sistema, como Tipo dinámico, Modelo oscuro y dirección de lectura adaptativa.

Desde este punto de vista, SwiftUI y React Native tienen ideas y tecnologías más similares. Es solo que Facebook casi no tiene voz en iOS o Android, por lo que existen ciertos problemas de compatibilidad y consistencia. Para lograr esta compatibilidad, no solo React Native necesita hacer mucho trabajo, sino que los desarrolladores también deben estar cansados de lidiar con varios problemas, que se puede decir que es una tecnología intermedia incómoda.

SwiftUI y React Native son fundamentalmente diferentes del pensamiento de plataforma cruzada de Flutter. Flutter abandona por completo el marco de interfaz de usuario nativo de la plataforma en ejecución, similar a "dibujar" cada control píxel por píxel en un lienzo, similar a un motor de juego 2D. Su propósito también es muy claro: garantizar que el mismo código muestre exactamente la misma interfaz de usuario en diferentes sistemas operativos, dispositivos de hardware y tamaños de pantalla. Esto parece ser lo que quieren los desarrolladores, porque estamos hartos de las incontrolables diferencias que muestra RN en distintas plataformas. Pero incluso si se descartan las diferencias en el lenguaje de diseño de los diferentes sistemas operativos, la interfaz de usuario en diferentes tamaños de pantalla debería ser al menos muy diferente. La interfaz de usuario de la plataforma de escritorio y la interfaz de usuario de la plataforma móvil, e incluso la interfaz de usuario del reloj, deben tener interfaces de usuario e interacciones completamente diferentes según los hábitos de uso y los métodos de manipulación del usuario. Si desea implementar la adaptación multiplataforma en Flutter, el resultado puede ser una pesadilla para cualquier programador. Necesita hacer muchos juicios y es posible que deba usar varios controles para lograr una sola función y, finalmente, tendrá que enfrentarse a muchas pruebas y errores.

Pero existen ventajas y desventajas. La solución multiplataforma casi perfecta de SwiftUI se basa en un bajo grado de libertad. A través del ejemplo anterior, también encontró que todos los estilos de control nativos del sistema se utilizan en la demostración. Esto no quiere decir que no podamos personalizarlo, pero:

No podemos personalizar suficientes artículos
Cuanto más contenido personalicemos, más funciones que el sistema nos agregue automáticamente perderá

Por ejemplo, si queremos modificar el color de fondo de la lista, perderemos algunas de las características del Modelo Oscuro que el sistema agregó automáticamente por nosotros. Necesitas hacer un trabajo adicional para decirle a la Aplicación de qué color debe mostrarse el fondo en modo blanco / negro.

Pero, afortunadamente, Apple ha comenzado a intentar romper con el marco de interfaz de usuario original del sistema, lo que en cambio nos hace más conveniente personalizar parte de la interfaz de usuario. En el pasado, necesitábamos implementar el estilo del botón a continuación, que requería muchos ajustes en los parámetros del UIButton, porque el UIButton predeterminado tiene el texto a la izquierda y la imagen a la derecha. Ahora, después de que SwiftUI se separe del marco de la interfaz de usuario del sistema, podemos implementar estilos de interfaz de usuario complejos a través de un código extremadamente simple.

Sin embargo, todavía hay una cierta brecha entre esto y la orgullosa "precisión del píxel" de Flutter. Es posible que no podamos controlar completamente todos los detalles de los controles de la interfaz de usuario como Flutter. Pero al igual que con el dibujo, se pierde cierta libertad a cambio de un desarrollo más rápido y eficiente, que refleja exactamente el estilo corporativo de Apple.

Pero, ¿ha terminado la historia de la multiplataforma SwiftUI? Creo que esto es solo el comienzo. SwiftUI, un marco de interfaz de usuario puramente descriptivo que es completamente independiente de la plataforma y el dispositivo, es precisamente la dirección correcta para las soluciones multiplataforma. SwiftUI se puede usar para describir la interfaz de usuario de iOS macOS tvOS e incluso watchOS. ¿Por qué no se puede usar para describir Android o la Web? SwiftUI ya tiene una serie de características como diseño Flex, combinación de enlace de datos, recarga en caliente, etc. Solo necesitamos seguir esta idea y aplicar la plantilla de Android o Web a SwiftUI, y también podemos obtener una interfaz de usuario que se ajuste al lenguaje de diseño y especificaciones de la plataforma. . Por supuesto, esto está lejos de ser tan simple como dije, pero no olvide que Swift es de código abierto y la operación multiplataforma no es un problema. Mientras existan las condiciones, todo es posible.

Pero entonces, ¿cómo será Flutter? Al menos por ahora, Flutter seguirá siendo una de las primeras soluciones multiplataforma para la mayoría de las empresas, y SwiftUI se utilizará a gran escala al menos 2 o 3 años después.