Noticias

Facebook re-escribe desde 0 Messenger, gran parte en desarrollo nativo

Facebook se da cuenta que las apps nativas son necesarias cuando se exige mucho a un desarrollo.

Resumen del artículo
  • Facebook anuncia la refactorización de la app Messenger, pasando a usar tecnología nativa en vez de basada en sus propias soluciones multiplataforma. Os contamos los detalles.

Si hay una polémica difícil de resolver en el mundo del desarrollo móvil, es aquella que se refiere al desarrollo nativo contra el híbrido. Y no solo nos referimos a un desarrollo híbrido basado en dibujar la interfaz en HTML5, también al uso de frameworks de UI que no sean el creado por el propio creador del sistema (Apple o Google). Principalmente porque estos fuerzan al sistema a realizar una traducción entre librerías poniendo más capas que hacen que las apps funcionen con peor rendimiento.

Puedes defender o no las apps híbridas o hechas con una librería multiplataforma. Pero lo que no es discutible porque es empíricamente demostrable, es que el desarrollo nativo es más rápido en su ejecución, las apps pesan menos porque usan las librerías que ya tiene cargadas el sistema y se usa menos código para conseguir lo mismo.

Estos hechos son en los que acaba de caer Facebook, que ha anunciado el denominado Proyecto Velocidad de la Luz (Project Lightspeed). Este, básicamente, se basa en refactorizar toda la app de Messenger y construirla usando en su mayoría la base de arquitectura nativa de la plataforma iOS.

Más rápida, más pequeña y más simple

Así es como lo define Facebook, los creadores del framework multiplataforma más usado hoy día: React Native. Pero ellos mismos se han dado cuenta de una serie de hechos que son incuestionables. Se han percatado que Messenger, con todas las funciones que ofrecía a los usuarios, se había convertido en un monstruo difícil de domar y que cada vez iba más lento, sobre todo en dispositivos más antiguos.

Así que no han tenido miedo en reconocer lo obvio: que cuando una app ofrece una funcionalidad compleja con muchas ramas y opciones, la opción más plausible es usar desarrollo nativo. Si nuestra app es una sola pantalla de información, casi más una web, una híbrida puede servirnos. Pero para cosas serias, hay que pegarse al sistema lo más posible y es lo que ha hecho Facebook.

La nueva app de Messenger ocupa solo el 25% del espacio de los más de 130MB que ocupa la versión actual, arranca el doble de rápido y reduce sus líneas de código en un 84% pasando de 1.7 millones a 360.000. Y para conseguirlo han establecido 4 pilares básicos: usar el sistema operativo nativo, reusar la interfaz, darle más poder a la base de datos SQLite y mejorar el servidor (ya que también han refactorizado el backend).

Vamos a transcribir algunos párrafos del artículo que han publicado, para que vean que no es algo que digamos nosotros: lo dice Facebook ante la cruda realidad.

Los sistemas operativos móviles continuan evolucionando rápida y dramáticamente. Nuevas funciones e innovaciones son constantemente añadidas por petición de los usuarios y la presión de la propia competencia. Cuando creamos una nueva función, suele tentarnos el construir nuestras propias abstracciones encima del sistema para cerrar una brecha funcional, agregar flexibilidad en la ingeniería o crear experiencias de usuario multiplataforma. Pero el sistema operativo suele ofrecer mucho de lo que necesitamos. Acciones como el renderizado, transcodificación, gestión de hilos o logging pueden ser gestionados por el sistema. Incluso cuando hay soluciones personalizadas que podrían ser más rápidas para métricas locales, usamos el sistema para optimizar las métricas globales.

Básicamente Facebook nos dice que en muchas ocasiones el sistema operativo ya ofrece lo que ellos necesitan y que poner una capa más por encima tal vez pueda ser bueno para algunas funciones específicas, pero globalmente es mejor usar lo que te ofrece el sistema.

Arquitectura de UI en el nuevo Messenger

Mientras las librerías de interfaz (UI) pueden ser muy potentes e incrementar la productividad del desarrollador, requieren una constante vigilancia y mantenimiento para mantener al día con todos los cambios que se realizan en los sistemas móviles. Así que mejor que reinventar la rueda, usamos la librería de interfaz disponible en el sistema nativo para soportar un gran número de loas funciones que la app necesita. Eso no solo reduce su tamaño, eliminando la necesidad de cachear o cargar grandes librerías personalizadas, también reduce la complejidad. Las librerías nativas no tienen que ser traducidas a ninguna sub-librería. También usamos algunas librerías de sistemas, incluyendo la librería de proceso de JSON, en vez de crear y almacenar nuestra propia librería en el código base de la app.

En este párrafo está lo más importante. Insistimos que una app híbrida o hecha con una librería de terceros de interfaz multiplataforma, puede ser una gran idea para muchos. Pero su peso para el sistema, la necesidad de tenerla en memoria cacheada, su carga para la CPU… si el sistema ya ofrece todo eso, ¿por qué reinventar la rueda? Mejor usar las funciones que ofrece el propio sistema en vez de perder el tiempo y conseguir un peor rendimiento y eficacia.

Conclusiones

Leyendo todo el documento se da a entender que la base del desarrollo es en C (como sucede con Office de Microsoft en todas las plataformas que comparten un mismo código común para todas ellas en este lenguaje), y desde este lenguaje invocan y usan las interfaces en Objective-C que ofrece UIKit y el resto de frameworks de iOS.

No podríamos considerar que el nuevo Messenger sea 100% nativo, porque Facebook sigue conservando partes de su desarrollo multiplataforma y su propia arquitectura de proyecto, pero sí han decidido que la mayoría de la UI se dibuje con UIKit y usar muchas de las librerías que ofrece Cocoa Touch en vez de las suyas, si ambas ofrecen la misma funcionalidad.

Sin duda un paso que demuestra, más todavía, que cuando una app tiene exigencias funcionales importantes (como el caso de Messenger) el desarrollo híbrido o con librerías de UI de terceros y tus propios componentes para todo, es una mala decisión estratégica pues ofreces una peor experiencia al usuario, más lenta, que ocupa más y que en los sistemas más antiguos no va a funcionar convenientemente.

Nuestras felicitaciones a Facebook por esta decisión y esperamos ansiosos que hagan lo mismo y pasen por Lightspeed al resto de sus apps. Un saludo y Good Apple Coding.

Fuente
Project Speedlight (Facebook)

Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Artículos relacionados

Botón volver arriba