Android之SharedPreferences使用

SharedPreferences

Android 五种数据存储的方式分别为：

Sharedpreferences是Android平台上一个轻量级的存储类，用来保存应用程序的各种配置信息，其本质是一个以“键-值”对的方式保存数据的xml文件，其文件保存在/data/data//shared_prefs目录下。在全局变量上看，其优点是不会产生Application 、 静态变量的OOM（out of memory）和空指针问题，其缺点是效率没有上面的两种方法高。

使用SharedPreferences

获取SharedPreferences对象

首先要获取SharedPreferences才能进行操作。获取SharedPreferences对象有下面两个方式：

1. 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：该模式会检查文件是否存在，存在就往文件追加内容，否则就创建新文件；

1. 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没有返回值。

性能问题

1. 跨进程不安全。 由于没有使用跨进程的锁，就算使用 MODE_MULTI_PROCESS，SharedPreferences 在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SharedPreferences 大约会有万分之一的损坏率。
2. 加载缓慢。 SharedPreferences 文件的加载使用了异步线程，而且加载线程并没有设置优先级，如果这个时候读取数据就需要等待文件加载线程的结束。这就导致主线程等待低优先线程锁的问题，比如一个 100KB 的 SP 文件读取等待时间大约需要 50 ~ 100ms，并且建议大家提前用预加载启动过程用到的 SP 文件。
3. 全量写入。 无论是 commit() 还是 apply()，即使我们只改动其中一个条目，都会把整个内容全部写到文件。而且即使我们多次写同一个文件，SP 也没有将多次修改合并为一次，这也是性能差的重要原因之一。
4. 卡顿。 由于提供了异步落盘的 apply 机制，在崩溃或者其它一些异常情况可能会导致数据丢失。所以当应用收到系统广播，或者被调用 onPause 等一些时机，系统会强制把所有的 SharedPreferences 对象的数据落地到磁盘。如果没有落地完成，这时候主线程会被一直阻塞。这样非常容易造成卡顿，甚至是ANR，从线上数据来看 SP 卡顿占比一般会超过 5%。