1. SharedPreferences基础解析Android轻量存储方案在Android应用开发中数据持久化是每个开发者必须掌握的核心技能。当我们需要保存用户偏好设置、应用配置或简单状态数据时SharedPreferences简称SP往往是首选方案。与SQLite数据库相比SP以键值对形式存储数据采用XML文件格式保存特别适合存储布尔值、整型、字符串等简单数据类型。我见过不少新手开发者一遇到存储需求就直接上数据库结果把简单问题复杂化。实际上SP的API设计极其简洁核心操作只有get和put两类方法。它的数据文件存放在/data/data/package_name/shared_prefs/目录下文件名默认为preference_name.xml。通过Android Studio的Device File Explorer可以方便地查看这些文件内容这对调试非常有帮助。重要提示虽然SP操作简单但误用会导致严重性能问题。我曾在一个用户量超百万的App中见过因频繁调用edit().commit()导致主线程卡顿的案例这点后文会详细说明。2. SharedPreferences核心操作详解2.1 基本读写操作流程获取SP实例的标准方式是通过Context的getSharedPreferences()方法。这里有个开发者常犯的错误——每次读写都重新获取实例。实际上SP内部有缓存机制正确的做法是在Activity或Application中保存实例引用// 在Application中初始化 val prefs getSharedPreferences(user_prefs, Context.MODE_PRIVATE) // 写操作 prefs.edit().putString(username, john_doe).apply() // 读操作 val username prefs.getString(username, default)注意模式参数MODE_PRIVATE是当前唯一推荐使用的模式其他模式如MODE_WORLD_READABLE在Android高版本已被废弃存在安全隐患。2.2 异步提交与同步提交SP提供了两种提交方式apply()异步写入磁盘无返回值commit()同步写入磁盘返回boolean表示成功与否在大多数场景下都应该使用apply()。我做过实测连续调用100次commit()会使主线程阻塞约2秒而apply()仅需几毫秒。但在某些特殊场景如应用退出前保存关键数据时可能需要使用commit()确保数据落盘。2.3 数据类型支持与限制SP支持以下数据类型基本类型Int、Long、Float、Boolean字符串String集合Set需要注意的是存储大型字符串或复杂对象需自行序列化如转为JSONSet集合中的元素必须是不可变的不同数据类型有对应的存取方法混用会导致ClassCastException3. 高级用法与性能优化3.1 监听数据变化通过注册OnSharedPreferenceChangeListener可以实时监控数据变化val listener SharedPreferences.OnSharedPreferenceChangeListener { _, key - when(key) { theme_color - updateUITheme() } } prefs.registerOnSharedPreferenceChangeListener(listener) // 记得在适当时机取消注册 override fun onDestroy() { super.onDestroy() prefs.unregisterOnSharedPreferenceChangeListener(listener) }3.2 多进程使用注意事项默认情况下SP不支持多进程同步。如果需要跨进程共享数据应该使用MODE_MULTI_PROCESS已废弃不推荐改用ContentProvider使用MMKV等第三方解决方案3.3 性能优化实践批量操作多次修改应集中在一个Editor中完成prefs.edit() .putBoolean(notifications, true) .putInt(login_count, 5) .apply()避免高频写入如记录用户操作次数时可以先内存累加再定时持久化大型数据分拆当单个SP文件超过100KB时应考虑按功能拆分为多个文件4. 常见问题排查与替代方案4.1 典型问题速查表问题现象可能原因解决方案读取返回默认值键名拼写错误使用常量定义键名数据修改未生效忘记调用apply()/commit()检查是否遗漏提交出现ClassCastException类型不匹配统一存取方法类型文件损坏异常关机或并发写入备份后删除重建4.2 SharedPreferences的局限性当遇到以下场景时应考虑其他存储方案需要存储复杂关系数据 → Room/SQLite需要高频写入大量数据 → 文件存储/MMKV需要跨进程实时同步 → ContentProvider/DataStore4.3 Jetpack DataStore的迁移Google推荐的DataStore正在逐步替代SP它提供两种实现Preferences DataStore类似SP的键值存储Proto DataStore支持类型安全的数据存储迁移示例// 在build.gradle中添加依赖 implementation androidx.datastore:datastore-preferences:1.0.0 // 创建DataStore实例 val Context.dataStore by preferencesDataStore(name settings) // 写入数据 suspend fun saveSettings() { context.dataStore.edit { preferences - preferences[PreferencesKeys.THEME_COLOR] dark } }在实际项目中我通常采用渐进式迁移策略新功能使用DataStore旧功能逐步重构两者可以共存一段时间。5. 实战经验与避坑指南键名管理建议使用object集中定义所有键名避免硬编码object PrefKeys { const val USER_NAME user_name const val LOGIN_COUNT login_count }默认值处理读取时务必考虑默认值情况特别是布尔值默认取false可能导致逻辑错误版本兼容在onCreate()中初始化默认值避免新版本新增配置项时出现NPE加密敏感数据不要直接用SP存储密码等敏感信息应使用EncryptedSharedPreferencesval masterKey MasterKey.Builder(context) .setKeyScheme(MasterKey.KeyScheme.AES256_GCM) .build() val securePrefs EncryptedSharedPreferences.create( context, secret_prefs, masterKey, EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV, EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM )测试技巧在单元测试中可以使用InstrumentationRegistry.getContext()获取测试上下文配合SharedPreferences.Editor.clear()快速重置测试环境在最近的一个电商App项目中我们通过将用户浏览历史从SP迁移到Room使页面加载速度提升了40%。这个案例告诉我们技术选型需要根据数据规模和访问频率动态调整没有一劳永逸的方案。