不使用数据库时如何在Android的Activity和Fragment间持久化数据

相关核心结论是准确的：Android会优先销毁后台进程释放内存，进程销毁后内存中的Singleton实例会被全部清空，应用回到前台时会重建新进程，不存在跨进程维持同一个Singleton实例的方法。

Android系统销毁后台进程是系统级不可控行为，所有仅存在于内存中的数据都会随进程销毁被清空，不存在完全不落地存储就能100%保证数据不丢失的方案，但可以选择多种比数据库更轻量的落地方式，不需要引入数据库框架、也不需要写复杂的数据库初始化逻辑：

• 轻量数据用SharedPreferences存储
  如果你的持久化对象是基础数据类型、字符串，或是可序列化为JSON的简单对象，直接使用系统自带的SharedPreferences即可实现透明读写。可以在Singleton封装层自动处理读写逻辑：Singleton实例为空时自动从SharedPreferences反序列化恢复数据，数据更新时同步写入SharedPreferences，整个过程对上层业务调用透明，无需编写增删改查类的数据库操作代码。
  注意：SharedPreferences采用全量读写的实现逻辑，不适合存储超过100KB的大对象或是高频修改的数据，避免出现性能问题。

• 仅需页面重建恢复的场景用onSaveInstanceState
  如果你的数据只需要覆盖Activity/Fragment意外销毁重建的场景，不需要支持应用进程完全被杀死后重启仍保留数据，可以直接使用系统自带的InstanceState机制：在Activity的onSaveInstanceState回调中把需要的数据存入Bundle，Fragment可以通过setArguments或者onSaveInstanceState存储状态，系统会自动将Bundle数据暂存到系统进程的缓存中，就算当前应用进程被临时销毁，重建页面时仍能取回之前存入的Bundle数据。
  注意：系统对Bundle存储的总大小有限制，通常建议不要超过1MB，超出会触发TransactionTooLargeException异常。

• 大体积高频修改数据用私有文件惰性存储
  如果你的数据体积较大、修改频次较高，不想每次修改都触发磁盘IO，可以监听应用前后台切换事件，仅在应用退到后台时一次性把Singleton中的全量数据序列化后写入应用内部存储的私有文件，应用回到前台时如果检测到Singleton为空就自动从私有文件读取恢复。这种方案磁盘IO次数少，性能优于每次修改都写存储的方案，也不需要引入数据库框架。

• 所有仅依赖内存的存储方案都无法应对系统主动杀进程的场景，如果你要求数据在应用重启、进程销毁等任意场景下都不丢失，必须做磁盘落地，只是可以根据数据特点选择上述更轻量的落地方式，不需要一定使用SQLite、Room等数据库框架。
• 无论采用哪种方案，都要给Singleton增加空保护逻辑：所有访问Singleton数据的位置要么做判空处理，要么确保调用前Singleton已经完成实例恢复逻辑，避免出现空指针崩溃。

内容的提问来源于stack exchange，提问作者AtomicallyBeyond