Millisegundos hacen millones: Cómo y por qué acelerar su aplicación, desde el Playbook de InDrive

Hola a todos, mi nombre es Vladimir Pchelyakov, soy un ingeniero de iOS en inDrive. En este artículo, hablaré de cómo el tiempo de inicio de aplicaciones afecta a los ingresos de la empresa, cómo aceleramos nuestra aplicación, y cubriré las herramientas, los enfoques, así como las situaciones reales y, por supuesto, los resultados. Este artículo puede servir como un plan para cualquier equipo que quiera acelerar el tiempo de lanzamiento de la aplicación y el camino crítico del usuario, porque los problemas que hemos resuelto probablemente existan en la mayoría de los proyectos no optimizados. Para el contexto, en la aplicación inDrive puedes pedir un taxi como pasajero, o puedes tomar pedidos y hacer viajes como conductor. En este artículo, cubriré: Cómo el tiempo de inicio afecta a los ingresos de la empresa Tipos de aplicaciones de lanzamiento Hora de lanzamiento de la aplicación, TTI y Haga tiempo Valor promedio y porcentaje Qué afecta al tiempo de arranque Ciclo de aceleración de aplicaciones Las formas más efectivas de acelerar Herramientas, procesos y situaciones Resultados Cómo el tiempo de inicio afecta a los ingresos de la empresa La mayoría de las personas piensan que los desarrolladores están "demasiado obsesionados con las optimizaciones" que no traen ningún valor real, pero los datos muestran que acelerar las cosas por cientos de milisegundos puede afectar al negocio casi tanto como lanzar una nueva característica o entrar en un nuevo mercado. Investigaciones inéditas Dentro de la compañía, llevamos a cabo un gran estudio que mostró que acelerar el camino crítico del pasajero en 750 ms aumenta el número de pedidos en 1,5%.Si tu aplicación tiene millones de pedidos, simplemente porque la aplicación comenzó a mostrar la interfaz más rápido, obtienes decenas o incluso cientos de miles de pedidos adicionales por día! Investigación de Deloitte Deloitte publicó algunos números muy impresionantes: acelerar un sitio web móvil por 100 ms da +8.5% de conversión en comercio electrónico, y +10% en viajes. Además, algunas empresas deliberadamente ralentizaron la aplicación para ciertos grupos de usuarios para demostrar la hipótesis: cuanto más rápido se lanza la aplicación, más pedidos realiza el usuario.Y la hipótesis se confirmó.Si siempre ha querido trabajar en acelerar la aplicación pero no tuvo argumentos fuertes, ahora los tiene. Tipos de lanzamiento de aplicaciones El tipo de lanzamiento de la aplicación afecta directamente a la métrica, por lo que es importante decirlas por separado. Apple no proporciona una API directa para determinar el tipo de lanzamiento, por lo que cada equipo lo hace a su manera. Lanzamiento frío Carga completa de la aplicación desde cero, el tipo más lento de lanzamiento. El proceso de la aplicación no estaba presente, no hay caché, todo se inicia desde cero. Por ejemplo, este es el primer lanzamiento después de descargar de la tienda, o después de varias horas o más después de que la aplicación se descargara de la memoria. Cold Launch es la única métrica honesta que se puede comparar de versión en versión para sacar conclusiones. Lanzamiento caliente La aplicación se terminó recientemente, por lo que no existe ningún proceso. Sin embargo, partes de la aplicación permanecen parcialmente en la memoria - las cachés del sistema y la caché del linker dinámico todavía están calientes.El sistema debe engendrar un nuevo proceso y reiniciar el tiempo de ejecución, pero salta gran parte del trabajo de I/O necesario en un lanzamiento frío, lo que lo hace notablemente más rápido. Esto sucede cuando descargas la aplicación de la memoria y casi inmediatamente la abres de nuevo, se abre notablemente más rápido.Esta métrica depende demasiado de muchos factores, por lo que no funciona para nosotros. Lanzamiento caliente No hay nada que medir aquí, la aplicación se abre de inmediato y no pasa por ningún camino, ya está en el lugar correcto. Precalentado Suena útil, pero causa muchos problemas: tuvimos "lances" de 15 minutos y 10 horas, porque prewarm creó el proceso de antemano, y calculamos el tiempo de una variable que se creó en el archivo principal, y el usuario no lanzó la aplicación inmediatamente sino después de decenas de horas. At first we could not understand where the error was and how the launch time could be equal to hours, and it also badly corrupted the statistics, because other data is measured in ms, and metrics with hours really messed up the picture. Tenga cuidado, Prewarm puede arruinar completamente las estadísticas. Hora de lanzamiento de aplicaciones, TTI y HANG HORA Cuando empezamos a trabajar en acelerar las cosas, resultó que incluso los términos básicos eran entendidos de manera diferente por todos. App Hora de lanzamiento Importante: no se trata de la pantalla de lanzamiento del sistema, que aparece de inmediato, sino de nuestro controlador de vista raíz: el momento en que se completa la vinculación de la biblioteca, se han terminado los métodos de AppDelegate, se crea el controlador de vista y se ha activado el método de vistaDidAppear. TTI (Tempo para interactuar) También puede llamarlo el camino crítico, porque afecta al comienzo de la creación o procesamiento de un pedido, y es lo que afecta a las métricas de negocio. Por ejemplo, en nuestro caso: Para el pasajero - cuando aparece el mapa y el usuario puede tocar "Dónde ir". cuanto más rápido esto suceda, más probable es que el pasajero cree una orden. Para el conductor - cuando se muestra la pantalla con las órdenes de los pasajeros.Cuanto más rápido esto suceda, más probable es que el conductor vea y tome una orden a tiempo. Condenar el tiempo Este es el momento en que la interfaz "congela" - se toca un botón, pero la acción no sucede de inmediato, por ejemplo, tarda un segundo. Usualmente esto es el resultado de pesados cálculos en el hilo principal. Y sí, el tiempo de la pendiente afecta directamente a TTI, porque las congelaciones aparecen no solo cuando el usuario toca un botón, sino también cuando algo en el camino crítico ocupa el hilo principal y la interfaz de usuario se congela durante la renderización. Por ejemplo, una pantalla desliza no en 300 ms, sino en más de un segundo. Valor promedio y porcentaje Después de recopilar datos de millones de usuarios, es necesario interpretar de alguna manera estas métricas, y hay al menos 2 opciones: valor medio y percentiles. Por qué el promedio no da la imagen completa La media parece conveniente y fácil de calcular, pero a veces es difícil sacar conclusiones de ella. Aquí un ejemplo: Tenemos 5 usuarios y los tiempos de lanzamiento para 5 usuarios = 1, 2, 3, 9, 12 segundos. El promedio es de 5,4 segundos. Pero esto no refleja la realidad: 3 de cada 5 usuarios lanzan la aplicación en 3 segundos o más rápido. 2 usuarios son muy lentos y distorsionan toda la estadística. Y si un lanzamiento se registra como "1 hora" (o el infinito viene debido a un error métrico), la media se vuelve completamente sin sentido. Cómo funcionan los percentiles y por qué son más precisos Un porcentaje muestra cuánto tiempo necesita la aplicación para que X por ciento de los usuarios se ajusten dentro de ese tiempo. En los mismos 5 valores: 1, 2, 3, 9, 12 El 50o percentil = 3 segundos → la mitad de los usuarios lanzan la aplicación en 3 segundos o más rápido. El 80o percentil = 9 segundos → 80% de los usuarios ven la aplicación en ≤ 9 segundos. El 99o percentil = 12 segundos → los usuarios “más pesados”: dispositivos débiles, Internet pobre. Además de la masa principal de usuarios, siempre tratamos de acelerar el 95o percentil, para mejorar la vida de las personas cuya aplicación carga más tiempo, probablemente debido al dispositivo o la mala Internet en su país. Por cierto, voy a señalar que operamos en 47 países de todo el mundo, y tenemos muchos países donde muchos usuarios tienen dispositivos débiles y mala Internet inestable. Qué influye en el tiempo de inicio Veamos las principales áreas que pueden ralentizar significativamente la aplicación. Requerimientos de red El número de solicitudes en la cadena, el orden de las solicitudes, la capacidad de caché, la velocidad de Internet. Iniciación de App En la puesta en marcha, ocurren un gran número de operaciones: vinculación de bibliotecas, lanzamiento del tiempo de ejecución de Objective-C, reflexión rápida, inicialización del SDK (análisis, anuncios, Firebase), carga de dylib, dild, rebase, vinculación de símbolos, inicialización del contenedor DI. Principales amenazas Cualquier operación pesada en el hilo principal aumenta TTI: decodificación JSON de modelos grandes y complejos, llamadas sincronizadas, cálculos innecesarios "en el inicio" porque era conveniente, incluso si se pueden mover en otro lugar. Características del dispositivo No podemos acelerar los dispositivos viejos, pero podemos adaptar la lógica para ellos o reducir la cantidad de carga. Un hecho interesante: para países con dispositivos débiles y internet lenta, Meta lanzó la aplicación Facebook Lite.La aplicación Facebook Lite es pequeña, lo que le permite ahorrar espacio en su teléfono y usar Facebook en condiciones 2G. Ciclo de aceleración de aplicaciones Para acelerar la aplicación, es necesario medir y mejorar de forma sistemática, no "corregir las cosas a simple vista". Nuestro ciclo es así: Mark up the app for data collection App Launch Splash TTI of all verticals (critical paths) Steps of the critical path Collect and visualize data Raw telemetry data Long-term storage, Big Query Desarrollador Xcode Find places of slowdown Instruments: LaunchTime, Profile, Network, Hangs Timeline analysis Fix problems Restructure requests Cache Offload the main thread Remove everything unnecessary from startup Correr los experimentos Compara los resultados, verifica las hipótesis Control startup time before a new release UI-performance tests on CI, alerts on degradations De esta manera, de versión en versión la aplicación se vuelve más rápida, más estable y más previsible.Por supuesto, el marcado y la visualización no se hacen en cada ciclo. Las formas más efectivas de acelerar El mayor efecto proviene de unos pocos pasos obvios pero sistemáticos: Cambiar el orden de las solicitudes de red Requisitos de Caching de Red Descargar el thread principal Eliminar las computadoras pesadas en la startup Estos son exactamente los cambios que nos dieron la mejora máxima de TTI con mínimo esfuerzo y riesgo de romper algo. Herramientas, procesos y situaciones En este capítulo te contaré sobre nuestras herramientas y pasaré por varios ejemplos reales, en los que mostraré cómo una herramienta complementa a otra y cómo se ve cada una de ellas. La optimización es imposible sin mediciones.Primero debes marcar el proyecto.Dentro de nuestra aplicación, las etapas clave de lanzamiento están marcadas: AppLaunchTracker – Lanzamiento de la aplicación hasta que aparece el primer controlador. SplashTracker - el tiempo de diferentes etapas de la pantalla de flash (obtención de funciones, perfil, determinación de la ubicación). CriticalPathTracker – el camino crítico del usuario con descomposición de pasos y el tiempo entre ellos VerticalsTTITracker — TTI para cada producto vertical. Todos los datos se visualizan en gráficos y dashboards (Kibana, Redash). Además, hemos establecido procesos: Comparación de versiones por rendimiento Pruebas de rendimiento en CI Alertas de degradación reuniones semanales regulares y una hoja de ruta para acelerar Utilizamos herramientas nativas: Xcode Instruments - Tiempo de lanzamiento, perfil, red, agujeros Xcode Organizer - Hangs, lanzamiento de la aplicación También recomiendo crear un mapa de ruta para entender el orden de ejecución de tareas. Nuestro se ve así: Veamos todo en acción. Trabajar con la orden de solicitudes de red Una de las formas más eficaces de acelerar TTI es reordenar el orden de las solicitudes de red y ejecutar solicitudes independientes en paralelo. Para el análisis usamos Xcode Instruments → Network, donde puede ver claramente qué solicitudes están pasando y sus dependencias. Lo que hicimos: El flujo específico Capturar un rastro de solicitudes de red los momentos en que las pantallas aparecieron en él De esta manera se hizo claro qué solicitudes realmente bloquean la interfaz de usuario de mostrar.Después de eso nos dirigimos al equipo de producto, mostramos los hallazgos, discutimos cómo optimizar el orden de las solicitudes de red, y luego creamos tareas. Caso sencillo Una solicitud de la que dependía la primera pantalla fue enviada demasiado tarde. Se podría mover al inicio del ciclo de vida de la pantalla, porque en realidad no tenía dependencia. Como resultado, el usuario vería la interfaz lista antes, lo que significa TTI más rápido. En Android encontramos un clásico "escalera": toggles → driver config → razones → ofertas Todas las solicitudes fueron estrictamente secuenciales.Sólo después comenzó la carga de pedidos. La solución: Combine varias solicitudes en una o ejecute solicitudes en paralelo si no hay dependencias. Hay una posibilidad de que los desarrolladores escribieron esta secuencia hace mucho tiempo por conveniencia u otras razones, y se mantuvo así porque no molestó a nadie. Un caso más complejo: Conductor de alimentación Originalmente, antes de cargar órdenes, se ejecutó una cadena de varias solicitudes: Establecimientos generales de taxi Configuración del taxista Instalaciones de Correos Todos ellos fueron secuenciales, y cada solicitud ralentizó el TTI, especialmente en internet lenta esto fue notable, ya que cada una de las tres solicitudes aumentó el tiempo total de camino. Nos juntamos con el equipo y simplificamos significativamente el esquema: Las solicitudes independientes se lanzaron en paralelo combinar dos configuraciones de solicitudes en una sola solicitud La solicitud de pedidos comenzó justo después de recibir los datos mínimos necesarios.Y sólo en casos raros tendríamos que esperar a una solicitud paralela, pero incluso entonces, se lanzó en paralelo con la primera, no desde cero después de la primera. Como resultado: instead of three sequential requests, there was one in the best case in the worst case — one fewer request than before Después de eso, realizamos un experimento. TTI acceleration of 0.5–0.8 seconds on average at the 95th percentile — up to 2 seconds Timelines Los gráficos por versión muestran que la aplicación se hizo más rápida o más lenta, pero no responden a la pregunta por qué. Para resolver este problema utilizamos líneas de tiempo - una descomposición de TTI por etapas. Es decir, recopilamos todas las etapas principales del camino crítico: Lanzamiento de la app delegate methods Hacer trampas getting location getting profile Navegación al módulo module initialization screen rendering This allows us to see precisely: ¿Cuál es la etapa que aceleró Dónde se produce una regresión what exactly affected the final TTI Son líneas de tiempo las que nos permiten realizar con seguridad grandes cambios y comprender sus consecuencias.Esto también se convirtió en la base para la toma de decisiones y la búsqueda de regresiones o lugares para la aceleración - las piezas más largas nos interesan más. Este es un muy buen nivel de detalle, pero planearlos para ser detallados y de alta calidad de inmediato, porque cambiarlos más tarde será incómodo, y comparar gráficos con una descomposición anterior será imposible. Informe de lanzamiento de la aplicación y eliminación del tifón Xcode App Launch Report muestra qué código ralentiza el lanzamiento. En nuestro caso: El contenedor DI Typhoon tomó ~30% del tiempo de lanzamiento varias de sus inicializaciones aparecieron consistentemente en los lugares más lentos Después de la destrucción del tifón: The first stage of launch was reduced by almost 3 times. From ~1.3 seconds to ~445 ms in version 5.122. On the timeline you can see how the first stage sped up 3 times, but the overall TTI became larger. If we did not have the breakdown, we would not have understood what was happening and how removing DI could slow everything down like that. But it turned out that along with the speedup, a bug made it into this version. I will talk about it in the next section. Hang Rate Ahora podemos ver cómo una herramienta complementa a otra: las líneas de tiempo dieron una imagen de que el lanzamiento se aceleró, pero algo más rompió y afectó a varias etapas iniciales. It showed that the new version of the app started slowing down significantly. Something was blocking the main thread. The tool shows that 92% of hang time was coming from a third-party SDK. Además, señala la línea específica. La razón — una solicitud de red de una biblioteca de terceros en el hilo principal con una espera de respuesta del servidor de hasta 10 segundos.El problema sólo se reprodujo en la Internet lenta, por lo que pasó desapercibido por nuestros testers y desarrolladores, ya que todo el mundo tiene Internet rápido en ordenadores portátiles y dispositivos. We filed an issue with the library, and after the fix, Hang Rate returned to normal. Investigación De vez en cuando perfilamos el camino principal del usuario ejecutándolo en diferentes dispositivos, y parece aproximadamente así. Here we found micro-freezes, and we immediately see which stages of the critical path they affect. Resultó que cierto código para trabajar con la ubicación del usuario estaba cargando pesadamente el hilo principal. Fixamos el problema, desaparecieron las micro-congelaciones aleatorias, y la tasa de Hang se hizo aún más baja. Además, la fase de captura de perfil se redujo de 480 ms → 21 ms. Pruebas de rendimiento en CI Encontrar problemas y resolverlos es bueno, pero aún mejor es aprender sobre una desaceleración antes de que la aplicación vaya a la App Store, e incluso antes de que comience la regresión de la versión. We made a native UI test that goes through a real scenario on the production server and sends the same metrics as for the production version. It works like this: pasa por el camino real del usuario a la pantalla clave runs at night ejecuta varias veces sin molestias de red Enviar métricas a telemetría Si el tiempo supera el umbral, una alerta viene a Slack. Esto da la posibilidad de capturar un problema antes del lanzamiento, que es actualmente el elemento más importante de todo el sistema.También vemos todas las mismas líneas de tiempo, y la prueba está lo más cerca posible de las condiciones reales de uso. Also, to be sure that our caching works well, we added internet throttling on CI — first the test runs at normal speed, everything is cached, then the same thing but on 3G slow internet. En mi opinión, este es uno de los componentes más importantes de trabajar en la velocidad de arranque - no dejar que tal versión vaya a la liberación. A continuación, queremos ejecutar esto en cada Pull Request de forma asíncrona, para no bloquear la fusión, ya que las pruebas de rendimiento se ejecutan en el mismo Mac Mini para mantener las mediciones honestas, y con un gran equipo habría una cola. Comparación de versiones Antes de agregar una nueva dependencia al proyecto, tenemos un proceso de comparación de versiones, una instrucción para el desarrollador sobre cómo comparar la versión actual de la aplicación y la versión con la nueva dependencia añadida. Una vez durante tal ejecución, vimos un aumento de 250 ms en el inicio de la aplicación y decidimos implementar esta característica sólo temporalmente y sólo a una parte de los usuarios, para no ralentizar la aplicación. Toggle Caching Veamos el último caso: mirando a las líneas de tiempo, una de las etapas más largas en nuestro camino es la obtención de trampas de características (700 ms), las barras negras en el gráfico. Implementamos el caché progresivo: si los cambios son más frescos que un tiempo determinado, utilizamos el caché. Naturalmente, ejecutamos un experimento A/B que muestra la mejora. El resultado: la etapa de cambio se redujo en las versiones 126–127 TTI se convirtió en usuarios notablemente más rápidos que abrieron la aplicación con frecuencia y aquellos con internet lenta se beneficiaron más. The chart shows driver toggles. It became so small because they open the app very frequently. Luces de tráfico y control de estado rápido Cuando hay demasiadas métricas, necesitas agregados. usamos "luces de tráfico". Usan fórmulas complejas de agregación por día, evaluación automática de mejoras y degradaciones.No describiré todo esto ahora ya que tomaría mucho tiempo, pero globalmente es todo para una respuesta rápida a la pregunta: "qué pasó con la versión". Por ejemplo, en una de las versiones hubo un impulso excepcional visible en TTI - el resultado de la descarga del hilo principal. Resultados finales Veamos los resultados de más de medio año de trabajo. Desde principios del año hasta septiembre (versiones 115 → 140): el tiempo desde el lanzamiento de la aplicación hasta la transición al producto vertical (50o percentil) se redujo en casi 3 veces: 2.8 sec → 1 sec Porcentaje de usuarios con lanzamiento más rápido que 5 segundos: 58% → 84% Para el 75 por ciento de los usuarios, la aplicación se lanza en 4 segundos, y era de 6,2 segundos. Al mismo tiempo, las mejoras ocurrieron gradualmente de versión en versión, con la excepción de un pico de bug, que rápidamente capturamos gracias a las herramientas.El porcentaje de usuarios que ejecutan la aplicación en frío comienza más rápido que 5 segundos. Conclusión Acelerar la aplicación no es una optimización de una vez, sino un proceso continuo: Metrología clara Horarios comprensibles Control automático antes de la liberación Análisis y experimentos regulares Y lo más importante - acelerar por cientos de milisegundos realmente afecta al negocio. no teóricamente, sino en porcentajes reales de pedidos.