Prueba de rendimiento de la aplicación móvil

• Prueba de rendimiento de la aplicación móvil: eche un vistazo

• 1. Indicadores de rendimiento de la aplicación

   Problemas de rendimiento de la aplicación, como bloqueos graves al usar la aplicación o carga lenta de la página, alto uso de la CPU, bloqueos de la aplicación, etc. Durante la prueba, debe prestar especial atención a la experiencia de rendimiento. El bajo rendimiento de la aplicación generalmente genera insatisfacción en los usuarios. con la aplicación. El uso es bajo y las desinstalaciones son altas.

  Dimensión de usuario de prueba especial de rendimiento

  

   Dimensión de tecnología de prueba especial de rendimiento

  

  respuesta

  El tiempo de respuesta y la velocidad del software afectan directamente la experiencia del usuario. Si un software no se puede cargar durante mucho tiempo, afectará directamente la actividad diaria y la retención del software. Por lo tanto, para un software, es fundamental probar la velocidad de respuesta.

  Excelente: 0~400ms, estándar: 400ms~2000ms, peligro oculto menor: 2000ms~5000ms, peligro oculto grave: más de 5000ms.

  Memoria

  En el sistema Android, además de compartir memoria con otros procesos (compartida sucia), cada proceso APP también utiliza memoria privada (privada sucia), normalmente usamos PSS (memoria privada + asignación proporcional de memoria compartida) para medir la memoria de un Sobrecarga de la aplicación. Dado que la memoria de un dispositivo móvil es fija, si el consumo de memoria es demasiado grande, la aplicación se congelará o fallará, y es necesario probar la memoria. En circunstancias normales, la aplicación no debería ocupar demasiados recursos de memoria y la memoria se puede liberar a tiempo para garantizar la estabilidad y fluidez de toda la aplicación.

  UPC

  La principal preocupación es el uso de la CPU. Al jugar con el teléfono móvil, habrá calor y calor.Es porque el uso de la CPU es demasiado alto y la CPU está demasiado ocupada, lo que hará que todo el teléfono móvil no pueda responder al usuario, el rendimiento general se reducirá. , la experiencia del usuario será deficiente y es fácil causar ANR (la aplicación no responde, la aplicación no responde, si el subproceso principal (subproceso de interfaz de usuario) no termina de procesar el trabajo correspondiente dentro del tiempo especificado, habrá ANR) y una serie de problemas.

  FPS

  La fluidez de uso de la aplicación, FPS es la definición en el campo de la imagen, que se refiere a la cantidad de cuadros por segundo que transmite la pantalla y, en general, se refiere a la cantidad de cuadros de animación o video. FPS es una medida de la cantidad de información utilizada para guardar y mostrar video en movimiento. Cuantos más fotogramas por segundo, más suave será el movimiento mostrado.

  En general, la frecuencia de actualización de la pantalla de un dispositivo Android es de 60 cuadros por segundo. Para mantener la pantalla fluida y no congelarse, se requiere que el tiempo de cada cuadro no supere los 1000/60 = 16,6 ms, que es la regla de oro de 16ms Si algunos fotogramas en el medio Si el tiempo de renderizado supera los 16ms, se producirán saltos de fotogramas en la imagen durante este período, por lo que la imagen originalmente fluida se atasca.

  Representación excesiva de GPU

  La representación de GPU se refiere a dibujar varias veces (más de una vez) en un píxel: mostrar una interfaz de actividad que no hace nada se considera dibujar la primera capa, agregar un fondo a la actividad es la segunda capa y colocar un TextView en él (con La Vista de texto del fondo) es la tercera capa, y el texto que muestra la Vista de texto es la cuarta capa. Es solo para mostrar un texto, pero el mismo píxel se dibuja cuatro veces, lo que debe optimizarse. El impacto del overdraw en el rendimiento de la animación es extremadamente serio, y si desea efectos de animación fluidos, no debe ignorar el overdraw.

  el consumo de energía

  Antes de probar el consumo de energía de la aplicación, debe tener una comprensión general del consumo de energía del propio teléfono móvil. Antes de la prueba, verifique el consumo de energía del teléfono móvil en modo de espera normal (en espera después de reiniciar) dentro del tiempo especificado , y luego inicie la aplicación para probarla para ver el consumo de energía. Cuánto ha aumentado la energía es la diferencia.

  Punto de prueba:

   No hay una diferencia significativa en el consumo de energía en espera antes y después de instalar el APK de destino en el teléfono móvil de prueba;

  En escenarios de uso común, puede entrar en espera normalmente y la corriente de espera está dentro del rango normal;

   No hay un fenómeno de consumo de energía anormal en uso continuo durante mucho tiempo.

  prueba de flujo

  Los tipos de redes actuales incluyen 2G3G4Gwifi, y existen diferencias entre los diferentes operadores. A menudo nos encontramos con diversas situaciones, como grandes recursos, solicitudes repetidas, respuesta de llamadas lenta y fallas de llamadas en el uso de la aplicación. Bajo diferentes tipos de red, no solo aceleramos la respuesta a las solicitudes, sino que también controlamos el uso del tráfico.

  El tráfico promedio por segundo, el valor recomendado es <5,12 kb, el tráfico promedio por 10 minutos, el valor recomendado es <3 MB, no hay comportamiento como el robo de tráfico de la aplicación. 

  2. Usa adb para probar

  1. Tiempo de respuesta de la aplicación y prueba de velocidad de respuesta

  1.1 Principales puntos de prueba

  Inicio en frío: intervalo de tiempo entre los inicios de la aplicación por primera vez (solo tiempo de inicio, cargas de página no incluidas)

  Comienzo en caliente: el intervalo de tiempo para el primer lanzamiento de la aplicación (solo el tiempo de inicio, excluyendo la carga de la página)

  Proceso de inicio de actividad

  

   

  

  1.2 Método de prueba

  Inicio fresco

  adb shell am start -W com.tencent.mm/.ui.LauncherUI (aplicación de inicio)

  adb shell am force -stop nombre del paquete (detener APP)

   Ruta absoluta, la primera Actividad

   am es un comando integrado en el shell, abreviatura de ActivityManager.

   -W significa que una vez completada la puesta en marcha, vuelve a la hora de puesta en marcha.

   Puede haber un caché de la aplicación (advertencia: la actividad no se inició, la intención se envió a la instancia superior que se está ejecutando actualmente), se recomienda ejecutar el comando directamente después de reiniciar el emulador

  

  significado

   ThisTime: El tiempo de inicio de la Actividad, en ms;

   TotalTime: el tiempo que tarda en iniciarse la propia aplicación, ThisTime+ la hora de inicio de recursos como la aplicación;

   WaitTime: el tiempo que tarda el sistema en iniciar la aplicación, TotalTime+ tiempo de inicio de recursos del sistema.

  Si solo le preocupa el tiempo de inicio de una aplicación en sí, consulte TotalTime; si le preocupa el tiempo que tarda el sistema en iniciar la aplicación, consulte WaitTime; si le preocupa el tiempo de inicio de todas las actividades de la interfaz de la aplicación, consulte ThisTime.

  Arranque en caliente

  Presione el botón de retorno (adb shell input keyevent 3) y luego inicie el comando adb

  Estándar de prueba: el tiempo de inicio en frío no supera los 1,5 s y el tiempo de inicio en caliente no supera los 1 s.

  Nota: este método no incluye el tiempo de procesamiento de la página.

  El tiempo de renderizado de la primera pantalla se puede obtener grabando la pantalla cuadro por cuadro.

  Método de grabación de pantalla Android:

  adb shell screenrecord --time-limit 10 /sdcard/video.mp4 (--time-limit 10: limite el tiempo de grabación a 10s, el valor predeterminado es 180s si no hay límite)

  adb pull /sdcard/video.mp4 /usuario/escritorio/video

  Grabar pantalla cuadro por cuadro

  Encuadre a través de ffmpeg (referencia de configuración de ffepeg: https://blog.csdn.net/chy466071353/article/details/54949221 )

  ffmpeg -id:/test/video.mp4 -r 10 -threads 2 d:/test/Android-Capture-%05d.png (-r 10 significa que 1s se divide en 10 cuadros, es decir, 1 cuadro es 0.1s )

  El contenido del video incluye: escritorio → el ícono de la aplicación bajo prueba se vuelve negro → muestra la pantalla de inicio de Zhihu → muestra el marco principal → se carga el contenido de la página de inicio.

  Dado que la carga del contenido de la página de inicio se completa de forma asíncrona, seleccionamos los nodos clave para el análisis, que son "el icono de la aplicación bajo prueba se vuelve negro" y "mostrar el marco principal".

  Use FFmpeg para convertir el video en imágenes enmarcadas y reste el sufijo de [la aplicación de imagen probada se vuelve negra] * 0.1s del sufijo de la imagen [Mostrar cuadro principal].

  

   (49-11)*0.1=3.8s

  1.3 Adquisición del tiempo de inicio de ios

  Consulte la práctica de prueba de tiempo de inicio de la aplicación Zhihu iOS - Zhihu , el método principal también es grabar la pantalla.

  Los métodos comunes de prueba de tiempo de inicio de iOS incluyen principalmente lo siguiente:

  1. Herramienta para desarrolladores de Xcode: con el complemento Time Profiler de Instruments, puede detectar el uso de la CPU de la aplicación. Puede ver el tiempo de inicio de la aplicación y el tiempo consumido por cada método;
  2. Estadísticas de cálculo del lado del cliente: a través de la llamada de la función clave del gancho, calcule y obtenga los datos de rendimiento. En la actualidad, el monitoreo del rendimiento de la aplicación Zhihu tiene datos de tiempo de inicio y existen herramientas de prueba de rendimiento de terceros similares;
  3. Grabación de pantalla: use métodos como capturas de pantalla, grabaciones de pantalla y grabaciones de cámara de alta velocidad para registrar cambios en la pantalla de dispositivos móviles, analizar los puntos de inicio y final del inicio y obtener el inicio de la aplicación que consume mucho tiempo.

  El método 1 puede obtener con precisión el tiempo que consume cada llamada de método, y la aplicación debe estar firmada por un certificado de desarrollador; de lo contrario, no se puede realizar la prueba;

  El método 2 puede obtener con precisión el consumo de tiempo de cada elemento de inicio, pero es algo diferente de la experiencia real del usuario y necesita obtener el código fuente del cliente e incrustar la herramienta en el cliente;

  El método 3 es consistente con la experiencia intuitiva del usuario, pero es problemático analizar capturas de pantalla y videos, y cuando se encuentra un problema, es imposible ubicar el elemento específico que requiere mucho tiempo de inicio.

  Para la prueba de comparación actual del tiempo de inicio de los productos de la competencia, los métodos 1 y 2 no son adecuados debido a las limitaciones del código fuente y la firma.

  Nota: A veces hay anuncios en la página de inicio y cada aplicación puede tener otros elementos de inicio en el proceso de mostrar el anuncio de inicio. Por lo tanto, debe probarse en dos escenarios, con anuncios y sin anuncios.

  2. Prueba de uso de memoria

  2.1 Principales puntos de prueba

  estado inactivo

  　　Cambie al fondo o no haga nada después del inicio, consumiendo la menor cantidad de memoria.

  estado moderado

  　　Aplicación de operación a largo plazo.

  estado de alta intensidad

  　　Para aplicaciones de alta intensidad, puede ejecutar monkey para probar (generalmente se usa para probar fugas de memoria).

  　　Pérdida de memoria (OOM): se refiere al uso de malloc o new para solicitar una parte de la memoria, pero no liberar la memoria a través de liberar o eliminar, lo que hace que esta parte de la memoria esté ocupada todo el tiempo.

  2.2 Método de prueba

  Usa el comando adb

   adb shell dumpsys meminfo com.tencent.mm

  principales indicadores

    Native heap allocNative: la memoria asignada por el código, la memoria asignada por la máquina virtual y el marco de trabajo de Android.

    Dalvik heap alloc: la memoria ocupada asignada por objetos Java

       Si estos dos valores siguen aumentando, significa que puede haber una pérdida de memoria

     PSS : el tamaño de la memoria que realmente ocupa la aplicación.

  Principal preocupación

  Después de salir de una página determinada, si la memoria retrocede.

     Si no retrocede en el tiempo, y el programa automáticamente GC (Garbage Collection, recolección de basura) o GC manual, entonces se puede confirmar que hay un problema.

  Si la memoria crece demasiado rápido después de realizar una determinada operación.

     Si el crecimiento es demasiado rápido, también puede haber riesgos y se requieren operaciones repetidas para confirmar

  Hay cuatro formas principales de memoria de Android: VSS, RSS, PSS, USS

  En términos generales, el tamaño de uso de la memoria tiene las siguientes reglas: VSS >= RSS >= PSS >= USS

  VSS : tamaño del conjunto virtual, consumo de memoria virtual. Es el tamaño de todas las direcciones de espacio de memoria a las que puede acceder un proceso. Este tamaño incluye
  algo de memoria que no reside en la RAM, ya que se han asignado mallocs pero aún no se han escrito. VSS rara vez se usa para medir la
  memoria real utilizada por el programa.

  RSS : Tamaño del conjunto residente, la memoria física real utilizada. RSS es la cantidad de memoria que un proceso realmente tiene en RAM. RSS puede
  ser engañoso, porque contiene la memoria ocupada por todas las bibliotecas compartidas utilizadas por el proceso, y una biblioteca compartida cargada en la memoria puede tener muchos
  procesos usándola. RSS no es una representación exacta de la cantidad de memoria utilizada por un solo proceso.

  PSS : tamaño de conjunto proporcional, la memoria física real utilizada, es diferente de RSS, asignará la memoria ocupada por la biblioteca compartida en proporción.
  Por ejemplo, si hay tres procesos compartiendo una biblioteca compartida que ocupa 30 páginas de control de memoria, cada proceso solo calculará 10 páginas al calcular el PSS.
  PSS es un valor muy útil, si se suman los PSS de todos los procesos del sistema, la suma resultante es la suma de la memoria ocupada por el sistema. Cuando
  se elimina un proceso, la memoria de la biblioteca compartida que ocupa será compartida por otros procesos que todavía usan la biblioteca compartida. De esta manera, PSS
  también puede ser engañoso, porque cuando se termina un proceso, PSS no representa el tamaño de memoria reclamado por el sistema.

  USS : Unique Set Size, la memoria física ocupada por el proceso solo. Esta parte de la memoria es completamente exclusiva del proceso. USS es un
  número muy útil porque muestra el verdadero costo de memoria para ejecutar un proceso en particular. Cuando se termina un proceso, USS es toda
  la memoria recuperada por el sistema. USS es la mejor opción para verificar si hay una pérdida de memoria en el proceso.

  Memoria

  JAVA se ejecuta en el entorno de memoria virtualizado por la JVM.La memoria de la JVM se puede dividir en tres áreas, montón (heap), stack (pila) y área de método (método).

  pila

  Es la estructura de datos más simple, pero es ampliamente utilizada en computadoras. La característica más notable de la pila es: LIFO (último en entrar, primero en salir), solo las referencias de tipos y objetos básicos (no objetos) se almacenan en la pila

  montón

  La memoria del montón se usa para almacenar objetos y arreglos creados por new. La memoria asignada en el montón es administrada por el recolector de basura automático de la máquina virtual Java. La JVM tiene solo un área de almacenamiento dinámico compartida por todos los subprocesos. Los tipos básicos y las referencias a objetos no se almacenan en el almacenamiento dinámico, solo se almacena el objeto en sí.

  Área de método (método)

  También llamada área estática, como el montón, todos los subprocesos la comparten. El área de métodos contiene todas las variables estáticas.

  pérdida de memoria

  Después de que el programa se aplica al sistema para asignar espacio de memoria (nuevo), no se libera después de su uso. Como resultado, la unidad de memoria siempre está ocupada y ni nosotros ni el programa podemos usar la unidad de memoria hasta que finalice el programa.

  sin memoria

  El espacio de memoria solicitado por el programa del sistema excede lo que el sistema puede proporcionar. Por ejemplo, un automóvil puede acomodar hasta 5 personas. Si realmente necesita empacar 10 personas, el automóvil estará abarrotado.

  Una gran cantidad de fugas de memoria puede provocar falta de memoria (OOM)

  Impacto de las fugas de memoria en las aplicaciones

  Las fugas de memoria no dañan directamente la APLICACIÓN, incluso si se encuentra una fuga de memoria, no necesariamente hace que la APLICACIÓN se bloquee

  Si no se puede liberar la memoria, la memoria de la aplicación se desbordará lentamente y se bloqueará.

  Al mismo tiempo, las fugas de memoria desencadenarán un GC frecuente del sistema y se producirá una fluctuación de la memoria, lo que provocará problemas de rendimiento (atascado y no fluido)

  3. Prueba de CPU ocupada

  3.1 Principales puntos de prueba

  Consumo durante el tiempo de inactividad (cambio al segundo plano), básicamente ninguna aplicación importante utiliza la CPU

  En el caso de ejecutar algunas aplicaciones, la CPU ha representado el 50%, observe el uso de la CPU de la aplicación

  Observe el rendimiento de la CPU en condiciones de alta carga (el uso de la CPU debe ser superior al 80%)

  3.2 Escenarios específicos

  Aplicación que se ejecuta en estado inactivo para monitorear el uso de la CPU

     La aplicación presiona el botón Home para salir al fondo y ya no ocupa el estado del sistema (generalmente medio minuto después de que la pantalla se apague)

     Utilización de CPU = 0%

  Aplicación de especificaciones medias en ejecución para monitorear el uso de la CPU

     Simule los escenarios de uso más comunes para los usuarios

     Uso de CPU≤30%

  Supervisar la tasa de uso de la CPU cuando la aplicación se ejecuta normalmente durante mucho tiempo con especificaciones completas

     La aplicación se ejecuta normalmente, abra la aplicación para operaciones básicas

     Uso de CPU≤50%

  3.3 Método de prueba

  adb shell dumpsys cpuinfo apk nombre del paquete

  adb capa superior -m -s | findstr nombre del paquete

   -m número

     Muestra el valor máximo del número especificado, generalmente no seguido de findstr

     El uso de -m hace que los nombres de las columnas se oculten

   -s número

     Ordenar en orden inverso por el número de columna especificado

     A partir del 1, hasta el 11

      9 significa CPU, 10 significa memoria

   -n número

      Salir después de actualizar varias veces

   -d número de segundos

     intervalo de actualización

   q Entrar

     abandonar

  4. Prueba de fluidez de la aplicación FPS

  Frame Rate: representa la cantidad de cuadros que dibuja la GPU en un segundo, por ejemplo: 30 fps, 60 fps

  Frecuencia de actualización: representa la cantidad de veces que la pantalla se actualiza en un segundo, lo que depende de los parámetros fijos del hardware, como 60 HZ.

  (1) Configuración de renderizado de GPU de perfil abierto→Sistema→Avanzado→Opciones de desarrollador→buscar perfil→buscar y hacer clic en Renderizado de GPU de perfil→In adb shell dumpsys gfxinfo

  (2) Abra la aplicación para probarla

  adb shell dumpsys gfxinfo nombre del paquete

   Información de gráficos para pid 1331 [com.tencent.mm]: indica que la información del marco del volcado actual es com.tencent.mm y el pid es 1331.

   Total de cuadros renderizados: 2218: Este volcado recopiló información de 2218 cuadros.

   Tramas Janky: 26 (1,17%): 26 de las tramas tardaron más de 16ms, y la probabilidad de Janky fue de 1,17%.

   Número de Vsync perdido: 3: fotogramas en los que falla la sincronización vertical

   Número de latencia de entrada alta: 2213: Procesando el cuadro cuyo tiempo de entrada excede

   Número de subprocesos de interfaz de usuario lentos: 1: porque el subproceso de interfaz de usuario provoca fotogramas lentos

   Número de subidas lentas de mapas de bits: 0: porque el mapa de bits carga fotogramas lentos

   Número de comandos de dibujo de emisión lenta: 3: fotogramas que causan lentitud debido al dibujo

   Draw: Indica el tiempo que tarda el método OnDraw() en la parte de crear la lista de visualización en Java.

   Preparar: Indica el tiempo de preparación del motor de renderizado.

   Proceso: Indica el tiempo que tarda el motor de renderizado en ejecutar la lista de visualización, cuantas más vistas, más tiempo.

   Ejecutar: Indica el tiempo real que se tarda en enviar un cuadro de datos a la pantalla para su diseño y visualización. De hecho, es el momento de mostrar el contenido del búfer frontal en la pantalla después de que el búfer posterior que realmente muestra los datos del cuadro se intercambie con el búfer frontal.

   Dibujar + Preparar + Procesar + Ejecutar = mostrar completamente un cuadro, este tiempo debe ser inferior a 16 ms para guardar 60 cuadros por segundo.

  El procesamiento de formularios a través de execl puede verificar visualmente la fluidez del software

  Solo mantenga Procesar, Dibujar y Ejecutar, y agregue las tres columnas para dibujar un gráfico de líneas; si el retraso es superior a 16 ms, debe optimizarse

   Configuración→Sistema→Avanzado→Opciones de desarrollador→buscar perfil→en pantalla como barras Los resultados se muestran en el dispositivo en forma gráfica

      Después de activar esta función, a medida que se actualiza la pantalla, se desplazará un histograma vertical en la interfaz para indicar el tiempo de procesamiento de cada cuadro. Cuanto más alto sea el histograma, más largo será el tiempo de procesamiento.

      Cada barra representa un cuadro, y la altura de cada barra representa el tiempo (en milisegundos) que tardó ese cuadro en procesarse

     Una línea verde horizontal en el medio de la interfaz representa 16 ms, y la línea de columnas de cada cuadro está debajo de esta línea verde para evitar la congelación causada por la pérdida de cuadros.

   Significado del color (sección de barra vertical en Android 6.0 y superior)

  5. Prueba de renderizado excesivo de GPU

  Habilitar sobreprocesamiento de GPU

  Configuración→Opciones de desarrollador→Haga clic en Depurar sobredibujado de GPU→Seleccione mostrar áreas sobredibujadas

   Representación de transición de GPU Los diferentes colores representan diferentes niveles de dibujo

  Colores Primarios: Pintados sin transiciones

  Azul: dibujar una vez (estado ideal)

  Verde: dibujar dos veces

  Rojo claro: dibujado tres veces (se puede optimizar)

  Carmesí: dibujado cuatro veces (debe optimizarse)

  Indicadores de prueba

   Control de transición dibujar a 2x

   No permitir que se dibujen transiciones 4x

  No permita el dibujo de transición 3x cuya área exceda 1/4 de la pantalla

  6. Adquisición de datos de tráfico

  Primero obtenga el comando de proceso adb shell ps | nombre del paquete grep

  Obtener tráfico: adb shell cat /proc/process name/net/dev

  recibir significa recibir paquetes (enlace descendente)

  Transmitir significa recibir paquetes (enlace ascendente)

  bytes indica el número de bytes enviados y recibidos

  paquetes indica la cantidad correcta de paquetes enviados y recibidos

  errs: Indica el volumen de paquetes de envío y recepción de errores

  drop indica la cantidad de paquetes descartados al enviar y recibir

  7. Adquisición de datos de potencia

  adb shell dumpsys conjunto de batería estado 1 (configure el teléfono para ingresar al estado sin carga y 2 al estado de carga) 

  db shell dumpsys batería (obtener energía) nivel significa energía

  8. Cómo realizar pruebas especiales de rendimiento

  1) ¿Cuándo comenzará?

  En general, solo se realizan iteraciones de versiones principales u optimizaciones clave de rendimiento.

  2) ¿Sobre qué base se basa la prueba?

  Versiones históricas y productos de la competencia

  3) ¿Cuándo se llevará a cabo?

  En general, no se requieren revisiones importantes después de la primera ronda de pruebas.

  4) ¿Qué escenas quieres?

  La escena central de la aplicación necesita ser optimizada

  5) ¿Qué paquete debe probarse?

  En general, prueba el paquete oficial, la reacción es realmente la sensación corporal del usuario.

  6) ¿Cuántas rondas medir?

  En general, hay una ronda de pruebas formales y el resto depende del desarrollo y la optimización.

  9. Proceso de prueba especial de rendimiento

  1) Seguimiento de la versión para determinar los requisitos de prueba de rendimiento de esta versión

  2) Determinar los escenarios de prueba y los puntos de enfoque con el desarrollo, y determinar los datos de referencia y los métodos de prueba

  Datos de referencia: los datos óptimos y los datos de productos de la competencia de las tres primeras versiones

  3) Ejecutar prueba de rendimiento para recopilar datos

  4) Escriba un informe de prueba de rendimiento

  10. Informe de prueba de rendimiento especial

  1) Información básica: versión/modelo de prueba/escenario de prueba/escenario de referencia

  2) Visión general del problema: lista de problemas específicos

  3) Lista de datos especiales de rendimiento específico

  4) Sugerencias/riesgos de reparación

  Ejemplo: