Arquitectura Android en 2026: Lo que Desplegamos a Escala

El Stack Android Ha Madurado — Su Arquitectura Debería También

Hace cinco años, la arquitectura Android significaba elegir entre MVP y MVVM y pelear con los ciclos de vida de Fragment. En 2026, la plataforma ha convergido alrededor de opiniones claras:

• Jetpack Compose para UI (los layouts XML son legacy)
• Kotlin Coroutines + Flow para datos asíncronos y reactivos
• Hilt para inyección de dependencias
• Room para persistencia local
• Retrofit + kotlinx.serialization para networking

Pero tener las bibliotecas correctas no es arquitectura. La arquitectura es cómo organiza el código para que un equipo de 5-15 ingenieros pueda entregar funciones sin pisarse entre sí.

La Arquitectura que Desplegamos

Después de construir la Plataforma de Vehículos Conectados de Ford y múltiples apps Android empresariales, convergimos en una arquitectura por capas:

Capa 1: UI (Compose)

• Pantallas son composables sin estado que reciben estado y emiten eventos
• ViewModels mantienen el estado como StateFlow
• Estado UI es una clase sealed por pantalla
• Navegación usa rutas type-safe

Capa 2: Dominio

• Casos de uso encapsulan operaciones de negocio individuales
• Cada caso de uso tiene un método público — operator fun invoke()
• Esta capa tiene cero imports de Android

Capa 3: Datos

• Repositories son la fuente única de verdad
• Offline-first por defecto: Room como fuente de datos primaria
• El patrón Repository abstrae las fuentes de datos

Offline-First Ya No Es Opcional

En sistemas de vehículos conectados, aprendimos esto a las malas: las conexiones celulares en estacionamientos, túneles y áreas rurales son poco confiables.

• Base de datos Room como fuente de verdad
• WorkManager para sincronización en segundo plano
• Resolución de conflictos con last-writer-wins y timestamps del servidor
• Estado de sincronización expuesto en la UI

Rendimiento de Compose: Lo Que Nadie Le Dice

• La estabilidad importa. Use anotaciones @Immutable o @Stable deliberadamente.
• LazyColumn no es RecyclerView. Para listas de más de 500 items, use parámetros key.
• El state hoisting no es gratis. Use derivedStateOf para valores calculados.
• La carga de imágenes necesita cuidado. Coil 3 con AsyncImage es el estándar.

Estrategia de Testing

• Tests unitarios (70%): Casos de uso, lógica de repositorio, máquinas de estado de ViewModel
• Tests de integración (20%): Operaciones de Room, serialización API
• Tests de UI (10%): Solo flujos críticos de usuario

Desplegando Confiablemente

• Feature flags para cada función nueva
• Rollouts graduales — 1% → 10% → 50% → 100%
• Baseline profiles para starts más rápidos
• R8 full mode para optimización agresiva
• App Bundle para tamaños de descarga óptimos

¿Construye una app Android que necesita funcionar a escala? Agende una revisión de arquitectura gratuita — hemos desplegado Android a millones de dispositivos.