1. La Pizarra vs. El Cuaderno: Memoria RAM vs. Persistencia No Volátil

En el ecosistema Android, cada aplicación se ejecuta dentro de su propio proceso de máquina virtual (ART - Android Runtime). La memoria RAM de este proceso actúa conceptualmente como una pizarra de aula de clases: es extraordinariamente rápida, eficiente para operaciones matemáticas y refresco de interfaz (60/120 Hz), pero es intrínsecamente volátil. Si el usuario rota la pantalla, entra una llamada telefónica, el sistema operativo mata el proceso en segundo plano por presión de memoria (Low Memory Killer - LMK) o el teléfono se apaga, todo dato almacenado exclusivamente en variables de memoria (Singletons, Companion Objects o ViewModels) es borrado de manera fulminante.

Por otro lado, la persistencia no volátil equivale a un cuaderno encuadernado en tinta: se escribe en la memoria de almacenamiento secundario (Flash NAND UFS / eMMC). Los datos permanecen intactos entre reinicios del dispositivo, cierres forzados de la aplicación y rotaciones de pantalla. Para todo desarrollador móvil, la regla cardinal es: La RAM es para el estado efímero del flujo presente; el almacenamiento no volátil es la única fuente fidedigna de verdad de la aplicación.

2. Los Cinco Pilares del Almacenamiento en Android

El framework de Android categoriza las opciones de almacenamiento en cinco niveles taxonómicos según su estructura, tamaño y ciclo de vida:

• Pilar 1 - Memoria RAM (Volátil): Colecciones en memoria, StateFlow, LiveData y variables locales. Ultrarrápida pero efímera.
• Pilar 2 - SharedPreferences & Jetpack DataStore: Almacenamiento de pares clave-valor (Key-Value) en formato XML dentro del sandbox. Diseñado para banderas booleanas, configuraciones de usuario (modo oscuro) y tokens livianos.
• Pilar 3 - Ficheros Internos (Internal Storage / filesDir): Archivos propietarios crudos (JSONs serializados, PDFs, fotos privadas) almacenados en /data/data/<package_name>/files/. Completamente privados para la aplicación.
• Pilar 4 - Memoria Caché (cacheDir) y Scoped Storage: Directorio temporal donde se descargan recursos auxiliares (thumbnails de Glide/Coil, respuestas HTTP). Android puede purgarlo automáticamente cuando el almacenamiento global escasea.
• Pilar 5 - Bases de Datos Relacionales (SQLite & Room Database): Motor relacional embebido para gestionar colecciones masivas, filtrado multicriterio, ordenamiento y relaciones complejas entre entidades.

3. Pilar 2 en Detalle: SharedPreferences y Jetpack DataStore

SharedPreferences almacena datos en un archivo físico XML ubicado en /data/data/<package_name>/shared_prefs/. Para mutar sus valores, se debe invocar a la interfaz SharedPreferences.Editor:

• apply(): Realiza la modificación de valores en memoria de manera inmediata y programa la escritura en disco de forma asíncrona. No retorna ningún valor de estado pero jamás bloquea el Hilo Principal (Main Thread), evitando provocar congelamientos de pantalla o ANR (Application Not Responding). Es la opción recomendada en el 99% de los casos.
• commit(): Escribe inmediatamente al archivo físico en disco de forma síncrona y bloqueante. Retorna un valor booleano indicando si la escritura fue exitosa. Si se ejecuta en el Main Thread con frecuencia, degrada severamente el rendimiento y la fluidez de la interfaz visual.

Antipatrones de SharedPreferences: Jamás deben guardarse listas masivas de objetos JSON, imágenes en base64 ni contraseñas bancarias en texto plano. En la arquitectura moderna de Jetpack, Google introdujo Preferences DataStore, reemplazando SharedPreferences con una API basada en Corrutinas de Kotlin y Kotlin Flow, que garantiza seguridad de tipos y transacciones 100% asíncronas.

4. Pilares 3 y 4: Ficheros Internos, Sandbox Linux y Scoped Storage

Android se apoya en el modelo de seguridad multiusuario del kernel de Linux. Al instalarse cada app, el sistema le asigna un identificador de usuario exclusivo (UID Linux). Todo archivo creado mediante context.openFileOutput("archivo.txt", Context.MODE_PRIVATE) o dentro de context.filesDir queda encapsulado en un Sandbox Privado. Ninguna otra aplicación puede leer, modificar ni listar esos archivos sin permisos explícitos de root.

En Kotlin profesional, la lectura y escritura de streams debe utilizar la función de extensión idiomática .use { ... }. Esta garantiza que el flujo de datos (FileOutputStream / FileInputStream) invoque automáticamente el método close() al terminar la operación, previniendo fugas graves de descriptores de archivos del sistema operativo incluso si se lanza una excepción.

Diferencia clave con cacheDir: Los archivos guardados en filesDir persisten indefinidamente hasta que el usuario desinstale la app o limpie los datos desde Configuración. En cambio, cacheDir está sujeto a limpieza automática preventiva por parte del sistema si el almacenamiento del dispositivo desciende por debajo de umbrales críticos de seguridad.

Scoped Storage (Almacenamiento Aislado): Desde Android 10 (API 29) y Android 11 (API 30), las apps ya no tienen acceso irrestricto a todo el almacenamiento compartido con WRITE_EXTERNAL_STORAGE. Para fotos y audio globales se debe emplear el MediaStore API, y para archivos arbitrarios externos, el Storage Access Framework (SAF).

5. Pilar 5: Motor SQLite y Arquitectura Moderna con Room Database

Android incluye desde su versión 1.0 el motor de base de datos relacional nativo y embebido en C: SQLite. Es un motor transaccional completo (ACID), autocontenido y sin servidor (serverless), cuyos datos residen en un único archivo .db en el almacenamiento interno.

Históricamente, el acceso a SQLite se realizaba heredando de la clase abstracta SQLiteOpenHelper, sobreescribiendo sus dos métodos fundamentales:

• onCreate(SQLiteDatabase db): Se ejecuta una única vez en la vida de la app cuando el archivo físico de la base de datos es creado por primera vez. Aquí se ejecutan sentencias DDL como CREATE TABLE.
• onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion): Se dispara cuando el desarrollador incrementa el número de versión entera en el constructor, permitiendo migraciones de esquema como ALTER TABLE.

Para manipular filas se utilizan objetos ContentValues (pares de columna-valor) y para leer resultados se utiliza un Cursor, el cual requiere iteración manual mediante cursor.moveToNext() y obtención por índice de columna (ej. cursor.getString(...)), sin olvidar invocar cursor.close().

La Revolución de Android Jetpack Room: La API clásica de SQLite carece de verificación de sintaxis SQL en tiempo de compilación y requiere una cantidad masiva de código repetitivo (Boilerplate). Por ello, Google desarrolló Room, la capa de abstracción oficial basada en tres componentes esenciales:

• @Entity: Clase de datos en Kotlin (data class) que define el esquema de una tabla relacional en la base de datos.
• @Dao (Data Access Object): Interfaz que define las operaciones de acceso a datos (SELECT, INSERT, UPDATE, DELETE). Room valida la sintaxis de las consultas SQL en tiempo de compilación; si un nombre de columna no existe, el proyecto falla antes de instalarse en el dispositivo.
• @Database: Clase abstracta que extiende de RoomDatabase y sirve como punto principal de acceso a las conexiones subyacentes.

Regla de Hilos: Por defecto, Room prohíbe terminantemente ejecutar consultas en el Main Thread porque provocaría bloqueos de UI (lanzará una excepción IllegalStateException a menos que se usen corrutinas con funciones suspend o hilos de trabajo).

6. apply() vs commit(): El Duelo Crítico

Uno de los puntos más importantes y que más se evalúa es entender la diferencia entre apply() y commit() en el SharedPreferences.Editor. Ambos métodos confirman los cambios, pero lo hacen de manera radicalmente diferente:

• apply() — El estándar moderno (99.9% de los casos): Actualiza la copia en memoria RAM al instante (la UI lo ve ya) y envía la escritura al disco en un hilo de fondo (background). No retorna ningún valor. Jamás congela la pantalla ni produce ANR. Es la opción recomendada para guardar preferencias de usuario, modo oscuro, tokens, etc.
• commit() — El método legacy (0.1% de los casos): Bloquea el hilo que lo llama hasta que los bytes se escriben físicamente en la memoria Flash. Retorna un boolean indicando si la escritura fue exitosa. Si se ejecuta en el Main Thread con el disco ocupado, causa lag severo o ANR (Application Not Responding). Solo se recomienda cuando necesitas confirmar el guardado antes de continuar con un proceso crítico, y siempre fuera del UI Thread.

Regla de oro: Si llamas a commit() en el hilo principal y la memoria flash está ocupada, la pantalla se congela. Si tarda más de 5 segundos, Android mata la aplicación con un ANR. Por eso Google introdujo apply() desde Android 2.3 (API 9).

7. Los 5 Asesinos de la Memoria RAM

Todo lo que vive únicamente en variables de memoria muere cuando Android necesita recursos. Estos son los 5 escenarios donde la RAM se pierde inevitablemente:

• 1. Rotación de pantalla: El usuario gira el teléfono → la Activity se destruye y se recrea. Los datos en variables se pierden.
• 2. Low Memory Killer (LMK): El sistema operativo mata tu app en segundo plano porque necesita memoria para otras apps.
• 3. Swipe para cerrar: El usuario descarta la app desde el reciente de aplicaciones.
• 4. Reinicio del equipo: La RAM siempre se vacía completamente al apagar o reiniciar el dispositivo.
• 5. Modo Doze / batería: El proceso se congela y se purga cuando el dispositivo entra en modo de ahorro de energía.

Test de 3 segundos: Si cierras la app y ese dato puede perderse sin que el usuario reclame → la RAM es correcto. Si el usuario espera que siga ahí → debes persistir.

8. Casos de Uso Reales de SharedPreferences

SharedPreferences es ideal para persistir datos atómicos simples que configuran el comportamiento de la app:

• Pantalla Onboarding (isFirstRun): Mostrar un carrusel de bienvenida solo la primera vez. Si es true → abrir tutorial y cambiar a false. Si es false → ir directo al MainActivity.
• Preferencias visuales (Theme): Modo oscuro o idioma. En el onCreate() lees el valor antes de setContentView() y aplicas el tema correcto al instante.
• Token de sesión (JWT): Guardar el token devuelto por el servidor para inyectarlo en las cabeceras HTTP de peticiones posteriores sin pedir login de nuevo.
• Puntaje máximo o estado rápido: Guardar el récord de un juego o si los sonidos están silenciados. Comparas y actualizas con editor.putInt("high_score", puntajeActual).apply().

Antipatrones: NO guardar listas masivas de objetos JSON, imágenes en base64, contraseñas en texto plano, ni datos que requieran consultas complejas. Para eso existen archivos, Room o DataStore.

9. Scoped Storage y el Sandbox de Linux

Android se apoya en el modelo de seguridad multiusuario del kernel de Linux. Al instalarse cada app, el sistema le asigna un identificador de usuario exclusivo (UID Linux). Todo archivo creado mediante context.openFileOutput() o dentro de context.filesDir queda encapsulado en un Sandbox Privado que ninguna otra aplicación puede leer sin permisos de root.

Desde Android 10 (API 29) y Android 11 (API 30), las apps ya no tienen acceso irrestricto a todo el almacenamiento compartido con WRITE_EXTERNAL_STORAGE. Para fotos y audio globales se debe emplear el MediaStore API, y para archivos arbitrarios externos, el Storage Access Framework (SAF).

cacheDir vs filesDir: Los archivos en filesDir persisten indefinidamente hasta que el usuario desinstale la app o limpie los datos. En cambio, cacheDir está sujeto a limpieza automática preventiva por parte del sistema si el almacenamiento del dispositivo desciende por debajo de umbrales críticos. La regla de oro: jamás guardar datos esenciales en caché; si se borran, la app debe ser capaz de re-descargarlos.

10. Room Database: Componentes y Reglas

Room es la capa de abstracción oficial de Google sobre SQLite. Sus tres componentes esenciales son:

• @Entity: Clase de datos (data class) que define el esquema de una tabla. Ejemplo: @Entity data class User(@PrimaryKey val id: Int, val name: String)
• @Dao (Data Access Object): Interfaz que define las operaciones de acceso a datos (@Query, @Insert, @Update, @Delete). Room valida la sintaxis SQL en tiempo de compilación; si un nombre de columna no existe, el proyecto falla antes de instalarse.
• @Database: Clase abstracta que extiende de RoomDatabase y sirve como punto principal de acceso a las conexiones subyacentes.

Regla de hilos: Room prohíbe terminantemente ejecutar consultas en el Main Thread porque provocaría bloqueos de UI (lanzará una excepción IllegalStateException). Se deben usar corrutinas con funciones suspend o hilos de trabajo.

Ventaja sobre SQLite clásico: La API clásica de SQLiteOpenHelper carece de verificación de sintaxis SQL en tiempo de compilación y requiere una cantidad masiva de código repetitivo (boilerplate). Room elimina ambos problemas.

Bibliografía y Referencias Académicas Oficiales

• Google Developers (2024). Android Data Storage Overview. Documentación oficial de Android. (filesDir, cacheDir y Scoped Storage).
• Google Developers (2024). Save key-value data with SharedPreferences & DataStore. Documentación de Jetpack Architecture.
• Google Developers (2024). Save data in a local database using Room. Documentación oficial de Android Jetpack.
• Griffiths, D., & Griffiths, D. (2021). Head First Android Development (3rd Edition). O'Reilly Media. (Persistencia relacional con SQLiteOpenHelper y Cursors).