Reporte perfilamiento de la app sprint III
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.
Igual que en el sprint anterior, 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 |
| 9 | Listado de álbumes | Se hace click en el botón crear álbum y se crea un nuevo álbum |
| 9 | Listado de álbumes | Se hace click en un album y desde este se crea un comentario |
- Consumo de CPU y memoria
Observaciones:
No hay un consumo significativo de CPU y memoria. Hay que tener en cuenta las optimizaciones que se hicieron en el sprint anterior de acuerdo al primer perfilamiento de la app, y que dichos cambios se replicaron para las mismas funcionalidades del sprint III, por lo que no se esperan mayores inconvenientes.
2. Asignaciones de memoria
3. Consumo de CPU y threads (%)
Observaciones: De nuevo se observa un consumo adecuado de memoria en la actividad principal (MainActivity).
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)
-
En el sprint anterior se implementó a la arquitectura un caché de datos que dio la pauta a nivel de arquitectura para que en el sprint actual las nuevas funcionalidades también se veneficiaran del mismo.