Compartir tecnología

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Descripción general de las herramientas relacionadas con la recopilación y el análisis del rendimiento

Existen muchas herramientas para recopilar, analizar y mostrar datos de rendimiento de aplicaciones móviles, que se pueden dividir aproximadamente en las siguientes categorías. Por ejemplo, herramientas de rendimiento móviles que pueden recopilar múltiples indicadores de rendimiento, perfdog y Solopi, entre las cuales Solopi es de código abierto y pefdog es una herramienta comercial. Herramientas que pueden realizar análisis de fallos, como el comercial Firebase Crashlytics y la herramienta de código abierto Sentry. Si necesita analizar datos relacionados con la red, puede utilizar Charles o Wireshark. Además, existen herramientas integrales de gestión del rendimiento, como Dynatrace. En términos generales, las capacidades, precisión y experiencia del usuario de las herramientas comerciales son definitivamente mejores que las herramientas de código abierto. Como estudio e investigación personal, solo puedo comenzar con herramientas de código abierto. Por lo tanto, al escribir este blog, también utilizaremos herramientas de código abierto como ejemplos.

Herramienta de prueba de rendimiento móvil：
PerfDog: una herramienta para monitorear el rendimiento de las aplicaciones, CPU, memoria, consumo de energía y otros datos, que admite pruebas de rendimiento y monitoreo en tiempo real de aplicaciones móviles.
Solopi: se centra en las pruebas y el seguimiento del rendimiento de las aplicaciones móviles, incluido el seguimiento en tiempo real de la velocidad de fotogramas, la CPU, la memoria y otros indicadores.

Herramienta de análisis de fallos：
Firebase Crashlytics: una potente herramienta de análisis e informes de fallos proporcionada por Google que puede monitorear los fallos de las aplicaciones en tiempo real.
Sentry: una herramienta de seguimiento de errores de código abierto que admite múltiples plataformas, incluidos informes de errores y monitoreo del rendimiento de aplicaciones móviles.

Herramientas de prueba de rendimiento de red：
Charles Proxy: una herramienta proxy de depuración de red que captura y analiza datos de solicitud y respuesta de red para aplicaciones móviles.
Wireshark: una herramienta de análisis de red de código abierto que admite la captura y análisis de paquetes de red de aplicaciones móviles.

herramientas APM(Gestión del rendimiento de la aplicación):
Dynatrace: una solución de monitoreo de rendimiento de pila completa, nativa de la nube, que admite el monitoreo del rendimiento de aplicaciones móviles y el análisis de la experiencia del usuario.

¿Qué métricas de desempeño se recopilan y cómo?

  Antes de realizar un análisis de rendimiento, primero debe comprender el significado de cada indicador de rendimiento. Tomando como ejemplo los indicadores de rendimiento recopilados por Solopi, echemos un vistazo a los indicadores comunes del rendimiento de las aplicaciones móviles y cómo se pueden recopilar.

Cuadros por segundo

La fórmula para calcular la velocidad de fotogramas es:Velocidad de fotogramas = número de fotogramas dibujados/período de tiempo,La velocidad de fotogramas objetivo para la mayoría de los desarrolladores de aplicaciones y juegos es60 FPS( fotogramas/segundo), ¿por qué la velocidad de fotogramas objetivo es 60 FPS? Debido a que la frecuencia de actualización de la pantalla de la mayoría de los teléfonos inteligentes y tabletas modernos es de 60 Hz, siempre que la velocidad de fotogramas alcance los 60 FPS, es decir, el número de fotogramas dibujados por segundo sea 60, los efectos visuales del usuario serán más fluidos y no habrá retrasos. El mínimo no puede ser inferior a 30 FPS. Esto se debe a que el monitor muestra repetidamente la imagen del cuadro anterior mientras espera un nuevo cuadro, lo que hace que la imagen no sea fluida. Los altos pueden alcanzar los 90 FPS (por ejemplo, para dispositivos con altas frecuencias de actualización).

Cómo recopilar información sobre la velocidad de fotogramas

  Hay dos formas de recopilar la velocidad de fotogramas. Una es utilizar la clase Choreographer para recopilar estadísticas de velocidad de fotogramas. Esto requiere escribir código dentro de la aplicación y solo puede recopilar la información de velocidad de fotogramas de la aplicación.Otra forma es utilizar herramienta gfxinfo. Tomando Solopi como ejemplo, el tiempo de espera del fotograma en 1 segundo también se calcula a través de la información de la herramienta gfxinfo y se deduce la velocidad de fotogramas real. Por lo tanto, cuando está casi estacionario, es posible que parte de la velocidad de fotogramas se muestre incorrectamente. Se recomienda realizar pruebas de velocidad de fotogramas en escenarios dinámicos como deslizamiento o cambio de página. El método gfxinfo puede recopilar información de velocidad de fotogramas de todas las aplicaciones y es muy adecuado como herramienta de recopilación de datos de rendimiento. Por lo tanto, aquí también nos centraremos en cómo recopilar información de velocidad de fotogramas a través de gfxinfo.

Hay dos pasos principales para recopilar información sobre la velocidad de fotogramas.paso uno: Obtenga información de gfxinfo mediante el comando adb,Paso 2 : analiza la información y calcula la información de velocidad de fotogramas. El contenido de la información de gfxinfo es aproximadamente el siguiente:

Estadísticas desde: hora de inicio de las estadísticas, la unidad es nanosegundos.
Cuadros totales renderizados: número total de cuadros renderizados.
Fotogramas Janky: el número de fotogramas Janky, es decir, el número de fotogramas que superan los 16 ms (intervalo de actualización de 60 fotogramas por segundo).
Porcentaje de fotogramas molestos: la relación entre fotogramas molestos y el número total de fotogramas.
Percentil 90: percentil 90, lo que indica que el 90 % de los fotogramas tienen tiempos de renderizado inferiores a este valor (en milisegundos).
Percentil 95: percentil 95, lo que indica que el 95 % de los fotogramas tienen tiempos de renderizado inferiores a este valor (en milisegundos).
Percentil 99: percentil 99, lo que indica que el 99 % de los fotogramas tienen tiempos de renderizado inferiores a este valor (en milisegundos).
Número de Vsync perdido: el número de sincronizaciones verticales no sincronizadas, es decir, el número de caídas de fotogramas causadas por una falla en el procesamiento a tiempo.
Número de latencia de entrada alta: el número de retrasos de entrada altos indica el número de retrasos causados ​​por un tiempo de procesamiento de eventos de entrada demasiado largo.
Número de subprocesos de UI lentos: el número de veces que el subproceso de UI respondió lentamente, es decir, el número de veces que el subproceso de UI tardó demasiado en procesarse.

Tomando Solopi como ejemplo, la velocidad de fotogramas se deduce a través del tiempo de espera del fotograma en la información de gfxinfo. Para el código del proyecto específico, puede ver el código fuente de solopi.

tasa de retraso/número de retrasos

Número de congelaciones : Durante el período de prueba, la cantidad de períodos durante los cuales se detecta que la velocidad de fotogramas es inferior al umbral. Cada vez que la velocidad de fotogramas cae por debajo del umbral durante un período de tiempo, se cuenta como tartamudeo. El umbral aquí se puede personalizar, por ejemplo, si es 60 FPS menor que la velocidad de fotogramas objetivo, se puede grabar como una congelación. Es decir, si el tiempo de renderizado del cuadro es superior a 16 ms, se calcula como atascado.

tasa de retraso : El porcentaje del tiempo de congelación respecto del tiempo total de prueba. Supongamos que en una prueba, la aplicación se ejecutó durante 120 segundos, durante los cuales la velocidad de fotogramas fue inferior a 16 FPS 4 veces en total, y el tiempo de retraso total fue de 8 segundos, entonces: el número de retrasos: 4 veces. Tasa de tartamudez: 8/120*100%=6,7%. En gfxinfo anterior, también hay información sobre la tasa de retraso.

procesador/memoria

  Tomando solopi como ejemplo, la CPU incluye el porcentaje de uso de CPU del proceso donde se encuentra la actividad de nivel superior de la aplicación y el porcentaje de uso de CPU global. Para aplicaciones de proceso único, estos datos representan el uso de CPU de la aplicación; Aplicaciones de procesos multiproceso, estos datos representan el uso de CPU de nivel superior del proceso de UI; cuando ocurre un cambio de proceso, Soloπ puede cambiar automáticamente a nuevos datos de proceso.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Tiempo de respuesta

  Tomemos como ejemplo a solopi, Contiene datos de tiempo de respuesta y tiempo de actualización para los clics en la aplicación. Pertenece a los datos de dimensión de la aplicación. El tiempo desde que el usuario hace clic hasta la primera vez que el sistema emite una actualización de la interfaz es el tiempo de respuesta, y el tiempo hasta que el sistema deja de actualizar la interfaz es el tiempo de actualización. La lógica de contar el tiempo de respuesta es dividir la grabación de la pantalla en cuadros. Según el sitio web oficial de Solopi, reconoce automáticamente el cuadro inicial y el cuadro final para contar el tiempo de respuesta. Cuando realmente use Solopi, encontrará esa página estadística. El tiempo de respuesta no es correcto. Por ejemplo, cuando el usuario hace clic en Inicio, cuando hace clic en la página de la aplicación, se incluye el tiempo de operación de la velocidad de la mano de alguien en el medio y esta parte se cuenta en el tiempo de respuesta. Por lo tanto, si desea calcular el tiempo de respuesta de la página preparada, es más preciso grabar solo la pantalla e identificar manualmente los fotogramas inicial y final de la página. Los pasos específicos para grabar fotogramas de pantalla son los siguientes:

Lo anterior es una comprensión del significado de los indicadores de rendimiento comunes en las aplicaciones móviles, así como instrucciones detalladas sobre cómo recopilarlos. Con respecto a fallas, etc., lo presentaremos en detalle en un blog posterior.