Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Evaluación del desempeño

Utilice Simpleperf para evaluar el rendimiento de un dispositivo. Simpleperf es una herramienta de creación de perfiles nativa para aplicaciones y procesos nativos en Android. Use CPU Profiler para inspeccionar el uso de la CPU de la aplicación y la actividad de los subprocesos en tiempo real.

Hay dos indicadores de rendimiento visibles para el usuario:

  • Rendimiento predecible y perceptible . ¿La interfaz de usuario (UI) descarta fotogramas o se procesa constantemente a 60FPS? ¿El audio se reproduce sin artefactos o estallidos? ¿Cuánto tiempo transcurre entre que el usuario toca la pantalla y el efecto que se muestra en la pantalla?
  • Tiempo necesario para operaciones más largas (como abrir aplicaciones).

El primero es más notorio que el segundo. Los usuarios normalmente notan jank, pero no podrán determinar el tiempo de inicio de la aplicación de 500ms frente a 600ms a menos que estén mirando dos dispositivos uno al lado del otro. La latencia táctil se nota de inmediato y contribuye significativamente a la percepción de un dispositivo.

Como resultado, en un dispositivo rápido, la canalización de la interfaz de usuario es lo más importante del sistema además de lo que es necesario para mantener la canalización de la interfaz de usuario funcional. Esto significa que la canalización de la IU debe adelantarse a cualquier otro trabajo que no sea necesario para una IU fluida. Para mantener una interfaz de usuario fluida, la sincronización en segundo plano, la entrega de notificaciones y trabajos similares deben retrasarse si se puede ejecutar el trabajo de la interfaz de usuario. Es aceptable intercambiar el rendimiento de operaciones más largas (tiempo de ejecución HDR +, inicio de la aplicación, etc.) para mantener una interfaz de usuario fluida.

Capacidad vs jitter

Al considerar el rendimiento del dispositivo, la capacidad y la fluctuación son dos métricas significativas.

Capacidad

La capacidad es la cantidad total de algún recurso que posee el dispositivo durante un período de tiempo. Pueden ser recursos de CPU, recursos de GPU, recursos de E / S, recursos de red, ancho de banda de memoria o cualquier métrica similar. Al examinar el rendimiento de todo el sistema, puede ser útil abstraer los componentes individuales y asumir una única métrica que determina el rendimiento (especialmente cuando se ajusta un nuevo dispositivo porque las cargas de trabajo que se ejecutan en ese dispositivo probablemente sean fijas).

La capacidad de un sistema varía según los recursos informáticos en línea. Cambiar la frecuencia de CPU / GPU es el medio principal para cambiar la capacidad, pero hay otros, como cambiar el número de núcleos de CPU en línea. En consecuencia, la capacidad de un sistema se corresponde con el consumo de energía; el cambio de capacidad siempre da como resultado un cambio similar en el consumo de energía.

La capacidad requerida en un momento dado está determinada de manera abrumadora por la aplicación en ejecución. Como resultado, la plataforma puede hacer poco para ajustar la capacidad requerida para una carga de trabajo determinada, y los medios para hacerlo se limitan a mejoras en el tiempo de ejecución (marco de Android, ART, Bionic, compilador / controladores de GPU, kernel).

Estar nervioso

Si bien la capacidad requerida para una carga de trabajo es fácil de ver, el jitter es un concepto más nebuloso. Para una buena introducción al jitter como un impedimento para los sistemas rápidos, consulte EL CASO DEL DESEMPEÑO DEL SUPERCOMPUTADOR QUE FALTA: LOGRAR UN RENDIMIENTO ÓPTIMO EN LOS 8.192 PROCESADORES DE ASCl Q. (Es una investigación de por qué la supercomputadora ASCI Q no logró el rendimiento esperado y es una excelente introducción a la optimización de sistemas grandes).

Esta página utiliza el término jitter para describir lo que el documento ASCI Q llama ruido . La fluctuación es el comportamiento aleatorio del sistema que evita que se ejecute un trabajo perceptible. A menudo es un trabajo que debe ejecutarse, pero es posible que no tenga requisitos de tiempo estrictos que hagan que se ejecute en un momento determinado. Debido a que es aleatorio, es extremadamente difícil refutar la existencia de jitter para una carga de trabajo determinada. También es extremadamente difícil probar que una fuente conocida de jitter fue la causa de un problema de rendimiento en particular. Las herramientas que se utilizan con más frecuencia para diagnosticar las causas de la fluctuación (como el rastreo o el registro) pueden introducir su propia fluctuación.

Las fuentes de fluctuación experimentadas en las implementaciones de Android en el mundo real incluyen:

  • Retraso del programador
  • Controladores de interrupciones
  • El código del controlador se ejecuta durante demasiado tiempo con la preferencia o las interrupciones deshabilitadas
  • Softirqs de larga duración
  • Contención de bloqueo (aplicación, marco, controlador de kernel, bloqueo de carpeta, bloqueo de mmap)
  • Contención del descriptor de archivo donde un subproceso de baja prioridad mantiene el bloqueo en un archivo, evitando que se ejecute un subproceso de alta prioridad
  • Ejecutar código crítico de la interfaz de usuario en colas de trabajo donde podría retrasarse
  • Transiciones inactivas de CPU
  • Inicio sesión
  • Retrasos de E / S
  • Creación de procesos innecesarios (por ejemplo, difusiones CONNECTIVITY_CHANGE)
  • Error de caché de página causado por memoria libre insuficiente

La cantidad de tiempo necesaria para un período determinado de fluctuación puede disminuir o no a medida que aumenta la capacidad. Por ejemplo, si un controlador deja las interrupciones desactivadas mientras espera una lectura de un bus i2c, tomará una cantidad fija de tiempo independientemente de si la CPU está a 384MHz o 2GHz. El aumento de la capacidad no es una solución viable para mejorar el rendimiento cuando se trata de fluctuaciones. Como resultado, los procesadores más rápidos no suelen mejorar el rendimiento en situaciones de fluctuación limitada.

Finalmente, a diferencia de la capacidad, la fluctuación está casi enteramente dentro del dominio del proveedor del sistema.

Consumo de memoria

El consumo de memoria se atribuye tradicionalmente al bajo rendimiento. Si bien el consumo en sí no es un problema de rendimiento, puede causar fluctuaciones a través de una sobrecarga de eliminación de memoria baja, reinicios del servicio y eliminación de caché de página. Reducir el consumo de memoria puede evitar las causas directas del bajo rendimiento, pero puede haber otras mejoras específicas que también eviten esas causas (por ejemplo, anclar el marco para evitar que se paginen cuando se paguen poco después).

Analizar el rendimiento inicial del dispositivo

Partir de un sistema funcional pero de bajo rendimiento e intentar corregir el comportamiento del sistema observando casos individuales de bajo rendimiento visible para el usuario no es una estrategia sólida. Debido a que un rendimiento deficiente no suele ser fácilmente reproducible (es decir, fluctuación) o un problema de aplicación, demasiadas variables en el sistema completo impiden que esta estrategia sea eficaz. Como resultado, es muy fácil identificar erróneamente las causas y realizar pequeñas mejoras mientras se pierden oportunidades sistémicas para corregir el rendimiento en todo el sistema.

En su lugar, utilice el siguiente enfoque general al abrir un nuevo dispositivo:

  1. Haga que el sistema se inicie en la IU con todos los controladores en ejecución y algunas configuraciones básicas del regulador de frecuencia (si cambia la configuración del regulador de frecuencia, repita todos los pasos a continuación).
  2. Asegúrese de que el kernel admita el punto de sched_blocked_reason sched_blocked_reason, así como otros puntos de seguimiento en la canalización de la pantalla que indican cuándo se envía el marco a la pantalla.
  3. Realice seguimientos largos de toda la canalización de la interfaz de usuario (desde la recepción de la entrada a través de una IRQ hasta el escaneo final) mientras ejecuta una carga de trabajo liviana y consistente (por ejemplo, UiBench o la prueba de bola en TouchLatency) .
  4. Corrija las caídas de fotogramas detectadas en la carga de trabajo ligera y constante.
  5. Repita los pasos 3 a 4 hasta que pueda ejecutar sin fotogramas descartados durante más de 20 segundos a la vez.
  6. Pase a otras fuentes de jank visibles para el usuario.

Otras cosas simples que puede hacer al principio de la visualización del dispositivo incluyen:

  • Asegúrese de que su kernel tenga el parche de punto de seguimiento sched_blocked_reason . Este punto de seguimiento está habilitado con la categoría de seguimiento programado en systrace y proporciona la función responsable de dormir cuando ese hilo entra en suspensión ininterrumpida. Es fundamental para el análisis del rendimiento porque el sueño ininterrumpido es un indicador muy común de jitter.
  • Asegúrese de tener suficiente seguimiento para la GPU y las canalizaciones de pantalla. En los SOC de Qualcomm recientes, los puntos de seguimiento se habilitan mediante:
  • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
    adb shell "echo 1 > /d/tracing/events/mdss/enable"
    

    Estos eventos permanecen habilitados cuando ejecuta systrace para que pueda ver información adicional en el seguimiento sobre la canalización de visualización (MDSS) en la sección mdss_fb0 . En los SOC de Qualcomm, no verá ninguna información adicional sobre la GPU en la vista de traza del sistema estándar, pero los resultados están presentes en la traza en sí (para obtener más detalles, consulte Comprensión del trazo del sistema ).

    Lo que desea de este tipo de seguimiento de pantalla es un evento único que indique directamente que se ha entregado un marco a la pantalla. A partir de ahí, puede determinar si ha alcanzado su tiempo de fotograma con éxito; si el evento X n ocurre menos de 16.7ms después del evento X n-1 (asumiendo una pantalla de 60Hz), entonces sabrá que no se produjo un tirón. Si su SOC no proporciona tales señales, trabaje con su proveedor para obtenerlas. La depuración de jitter es extremadamente difícil sin una señal definitiva de finalización de la trama.

Usar puntos de referencia sintéticos

Los puntos de referencia sintéticos son útiles para garantizar que la funcionalidad básica de un dispositivo esté presente. Sin embargo, tratar los puntos de referencia como un indicador del rendimiento percibido del dispositivo no es útil.

Según las experiencias con los SOC, las diferencias en el rendimiento de referencia sintética entre los SOC no se correlacionan con una diferencia similar en el rendimiento perceptible de la IU (número de fotogramas descartados, tiempo de fotograma del percentil 99, etc.). Los puntos de referencia sintéticos son sólo puntos de referencia de capacidad; El jitter afecta el rendimiento medido de estos puntos de referencia solo robando tiempo a la operación general del punto de referencia. Como resultado, los puntajes de referencia sintéticos son en su mayoría irrelevantes como métrica del desempeño percibido por el usuario.

Considere dos SOC que ejecutan Benchmark X que procesa 1000 cuadros de IU e informa el tiempo de procesamiento total (una puntuación más baja es mejor).

  • SOC 1 procesa cada fotograma de Benchmark X en 10 ms y obtiene una puntuación de 10,000.
  • SOC 2 procesa el 99% de los fotogramas en 1 ms, pero el 1% de los fotogramas en 100 ms y obtiene una puntuación de 19,900, una puntuación mucho mejor.

Si el punto de referencia es indicativo del rendimiento real de la interfaz de usuario, el SOC 2 sería inutilizable. Suponiendo una frecuencia de actualización de 60Hz, SOC 2 tendría un marco irregular cada 1,5 segundos de funcionamiento. Mientras tanto, el SOC 1 (el SOC más lento según el Benchmark X) sería perfectamente fluido.

Usar informes de errores

Los informes de errores a veces son útiles para el análisis de rendimiento, pero debido a que son tan pesados, rara vez son útiles para depurar problemas esporádicos de jank. Pueden proporcionar algunas pistas sobre lo que estaba haciendo el sistema en un momento determinado, especialmente si el problema se debió a una transición de la aplicación (que se registra en un informe de error). Los informes de errores también pueden indicar cuándo algo está más mal en el sistema que podría reducir su capacidad efectiva (como estrangulamiento térmico o fragmentación de la memoria).

Uso de TouchLatency

Varios ejemplos de mal comportamiento provienen de TouchLatency, que es la carga de trabajo periódica preferida que se usa para Pixel y Pixel XL. Está disponible en frameworks/base/tests/TouchLatency y tiene dos modos: latencia táctil y bola que rebota (para cambiar de modo, haz clic en el botón en la esquina superior derecha).

La prueba de la pelota que rebota es tan simple como parece: una pelota rebota por la pantalla para siempre, independientemente de la entrada del usuario. Por lo general, también es, con mucho, la prueba más difícil de ejecutar perfectamente, pero cuanto más cerca esté de ejecutarse sin ningún fotograma perdido, mejor será su dispositivo. La prueba de la pelota que rebota es difícil porque es una carga de trabajo trivial pero perfectamente consistente que se ejecuta a un reloj muy bajo (esto supone que el dispositivo tiene un regulador de frecuencia; si el dispositivo está funcionando con relojes fijos, desacelere la CPU / GPU casi al mínimo al ejecutar la prueba de la pelota que rebota por primera vez). A medida que el sistema se inactiva y los relojes se acercan al inactivo, aumenta el tiempo requerido de CPU / GPU por cuadro. Puedes ver la pelota y ver cómo se mueven las cosas, y también podrás ver los fotogramas perdidos en el trazado del sistema.

Debido a que la carga de trabajo es tan consistente, puede identificar la mayoría de las fuentes de fluctuación mucho más fácilmente que en la mayoría de las cargas de trabajo visibles para el usuario si realiza un seguimiento de lo que se está ejecutando exactamente en el sistema durante cada marco perdido en lugar de la canalización de la interfaz de usuario. Los relojes más bajos amplifican los efectos de la fluctuación al hacer que sea más probable que cualquier fluctuación provoque una caída de cuadro. Como resultado, cuanto más cercana esté la latencia táctil a 60 FPS, menos probabilidades hay de que tenga comportamientos de sistema incorrectos que provoquen una interrupción esporádica y difícil de reproducir en aplicaciones más grandes.

Como la fluctuación es a menudo (pero no siempre) invariante a la velocidad del reloj, utilice una prueba que se ejecute en relojes muy bajos para diagnosticar la fluctuación por las siguientes razones:

  • No todo el jitter es invariante a la velocidad del reloj; muchas fuentes solo consumen tiempo de CPU.
  • El gobernador debe acercar el tiempo de fotograma promedio a la fecha límite marcando el tiempo, de modo que el tiempo dedicado a ejecutar trabajos que no sean de IU puede llevarlo al límite para dejar caer un fotograma.