¿Cómo construimos Facebook Lite para cada teléfono Android y redes?
Gautam Roy
Pusimos en marcha Facebook Lite, nuestra versión de Facebook para Android creada para mercados emergentes en junio de 2015. Hoy en día estamos muy contentos de anunciar que la aplicación ha alcanzado los 100 millones de usuarios activos mensuales. Es la versión de Facebook de más rápido crecimiento, llegando a 100 millones de usuarios en menos de nueve meses. Tiene un APK de menos de 1 MB de tamaño, es decir, puede ser descargada en cuestión de segundos en conexiones lentas. La aplicación es compatible con 56 idiomas y es la más popular en Brasil, India, Indonesia, México y Filipinas.
¿Por qué Facebook Lite?
Es importante para nosotros que todo el mundo tenga una gran experiencia al usar Facebook en su teléfono sin importar el dispositivo o la conexión disponibles. Debido a diversas circunstancias y tipos de hardware de red las experiencias pueden ser diferentes. Más de la mitad de la población mundial – al menos 1,6 billones de personas- todavía vive en lugares donde las redes de banda ancha móvil (3G y 4G) no están disponibles, lo que hace difícil el acceso a datos. Incluso para las personas en redes 3G, la intermitencia y la estabilidad de la conexión son a menudo los mayores obstáculos para tener una experiencia móvil óptima.
A través de nuestra investigación en mercados emergentes y al ver cómo las personas utilizan nuestras aplicaciones, sabemos que el costo de datos y el uso general de los mismos es extremadamente importante para la gente. Por esto mismo hemos estado trabajando en reducir el uso de datos para las personas en mercados emergentes cuando quieran acceder a Facebook. Además de mejorar la forma en que la aplicación de Facebook para Android corre en redes 2G, introdujimos Facebook Lite en 2015 para abordar esas limitaciones. Nuestro objetivo cuando la lanzamos era ofrecer una experiencia ligera, rápida y nativa de Facebook para quienes utilizan teléfonos Android y conexiones de red comunes en mercados emergentes.
Nuestros Objetivos
Nuestra tarea se redujo a las siguientes metas:
- Mantenernos por debajo del límite de tamaño de 1 MB APK
- Diseñar una interacción cliente-servidor para minimizar el uso de datos y que fuera funcional en redes 2G.
- Construir una aplicación que funcionara en Gingerbread y en dispositivos clase 2009.
Una Mirada a la arquitectura
Dadas las limitaciones, escogimos una arquitectura de servidor proxy con un cliente muy ligero. Utilizamos la exitosa arquitectura Facebook For Every Phone como punto de partida y lo adaptamos para Android.
Para alcanzar el tamaño ideal de APK, el APK-Lite no tiene el código de producto y los recursos de una aplicación típica de Android. El cliente Lite es una sola máquina virtual que proporciona diferentes capacidades para interactuar con el sistema operativo (Tales como: leer un archivo, abrir la cámara, crear una base de datos SQLite, etc.) y un motor de renderizado para conducir la interfaz de usuario de Android. El código de producto se escribe en el servidor y se expresa en términos de las capacidades del cliente. Los recursos son enviados desde el servidor según sea necesario y se guardan en caché, así se tiene una escalabilidad infinita para la construcción de un producto adicional sin saturar el APK.
La arquitectura Lite está diseñada para permitir que el lado del servidor haga el trabajo pesado, lo que permite que la aplicación funcione correctamente en dispositivos de muy baja potencia, como el LG Optimus ME. El servidor recupera los datos de los servicios de back-end de Facebook y los envía al cliente en forma de árbol de UI comprimido similar a un DOM, que es renderizado por el cliente. Como cliente habla con un único servidor en una sesión y el servidor puede enviar datos al cliente, además de los datos solicitados por el cliente.
En lugar de utilizar HTTPS, Lite utiliza un protocolo de mensaje personalizado a través de TLS (directamente sobre TCP). El intercambio de mensajes comprimido se lleva a cabo en la conexión persistente de TLS que establece el cliente al servidor para la sesión. Este diseño abre la puerta a una gran cantidad de optimizaciones que ayudan a la reducción de datos usados y el desempeño en redes 2G.
Lite tiene un conjunto de servidores de imágenes que se comunican con CDN y otros repositorios de imagen para permitir al servidor Lite enviar imágenes del tamaño exacto al cliente.
Alcanzando nuestras metas
APKs pequeños
Descargar una aplicación típica con 20 MB en APK puede tardar más de 30 minutos en una red 2G, y lo más probable es que la descarga falle antes de su finalización debido a fluctuaciones en la red. La restricción de nuestro tamaño en APK hace que sea más fácil para las personas el descargarlo. Esto también significa que las personas tienen que utilizar menos datos al actualizar la aplicación; por esto, tuvimos sumo cuidado al minimizar el tamaño del archivo APK de la aplicación. Como se ha mencionado antes, la aplicación está diseñada de modo que el cliente es una máquina virtual genérica y el código del producto está en el servidor. Los elementos que tienden a inflar los APK como las traducciones de cadenas y recursos PNG, se envían desde el servidor y son cacheados en vez de incorporados en el APK. En varios lugares, para ahorrar datos y tamaño utilizamos símbolos Unicode en lugar de recursos de imagen para representar iconos.
Optimizando para conexiones más lentas y mayor eficiencia de datos
El stack de redes de Lite optimiza para trabajar en redes 2G y reducir el uso de datos. Para lograr alcanzar un protocolo de cable extremadamente eficiente en bytes en lugar de utilizar HTTPS, Lite utiliza un protocolo de mensaje personalizado a través de TLS (directamente sobre TCP). Uno de los puntos de preocupación más grandes en una red 2G es que el establecimiento de conexión puede ser muy lento y puede tardar varios segundos. Como la mayor parte del tráfico Lite fluye a través de una sola conexión con el servidor, este punto de preocupación se mitiga en comparación.
Aprovechando el hecho de que el cliente habla repetidamente al mismo servidor, la compresión dinámica compartida de diccionarios se aplica a los mensajes en una sesión. Utilizamos la compresión LZMA2 para los mensajes de servidor a cliente debido a la gran relación de compresión, así como el bajo uso de recursos en descompresión y utilizamos DEFLATE para los mensajes entre cliente y servidor.
Herramientas como Augmented Traffic Control y el Laboratorio de Innovación de Internet.org-han sido vitales para que nuestros ingenieros simulen redes 2G y realicen pruebas en condiciones reales.
La mayor parte de uso de datos de la aplicación proviene de las imágenes y esta era un área en la que queríamos reducir el uso de datos por parte de la aplicación. Controlamos el tamaño de la imagen para poder controlar la cantidad de datos utilizados. El servidor Lite sabe exactamente el ancho de la altura y la densidad de la pantalla del cliente. En lugar de hablar al CDN directamente, el cliente Lite recibe imágenes del tamaño exacto sobre la misma conexión TCP desde el servidor Lite. El servidor puede ajustar la calidad JPEG de la imagen y el tamaño necesario de la misma en lugar de utilizar los pocos tamaños admitidos en el CDN. Las optimizaciones de calidad y tamaño del JPEG hacen una gran cantidad de las pequeñas imágenes; cuando se trata de imágenes grandes estas son fragmentadas para su transporte. El servidor de imágenes Lite también proporciona almacenamiento en caché y transcodificación de imágenes.
El hecho de que los clientes hablen a un servidor permite al servidor anticipar y enviar datos en algunas situaciones. Lite tiene un mecanismo de diferencias, por lo que verifica que el cliente haya recibido y sólo envía los cambios desde el servidor a la pantalla existente en lugar de toda la pantalla, ahorrando datos en el proceso. Por ejemplo, si se hace una actualización en el News Feed y el único cambio es el recuento de algunas historias, solo la diferencia es enviada al cliente. Por otra parte, si un nuevo comentario llega a una historia, el servidor puede actualizar el cliente con el comentario a través del mecanismo diferencial, incluso sin que el cliente solicite los datos.
Rendimiento en todos los dispositivos Android de mercados emergentes
Empezamos con el objetivo de funcionar correctamente en cada dispositivo de bajo rendimiento que todavía se pueda encontrar en los mercados emergentes. Un dispositivo de clase 2009 como el Samsung Galaxy Y viene con características muy restrictivas de 290 MB de RAM, procesador de 600 MHz y 180 MB de memoria interna. Nuestros datos también mostraron que también era importante dar soporte a Gingerbread. La arquitectura del cliente asegura la minimización de CPU, almacenamiento y uso de la RAM es el cliente. Las tareas de uso intensivo de recursos como el diseño de pantalla se llevan a cabo a través del servidor Lite, mientras que las animaciones e interacciones de interfaz de usuario son evitadas. Imágenes en caché y otros recursos son elegidas para permanecer por debajo de las decenas de MB y la arquitectura de cliente toma medidas para mantener un bajo uso de memoria y liberarla cuando esté en un segundo plano.
Estas opciones de diseño ayudan a Facebook Lite a alcanzar las mejores métricas de rendimiento en su clase como: acceso, tiempo de puesta en marcha, pull-to-refresh y los tiempos de carga de imágenes en redes con anchos de banda bajos e intermitentes.
Con Facebook Lite, nuestro objetivo es proporcionar la mejor experiencia de Facebook como sea posible para todos, sin importar el dispositivo o conexión. Esperamos que al compartir la forma en que construimos la aplicación animemos a más gente a construir para los próximos próxima billones que se conectarán en el futuro.
