📊 Informe de Perfilamiento de Aplicación – Proyecto: Vinilos

Fecha de Análisis: 5 de mayo de 2025
Dispositivo de Prueba: Pixel 7 – Android API 36
Herramientas Utilizadas: Android Studio Profiler (CPU, Heap Dump, Native Memory)
Nombre del Proyecto: vinilos

---

1. 🔍 Análisis de Uso de CPU

✔ Metodología

Se utilizó la herramienta "Find CPU Hotspots" para detectar métodos de Java/Kotlin con mayor uso de CPU durante la ejecución normal de la aplicación.

📌 Observaciones Principales

• Carga constante en el hilo principal (main), con múltiples picos de procesamiento.
• El método loopOnce() del Looper destaca con 58,813,747 μs, lo que indica procesamiento repetitivo o tareas pesadas en el hilo de la UI.
• Métodos como nextLegacy(), nativePollOnce() y dispatchMessage() también muestran alta actividad.
• dispatchMessage() consume el 51.33% del tiempo hijo de loopOnce(), lo cual revela que los mensajes/callbacks en la UI son costosos.

✅ Recomendaciones

• Revisar qué tareas se ejecutan en los Handlers o callbacks de UI.
• Externalizar operaciones pesadas del hilo principal usando Coroutine, ExecutorService, o WorkManager.
• Usar herramientas como StrictMode para identificar operaciones bloqueantes.

---

2. 🧠 Análisis de Memoria Nativa

✔ Metodología

Se usó el perfilador de "Native Allocations" para rastrear el consumo de memoria en procesos gráficos y nativos.

📌 Observaciones Principales

• El hilo android.ui.renderthread.RenderThread muestra uso intensivo de memoria nativa.
• Actividad frecuente de métodos como CanvasContext::draw(), GrDirectContext::flushSurfaces() y funciones de OpenGL (glBufferData).
• Alta asignación de memoria a través de malloc, operator new, y elementos de Skia (SkDrawable, SkCanvas, GrRenderTask).
• Indicios de dibujado excesivo o poco optimizado en la UI.

✅ Recomendaciones

• Evitar redibujos innecesarios, revisando llamadas a invalidate() o requestLayout().
• Optimizar el uso de Canvas, Bitmap y otras operaciones gráficas.
• Utilizar bibliotecas como Glide o Coil para gestión de imágenes eficiente.

---

3. 🗃 Análisis de Heap Dump

✔ Metodología

Análisis realizado mediante Heap Dump en tiempo de ejecución, usando agrupación por clase.

📌 Observaciones Principales

Clase	Retained Size	Instancias
EmojiCompat	352,389 bytes	1
MaterialButton	12,493 bytes	66
MaterialTextView	11,193 bytes	64
RecyclerView	11,197 bytes	10
LinearLayout	9,639 bytes	96
CardView	9,505 bytes	9

• EmojiCompat ocupa una cantidad significativa de memoria retenida, aunque solo tiene una instancia.
• Varias vistas (MaterialButton, TextView, RecyclerView, LinearLayout) tienen un peso considerable.

✅ Recomendaciones

• Evaluar si EmojiCompat es necesario. Considerar desactivarlo si no se utiliza.
• Reducir el uso de layouts anidados: optar por ConstraintLayout.
• Utilizar ViewStub o include para mejorar eficiencia.
• Optimizar adaptadores y vistas reciclables como RecyclerView.

---

4. 📌 Conclusiones Generales

Aspecto Analizado	Resultado / Estado	Recomendaciones
Hilo Principal (UI)	Saturado con tareas repetitivas	Mover lógica pesada a hilos secundarios
CPU	Consumo elevado en dispatchMessage()	Revisar callbacks registrados
Memoria Nativa	Carga alta en RenderThread y Skia	Optimizar renderizado gráfico
Heap Dump	Uso ineficiente de vistas y componentes	Minimizar layouts anidados y vistas innecesarias

---

🛠 Herramientas y Buenas Prácticas Recomendadas

• StrictMode: para detectar operaciones de I/O en el hilo principal.
• Memory Profiler: para seguimiento en tiempo real del uso de memoria.
• Systrace / Perfetto: para visualizar cuellos de botella en ejecución.
• LeakCanary: para detección automática de fugas de memoria.

---