La prueba de rendimiento de la UI le garantiza que su aplicación no solo cumpla con los requisitos funcionales sino que la interacción del usuario con su aplicación sea fluida y funcione constantemente a 60 fotogramas por segundo (Why 60fps?) sin disminuir o retrasar fotogramas (lo que llamamos “jank”). Este documento explica las herramientas disponibles para medir el rendimiento de la UI y establece un enfoque para integrar las medidas de rendimiento de la UI en sus prácticas de prueba.
Para mejorar el rendimiento, primero necesita poder medir el rendimiento de su sistema y, luego, diagnosticar e identificar los problemas que puedan surgir debido a las varias secciones de su canalización.
dumpsys es una herramienta de Android que se ejecuta en el dispositivo y vuelca información útil sobre el estado de los servicios del sistema. Al pasar el comando gxinfo a dumsys, se obtiene una salida de logcat con información de rendimiento en relación con los fotogramas de animación que ocurren durante la fase de grabado.
> adb shell dumpsys gfxinfo <PACKAGE_NAME>
Este comando puede crear múltiples variantes diferentes de datos del intervalo del fotograma.
En la versión preliminar de Android M, el comando emite un análisis adicional a logcat sobre los datos del fotograma. Estos datos se recopilan en toda la duración del proceso. Por ejemplo:
Stats since: 752958278148ns Total frames rendered: 82189 Janky frames: 35335 (42.99%) 90th percentile: 34ms 95th percentile: 42ms 99th percentile: 69ms Number Missed Vsync: 4706 Number High input latency: 142 Number Slow UI thread: 17270 Number Slow bitmap uploads: 1542 Number Slow draw: 23342
Estas estadísticas de alto nivel representan, en un nivel avanzado, el rendimiento de representación de la aplicación y su estabilidad en muchos fotogramas.
La versión preliminar de Android M ofrece un nuevo comando para gfxinfo, es framestats que brinda información extremadamente detallada sobre el intervalo del fotograma reciente, de manera que usted puede localizar y depurar errores de manera más precisa.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats
Este comando emite información sobre el intervalo del fotograma, medida en nanosegundos, de los últimos 120 fotogramas que produjo la aplicación. A continuación, se muestra un ejemplo sin formato de adb dumpsys gxinfo <PACKAGE_NAME> framestats:
0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, 0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, 0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, 0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683,
Cada línea de esta salida representa un fotograma producido por la aplicación. Cada línea tiene un número fijo de columnas que describen el tiempo transcurrido en cada etapa de la canalización de producción de fotogramas. En la siguiente sección, se describe este formato en detalle y se explica qué representa cada columna.
Debido a que el bloque de datos se emite en formato CSV, es muy sencillo pegarlo en su herramienta de hoja de cálculo preferida, o recopilar y redistribuir con un script. La siguiente tabla explica el formato de las columnas de los datos de salida. Las marcas de tiempo están en nanosegundos.
Puede utilizar esta información de distintas maneras. Un método de visualización simple pero eficaz es el histograma que muestra la distribución de los tiempos del fotograma (FRAME_COMPLETED - INTENDED_VSYNC) en distintos bloques de latencia; vea la siguiente figura. Este gráfico indica brevemente que la mayoría de los fotogramas estuvieron muy bien, es decir, por debajo del límite de 16 ms (marcado en rojo). Sin embargo, algunos fotogramas estuvieron muy por arriba del límite. En el histograma, podemos observar los cambios con el correr del tiempo para ver la creación de los cambios totales o los nuevos valores atípicos. También puede graficar la latencia de entrada, el tiempo dedicado al diseño o cualquier otra medición interesante similar sobre las marcas de tiempo en los datos.
Si, en las Opciones de Desarrollador, Profile GPU rendering se configura en In adb shell dumpsys gfinfo, el comando adb shell dumpsys gfxinfo emite sobre el tiempo de los 120 fotogramas más recientes y los agrupa en algunas categorías diferentes con valores separados por tabulación.
Esta información puede resultar útil para indicar qué partes de la canalización del dibujo podrían funcionar lento en un nivel alto.
Al igual que framestats, es muy sencillo pegar esta información en su herramienta de hoja de cálculo preferida, o recolectar y redistribuir con un script. El siguiente gráfico detalla dónde pasaron tiempo muchos de los fotogramas generados por la aplicación.
El resultado de ejecutar gfxinfo, copiar la salida, pegar en una aplicación de hoja de cálculo y graficar la información en forma de barras apiladas.
Cada barra vertical representa un fotograma de animación, su altura representa la cantidad de milisegundos que le llevó calcular ese fotograma de animación. Cada segmento de color de la barra representa una etapa diferente de la canalización de representación, de manera que usted pueda observar qué partes de su aplicación pueden estar creando un cuello de botella. Para obtener más información sobre la canalización de representación y cómo optimizarla, consulte el video Invalidations Layouts and Performance.
Los intervalos de framestats y del fotograma simple recopilan datos durante un período muy breve: aproximadamente dos segundos que valen la pena representar. Para poder controlar este período con precisión, por ejemplo para limitar los datos a una animación en particular, puede restablecer todos los contadores y agregar los datos recopilados.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset
Esto se puede usar junto con los comandos de volcado para recopilar y restablecer a una cadencia normal a fin de capturar continuamente períodos de fotogramas de menos de dos segundos.
La identificación de regresiones es un buen primer paso para localizar los problemas y mantener la aplicación funcionando correctamente. Sin embargo, dumpsys solo identifica la existencia y la gravedad relativa de los problemas. Usted todavía debe diagnosticar la causa particular de los problemas de rendimiento y encontrar las soluciones adecuadas. Para esto, es sumamente recomendable que utilice la herramienta systrace.
Para obtener más información sobre el funcionamiento de la canalización de representación de Android, los problemas comunes que puede encontrar y cómo solucionarlos, es posible que algunos de los siguientes recursos le resulten útiles:
Un enfoque para realizar la prueba de rendimiento de la UI es solicitar a un evaluador que realice una serie de operaciones de usuario en la aplicación objetivo para identificar visualmente jank, o bien, pasar mucho tiempo utilizando un enfoque basado en alguna herramienta para encontrar jank. Sin embargo, este enfoque manual tiene sus riesgos, la habilidad humana para percibir cambios en los índices de los fotogramas varía de manera alarmante. Además, este proceso lleva mucho tiempo, es tedioso y propenso a errores.
Un método más eficiente es registrarse y analizar las mediciones de rendimiento clave a partir de pruebas automatizadas de UI. Android M Developer Preview incluye nuevas capacidades de registro que facilitan la determinación de la cantidad y gravedad de jank en las animaciones de su aplicación y pueden utilizarse para crear un proceso estricto a fin de determinar su rendimiento actual y realizar un seguimiento de futuros objetivos de rendimiento.
Este artículo lo guía a través de un enfoque recomendado para utilizar esa información a fin de automatizar su prueba de rendimiento.
Esto se divide básicamente en dos acciones clave. Primero, identificar qué está probando y cómo lo prueba. Segundo, configurar y mantener un entorno de prueba automatizado.
Antes de comenzar con las pruebas automatizadas, es importante establecer algunas decisiones de alto nivel para entender correctamente el espacio de prueba y las necesidades que puede tener.
Recuerde que el usuario visualiza el rendimiento negativo cuando una animación fluida se interrumpe. Por lo tanto, al identificar qué tipo de acciones de UI desea probar, se recomienda centrarse en aquellas animaciones clave que el usuario ve más o que son más importantes para su experiencia. Por ejemplo, a continuación, se mencionan situaciones comunes que es útil identificar:
Trabaje con los ingenieros, diseñadores y gerentes de productos de su equipo a fin de priorizar estas animaciones clave para la cobertura de la prueba.
Desde un nivel alto, puede ser crítico identificar sus metas de rendimiento específicas y concentrarse en escribir pruebas y recopilar datos sobre ellas. Por ejemplo:
Para todas estas situaciones, es recomendable realizar un seguimiento que muestre el rendimiento en múltiples versiones de su aplicación.
El rendimiento de la aplicación varía según el dispositivo en el que se ejecuta. Algunos dispositivos pueden tener menos memoria, GPU menos potentes o CPU más lentos. Esto significa que las animaciones que funcionan bien en un conjunto de hardware pueden no hacerlo en otros, o peor, pueden provocar un cuello de botella en diferentes secciones de la canalización. Por lo tanto, para justificar esta variación en lo que un usuario puede ver, seleccione una serie de dispositivos, tanto de alta gama como de baja, tablets, etc., en los que ejecutará las pruebas. Busque variedad en rendimiento de CPU, memoria RAM, resolución de pantalla, tamaño, etc. Las pruebas exitosas en un dispositivo de alta gama pueden fallar en uno de baja gama.
Algunos conjuntos de herramientas, como UI Automator y Espresso, están diseñados para ayudar a automatizar el desplazamiento de un usuario por su aplicación. Estos son marcos simples que imitan la interacción del usuario con el dispositivo. Para utilizar estos marcos, debe crear con éxito scripts únicos que se ejecuten en un conjunto de acciones de usuarios y reproducirlos en el dispositivo en sí.
Al combinar estas pruebas automatizadas junto con dumpsys gfxinfo, puede crear rápidamente un sistema reproducible que le permite ejecutar una prueba y medir la información de rendimiento de esa condición particular.
Una vez que pueda ejecutar una prueba de UI y una canalización para recopilar datos de una sola prueba, el próximo paso importante es elegir un marco que pueda ejecutar esa prueba muchas veces en múltiples dispositivos y agregar los datos de rendimiento resultantes para que su equipo de desarrollo los analice mejor.
Vale la pena mencionar que los marcos para pruebas de UI (como UI Automator) se ejecutan directamente en el emulador/dispositivo objetivo. A la recopilación de información de rendimiento realizada por dumpsys gfxinfo la impulsa un equipo de host que envía comandos por ADB. Para ayudar a unir la automatización de estas entidades separadas, se diseñó el marco MonkeyRunner. Un sistema de scripts que se ejecuta en su equipo de host y que puede emitir comandos a un conjunto de dispositivos conectados y recibir datos de ellos.
Al crear un conjunto de scripts para la automatización adecuada de las pruebas de rendimiento de UI, usted podrá, como mínimo, utilizar MonkeyRunner para realizar con éxito las siguientes tareas:
Una vez que se identifican los patrones de problemas o las regresiones, el paso siguiente es identificar y aplicar la solución. Si su marco de pruebas automatizadas preserva detalles precisos del intervalo para los fotogramas, puede ayudarlo a investigar cambios sospechosos de código o diseño (en el caso de una regresión), o delimitar la parte del sistema que está analizando al cambiar a una investigación manual. Para realizar una investigación manual, systrace es un buen lugar para comenzar, ya que muestra información precisa sobre cada etapa de la canalización de representación, cada subproceso y núcleo del sistema, además de cualquier marca de evento personalizada que usted defina.
Es importante mencionar las dificultades para obtener y medir los intervalos que son producto del rendimiento de la representación. Estos números son, por naturaleza, no deterministas y, a menudo, fluctúan según el estado del sistema, la cantidad de memoria disponible, el límite térmico y la última vez que un rayo solar tocó el área de la tierra donde se encuentra. El punto es que puede ejecutar la misma prueba dos veces y obtener números apenas diferentes que pueden estar cerca pero no ser iguales.
Para recopilar y definir datos correctamente de esta manera, deberá ejecutar la misma prueba muchas veces y acumular los resultados como un promedio o un valor promedio (para que resulte más fácil, lo llamaremos un “lote”). Esto le ofrece una aproximación estimada del rendimiento de la prueba, sin requerir intervalos exactos.
Los lotes se pueden usar entre cambios de código para verificar el impacto relativo que esos cambios tienen en el rendimiento. Si el índice de fotograma promedio para el lote previo al cambio es que el lote después del cambio, entonces, generalmente está en presencia de un incremento general en relación con el rendimiento para ese cambio particular.
Esto significa que cualquier prueba automatizada de UI que lleve a cabo debería tener en cuenta este concepto, además de justificar cualquier anomalía que pudiera surgir durante una prueba. Por ejemplo, si el rendimiento de su aplicación disminuye repentinamente debido a algún problema con el dispositivo (que no sea provocado por la aplicación), deberá volver a ejecutar el lote para obtener intervalos menos caóticos.
Entonces, ¿cuántas veces debe ejecutar una prueba para que los resultados sean significativos? El mínimo debe ser 10 veces y con números más altos, como 50 o 100, para obtener resultados más precisos (por supuesto, ahora cambia el tiempo por la precisión).