SharePreference 优化建议

1、不要存放大的 key 或 value 在 SharedPreferences 中，否则会一直存储在内存中（Map 容器中）得不到释放，内存使用过高会频繁引发 GC，导致界面丢帧甚至 ANR。

2、不相关的配置选项最好不要放在一起，单个文件越大加载时间越长。（参照 SharedPreferences 初始化时会开启异步线程读取对应文件，如果此时耗时较长，当对其进行相关数据操作时会导致线程等待）

3、读取频繁的 key 和 不频繁的 key 尽量不要放在一起。（如果整个文件本身就较小则可以忽略）

4、不要每次都 edit 操作，每次 edit 都会创建新的 EditorImpl 对象，最好批量处理统一提交。否则每次 edit().commit() 都会创建新的 EditorImpl 对象并进行一次 I/O 操作，严重影响性能。

5、commit 提交发生在 UI 线程，apply 提交发生在工作线程，对于数据的提交最好是批量操作统一提交。虽然 apply 任务发生在工作线程（不会因为 I/O 阻塞 UI 线程），但是如果添加过多任务也有可能带来其它”严重后果“（参照系统源码 ActivityThread - handlePauseActivity 方法实现）。

6、尽量不要存放 JSON 或 HTML 类型数据，这种可以直接文件存储。

7、最好能够提前初始化 SharedPreferences，避免 SharedPreferences 第一次创建时读取文件内容线程未结束而出现的等待情况，参照优化点第 2 条。

8、不要指望它能够跨进程通信：Context.MODE_MULTI_PROCESS。

实际项目中： 当前项目中很多业务一些状态的持久化都保存在了一个Preference中，其中定义了100个Key，几乎所有的业务持久化都保存在其中了

存在的问题：

1 长期下来，会导致Preference过大，其初始化时间过长

2 如果业务模块需要持久化一些状态，尽量使用只和自身业务相关的Preference 

 解决方式：

1 拆分出几个独立的Preference(用户信息和登录状态相关，阅读任务相关的，app设置相关的，app 配置相关的(比如 图片host 配置等)

2 修改读取方式，由 commonPreference ---> businessPreference

3 进行数据库升级，然后将commonPreference中的状态 迁移到 businessPreference