SharedPreferences: qué es, almacenamiento clave-valor de Android

¿Qué es SharedPreferences?

SharedPreferences es un mecanismo integrado de Android para almacenar pares clave-valor en un archivo XML en el almacenamiento interno del dispositivo. Está disponible desde API Level 1 y no requiere bibliotecas adicionales. Su propósito principal es guardar preferencias de usuario, estado de la interfaz, indicadores de primer inicio y otros datos simples que no requieren una base de datos estructurada.

Cada archivo de SharedPreferences está asociado con un nombre específico y un modo de acceso. Por defecto se utiliza el modo Context.MODE_PRIVATE, que restringe el acceso al archivo solo a la aplicación actual. Anteriormente Android admitía los modos MODE_WORLD_READABLE y MODE_WORLD_WRITEABLE, pero fueron declarados obsoletos a partir de API Level 17 y eliminados por completo en Android 7.0 (API 24) por razones de seguridad.

A pesar de su simplicidad, SharedPreferences se utiliza en millones de aplicaciones Android. Según Google, más del 90% de las aplicaciones publicadas en Google Play usan SharedPreferences para almacenar configuraciones. Sin embargo, para escenarios complejos (grandes volúmenes de datos, seguridad de tipos, asincronía) Google recomienda soluciones más modernas como Preferences DataStore de la biblioteca Android Jetpack.

Formato de almacenamiento: XML en el dispositivo

Físicamente, SharedPreferences se almacena como un archivo XML en el directorio de la aplicación: /data/data/{package_name}/shared_prefs/{file_name}.xml. El archivo contiene un elemento raíz <map> con elementos hijos <string>, <int>, <boolean>, <float> y <long> según el tipo de valor almacenado. El tamaño del archivo no está limitado, pero para grandes volúmenes de datos (más de 100 KB) el rendimiento de lectura y escritura comienza a degradarse notablemente.

Los archivos de SharedPreferences no están cifrados por defecto. Los datos se almacenan en texto plano en el sistema de archivos del dispositivo. Para almacenar datos sensibles (tokens, contraseñas) se recomienda usar EncryptedSharedPreferences de la biblioteca AndroidX Security, que cifra automáticamente las claves y valores mediante AES256-GCM.

Cómo funciona SharedPreferences en Android

SharedPreferences funciona según el principio de almacenamiento en caché en memoria con sincronización periódica en disco. En el primer acceso al archivo (a través de getSharedPreferences), Android carga el archivo XML en la RAM y lo analiza en un objeto Map. Todas las operaciones de lectura posteriores se realizan desde la memoria, sin volver a leer del disco. Esto garantiza una alta velocidad de acceso a los datos.

Las operaciones de escritura utilizan Editor — un búfer interno de cambios. Cuando el desarrollador llama a putString o putBoolean, los cambios se almacenan en el objeto Editor en memoria. La escritura real en disco ocurre cuando se llama al método commit (síncrono) o apply (asíncrono). Hasta que se llamen estos métodos, los datos no se guardan, y si la aplicación falla inesperadamente, los cambios pueden perderse.

Modos de acceso y contexto

Para obtener una instancia de SharedPreferences se usan dos métodos: getPreferences y getSharedPreferences. El primero solo está disponible dentro de una Activity y crea un archivo con el nombre de la Activity. El segundo es más flexible, acepta un nombre de archivo y modo de acceso, y es accesible desde cualquier contexto (Application, Activity, Service). Se recomienda usar getSharedPreferences con un nombre de archivo que corresponda al módulo o funcionalidad de la aplicación.

// Obteniendo SharedPreferences
val prefs = context.getSharedPreferences(
    "user_settings", Context.MODE_PRIVATE
)

// Escribir datos
with(prefs.edit()) {
    putString("username", "Ana")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// Leer datos
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

Al usar MODE_MULTI_PROCESS (obsoleto) SharedPreferences se sincroniza entre procesos. Sin embargo, esta sincronización no garantiza atomicidad, y Google recomienda evitar SharedPreferences en escenarios multiproceso. Para tales casos es mejor usar ContentProvider, Room con acceso entre procesos o DataStore.

Métodos principales de SharedPreferences

SharedPreferences proporciona un conjunto de métodos para leer datos por clave y la interfaz Editor para escribir. Cada método de lectura acepta dos parámetros: una clave y un valor por defecto que se devuelve si la clave no se encuentra. El valor por defecto también determina el tipo de retorno: getString devuelve String, getInt devuelve Int, y así sucesivamente.

Editor y apply vs commit

Editor es un objeto interno de SharedPreferences que recopila los cambios en un búfer. Después de realizar todos los cambios, el desarrollador llama a commit() (escritura síncrona) o apply() (escritura asíncrona). La diferencia es crítica: commit bloquea el hilo actual hasta completar la escritura en disco y devuelve un boolean (éxito/fracaso), mientras que apply realiza la escritura en un hilo en segundo plano y devuelve el control inmediatamente, pero no devuelve un resultado.

Se recomienda usar apply en lugar de commit en todos los casos en que no sea necesario conocer el resultado de la escritura. apply es más rápido y no bloquea el hilo de la UI. commit solo debe usarse cuando es crítico saber si los datos se guardaron correctamente, o al trabajar con modo multiproceso. Para eliminar claves individuales se usa el método remove, para borrado completo — clear. Todas las operaciones de eliminación también se realizan a través de Editor.

// Cambios múltiples - un apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Listener de cambio de valor
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Clave cambiada: $key")
}

A partir de Android 12 (API 31), SharedPreferences se mejoró con soporte para registerOnSharedPreferenceChangeListener con cancelación automática de suscripción mediante Lifecycle. Esto ayuda a evitar fugas de memoria asociadas con listeners olvidados. En versiones anteriores, el desarrollador debe llamar manualmente a unregisterOnSharedPreferenceChangeListener en onDestroy o onStop del componente.

SharedPreferences vs alternativas de almacenamiento

A pesar de su amplia difusión, SharedPreferences no es una solución universal para todos los escenarios de almacenamiento de datos en Android. Dependiendo del volumen de datos, requisitos de seguridad de tipos y rendimiento, Google recomienda varias alternativas incluidas en Android Jetpack y la biblioteca estándar de Android.

DataStore — alternativa moderna

DataStore es una biblioteca de Android Jetpack presentada por Google como reemplazo de SharedPreferences. Proporciona dos variantes: Preferences DataStore (clave-valor, como SharedPreferences) y Proto DataStore (almacenamiento tipado mediante Protocol Buffers). DataStore usa corrutinas y Flow para operación asíncrona, garantiza seguridad de tipos y maneja automáticamente las migraciones de versión. Google recomienda DataStore para todos los proyectos nuevos.

La principal ventaja de DataStore es la asincronía a nivel de API. Todas las operaciones de lectura devuelven Flow, y las operaciones de escritura son funciones suspend. Esto elimina por completo el bloqueo del hilo de la UI que puede ocurrir con la lectura síncrona de SharedPreferences. Además, DataStore garantiza la consistencia de los datos: la escritura se realiza en una transacción y, en caso de fallo, todos los cambios se revierten.

Ejemplo de uso de SharedPreferences en una aplicación

Consideremos un ejemplo práctico: configuración del tema (claro/oscuro/sistema) en una aplicación Android. El usuario selecciona un tema y la elección se guarda en SharedPreferences. En ejecuciones posteriores de la aplicación, el tema se restaura desde la configuración guardada. Para actualizaciones reactivas de la interfaz, se utiliza la observación de cambios mediante SharedPreferences.OnSharedPreferenceChangeListener.

Guardar configuración del usuario

Crearemos una clase ThemePreferences que encapsula todo el trabajo con SharedPreferences para el tema. La clase proporciona métodos getTheme (lectura), setTheme (escritura) y observeTheme (observación). El nombre del archivo de configuración será "app_preferences" con modo MODE_PRIVATE. Por comodidad, las claves se colocan en un companion object como constantes.

class ThemePreferences(context: Context) {
    companion object {
        private const val PREF_NAME = "app_preferences"
        private const val KEY_THEME = "theme_mode"
        const val THEME_LIGHT = "light"
        const val THEME_DARK = "dark"
        const val THEME_SYSTEM = "system"
    }

    private val prefs = context
        .getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE)

    fun getTheme(): String =
        prefs.getString(KEY_THEME, THEME_SYSTEM) ?: THEME_SYSTEM

    fun setTheme(theme: String) {
        prefs.edit { putString(KEY_THEME, theme) }
    }

    fun observeTheme(callback: (String) -> Unit) {
        prefs.registerOnSharedPreferenceChangeListener { _, key ->
            if (key == KEY_THEME) {
                callback.invoke(getTheme())
            }
        }
    }
}

En una Activity o Fragment, obtener una instancia de ThemePreferences se realiza a través del contexto de la aplicación. Al inicializar, se llama a getTheme para establecer el tema actual. Cuando el usuario selecciona un nuevo tema, se llama a setTheme, y mediante observeTheme la interfaz se actualiza sin reiniciar la Activity. Es importante cancelar la suscripción al listener en onDestroy para evitar fugas de memoria, especialmente si la Activity se recrea al cambiar la configuración.

Para aplicaciones con versión mínima objetivo Android 12+, se recomienda usar registerOnSharedPreferenceChangeListener junto con LifecycleObserver. Esto gestiona automáticamente la suscripción y cancelación al cambiar el ciclo de vida del componente. Para versiones anteriores, la suscripción y cancelación deben gestionarse manualmente, lo que es una fuente frecuente de errores en aplicaciones de producción que usan SharedPreferences.