TL;DR

  • Elige cache-first para datos de lectura intensiva (perfiles, catálogos) y network-first para contenido sensible al tiempo (feeds, notificaciones)
  • Implementa caching multicapa: HTTP cache (OkHttp) para capa de red + Room/SQLite para persistencia + LRU en memoria para datos calientes
  • Prueba escenarios offline sistemáticamente—cache hit/miss, expiración, invalidación y límites de almacenamiento bajo condiciones de red reales

Ideal para: Equipos construyendo apps móviles con requisitos offline o condiciones de red inestables No recomendado si: Tu app es puramente online sin necesidades de funcionalidad offline Tiempo de lectura: 15 minutos

El caching efectivo es esencial para aplicaciones móviles para proporcionar experiencias rápidas y responsivas mientras se minimiza el uso de red y consumo de batería. Esta guía cubre estrategias de caching, patrones de implementación y enfoques de testing con ejemplos de código prácticos.

Combinado con pruebas de rendimiento API adecuadas, las estrategias de caching forman la base de la optimización de rendimiento de apps móviles. Entender las métricas de rendimiento de apps móviles te ayuda a medir el impacto de tu implementación de caching.

Enfoques Asistidos por IA

Los asistentes de IA modernos pueden ayudar a diseñar y depurar implementaciones de caching. Aquí hay prompts prácticos para tareas comunes:

Diseñando lógica de invalidación de caché:

Mi app móvil cachea perfiles de usuario, catálogos de productos y datos
del carrito de compras. Diseña una estrategia de invalidación para cada
tipo de dato considerando:

1. Frecuencia de cambio de datos (perfiles: raro, catálogos: diario, carrito: frecuente)
2. Acciones de usuario que deben disparar invalidación (logout, compra, pull refresh)
3. Escenarios de server-push (cambios de precio, actualizaciones de inventario)
4. Resolución de conflictos cuando cambios offline se sincronizan

Proporciona código Kotlin usando Room database con timestamps de caché apropiados.

Depurando inconsistencias de caché:

Los usuarios reportan ver datos obsoletos después de actualizar la app. Setup actual:

- OkHttp HTTP cache (10MB)
- Room database para almacenamiento offline
- SharedPreferences para configuración de usuario

El problema: Después de actualizar un perfil via API, el perfil viejo
se muestra hasta reiniciar la app. Proporciona pasos de debugging y fixes.

Código actual del repositorio:
[pega tu implementación del repositorio]

Optimizando gestión de tamaño de caché:

La caché de mi app móvil crece sin límite y los usuarios se quejan del
almacenamiento. Capas de caché actuales:

- Image cache: Glide con 250MB disk cache
- Respuestas API: Room database (actualmente 150MB)
- HTTP cache: OkHttp 50MB

Diseña una estrategia de eviction que:

1. Priorice datos accedidos recientemente
2. Distinga entre caché crítica (datos de usuario) y prescindible (imágenes)
3. Proporcione controles de usuario para limpiar caché
4. Monitoree y reporte tamaños de caché

Incluye implementación Android con WorkManager para limpieza periódica.

Generando escenarios de test de caché:

Genera casos de test comprehensivos para una capa de caching móvil que incluye:

- HTTP cache con OkHttp
- Room database para persistencia offline
- In-memory LRU cache para datos calientes

Los escenarios de test deben cubrir:

1. Paths de cache hit/miss
2. Manejo de expiración y TTL
3. Modo offline con datos obsoletos
4. Invalidación de caché en acciones de usuario
5. Aplicación de límites de almacenamiento
6. Patrones de acceso concurrente

Proporciona código de test en Kotlin usando MockK y Turbine para testing de Flow.

Cuándo Usar Diferentes Estrategias de Caching

Framework de Decisión de Estrategia

Tipo de DatoEstrategiaTTLDisparador de Invalidación
Perfil de usuarioCache-first24 horasUsuario edita perfil, logout
Catálogo de productosNetwork-first con fallback1 horaAdmin actualiza, sync diario
Carrito de comprasNetwork-firstSin cachéCada modificación
Assets estáticos (imágenes)Cache-first7 díasActualización de versión de app
Feeds en tiempo realNetwork-first5 minutosPull-to-refresh, push notification
Configuración/feature flagsCache-first1 horaInicio de app, sync en background

Considera Cache-First Cuando

  • Los datos cambian infrecuentemente: Perfiles de usuario, configuración de app, datos de referencia
  • El acceso offline es crítico: Documentos, contenido descargado, borradores generados por usuario
  • La latencia de red impacta UX: Carga inicial de app, transiciones de navegación
  • El ancho de banda es costoso: Usuarios con planes de datos limitados, mercados emergentes

Considera Network-First Cuando

  • La frescura de datos es crítica: Datos financieros, niveles de inventario, colaboración en tiempo real
  • Los requisitos de seguridad lo demandan: Tokens de autenticación, datos sensibles
  • Los datos cambian impredeciblemente: Feeds sociales, notificaciones, documentos colaborativos
  • El servidor es la fuente de verdad: Total del carrito, estado del pedido

Android Estrategias de Caching

HTTP Cache con OkHttp

val cacheSize = 10 * 1024 * 1024 // 10 MB
val cache = Cache(context.cacheDir, cacheSize.toLong())

val client = OkHttpClient.Builder()
    .cache(cache)
    .build()

Implementación de Caché Personalizado

class ApiCache(private val context: Context) {
    private val prefs = context.getSharedPreferences("api_cache", Context.MODE_PRIVATE)

    fun <T> getCached(key: String, type: Class<T>, maxAge: Long = 3600_000): T? {
        val cachedJson = prefs.getString(key, null) ?: return null
        val timestamp = prefs.getLong("${key}_timestamp", 0)

        if (System.currentTimeMillis() - timestamp > maxAge) {
            return null
        }

        return Gson().fromJson(cachedJson, type)
    }

    fun <T> cache(key: String, data: T) {
        val json = Gson().toJson(data)
        prefs.edit()
            .putString(key, json)
            .putLong("${key}_timestamp", System.currentTimeMillis())
            .apply()
    }
}

Testing Estrategias de Caché

El testing comprensivo del comportamiento de caché es esencial. Para técnicas más amplias de testing API, explora mejores prácticas de dominio de testing API que complementan la validación de caché.

@Test
fun testCacheHit() = runTest {
    val repository = UserRepository(mockApi, cache)

    // Primera llamada - debe llamar API
    repository.getUser("123")
    verify(exactly = 1) { mockApi.getUser("123") }

    // Segunda llamada - debe usar caché
    repository.getUser("123")
    verify(exactly = 1) { mockApi.getUser("123") }
}

@Test
fun testCacheExpiration() = runTest {
    repository.getUser("123")

    delay(3600_001) // Esperar expiración

    repository.getUser("123")
    verify(exactly = 2) { mockApi.getUser("123") }
}

@Test
fun testOfflineCache() = runTest {
    networkMonitor.setConnected(true)
    repository.getUser("123")

    networkMonitor.setConnected(false)
    every { mockApi.getUser(any()) } throws UnknownHostException()

    val cachedUser = repository.getUser("123")
    assertNotNull(cachedUser)
}

Probar escenarios offline es crítico para apps móviles. Aprende más sobre estrategias comprensivas de testing de condiciones de red para asegurar que tu caché funcione confiablemente en todos los estados de conectividad.

Políticas de Caché

enum class CachePolicy(val maxAge: Long) {
    SHORT(5 * 60 * 1000),        // 5 minutos
    MEDIUM(30 * 60 * 1000),      // 30 minutos
    LONG(24 * 60 * 60 * 1000),   // 24 horas
    PERMANENT(Long.MAX_VALUE)
}

class CacheStrategy {
    // Network-first
    suspend fun <T> networkFirst(key: String, fetch: suspend () -> T): T {
        return try {
            val result = fetch()
            cache.cache(key, result)
            result
        } catch (e: IOException) {
            cache.getCached(key) ?: throw e
        }
    }

    // Cache-first
    suspend fun <T> cacheFirst(key: String, fetch: suspend () -> T): T {
        cache.getCached(key)?.let { cached ->
            CoroutineScope(Dispatchers.IO).launch {
                try {
                    cache.cache(key, fetch())
                } catch (e: Exception) { }
            }
            return cached
        }

        val result = fetch()
        cache.cache(key, result)
        return result
    }
}

Sincronización de Caché

class SyncManager(private val api: ApiService, private val database: AppDatabase) {
    suspend fun syncUsers() {
        val users = api.getUsers()

        database.withTransaction {
            database.userDao().deleteAll()
            database.userDao().insertAll(users.map { it.toEntity() })
            setSyncTimestamp("users", System.currentTimeMillis())
        }
    }

    fun needsSync(key: String, maxAge: Long = 3600_000): Boolean {
        val lastSync = getSyncTimestamp(key)
        return System.currentTimeMillis() - lastSync > maxAge
    }
}

Gestión de Almacenamiento

class CacheSizeManager(private val maxSize: Long = 50 * 1024 * 1024) {
    fun enforceLimit() {
        val cacheDir = context.cacheDir
        val currentSize = calculateSize(cacheDir)

        if (currentSize > maxSize) {
            val filesToDelete = getOldestFiles(cacheDir, currentSize - maxSize)
            filesToDelete.forEach { it.delete() }
        }
    }
}

Mejores Prácticas

  1. Usa duraciones de caché apropiadas - Corto para datos dinámicos, largo para estáticos
  2. Implementa invalidación de caché - Limpia caché en logout, actualizaciones
  3. Monitorea tamaño de caché - Previene crecimiento ilimitado
  4. Prueba escenarios offline - Asegura degradación graceful
  5. Usa ETags y requests condicionales - Optimiza ancho de banda

Conclusión

El caching efectivo de API requiere:

  • Políticas de caché estratégicas
  • Mecanismos de invalidación apropiados
  • Gestión de almacenamiento
  • Soporte offline
  • Testing comprensivo

El caching bien implementado mejora significativamente el rendimiento de apps móviles, reduce costos y mejora la experiencia de usuario en todas las condiciones de red.

Ver También

Recursos Oficiales