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 Dato | Estrategia | TTL | Disparador de Invalidación |
|---|---|---|---|
| Perfil de usuario | Cache-first | 24 horas | Usuario edita perfil, logout |
| Catálogo de productos | Network-first con fallback | 1 hora | Admin actualiza, sync diario |
| Carrito de compras | Network-first | Sin caché | Cada modificación |
| Assets estáticos (imágenes) | Cache-first | 7 días | Actualización de versión de app |
| Feeds en tiempo real | Network-first | 5 minutos | Pull-to-refresh, push notification |
| Configuración/feature flags | Cache-first | 1 hora | Inicio 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
- Usa duraciones de caché apropiadas - Corto para datos dinámicos, largo para estáticos
- Implementa invalidación de caché - Limpia caché en logout, actualizaciones
- Monitorea tamaño de caché - Previene crecimiento ilimitado
- Prueba escenarios offline - Asegura degradación graceful
- 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
- Testing de Rendimiento de Apps Móviles - Métricas y herramientas para medir efectividad del caché
- Testing Móvil Multiplataforma - Estrategias para probar comportamiento de caché en iOS y Android
- Dominio del Testing de API - Prueba comportamiento de caché como parte de validación de API
- Testing de Rendimiento de API - Valida tiempos de respuesta API con y sin caching
- Gestión de Datos de Test - Estrategias para gestionar datos de test en entornos cacheados
