SharedPreferences y seguridad de subprocesos
Mirando los documentos de SharedPreferences dice:
"Nota: actualmente esta clase no admite el uso a través de múltiples procesos, lo que se agregará más tarde."
- Android - Transición de elementos compartidos en el cuadro de diálogo
- Android registerOnSharedPreferenceChangeListener () causa bloqueo en una vista personalizada
- ¿Cómo crear un directorio compartido con acceso de lectura y escritura a todas las aplicaciones en Android?
- Android: Cómo almacenar una matriz de cadenas en SharedPreferences para android
- ¿Puede la biblioteca compartida llamar a otra biblioteca compartida?
Así que en sí mismo y no parece ser Thread Safe. Sin embargo, ¿qué tipo de garantías se hacen con respecto a commit () y apply ()?
Por ejemplo:
synchronized(uniqueIdLock){ uniqueId = sharedPreferences.getInt("UNIQUE_INCREMENTING_ID", 0); uniqueId++; sharedPreferences.edit().putInt("UNIQUE_INCREMENTING_ID", uniqueId).commit(); } ¿Estaría garantizado que el uniqueId fue siempre único en este caso?
Si no es así, ¿hay una mejor manera de realizar un seguimiento de un identificador único para una aplicación que persiste?
- Sugerir para trabajar junto con un proyecto compartido
- Android Widget: muestra la actividad de configuración antes de que el widget se agregue a la pantalla.
- Intentos de Android: Inicia la actividad usando el nombre de clase de otra aplicación que tiene el mismo sharedUserId
- Transición de elementos compartidos de Android entre fragmentos con vista de reciclaje y detalles
- Escribir un archivo de acceso privado en el directorio de archivos de otra aplicación
- Anulación del diseño utilizado para una preferencia en una preferenciaActividad / preferencia Pantalla utilizando temas
Los procesos y los hilos son diferentes. La implementación de SharedPreferences en Android es segura para los subprocesos, pero no es segura para el proceso. Normalmente, la aplicación se ejecutará todo en el mismo proceso, pero es posible que lo configure en AndroidManifest.xml, por lo que, digamos, el servicio se ejecuta en un proceso distinto de, digamos, la actividad.
Para verificar la seguridad de thready, vea el SharedPreferenceImpl de ContextImpl.java de AOSP. Tenga en cuenta que hay un sincronizado dondequiera que usted esperaría que haya uno.
private static final class SharedPreferencesImpl implements SharedPreferences { ... public String getString(String key, String defValue) { synchronized (this) { String v = (String)mMap.get(key); return v != null ? v : defValue; } } ... public final class EditorImpl implements Editor { public Editor putString(String key, String value) { synchronized (this) { mModified.put(key, value); return this; } } ... } }
Sin embargo, para su caso de la identificación única que parece que todavía quieren un sincronizado como usted no quiere que cambie entre el obtener y poner.
Usted debe estar enterado que SharedPreferences no está trabajando en los teléfonos de Samsung, echa un vistazo a la edición de android .
He implementado almacenamiento de preferencias de base de datos sencillo que puede encontrar en github .
Aclamaciones,
Me preguntaba lo mismo – y se encontró con este hilo que dice que no son hilos seguros:
Las implementaciones de Context.getSharedPreferences () y Editor.commit () no se sincronizan en el mismo monitor.
Desde entonces he mirado el código de Android 14 para comprobar, y está muy involucrado. Especificamente SharedPreferencesImpl parece utilizar cerraduras diferentes al leer y escribir en el disco:
-
enqueueDiskWrite()bloquea enmWritingToDiskLock -
startLoadFromDisk()bloquea enthis, y lanza un hilo de bloqueo enSharedPreferencesImpl.this
No estoy convencido de que este código sea realmente seguro.
Creo que lo hará.
Usted puede probarlo usando el sueño dentro de la sección sincronizada y llame desde diferentes hilos