Qué resuelve el ViewModel: sobrevivir a la rotación

Todo lo que has construido hasta aquí —el estado inmutable, el bucle intent-reduce-render, el container de Orbit— descansa sobre un supuesto silencioso: que existe algún lugar donde ese estado puede vivir más tiempo que la pantalla que lo muestra. En Android ese lugar no es obvio, porque la Activity es una de las entidades más frágiles del sistema: el propio framework la aniquila y la reconstruye ante el gesto más trivial del usuario. El ViewModel no nació como una capa de arquitectura limpia ni como el vértice de un diagrama; nació como la solución a esa fragilidad concreta. Entenderlo bien exige mirar tres cosas: qué se rompe exactamente, con qué mecanismo se repara y cuál es su ciclo de vida real, que no coincide con el de ninguna vista.

La Activity es desechable, tu estado no

En Android, la Activity y el Fragment no son objetos que tú gobiernas: son objetos que el sistema crea, destruye y vuelve a crear cuando le conviene. El detonante más famoso es la rotación, pero la lista es mucho más larga: pasar a modo oscuro, cambiar el idioma del dispositivo, entrar en pantalla dividida, redimensionar una ventana en un plegable o en escritorio, conectar un teclado físico, ajustar el tamaño de fuente del sistema. Todos son cambios de configuración, y la respuesta por defecto del framework ante cualquiera de ellos es idéntica: destruir la instancia viva y construir una nueva.

Esa política, que parece brutal, es en realidad coherente. En Android los recursos se resuelven por calificadores: hay un layout para vertical y otro para apaisado, unos values para español y otros para inglés, un drawable para tema claro y otro para oscuro. Cuando la configuración cambia, casi todo lo que la pantalla había resuelto —dimensiones, cadenas, imágenes, densidades— deja de ser válido. En lugar de intentar parchear cada referencia una por una, el sistema toma el camino simple y honesto: tira la pantalla entera y la vuelve a resolver desde cero con la configuración nueva.

Existe una vía de escape aparente y conviene desactivarla cuanto antes: declarar en el manifiesto que tu Activity maneja por su cuenta ciertos cambios de configuración. La instancia deja de destruirse, sí, pero a cambio te haces responsable de volver a resolver a mano cada recurso afectado, y esa lista crece con cada versión del sistema —densidades nuevas, plegables, ventanas redimensionables—. Además no soluciona el problema de fondo: no impide que el sistema mate tu proceso ni que la pantalla se reconstruya por cualquier otra razón. Es una optimización puntual para casos muy concretos, nunca una arquitectura.

El coste de esa simplicidad lo pagas tú. Cada objeto que colgaba de la Activity muere con ella. Si el resultado de una llamada de red vivía en un campo de la Activity, la instancia nueva arranca vacía: vuelve a mostrar el indicador de carga, vuelve a pedir los mismos datos, vuelve a gastar batería y ancho de banda, y en el peor de los casos vuelve a ejecutar una operación que no era idempotente. El usuario, que solo giró el teléfono, ve cómo su pantalla se reinicia. Ese es el bug fundacional que el ViewModel vino a matar.

El mecanismo real de retención

Conviene desmitificarlo: el ViewModel no sobrevive por magia del compilador ni por un truco del recolector de basura. Sobrevive porque hay una caja que el sistema traspasa a mano de la instancia vieja a la nueva. Esa caja es el ViewModelStore: un mapa de claves a instancias de ViewModel. Quien la posee es un ViewModelStoreOwner —tu Activity, tu Fragment, una entrada del grafo de navegación—, y quien la consulta es el ViewModelProvider, que ante una petición devuelve la instancia existente si la clave ya está ocupada y solo llama a la fábrica si no lo está.

// La delegación esconde tres pasos: buscar el owner, buscar la clave, crear si falta.
class PerfilActivity : AppCompatActivity() {
    private val viewModel: PerfilViewModel by viewModels()
}

// Equivalente explícito, sin azúcar sintáctico:
val viewModel = ViewModelProvider(this)[PerfilViewModel::class.java]

El paso decisivo ocurre durante el cambio de configuración: antes de morir, la Activity entrega su ViewModelStore al mecanismo de instancias retenidas del framework, y la Activity recién nacida lo recoge y lo adopta como propio. Por eso la segunda llamada a viewModels() no construye nada: encuentra la clave ocupada y devuelve exactamente el mismo objeto en memoria. No hay serialización, no hay copia, no hay coste: es la misma referencia atravesando la frontera entre dos instancias de pantalla.

Falta una pieza en el circuito: quién construye el objeto la primera vez. De eso se encarga una fábrica, y por defecto la fábrica solo sabe invocar el constructor vacío. En cuanto tu ViewModel necesita colaboradores —un repositorio, un caso de uso, el propio SavedStateHandle— hay que darle una fábrica que sepa proveerlos. Puedes escribirla a mano o delegarla en el grafo de inyección de dependencias, que es lo habitual en un proyecto real.

// Fábrica explícita: útil para entender qué hace la anotación por debajo
class PerfilFactory(private val repo: PerfilRepo) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(clase: Class<T>): T =
        PerfilViewModel(repo) as T
}

// En la práctica, el grafo de inyección genera esa fábrica por ti
@HiltViewModel
class PerfilViewModel @Inject constructor(private val repo: PerfilRepo) : ViewModel()

Ese reparto importa más de lo que parece: la fábrica se consulta una sola vez por ciclo de vida del dueño. Las dependencias que inyectas se resuelven en la creación y se conservan intactas a través de todas las rotaciones posteriores, porque no se vuelve a crear nada. Es otra forma de decir lo mismo que el ViewModelStore: lo que hay dentro del objeto retenido queda retenido con él.

De ahí se sigue una consecuencia que mucha gente descubre tarde: el alcance del ViewModel es el alcance de su dueño. No hay un solo tipo de ViewModel, hay tantos ámbitos como dueños posibles, y elegir el dueño equivocado produce o bien estado que no se comparte cuando debería, o bien estado que sobrevive cuando ya debería haber muerto.

flowchart TD
A[Usuario gira el dispositivo] --> B[La Activity recibe onDestroy]
B --> C[El ViewModelStore se conserva]
B --> D[Vistas y binding se destruyen]
C --> E[La Activity nueva pide el mismo ViewModel]
D --> F[Se reconstruye la jerarquia de vistas]
E --> G[Mismo objeto, mismo estado, sin recargar]
F --> G
style C fill:#a6e3a1,color:#11111b
style D fill:#f38ba8,color:#11111b
style G fill:#89b4fa,color:#11111b

El ciclo de vida real: hasta onCleared

Con el mecanismo en la mano, el ciclo de vida se vuelve preciso. Un ViewModel nace de forma perezosa la primera vez que alguien lo pide a su ViewModelProvider. A partir de ahí atraviesa impasible todos los cambios de configuración de su dueño: puede ver nacer y morir tres, diez o cincuenta instancias de Activity sin enterarse, porque nunca supo de su existencia. Y muere una sola vez: cuando su dueño desaparece definitivamente —la Activity termina de verdad, el fragmento se retira, la entrada del grafo sale del back stack— el framework limpia el ViewModelStore, lo que cancela su scope de corrutinas e invoca onCleared.

Ese onCleared es el único gancho de destrucción que tienes, y su contrato es estrecho: se llama en el hilo principal, sin garantías de que la vista siga existiendo, y sirve para soltar recursos que el ViewModel posea de forma explícita —un oyente registrado a mano, una conexión, un Closeable—. Todo lo que cuelgue de su scope de corrutinas ya se cancela solo, como verás en la lección siguiente.

class SensorViewModel(private val sensores: SensorHub) : ViewModel() {

    private val oyente = SensorListener { valor -> /* ... */ }

    init { sensores.registrar(oyente) }

    override fun onCleared() {
        sensores.quitar(oyente)   // lo que registraste a mano, lo retiras a mano
    }
}

Importa el orden en que ocurren las cosas: el framework cancela primero el scope de corrutinas y después invoca onCleared. Eso significa que dentro de ese método no puedes lanzar trabajo suspendido en el scope del propio ViewModel, porque ya está muerto y cualquier corrutina que intentes arrancar allí terminará de inmediato. Si necesitas una limpieza asíncrona, tiene que apoyarse en un ámbito de mayor duración que no dependa de la pantalla que acaba de desaparecer.

Hay un corolario que gobernará la última lección de este nivel y conviene anticiparlo aquí, porque se deduce de lo anterior sin esfuerzo. Si el ViewModel vive más que cualquier vista, entonces guardar dentro de él una referencia a una vista, a un Fragment, a un objeto de enlace de vistas o a un Context de Activity impide que el recolector libere esa jerarquía muerta. No es una mala práctica estilística: es la consecuencia aritmética de que un objeto largo sujete a uno corto.

Las fronteras: lo que nunca prometió

Igual de importante es marcar el perímetro de lo que no resuelve, porque casi todas las decepciones con el ViewModel vienen de pedirle garantías que jamás ofreció. Un objeto retenido en memoria depende de que la memoria siga existiendo, y esa condición no está en tus manos.

Estas tres exclusiones no son defectos: son la contrapartida exacta de su virtud. El ViewModel es barato, rápido y sin coste de serialización precisamente porque vive en memoria y no negocia con nadie. Cada una de las cosas que no hace la hace mejor otro mecanismo con otro precio: el Bundle paga serialización a cambio de cruzar la muerte del proceso, la base de datos paga entrada y salida a cambio de durar para siempre. Un diseño sano combina los tres en lugar de estirar uno hasta romperlo.