Evalúa el rendimiento

Usa Simpleperf para evaluar el rendimiento de un dispositivo. Simpleperf es una herramienta de generación de perfiles nativa apps y procesos nativos en Android. Usa Generador de perfiles de CPU para inspeccionar el uso de CPU y la actividad de subprocesos de las apps en tiempo real.

Existen dos indicadores de rendimiento visibles para el usuario:

• Rendimiento predecible y perceptible. ¿El usuario interfaz de usuario (IU) omita fotogramas o renderizarla de forma coherente a 60 FPS? ¿Se reproduce el audio? sin artefactos ni explosión? ¿Cuánto tiempo hay entre que el usuario toca la pantalla y el efecto que se muestra en ella?
• Duración necesaria para operaciones más largas (como abriendo apps).

El primero es más notorio que el segundo. Por lo general, los usuarios notan los bloqueos pero no podrá distinguir el tiempo de inicio de la app entre 500 ms y 600 ms, mira dos dispositivos uno al lado del otro. La latencia táctil se ve afectada son notorios y contribuyen significativamente a la percepción de un dispositivo.

Como resultado, en un dispositivo rápido, la canalización de IU es lo más importante en al sistema aparte de lo necesario para mantener funcional la canalización de IU. Esta significa que la canalización de la IU debe interrumpir cualquier otro trabajo que no sea necesario para una IU fluida. Para mantener una IU fluida, sincronización en segundo plano, entrega de notificaciones, y todos los trabajos similares deben retrasarse si se puede ejecutar un trabajo de IU. Sí aceptable para cambiar el rendimiento de las operaciones más largas (tiempo de ejecución HDR+, inicio de la app, etc.) para mantener una IU fluida.

Capacidad frente a Jitter

Cuando consideres el rendimiento del dispositivo, ten en cuenta la capacidad y el jitter. son dos métricas significativas.

Capacidad

La capacidad es la cantidad total de algún recurso que posee el dispositivo en cierta cantidad de tiempo. Pueden ser recursos de CPU, GPU y E/S, los recursos de red, el ancho de banda de memoria o cualquier métrica similar. Al examinar 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 dispositivo nuevo porque es probable que las cargas de trabajo que se ejecutan en él sean fijas).

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

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

Jitter

Si bien la capacidad requerida de una carga de trabajo es fácil de ver, el Jitter es un un concepto confuso. Para una buena introducción al jitter como impedimento para acelerar de seguridad, consulta EL CASO DEL RENDIMIENTO FALTANTE DE LAS SUPERCOMPAÑÍAS: LOGRAR UN RENDIMIENTO ÓPTIMO EN LOS 8,192 PROCESADORES DE ASCl Q. (Es una investigación de por qué la ASCI La supercomputadora Q no logró el rendimiento esperado y es una una introducción a la optimización de sistemas grandes).

En esta página, se utiliza el término jitter para describir lo que llama el informe de ASCI Q ruido. El jitter es el comportamiento aleatorio del sistema que impide no ejecute el trabajo. Suele ser un trabajo que debe ejecutarse, pero puede que no tenga controles requisitos de tiempo que hacen que se ejecute en un momento en particular. Porque es aleatorio, es muy difícil refutar la existencia de jitter de un carga de trabajo determinada. También es muy difícil demostrar que una fuente conocida de El Jitter fue la causa de un problema de rendimiento específico. Las herramientas más comunes para diagnosticar las causas del jitter (como el seguimiento o el registro) puede generar su propio Jitter.

Fuentes de Jitter con experiencia en implementaciones reales de Android incluyen:

• Demora del programador
• Interrumpir controladores
• El código del controlador se ejecuta durante demasiado tiempo con la interrupción o las interrupciones inhabilitadas
• Softirq de larga data
• Contención de bloqueo (app, framework, controlador de kernel, bloqueo de Binder, mmap) bloqueo)
• Contención del descriptor de archivos en la que un subproceso de prioridad baja mantiene el bloqueo en una y evita que se ejecute un subproceso de alta prioridad
• Ejecución de código crítico para la IU en colas de trabajo donde podría retrasarse
• Transiciones de inactividad de la CPU
• Registro
• Retrasos en la E/S
• Creación innecesaria de procesos (por ejemplo, transmisiones de CONNECTIVITY_CHANGE)
• hiperpaginación en caché de la página debido a que no hay suficiente memoria libre

La cantidad de tiempo requerida para un período de Jitter puede o no disminuyen a medida que aumenta la capacidad. Por ejemplo, si un conductor se va y, inhabilitado mientras esperas una lectura a través de un bus i2c, este tomará sin importar si la CPU está a 384 MHz o 2 GHz. En aumento no es una solución factible para mejorar el rendimiento cuando el Jitter involucradas. Por ello, los procesadores más rápidos no suelen mejorar el rendimiento en situaciones de Jitter.

Por último, a diferencia de la capacidad, el jitter está casi completamente dentro del dominio de la proveedor del sistema.

Consumo de memoria

Tradicionalmente, se culpa al consumo de memoria del rendimiento deficiente. Mientras que el consumo en sí mismo no es un problema de rendimiento, puede provocar un jitter por sobrecarga de reducción de memoria, reinicios del servicio y hiperpaginación de la caché de páginas Reducido el consumo de memoria puede evitar las causas directas del rendimiento deficiente, pero pueden ser otras mejoras orientadas que también eviten esas causas (por ejemplo, fijar el framework para evitar que se pagina cuando se realice la paginación poco después).

Cómo analizar el rendimiento inicial del dispositivo

Comenzar desde un sistema funcional, pero con bajo rendimiento, y tratar de solucionar el problema el comportamiento del sistema a través del análisis de casos individuales el rendimiento no es una estrategia sólida. Porque el rendimiento es deficiente por lo general, no es fácil de reproducir (es decir, Jitter) o un problema de la app. muchas variables en todo el sistema impiden que esta estrategia sea eficaz. Como resultado, es muy fácil identificar erróneamente las causas y hacer mejoras menores mientras o perder oportunidades sistémicas de mejorar el rendimiento en todo el sistema.

En su lugar, usa el siguiente enfoque general cuando crees un nuevo dispositivo:

1. Haz que el sistema se inicie en la IU con todos los controladores en ejecución y algunos controladores configuración del regulador de frecuencia (si lo cambias, repite todos los pasos que aparecen a continuación).
2. Asegúrate de que el kernel admita el punto de seguimiento sched_blocked_reason así como otros puntos de seguimiento en la canalización de visualización que indican cuándo la trama se entrega a la pantalla.
3. Realizar seguimientos prolongados de toda la canalización de la IU (desde la recepción de entradas a través de IRQ) al análisis final) mientras ejecutas una carga de trabajo ligera y coherente (por ejemplo, UiBench o la prueba de bola en TouchLatency).
4. Se corrigieron las caídas de fotogramas detectadas en el dispositivo ligero y coherente carga de trabajo.
5. Repite los pasos 3 a 4 hasta que puedas ejecutar sin fotogramas inactivos por más de 20 segundos por vez.
6. Pasa a otras fuentes de bloqueo visibles para el usuario.

Entre otras acciones sencillas que puedes realizar al comienzo del primer paso en el dispositivo, se incluyen las siguientes:

• Asegúrate de que tu kernel tenga el elemento sched_blocked_reason parche de punto de seguimiento. Este punto de seguimiento está habilitado con la categoría de seguimiento programado en Systrace y proporciona la función responsable del sueño cuando subproceso entra en suspensión sin interrupciones. Es fundamental para el análisis del rendimiento. porque el sueño sin interrupciones es un indicador muy común de jitter.
• Asegúrate de tener suficiente seguimiento para las canalizaciones de GPU y Display. Activada SOC recientes de Qualcomm, los puntos de seguimiento se habilitan mediante lo siguiente:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

Estos eventos permanecen habilitados cuando ejecutas Systrace para que puedas ver información del seguimiento sobre la canalización de visualización (MDSS) en el mdss_fb0. En los SOC de Qualcomm, no verás ninguna consulta adicional información de la GPU en la vista estándar de Systrace, pero los resultados presente en el seguimiento (para obtener más información, consulta Comprensión Systrace

Lo que quieres de este tipo de seguimiento de la pantalla es un evento único que indica directamente que un fotograma se entregó a la pantalla. A partir de ahí, para determinar si alcanzaste la velocidad de procesamiento de los fotogramas; si el evento Xn se produce menos de 16.7 ms después del evento Xn-1 (suponiendo una pantalla de 60 Hz), sabes que no bloqueaste. Si su SOC no proporciona tales indicadores, trabaje con tu proveedor para obtenerlos. Depurar el Jitter es extremadamente difícil sin un es el indicador definitivo de la finalización de la trama.

Cómo usar comparativas sintéticas

Las comparativas sintéticas son útiles para garantizar la funcionalidad básica de un dispositivo. está presente. Sin embargo, tratar las comparativas como un proxy para el dispositivo percibido el rendimiento no es útil.

Según las experiencias con los SOC, las diferencias en las comparativas sintéticas el rendimiento entre los SOC no se correlaciona con una diferencia similar en rendimiento perceptible de la IU (cantidad de fotogramas descartados, fotograma del percentil 99) tiempo, etcétera). Las comparativas sintéticas son comparativas solo de capacidad. impactos de Jitter el rendimiento medido de estas comparativas solo mediante el robo de tiempo del volumen masivo una sola operación de la comparativa. Como resultado, las puntuaciones de comparativas sintéticas se irrelevante como métrica del rendimiento percibido por el usuario.

Considera dos SOC que ejecutan la comparativa X que renderiza 1,000 fotogramas de IU y informa el tiempo total de renderización (una puntuación más baja es mejor).

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

Si las comparativas indican un rendimiento real de la IU, el SOC 2 inutilizable. Suponiendo una frecuencia de actualización de 60 Hz, SOC 2 tendrá un fotograma con bloqueos cada 1.5 s de operación. Mientras tanto, SOC 1 (el SOC más lento según la comparativa X) sería perfectamente fluido.

Usa los informes de errores

Los informes de errores a veces son útiles para el análisis de rendimiento, pero debido a que son tan pesadas que rara vez son útiles para depurar problemas de bloqueos esporádicos. Pueden proporcionar algunas sugerencias sobre lo que estaba haciendo el sistema en un momento determinado. en especial si el bloqueo fue en torno a una transición de app (que se accede un informe de errores). Los informes de errores también pueden indicar cuándo algo es más amplio un error en el sistema que podría reducir su capacidad efectiva (como las limitación o fragmentación de la memoria).

Cómo usar TouchLatency

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

La prueba de rebote es tan simple como parece: una pelota rebota alrededor de la pantalla para siempre, sin importar la entrada del usuario. Además, suele por lejos es la prueba más difícil de ejecutar a la perfección, pero cuanto más mientras se ejecuta sin pérdida de fotogramas, mejor será el dispositivo. El La prueba de rebote es difícil porque es un tema trivial, pero que se ejecuta en un reloj muy bajo (esto supone que el dispositivo tiene una frecuencia gobernador Si, en cambio, el dispositivo se ejecuta con relojes fijos, ajusta el formato del reloj CPU/GPU casi al mínimo cuando se ejecuta la prueba de rebote por primera vez). A medida que el sistema se desactiva y los relojes se acercan al estado de inactividad, la CPU/GPU requerida aumenta el tiempo por fotograma. Puedes ver cómo la pelota se bloquea y cómo se bloquea. también podrán ver los fotogramas perdidos en Systrace.

Debido a que la carga de trabajo es muy coherente, se pueden identificar el Jitter mucho más fácil que en la mayoría de las cargas de trabajo visibles para el usuario. se ejecuta exactamente en el sistema durante cada fotograma perdido en lugar de la IU en una canalización de integración continua. Los relojes más bajos amplifican los efectos del Jitter, ya que más probabilidades de que cualquier jitter cause una disminución del fotograma. Como resultado, el si la TouchLatency es 60 FPS, es menos probable que el sistema comportamientos que causan bloqueos esporádicos y difíciles de reproducir en espacios de Google Chat.

Dado que el jitter a menudo no varía en función de la velocidad del reloj, usa una prueba que se ejecuta en relojes muy bajos para diagnosticar el Jitter por los siguientes motivos:

• No todo el Jitter depende de la velocidad del reloj. muchas fuentes solo consumen CPU tiempo.
• El gobernador debe tener la latencia de fotogramas promedio cerca de la fecha límite a más tardar por lo que el tiempo dedicado a ejecutar trabajos que no sean IU dejar caer un marco.