image.png
..
SharedPreferences
Android 五种数据存储的方式分别为：
| 名字 | 介绍 |
|---|---|
| SharedPreferences | 以Map形式存放简单的配置参数； |
| ContentProvider | 将应用的私有数据提供给其他应用使用； |
| 文件存储 | 以IO流形式存放，可分为手机内部和手机外部（sd卡等）存储，可存放较大数据； |
| SQLite | 轻量级、跨平台数据库，将所有数据都是存放在手机上的单一文件内，占用内存小； |
| 网络存储 | 数据存储在服务器上，通过连接网络获取数据； |
Sharedpreferences是Android平台上一个轻量级的存储类，用来保存应用程序的各种配置信息，其本质是一个以“键-值”对的方式保存数据的xml文件，其文件保存在/data/data//shared_prefs目录下。在全局变量上看，其优点是不会产生Application 、 静态变量的OOM（out of memory）和空指针问题，其缺点是效率没有上面的两种方法高。
使用SharedPreferences
获取SharedPreferences对象
首先要获取SharedPreferences才能进行操作。获取SharedPreferences对象有下面两个方式：
-
getSharedPreferences(String name, int mode)
通过Context调用该方法获得对象。它有两个参数，第一个name 指定了SharedPreferences存储的文件的文件名，第二个参数mode 指定了操作的模式。
mode的模式：
Context.MODE_PRIVATE: 指定该SharedPreferences数据只能被本应用程序读、写；
Context.MODE_WORLD_READABLE: 指定该SharedPreferences数据能被其他应用程序读，但不能写；
Context.MODE_WORLD_WRITEABLE: 指定该SharedPreferences数据能被其他应用程序读；
Context.MODE_APPEND：该模式会检查文件是否存在，存在就往文件追加内容，否则就创建新文件；
-
getPreferences(int mode)
通过Activity调用获得对象。它只有一个参数mode 指定操作模式。这种方式获取的对象创建的文件 属于Activity,只能在该Activity中使用，且没有指定的文件名，文件名同Activity名字。
例子：
mContextSp = this.getSharedPreferences( "testContextSp", Context.MODE_PRIVATE );
mActivitySp = this.getPreferences( Context.MODE_PRIVATE );
写数据
步骤1：创建一个SharedPreferences对象
SharedPreferences sharedPreferences= getSharedPreferences("data",Context.MODE_PRIVATE);
步骤2： 实例化SharedPreferences.Editor对象
SharedPreferences.Editor editor = sharedPreferences.edit();
步骤3：将获取过来的值放入文件
editor.putString("name", “Tom”);
editor.putInt("age", 28);
editor.putBoolean("marrid",false);
步骤4：提交
editor.commit();
读取数据
SharedPreferences sharedPreferences= getSharedPreferences("data", Context .MODE_PRIVATE);
String userId=sharedPreferences.getString("name","");
删除指定数据
editor.remove("name");
editor.commit();
清空数据
editor.clear();
editor.commit();
commit和apply区别
apply函数立即更改内存中的SharedPreferences对象，但异步地将更新写入磁盘。
commit函数同步地将数据写入磁盘。在主线程调用它应该多注意，因为可能引起阻塞，引起ANR。
commit有返回值，返回是否成功写入永久性存储种。apply没有返回值。
性能问题
- 跨进程不安全。
由于没有使用跨进程的锁，就算使用 MODE_MULTI_PROCESS，SharedPreferences 在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SharedPreferences 大约会有万分之一的损坏率。 - 加载缓慢。
SharedPreferences 文件的加载使用了异步线程，而且加载线程并没有设置优先级，如果这个时候读取数据就需要等待文件加载线程的结束。这就导致主线程等待低优先线程锁的问题，比如一个 100KB 的 SP 文件读取等待时间大约需要 50 ~ 100ms，并且建议大家提前用预加载启动过程用到的 SP 文件。 - 全量写入。
无论是 commit() 还是 apply()，即使我们只改动其中一个条目，都会把整个内容全部写到文件。而且即使我们多次写同一个文件，SP 也没有将多次修改合并为一次，这也是性能差的重要原因之一。 - 卡顿。
由于提供了异步落盘的 apply 机制，在崩溃或者其它一些异常情况可能会导致数据丢失。所以当应用收到系统广播，或者被调用 onPause 等一些时机，系统会强制把所有的 SharedPreferences 对象的数据落地到磁盘。如果没有落地完成，这时候主线程会被一直阻塞。这样非常容易造成卡顿，甚至是ANR，从线上数据来看 SP 卡顿占比一般会超过 5%。
网友评论