Autor: shizhengtao, experto en herramientas de ajuste de rendimiento de Huawei
La optimización del rendimiento de las aplicaciones siempre ha sido un problema importante al que se enfrentan los desarrolladores. La versión preliminar para desarrolladores de HarmonyOS NEXT recientemente presentada en la conferencia HDC de 2023, que incluye el kit de desarrollo Harmony DevEco Profiler, proporciona una solución al problema del retraso de las aplicaciones. ? Este artículo te llevará a descubrirlo.
1. Monitor en tiempo real , detecta eficientemente problemas atascados
Realtime Monitor monitorea una serie de indicadores de rendimiento durante el funcionamiento de la aplicación en tiempo real y muestra estos indicadores en un panel visual. Es muy sencillo de usar para los desarrolladores: solo necesita seleccionar el proceso de solicitud que desea observar en la esquina superior izquierda de la interfaz de la herramienta DevEco Profiler, y esta función se activará automáticamente.
Figura 1 Monitor en tiempo real
En Realtime Monitor, puede ver los siguientes elementos indicadores:
① Eventos de rendimiento del sistema: con la ayuda de las capacidades integradas de detección de rendimiento de HarmonyOS NEXT, puede ayudarle a descubrir automáticamente algunos eventos operativos relacionados con el rendimiento y la estabilidad.
② Eventos anormales del sistema: con la ayuda de las capacidades integradas de detección de anormalidades de HarmonyOS NEXT, puede ayudarlo a descubrir automáticamente algunos eventos operativos anormales.
③Capacidad en primer plano: detecta la UIAbility que muestra actualmente la aplicación en primer plano. Cuando se encuentra un indicador anormal, puede aprender rápidamente qué UIAbility se genera cuando se está ejecutando.
④Uso de la CPU: detecta el uso de la CPU de la aplicación y la carga general de la CPU del sistema. El uso continuo de la CPU a menudo conduce al problema del consumo excesivo de energía, en el que es necesario concentrarse.
⑤Uso de memoria: detecta el uso de memoria de la aplicación y la carga general de memoria del sistema.Si hay un aumento periódico en la memoria de la aplicación, es probable que haya ocurrido una pérdida de memoria, lo que requiere atención especial.
⑥Dispositivo FPS: Detecta la velocidad de fotogramas FPS actual del dispositivo. Cuando la interfaz de la aplicación es estática y el FPS es alto, puede haber un problema de sobrerrepresentación. Cuando la interfaz de la aplicación cambia mucho pero el FPS no es alto, puede haber un problema de pérdida de fotograma, que es lo que se mencionó anteriormente, problemas de fluidez.
⑦Utilización de GPU del dispositivo: detecta la utilización actual de GPU del dispositivo. Cuando la velocidad de fotogramas de FPS no es suficiente, se puede realizar una demarcación preliminar comparando los indicadores de utilización de GPU y utilización de CPU: si el cuello de botella está en el lado de la GPU o en la CPU. lado.
⑧Consumo de energía del dispositivo: detecte el consumo de energía y el consumo total de energía de cada dispositivo físico utilizado por la aplicación para ayudarlo a analizar rápidamente la distribución actual del consumo de energía de la aplicación.
Con la ayuda de estos indicadores de rendimiento en tiempo real, puede comprender rápidamente el rendimiento en ejecución del proceso de la aplicación, de modo que pueda descubrir y delimitar rápidamente cuándo ocurren ciertos problemas de rendimiento en la aplicación.
2. Análisis basado en escenarios, analizando directamente el código fuente del problema.
Al comienzo del diseño de la herramienta DevEco Profiler, determinamos un concepto central, que es proporcionar herramientas de ajuste de bajo umbral basadas en escenarios, crear un diseño de interacción de UX de arriba hacia abajo y guiar a los desarrolladores para que puedan despegar el capullos al analizar datos de rendimiento, proceda capa por capa, en lugar de caer directamente en los detalles del océano de datos desde el principio. Esto es muy importante en el campo del ajuste del rendimiento. Esperamos reflejar intuitivamente el modelo de falla detrás de cada tipo de problema de rendimiento para los desarrolladores a través del diseño de la interfaz. Los desarrolladores pueden completar la delimitación preliminar y el juicio del problema tan pronto como obtengan los datos de rendimiento y luego analizar los datos capturados de manera específica. Una idea de solución clara es una de las condiciones necesarias para resolver los problemas de rendimiento. Además, otro punto extremadamente importante es que en todos los escenarios esperamos ayudar a los desarrolladores a localizar directamente la línea de código del problema. Después de localizar la función de cuello de botella a través de la herramienta, puede hacer doble clic directamente en el marco de la pila de funciones para encontrar rápidamente el código del problema. En DevEco, abra los archivos fuente relevantes en el editor de Studio y los desarrolladores podrán analizarlos y optimizarlos inmediatamente. En el DevEco Profiler presentado en la conferencia HDC en agosto, además de las plantillas de ajuste básicas relacionadas con puntos de acceso de funciones y análisis de memoria que se han lanzado, este año ha traído a los desarrolladores dos plantillas principales que realmente encarnan el concepto de escenarioización. : Inicie Insight y Frame Insight.
Launch Insight: desmantela de manera integral el proceso de inicio en frío de la aplicación, captura datos que consumen mucho tiempo en diferentes etapas y ayuda a los desarrolladores a analizar rápidamente los cuellos de botella que consumen mucho tiempo en el proceso de inicio en frío.
Frame Insight: registra los datos de representación de cada cuadro, identifica automáticamente los cuadros atascados y proporciona información de seguimiento del sistema y datos de muestreo de la pila de funciones durante el mismo período para ayudar a los desarrolladores a analizar de manera eficiente la ubicación y las causas de los cuadros atascados.
A continuación, echemos un vistazo más de cerca a la plantilla Frame y veamos cómo ayuda a los desarrolladores a analizar el problema de pérdida de frames de una manera clara y específica.
3. Frame Insight , localiza eficientemente problemas atascados
Mencionamos en la sección anterior que el modelo de falla detrás del problema de rendimiento se reflejará intuitivamente para los desarrolladores. Por lo tanto, antes de presentar la plantilla Frame, los desarrolladores primero deben comprender brevemente el proceso de representación de gráficos en HarmonyOS NEXT. Si hay un retraso, cuáles son sus posibles etapas y causas.
En HarmonyOS NEXT, el sistema de gráficos adopta un modo de renderizado unificado y sigue un modo de canalización típico. Tomando como ejemplo la frecuencia de actualización de 60 Hz, todo el proceso se muestra en la Figura 2 a continuación. Si es 90 Hz, el ciclo de cada Vsync es 11,1 señora.
Figura 2 Proceso de renderizado con frecuencia de actualización de 60 Hz
En todo el proceso de renderizado, el lado de la aplicación primero responde al clic en la pantalla del consumidor y otros eventos de entrada. Después de que el lado de la aplicación lo procesa, se envía al Servicio de renderizado. Después de que el Servicio de renderizado coordina el procesamiento de la GPU y otros recursos, el final La imagen se envía uniformemente para mostrarla en la pantalla. Los lectores inteligentes deben haber podido deducir el modo de falla correspondiente de este proceso en este momento, como se muestra en las Figuras 3 y 4.
Figura 3 Modelo de error de retraso de la aplicación que provoca pérdida de fotogramas
Figura 4 Modelo de error del servicio de renderizado atascado provocando pérdida de fotogramas
A lo largo de todo el proceso de procesamiento, pueden ocurrir retrasos tanto en el lado de la aplicación como en el lado del servicio de renderizado, lo que hace que el usuario final observe una pérdida de cuadros. A estas dos situaciones las llamamos AppDeadlineMissed y RenderDeadlineMissed respectivamente. En términos generales, lo primero puede deberse a que el código de procesamiento lógico de la aplicación no es lo suficientemente eficiente, y lo segundo puede deberse a que la estructura de la interfaz es demasiado compleja o la carga de la GPU es demasiado pesada. Ambos modelos de fallas se pueden visualizar a través de nuestra plantilla Frame. Después de complementar estos conocimientos preliminares, vayamos al grano.
El primer paso es seleccionar y grabar la plantilla, este paso es muy sencillo. Los desarrolladores pueden reproducir fotogramas entrecortados y perdidos durante la grabación con solo unos pocos clics del mouse. El proceso completo se muestra en la Figura 5. Durante la grabación, DevEco Profiler utilizará las ricas herramientas DFX en HarmonyOS NEXT para recopilar automáticamente varios datos de rendimiento necesarios para los desarrolladores en escenarios de pérdida de fotogramas. Una vez completados la grabación y el análisis, comenzó el análisis.
Figura 5 Análisis de grabación de plantilla de cuadro
Una vez completada la grabación, puede observar una serie de líneas de datos, como se muestra en la Figura 6.
Figura 6 Línea de datos de plantilla de marco
① Carril de natación de cuadros: presenta visualmente los datos de rendimiento correspondientes al modelo de falla de pérdida de cuadros, lo que ayuda a los desarrolladores a localizar rápidamente el período de pérdida de cuadros y hacer un juicio preliminar sobre la causa de la pérdida de cuadros.
②Carril de pila de llamadas de ArkTS: capture y presente puntos de acceso de funciones de ArkTS para ayudar a los desarrolladores a localizar cuellos de botella que consumen mucho tiempo en el lado de ArkTS.
③Carril de pila de llamadas nativa: capture y presente los puntos de acceso de funciones de Native C++ para ayudar a los desarrolladores a localizar cuellos de botella que consumen mucho tiempo en el lado nativo.
④Carril de natación del núcleo de la CPU: captura y presenta los detalles de ejecución de cada núcleo de la CPU, lo que ayuda a los desarrolladores a localizar problemas de rendimiento causados por la prioridad de los subprocesos, la programación del sistema, etc., así como los detalles de ejecución reales del subproceso.
⑤Carril de natación de seguimiento del sistema: capture y presente el seguimiento del sistema y el seguimiento del usuario de cada proceso para ayudar a los desarrolladores a comprender y ver los detalles de ejecución del sistema y el tiempo de ejecución preciso de ciertas tareas principales. Al analizar el problema de pérdida de cuadros, primero puede concentrarse en expandir el primer carril de cuadros. En este carril de natación, capturamos información clave del nodo en el proceso de representación de gráficos y la visualizamos, como se muestra en la Figura 7.
Figura 7 Carril del marco
① Procesamiento del marco de la aplicación: le muestra el tiempo de procesamiento de cada cuadro en el lado de la aplicación. La longitud del cuadro es el consumo de tiempo específico. Los verdes son los cuadros completados dentro del período predeterminado y los rojos no están dentro del período predeterminado. período predeterminado marco completado
② Procesamiento de fotogramas de RenderService : le muestra el tiempo de procesamiento de cada fotograma en el lado del Servicio de renderizado. La lógica de visualización de la barra es la misma que en el lado de la aplicación.
③Relación de envío: al conectar los fotogramas enviados por el lado de la aplicación y los fotogramas recibidos y procesados por el lado del Servicio de renderizado, y marcados con los números correspondientes, puede observar inmediatamente el proceso de renderizado de esta aplicación en el sistema.
④ Tiempo de procesamiento de inicio y finalización esperado: dos líneas verticales marcan el cuadro seleccionado, el tiempo de inicio de procesamiento esperado y el tiempo de finalización esperado del procesamiento. Una vez agotado el tiempo, puede usar estas dos líneas verticales para observar otros datos de rendimiento al mismo tiempo.
⑤Datos detallados: le proporciona datos detallados del cuadro seleccionado. A través del botón de salto de Sector correspondiente o Flujos anteriores, puede encontrar rápidamente el seguimiento detallado del sistema correspondiente para un análisis más detallado. A través de este carril, los desarrolladores pueden descubrir rápidamente los datos faltantes. posición del marco y completar la delimitación preliminar: si aparece rojo durante el procesamiento del marco de la aplicación, es necesario examinar más a fondo la lógica de procesamiento en el hilo de la interfaz de usuario para ver si es demasiado compleja o ineficiente, o si otras tareas se apropian de los recursos. Si aparece rojo durante el procesamiento del marco de RenderService, debe examinar si el diseño de la interfaz es demasiado complejo. Esto último se puede analizar más a fondo con la ayuda de herramientas como ArkUI Inspector en DevEco Studio, que no se detallará en este artículo. Sigamos analizando el primer fenómeno.
Después de encontrar el marco de tiempo de espera de procesamiento, los desarrolladores tienen dos opciones: una es analizar el seguimiento del sistema y la otra es analizar los puntos calientes de funciones muestreadas. El primer método requiere una comprensión profunda de todo el sistema y los puntos de seguimiento clave, lo que puede resultar difícil para los desarrolladores en esta etapa, por lo que aún recomendamos que los desarrolladores analicen directamente los puntos críticos de funciones. El método de análisis es muy simple: simplemente busque el carril ArkTS Callstack y selecciónelo. Aquí hay un pequeño truco: los desarrolladores pueden hacer clic en el botón Colección en el área de información del carril de natación para colocar la colección del carril de procesamiento del marco de la aplicación en la parte superior, como se muestra en la Figura 8, lo que puede prevenir efectivamente la pérdida de información contextual.
Imagen 8: Fije los carriles clave en la parte superior
Después de seleccionar el cuadro de período del marco rojo en el carril de natación de ArkTS Callstack, puede ver los puntos activos de funciones durante este período en el panel de detalles a continuación. Proporcionamos dos formularios de visualización de puntos de acceso a funciones para que los desarrolladores elijan: uno es una lista de árbol en forma de arriba hacia abajo, como se muestra en la Figura 9; el otro es un gráfico de llama con el que muchos desarrolladores pueden estar más familiarizados, como se muestra en Figura 9. Se muestra en diez. Los desarrolladores pueden optar por verlo a su manera. En términos generales, si la pila de funciones es relativamente compleja en el período de tiempo seleccionado, será más eficiente utilizar el gráfico de llamas para encontrar puntos calientes. Además de estos dos formularios, también brindamos la capacidad de encontrar automáticamente la ruta del cuello de botella, que se muestra en el lado derecho de las Figuras 9 y 10. Cuando hace clic en un nodo del marco de pila de funciones específico en el gráfico de arriba hacia abajo o en llamas de la izquierda, calcularemos para usted la ruta de llamada que consume más tiempo desde este nodo hacia abajo. Cuando hace clic en este Al llamar a un marco de pila de funciones en el ruta, el gráfico de la izquierda se expandirá o se centrará automáticamente en el nodo correspondiente, lo que mejorará la eficiencia de la ubicación del cuello de botella.
Figura 9 Vista de arriba hacia abajo del punto de acceso a funciones
Figura 10 Gráfico de llama de punto caliente de función
Después de bloquear una función activa, solo necesita hacer doble clic en el nodo de función y la herramienta Profiler abrirá automáticamente el archivo fuente correspondiente y se centrará en la línea de código correspondiente. Por supuesto, aquí hay una premisa: el archivo fuente debe pertenecer al proyecto actual y estar compilado en DevEco Studio.
4. Verificación y optimización iterativa.
A través de los pasos anteriores, los desarrolladores deberían haber podido localizar el código del cuello de botella, pero la tarea está lejos de terminar. También debe volver a utilizar las primeras capacidades de la herramienta para verificar una vez completada la optimización. En términos generales, la optimización del rendimiento no es algo que se pueda lograr de la noche a la mañana y requiere una mejora gradual y paso a paso. Esto requiere experiencia, pero aún más paciencia: cada retraso probablemente se deba a la superposición de múltiples subproblemas. Esta es una de las razones por las que la tarea de optimización del rendimiento a menudo debe ser realizada por expertos del equipo.
Por supuesto, esto en realidad indica una manera para que nosotros, los programadores, obtengamos un ascenso y obtengamos un aumento salarial. Aprenda a ajustar y resolver problemas difíciles, como problemas de rendimiento. Si resuelve más problemas, naturalmente se convertirá en la columna vertebral técnica del equipo. También espero que este artículo y nuestra herramienta de ajuste DevEco Profiler puedan ayudar a los desarrolladores en su camino de promoción. Gracias por leer.