Reporte perfilamiento de la app
El objetivo del siguiente reporte es anticipar y detectar problemas de desempeño que se puedan presentar en la aplicación Vinilos y que eventualmente puedan desencadenar en GUI lags, errores de tipo ANR, Memory bloats/OOM que a su vez puedan desencadenas igualmente en consumos importante de energía.
Para la realización del siguiente reporte se utilizó la herramienta Profiler de Android para las siguientes métricas:
-CPU -Memoria -Threads/Corrutinas y asignación de CPU
- API 32 - Tiramisu - Motorola Droid Maxx
- API 31 - Snow Cone - Samsung Galaxy S7
- API 30 - Red Velvet Cake - Emulador
Las siguientes gráficas muestran los resultados realizados por la herramienta Profiler. En la ejecución del perfilamiento se navegaron todas las pantallas en el siguiente orden:
| Paso | Pantalla | Funcionalidad |
|---|---|---|
| 1 | Selección de tipo de usuario | Se inicia la app, se despliega el layout y se hace click en el botòn "visitante" |
| 2 | Listado de álbumes | Se hace scroll via swipe gesture, se seleccciona el último álbum |
| 3 | Detalle de álbum | Se presiona el botón coleccionistas en la navegación principal |
| 4 | Listado de coleccionistas | Se presiona el botón Artistas en la navegación principal |
| 5 | Listado de artistas | Se selecciona el primer artista del listado |
| 6 | Detalle de artista | Se visualiza el contenido, se presiona el botón regresar dos veces |
| 7 | Selección de tipo de usuario | Se inicia la app, se despliega el layout y se hace click en el botòn "visitante" |
| 8 | Listado de álbumes | Se hace scroll via swipe gesture, se seleccciona el último álbum |
- Consumo de CPU y memoria
Observaciones: No hay un consumo significativo de CPU y memoria. Sin embargo, no se espera una asignación de memoria inicial de 128MB, se procede a revisar otras gráficas para detectar la posible causa.
2. Asignaciones de memoria
3. Consumo de CPU y threads (%)
4. Asignación de memoria por componente
- Tabla de asignación de memoria
Observaciones: De nuevo se observa un consumo adecuado de memoria en la actividad principal (MainActivity). Sin embargo se observa una asignación adicional cada vez que se realizan las siguientes acciones tanto como de procesamiento (CPU) como de asignación de memoria : Pantalla de de selección de usuario (pasos 1 y 7). Adicional a esto hay una asignación reiterativa de memoria cada vez que se despliega la información en los listados y en los detalles.
Conclusiones y bugs reportados:
-
La aplicación no tiene problemas importantes, ya que antes de las pruebas ya se venía haciendo uso de corutinas que permite separar los hilos de ejecución tanto en los viewmodels (viewModelScope.launch) y funciones suspendcomo parte de la libreria Retrofit (i.e suspend fun getAlbums(): List)
-
Se detecta un consumo adicional tanto de procesamiento como de consumo de memoria en la pantalla de selección de usuario. El problema no está ubicado necesariamente en el hilo para el render (GUI) ademas de verificar que no existen assets grandes (i.e imagenes), pero si se detecta que está en código (code). Se revisan los assets de código y se determina que existe código SVG demasiado granular para el logo, impactando principalmente en el procesamiento y la asignacion en memoria adicional de todos sus nodos SVG relacionados. Se abre un ticket con el fin de optimizar el svg. Ir a la incidencia
-
El procesamiento adicional que se detecta cada vez que se carga el contenido dinámico no debería hacerse todo el tiempo. por lo que se determina que utilizar cache evita hacer el roundtrip innecesario al servidor y su posterior procesamiento cada vez que se carga la información. Ir a la incidencia