Las estrategias implementadas en el Sprint 2 se mantienen como base del sistema de caché de la aplicación:

El patrón Cache-Aside sigue operando en todos los repositorios existentes:

Caso optimizado: En el Sprint 2, CacheManager requería un Context como parámetro en cada llamada a getInstance(context), acoplando el sistema de caché a la capa de Android y dificultando su uso en capas de datos puras.

Optimización implementada: CacheManager fue refactorizado para ser independiente del contexto. Todas las llamadas pasaron de:

// Sprint 2
CacheManager.getInstance(context).getAlbums()
CacheManager.getInstance(context).addAlbums(albums)

a:

// Sprint 3
CacheManager.getInstance().getAlbums()
CacheManager.getInstance().addAlbums()

Beneficio: El CacheManager ahora puede ser consumido desde cualquier capa sin necesidad de propagar el Context, simplificando los repositorios y reduciendo el acoplamiento arquitectural.

La consulta del detalle de un coleccionista fue una funcionalidad añadida en este sprint. Siguiendo el patrón establecido por las micro-optimizaciones, el detalle de un coleccionista también es guardado en caché:

override suspend fun getCollectorById(id: Int): Collector {
    val potentialResp = CacheManager.getInstance().getCollectorDetail(id)
    return if (potentialResp == null) {
        Log.d("Cache decision", "get collector $id from network")
        val collector = remoteDataSource.fetchCollectorById(id)
        CacheManager.getInstance().addCollectorDetail(id, collector)
        collector
    } else {
        Log.d("Cache decision", "return collector $id from cache")
        potentialResp
    }
}

Beneficio observable: La segunda apertura del detalle de un coleccionista resuelve su información en memoria (~ms) sin llamadas a red, reduciendo la latencia percibida y el consumo de datos.

Para el formulario de creación de un álbum, como existe la posibilidad de obtener los géneros y sellos discográficos de manera remota, se incorporó caché para almacenar sus datos. Ejemplo:

override suspend fun getGenres(): List<String> {
    val potentialResp = CacheManager.getInstance().getGenres()
    return if (potentialResp.isEmpty()) {
        Log.d("Cache decision", "get genres from network")
        val genres = remoteDataSource.fetchGenres()
        CacheManager.getInstance().addGenres(genres)
        genres
    } else {
        Log.d("Cache decision", "return ${potentialResp.size} genres from cache")
        potentialResp
    }
}

Beneficio observable: La segunda apertura del formulario de creación resuleve géneros y sellos en memoria (~ms) sin llamadas a red, reduciendo la latencia percibida y el consumo de datos.

Caso optimizado: En el Sprint 2, el caché no se invalidaba al crear o modificar datos, lo que podía ocasionar que la app mostrar información obsoleta tras una operación de escritura exitosa.

Optimización implementada: Se incorporó invalidación selectiva del caché en las operaciones de mutación de AlbumRepositoryImpl:

override suspend fun createAlbum(album: AlbumRequest): Album {
    val result = remoteDataSource.createAlbum(album)
    // Clear albums cache to force refresh
    CacheManager.getInstance().clearAlbums()
    return result
}

override suspend fun addTrack(albumId: Int, track: TrackRequest): Track {
    val result = remoteDataSource.addTrack(albumId, track)
    // Clear album detail cache to force refresh
    CacheManager.getInstance().clearAlbumDetail(albumId)
    return result
}

Beneficio: Garantiza consistencia entre los datos mostrados en UI y el estado real del backend después de cualquier operación de escritura, evitando que el usuario vea datos obsoletos.

┌──────────────────────────────────────────────────────────┐
│ UI Layer                                                 │
│  AlbumListFragment · AlbumDetailFragment                 │
│  AlbumCreateFragment · TrackAssociateFragment            │
│  MusicianListFragment · MusicianDetailFragment           │
│  CollectorListFragment                                   │
└───────────────────────────┬──────────────────────────────┘
                            │ observa LiveData
                            ▼
┌──────────────────────────────────────────────────────────┐
│ ViewModels                                               │
│  AlbumViewModel · AlbumDetailViewModel                   │
│  AlbumCreateViewModel · TrackAssociateViewModel          │
│  MusicianViewModel · MusicianDetailViewModel             │
│  CollectorViewModel                                      │
└───────────────────────────┬──────────────────────────────┘
                            │ suspend fun
                            ▼
┌──────────────────────────────────────────────────────────┐
│ Repository Layer (lógica Cache-Aside + Invalidación)     │
│  AlbumRepositoryImpl                                     │
│  MusicianRepositoryImpl                                  │
│  CollectorRepositoryImpl                                 │
└──────────┬──────────────────────────┬────────────────────┘
           │                          │
     Cache Hit                  Cache Miss / Escritura
           │                          │
           ▼                          ▼
┌─────────────────────┐   ┌─────────────────────────┐
│ CacheManager        │   │ RemoteDataSource        │
│ (Singleton)         │   │  → Retrofit + OkHttp3   │
│ sin Context ← NUEVO │   │  → Backend API          │
│                     │   └────────────┬────────────┘
│ albums: List        │                │
│ musicians: List     │◄───────────────┘
│ collectors: List    │   guarda en caché
│ albumDetails: Map   │
│ musicianDetails: Map│
│ performerPrizes: Map│
│ genres: List     ← NUEVO Sprint 3
│ recordLabels: List ← NUEVO Sprint 3
│                     │
│ clearAlbums()    ← NUEVO: invalidación
│ clearAlbumDetail()← NUEVO: invalidación
└─────────────────────┘

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

Referencia: Perfilamiento y resultados Sprint 3.xlsx

Las estrategias de caching implementadas se correlacionan directamente con cambios observables en las métricas de memoria y concurrencia obtenidas durante el perfilamiento:

• Gestión de hilos y concurrencia: El uso de CacheManager, Glide y caching de servicios Retrofit reduce operaciones repetitivas de red y recreaciones innecesarias de objetos, contribuyendo a estabilizar parcialmente la cantidad de hilos en varias HUs, especialmente en Android 13. En Android 15 y 16 el comportamiento es más variable debido a mecanismos internos de scheduling y administración de tareas.

• Consumo de memoria: La reutilización de datos cacheados y de objetos pesados como SimpleDateFormat ayuda a disminuir recreaciones innecesarias en memoria. Sin embargo, optimizaciones como RecyclerView y DiffUtil requieren estructuras auxiliares para reciclar vistas y calcular diferencias, por lo que algunas HUs presentan incrementos moderados de RAM, particularmente en Android 15 y 16.

• Renderizado y trabajo de UI: La reutilización de datos en caché reduce recargas completas de pantallas y solicitudes HTTP redundantes. Adicionalmente, optimizaciones como la reducción de overdraw, el caching de instancias Retrofit y la migración hacia RecyclerView disminuyen trabajo redundante de UI y recreación innecesaria de layouts.

Las estrategias de caching y micro-optimizaciones actúan conjuntamente como mecanismos de reducción de trabajo redundante, intercambiando un pequeño costo adicional de memoria auxiliar por ahorro en tiempo de respuesta, reutilización de recursos y menor cantidad de operaciones repetitivas de UI y red.

En el Sprint 3 se extiende la estrategia de caching del Sprint 2 en tres dimensiones:

1. Refactorización estructural: CacheManager eliminó su dependencia de Context, mejorando la arquitectura y testeabilidad.
2. Cobertura de nuevos datos: El detalle de un coleccionista, los géneros y los sellos discográficos se cachean, completando la cobertura para todos los flujos de lectura incluyendo el de creación.
3. Consistencia tras escritura: La invalidación selectiva de caché garantiza que los datos mostrados en UI reflejen siempre el estado real del backend.

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