本地存储(2) - SP

SharedPreferences

在内存/data/data/包名/shared_prefs目录下，以xml格式进行保存，适用于存储一些键值对，一般用来存储配置信息。

 

一、优缺点

1、与数据库相比，免去了创建数据库、表，写SQL语句等诸多操作，相对而言操作更加方便，快捷。

2、只能存储五种简单的数据类型 （boolean float int long string）

3、无法进行条件查询

 

二、使用步骤

1.根据上下文获取SharedPreferences对象（需指定权限，默认MODE_PRIVATE）。

2.利用edit()方法获取Editor对象。

3.通过Editor对象来存储key-value键值对数据。

4.通过commit()或apply方法提交数据。

Context.MODE_PRIVATE: 指定该SharedPreferences数据只能被本应用程序读、写。

Context.MODE_WORLD_READABLE:  指定该SharedPreferences数据能被其他应用程序读，但不能写。

Context.MODE_WORLD_WRITEABLE:  指定该SharedPreferences数据能被其他应用程序读，写。

 

三、注意事项

1、不要存放大的key和value，因为内存会缓存一份，导致占用内存过大，引起界面卡、频繁GC等等。

2、建议业务不相关的配置项分文件存储。（文件越大读取越慢，尽量别存defalut文件）

3、批量操作数据需求，尽量一次提交（edit和apply）。

4、尽量不要存放JSON和HTML，这种场景请直接使用json！

5、不要用来进行跨进程通信

参考:http://weishu.me/2016/10/13/sharedpreference-advices/

 

四、操作安全性

1、SharePreferences是线程安全的 里面的方法有大量的synchronized来保障，但不是进程安全，因此不要

从 Android N 开始, 不再支持 MODE_WORLD_READABLE & MODE_WORLD_WRITEABLE. 一旦指定, 会抛异常 。也不要用MODE_MULTI_PROCESS 迟早被放弃。

2、第一次getSharePreference会读取磁盘文件，异步读取，写入到内存中，后续的getSharePreference都是从内存中拿了。

3、第一次读取完毕之前 所有的get/set请求都会被卡住 等待读取完毕后再执行，所以第一次读取会有ANR风险。

4、所有的get都是从内存中读取。

5、提交都是 写入到内存和磁盘中 。apply跟commit的区别在于

• commit和apply虽然都是原子性操作，但是原子的操作不同，commit是原子提交到数据库，所以从提交数据到存在Disk中都是同步过程，中间不可打断。
• 而apply方法的原子操作是原子提交的内存中，而非数据库，所以在提交到内存中时不可打断，之后再异步提交数据到数据库中，因此也不会有相应的返回值。
• 所有commit提交是同步过程，效率会比apply异步提交的速度慢，但是apply没有返回值，永远无法知道存储是否失败。
• 在不关心提交结果是否成功的情况下，优先考虑apply方法.

6、每次commit/apply都会把全部数据一次性写入到磁盘，即没有增量写入的概念 。 所以单个文件千万不要太大 否则会严重影响性能。

微信的第三方MMKV来替代SharePreference:https://github.com/tencent/mmkv -> 原理 解决sp无增量

 

原理

edit() -> 通过XmlPullParserException 解析/data/data/包名/shared_prefs/下文件 解析到内存。