Arreglar las métricas de arranque en frío de la aplicación descarriladas | de Akash Khunt | febrero 2023

Foto de Bart Christiaanse en Unsplash Estuve trabajando para un cliente durante las últimas semanas y uno de los mayores problemas que enfrentamos fue este Arranque lento en frío o TTID lento (Tiempo hasta la primera visualización). Puedes ver la métrica de inicio lento en frío de tu aplicación en Play Console. signos vitales de Android Sección.Definición tomada directamente de Play Console:

Arranque lento en frío – El porcentaje de sesiones diarias en las que los usuarios experimentaron al menos un tiempo de arranque en frío de más de cinco segundos. Esto se mide como el tiempo que transcurre desde que un usuario inicia su aplicación hasta que aparecen los primeros cuadros en la pantalla. Una sesión diaria se refiere a un día en que se utilizó su aplicación.

Antes de entrar en el problema, revisemos parte de la historia. Antes de Android 12, no había una forma coherente de implementar la pantalla de bienvenida. Los desarrolladores solían tener una actividad/fragmento dedicado con un tema personalizado con fondo o un tema personalizado con un fondo aplicado a la aplicación o, en el peor de los casos, solo una actividad/fragmento sin tema con fondo (lo que da como resultado una pantalla en blanco visible antes de que la aplicación dibuje su primer cuadro) Pero con Android 12, Google presentó API de pantalla de bienvenida Esto brindó una forma consistente de implementar la pantalla de inicio para que cada aplicación en su dispositivo tenga una experiencia similar al iniciar la aplicación. Además, no hay forma de evitar esta migración porque desde Android 12, el sistema siempre aplica la nueva pantalla de inicio para todas las aplicaciones. Si miras la parte de la migración en el documentos oficiales Parece un proceso muy simple, pero hay una trampa que no es visible a menos que lea la documentación con mucho cuidado o comprenda la implementación interna. En nuestro caso, antes de migrar a esta API de pantalla de inicio, nuestra métrica de lentitud de arranque en frío era muy similar a la de nuestros pares (según lo informado por Play Console). Pero después de migrar a la API de pantalla de bienvenida, nuestra métrica de arranque en frío lento aumentó en un múltiplo 😢.

NOTA: según la selección de la categoría de su aplicación, Play Console le mostrará la comparación relativa de la mayoría de las métricas, como ANR, el tamaño de la aplicación y los problemas de lanzamiento de la aplicación con sus competidores en el signos vitales de Android Sección.

Después de ver los resultados en Play Console, los desarrolladores entraron en pánico porque no encontramos ningún problema, incluso durante las pruebas de lanzamiento. Para verificar las métricas, tomamos todos los dispositivos que teníamos en nuestro inventario y comenzamos a medir el tiempo que tomaba mostrar la pantalla de inicio, pero incluso después de eso no vimos ningún problema, y ​​aquí es donde nos equivocamos. Lo que medimos fue el TTFD (tiempo hasta la visualización completa) y no el TTID. Lo que informa Play Console es TTID, que el sistema operativo Android recopila automáticamente. Como ejemplo, el sistema operativo Android imprime el registro real a continuación Cargar juego app.Displayed com.android.vending/.AssetBrowserActivity: +1s39ms Entonces, también comenzamos a examinar los registros de nuestra aplicación en diferentes dispositivos y verificamos que las métricas informadas por Play Console fueran correctas. Esto nos hizo pensar que debimos haber cometido un error en nuestra migración a la API de la pantalla de bienvenida y las métricas se habían descarrilado. Después de eso, revisamos todos los pasos mencionados en la documentación oficial varias veces para ver si nos perdimos algo, pero no encontramos ningún problema en nuestra implementación. Luego comenzamos a mirar más de cerca los documentos y vislumbramos una pista muy importante, es decir, una SplashScreen es una ventana y, por lo tanto, cubre una actividad.La referencia a ella Pantalla de bienvenida usa la ventana directamente Esto nos ayudó a conectar los puntos ya que TTID requiere que la aplicación dibuje su primer cuadro, pero dado que la API de la pantalla de bienvenida usa una ventana directamente, el dibujo del primer cuadro se retrasa esencialmente hasta que una vista se procesa usando Actividad, Fragmento o Diálogo. Para darle un poco de información, solíamos tener un SplashActivity dedicado donde mostrábamos el logotipo y el eslogan de nuestra marca, lo que aseguraba que el primer cuadro se renderizara en el propio SplashActivity. Entonces, incluso si hacemos una llamada de red u otra configuración antes de que el usuario llegue a HomeActivity, el tiempo de TTID será muy corto porque SplashActivity comenzó a mostrar la vista setContentView(). Pero después de la migración, nuestro primer renderizado de cuadros tuvo lugar en HomeActivity, que se vuelve visible después de que SplashActivity haya terminado su trabajo, lo que hace que el tiempo de TTID sea mucho más largo. Esto pasó porque no llamamos setContentView() en SplashActivity, ya que la API de SplashScreen ya muestra el contenido directamente en la ventana. También verificamos la implementación de la API para saber cómo funciona exactamente y descubrimos que inicialmente tiene 2 implementaciones, una para API 31+ (Android 12+) y otra para las API inferiores de Android.Pantalla de bienvenida Implementaciones Otro detalle de implementación muy importante es el establecerKeepOnScreenCondition() que actúa como un interruptor de límite entre el Pantalla de bienvenida y su propia representación de la interfaz de usuario a través de Actividad, Fragmento o Diálogo, ya que esto bloqueará la representación de la interfaz de usuario siempre que el Condición El predicado se evalúa como verdadero.establecerKeepOnScreenCondition() Implementación Ahora que finalmente comprendimos los aspectos internos de la API SplashScreen, refactorizamos nuestro código para acomodar nuestra TTID La métrica se ha restablecido al valor anterior 🙂.