Perfilamiento de la app - sjfuentes-uniandes/ing-sw-app-moviles GitHub Wiki

Perfilamiento dispositivo 1

Características dispositivo 1

  • Google Pixel 9
  • RAM: 12GB

Las capturas muestran siempre:

  • Izquierda: versión antes de las optimizaciones.
  • Derecha: versión después de las optimizaciones.

CPU y memoria – antes vs después

Consumo de memoria (Java/Kotlin Allocations) – antes vs después

Las micro-optimizaciones implementadas se pueden revisar en esta página

Análsis de la gráfica

CPU y memoria en tiempo real

Referencia: primera imagen (CPU + MEMORY).

Observaciones de CPU (LIVE_CPU):

  • La versión optimizada (derecha) mantiene un patrón de uso de CPU más estable, con picos menos agresivos.
  • El trabajo del hilo principal durante actualizaciones de listas es menor:
    • Con notifyDataSetChanged() se re-pintaban todos los ítems.
    • Con DiffUtil + setHasFixedSize(true) solo se actualizan los elementos que cambian y se evita recalcular el tamaño del RecyclerView.

Conclusión CPU:

  • Las optimizaciones son micro, por lo que no se ve una caída dramática de CPU total, pero sí:
    • Menos picos.
    • Carga más repartida.
    • Menos riesgo de “jank” (saltos de frames) al hacer scroll o refrescar.

Uso total de memoria (heap)

Referencia: primera imagen y segunda imagen (MEMORY + Java/Kotlin Allocations).

En la gráfica de MEMORY:

  • Antes de las optimizaciones la curva:
    • Llega más cerca del rango alto (256–384 MB).
    • Muestra incrementos más bruscos.
  • Después de las optimizaciones:
    • El uso efectivo de memoria se mantiene más bajo y estable.
    • La pendiente de crecimiento es más suave, lo que indica:
      • Menos objetos retenidos a largo plazo.
      • Menos presión sobre el Garbage Collector.

Contribuyen a esto:

  • Glide usando URLs válidas y placeholders directos (menos objetos temporales y menos decodificaciones “en vacío”).
  • Menos recreación masiva de ViewHolder/views gracias a DiffUtil.
  • Limpieza de drawables y recursos no utilizados.

Java / Kotlin Allocations

Referencia: segunda imagen: Track Memory Consumption (Java/Kotlin Allocations).

  • El número total de asignaciones Java/Kotlin es del mismo orden antes y después (ambas ejecuciones rondan ~1.x M allocations).
  • La diferencia está en cómo se comporta el heap:
    • Antes: patrón con más “dientes de sierra” y variaciones fuertes en los segmentos de memoria.
    • Después: curvas más suaves y un uso más uniforme de las regiones de memoria.

Interpretación:

  • Aunque el número bruto de allocations no cambia de forma extrema (la pantalla sigue haciendo lo mismo funcionalmente), las optimizaciones:
    • Reducen el tamaño o duración de ciertos objetos.
    • Evitan allocations inútiles (URLs vacías, requests que no se usan).
    • Permiten que el GC recicle memoria de forma más eficiente.

Resultado práctico:

  • Menos pausas de GC visibles.
  • Menos riesgo de OutOfMemory en dispositivos con poca RAM.
  • Comportamiento más predecible del heap a lo largo del tiempo.

Perfilamiento dispositivo 2

Características dispositivo 2

  • Oppo Reno13F
  • RAM: 12GB

Las capturas muestran siempre:

  • Izquierda: versión antes de las optimizaciones.
  • Derecha: versión después de las optimizaciones.

CPU y memoria – antes vs después

Consumo de memoria (Java/Kotlin Allocations) – antes vs después

Las micro-optimizaciones implementadas se pueden revisar en esta página

🎯 Optimizaciones Implementadas

Componente Cambio Beneficio Esperado
ArtistsAdapter notifyDataSetChanged() → DiffUtil Menos re-binds, menos allocations
RecyclerView Agregado setHasFixedSize(true) Sin re-mediciones innecesarias
Layout Detalle Botón 32→48dp, fuente auto-resize, imagen 250→200dp Mejor UX y menos memoria

📊 Resultados Comparativos

Métrica CON Optimizaciones SIN Optimizaciones Mejora
RAM Pico 163 MB ~185 MB -12% (22 MB) ✅
Allocations (scroll) ~850 objetos ~2,100 objetos -60% ✅
Frames Jank (>16ms) 6.41% ~11.8% -46% ✅
CPU Promedio (scroll) ~22% ~35% -37% ✅
Tiempo navegación ~180ms ~240ms -25% ✅
Eventos GC (32s) 0-1 2-3 -50% ✅

✅ Conclusiones

Las optimizaciones implementadas mejoran significativamente el rendimiento:

  1. Memoria: Reducción del 12% (22 MB) gracias a DiffUtil (-60% allocations) y imagen optimizada (-4MB)
  2. Fluidez: Mejora del 46% en frames con jank, transiciones 25% más rápidas
  3. CPU: Reducción del 37% en uso durante scroll por DiffUtil y setHasFixedSize
  4. Estabilidad: 50% menos eventos GC, memoria más estable

Resumen: Las optimizaciones reducen consumo de memoria en 12%, mejoran fluidez en 46%, y reducen CPU en 37%, resultando en mejor experiencia de usuario.

Perfilamiento dispositivo 3

Características dispositivo 3

  • Vivo y38
  • RAM: 8GB

Las capturas muestran siempre:

  • Izquierda: versión antes de las optimizaciones.
  • Derecha: versión después de las optimizaciones.

CPU y memoria – antes vs después

Consumo de memoria (Java/Kotlin Allocations) – antes vs después

Las micro-optimizaciones implementadas se pueden revisar en esta página

2) Resultados Comparativos

Métrica CON Optimizaciones SIN Optimizaciones Mejora
RAM Pico (PSS) 103.37 MB 106.67 MB -3.09% (3.3 MB) ✅
Java Heap 11.94 MB 17.86 MB -33.15% (5.92 MB) ✅
Code Size 30.11 MB 31.29 MB -3.77% (1.18 MB) ✅
Frames Jank (>16ms) 8.30% ~11-12% -28% ✅
Frame Time (p50) 11 ms ~12-13 ms -8 a -15% ✅
Frame Time (p90) 17 ms ~18-20 ms -5 a -15% ✅

3) Conclusiones

✅ Mejoras Significativas

  • Reducción de memoria Java Heap (-33.15%): Ahorro de 5.92 MB gracias a R8, ViewBinding y gestión eficiente de recursos.

  • Menor consumo total de RAM (-3.09%): Ahorro de 3.3 MB en memoria total del proceso.

  • Código optimizado (-3.77%): Reducción de 1.18 MB por minificación y eliminación de código no utilizado.

  • Rendimiento gráfico fluido: Frames Janky de 8.30%, dentro del objetivo (<10%). La mayoría de frames se renderiza en 10-12 ms (objetivo: <16 ms para 60 FPS).

  • Sin memory leaks detectados: Arquitectura limpia con Single Activity y MVVM.