CacheManager es un Singleton thread-safe (@Volatile + synchronized) ubicado en app/.../network/CacheManager.kt. Es consumido por los Repositories mediante CacheManager.getInstance(context):

Cada Repository aplica el patrón Cache-Aside: consulta primero el CacheManager y solo va a red si no hay datos. Ejemplo real del código (AlbumRepositoryImpl):

override suspend fun getAlbums(): List<Album> {
    val potentialResp = CacheManager.getInstance(context).getAlbums()
    return if (potentialResp.isEmpty()) {
        Log.d("Cache decision", "get albums from network")
        val albums = remoteDataSource.fetchAlbums()
        CacheManager.getInstance(context).addAlbums(albums)
        albums
    } else {
        Log.d("Cache decision", "return ${potentialResp.size} albums from cache")
        potentialResp
    }
}

El fin es evitar llamadas HTTP repetidas cuando los datos ya fueron obtenidos durante la sesión.

• Velocidad de navegación: Accesos repetidos a la misma pantalla se resuelven en memoria (~ms) sin esperar respuesta de red (~1-2s).
• Reducción de transferencia de datos: Solo se descarga la primera vez; navegaciones subsecuentes no generan tráfico.
• Menor uso de radio (batería): Menos conexiones HTTP activas = menos tiempo con radio LTE/WiFi encendida.
• Fluidez en UI: Los ViewModels reciben datos inmediatos, LiveData se actualiza sin delays perceptibles.

Configurado en app/.../MyAppGlideModule.kt con integración OkHttp3. Se consume en 4 componentes de UI:

Configuración real:

@GlideModule
class MyAppGlideModule : AppGlideModule() {
    override fun registerComponents(context: Context, glide: Glide, registry: Registry) {
        val client = OkHttpClient.Builder()
            .addInterceptor { chain ->
                val request = chain.request().newBuilder()
                    .header("User-Agent", "Mozilla/5.0")
                    .build()
                chain.proceed(request)
            }
            .build()
        registry.replace(GlideUrl::class.java, InputStream::class.java,
            OkHttpUrlLoader.Factory(client))
    }
}

Glide gestiona automáticamente un caché de dos niveles (memoria LRU + disco) para imágenes. El fin es:

• Evitar descargar la misma imagen más de una vez por sesión (memory cache).
• Conservar imágenes entre sesiones (disk cache).
• Desacoplar la carga de imágenes del hilo principal de UI.

• Scroll fluido: Las imágenes ya cargadas se muestran instantáneamente al hacer scroll, sin flicker ni reloads.
• Ahorro de datos: Imágenes (típicamente 20-100 KB cada una) se descargan una sola vez y se reutilizan.
• Gestión de memoria automática: Glide usa LRU — libera imágenes menos usadas cuando la memoria lo requiere, sin intervención del desarrollador.
• Carga asincrónica: Las imágenes se cargan en background; la UI no se bloquea mientras se descargan o decodifican.

┌──────────────────────────────────────────────────────────┐
│ UI Layer                                                 │
│  AlbumListFragment · AlbumDetailFragment                 │
│  MusicianListFragment · MusicianDetailFragment           │
│  CollectorListFragment                                   │
└───────────────────────────┬──────────────────────────────┘
                            │ observa LiveData
                            ▼
┌──────────────────────────────────────────────────────────┐
│ ViewModels                                               │
│  AlbumViewModel · AlbumDetailViewModel                   │
│  MusicianViewModel · MusicianDetailViewModel             │
│  CollectorViewModel                                      │
└───────────────────────────┬──────────────────────────────┘
                            │ suspend fun
                            ▼
┌──────────────────────────────────────────────────────────┐
│ Repository Layer (lógica Cache-Aside)                    │
│  AlbumRepositoryImpl                                     │
│  MusicianRepositoryImpl                                  │
│  CollectorRepositoryImpl                                 │
└──────────┬────────────────────────────────┬──────────────┘
           │                                │
     Cache Hit                        Cache Miss
           │                                │
           ▼                                ▼
┌─────────────────────┐         ┌─────────────────────────┐
│ CacheManager        │         │ RemoteDataSource        │
│ (Singleton)         │         │  → Retrofit + OkHttp3   │
│                     │         │  → Backend API          │
│ albums: List        │         └────────────┬────────────┘
│ musicians: List     │                      │
│ collectors: List    │◄─────────────────────┘
│ albumDetails: Map   │     guarda en caché
│ musicianDetails: Map│
│ performerPrizes: Map│
└─────────────────────┘

┌──────────────────────────────────────────────────────────┐
│ Glide (paralelo, en UI Layer)                            │
│                                                          │
│  ImageView.load(url)                                     │
│       ↓                                                  │
│  Memory LRU → Disk Cache → Network (OkHttp3)            │
│       ↓           ↓              ↓                       │
│    instant     ~10-50ms      ~500-1500ms                 │
└──────────────────────────────────────────────────────────┘

Referencia: Perfilamiento y resultados Sprint 2.xlsx

Las estrategias de caché implementadas se correlacionan directamente con mejoras en las métricas de rendimiento:

• Tiempo de respuesta de pantallas: El patrón Cache-Aside reduce la latencia de accesos repetidos de ~1-2 segundos (red) a milisegundos (memoria). Cualquier medición de tiempo de carga en segunda visita debería reflejar esta mejora.
• Consumo de memoria: El footprint de CacheManager es bajo (listas y mapas de objetos ligeros). Glide gestiona su propia memoria con LRU adaptativo. No se observa degradación por uso de caché.
• Transferencia de red: Las llamadas HTTP se reducen significativamente — solo se ejecutan en cache-miss (primera carga). Esto es verificable en las métricas de red del perfilamiento.

El caching actúa como estrategia de optimización de recursos al intercambiar un mínimo de memoria (~KB) por ahorro sustancial en tiempo, datos y energía.

La aplicación utiliza dos estrategias de caching complementarias:

Ambas operan de forma transparente para la UI: los ViewModels y Fragments consumen datos sin conocer si provienen de caché o de red. La decisión se centraliza en la capa Repository (datos) y en Glide (imágenes), lo que mantiene la arquitectura limpia y la lógica de caching aislada.

El resultado es una aplicación que responde rápido en navegaciones frecuentes, consume menos datos móviles y optimiza el uso de batería — todo con un costo de memoria negligible.

Tecnologías: Glide 5.0.7 · OkHttp3 5.3.2 · Retrofit2 3.0.0 · Kotlin Coroutines