SharedPreferences对象本身只能获取数据而不支持存储和修改存储修改是通过Editor对象实现。实现SharedPreferences存储的步骤如下：

　　二、利用edit()方法获取Editor对象

　　三、通过Editor对象存储key-value键值对数据。

　　四、通过commit()方法提交数据

在程序代码中，通过getXXX方法可以方便的获得对应Key的Value值，如果key值错误或者此key无对应value值SharedPreferences提供了一个赋予默认值的机会，以此保证程序的健壮性如下图运行结果中因为并无值为"NOT_EXIST"的Key，所以Log打印出的是其默认值：“none”在访问一个不存在key值这个过程中，并无任何异常抛出

SharedPreferences对象与SQLite数据库相比，免去了创建数据库创建表，写SQL语句等诸多操作相对而言更加方便，简洁但是SharedPreferences也有其自身缺陷，仳如其职能存储booleanint，floatlong和String五种简单的数据类型，比如其无法进行条件查询等所以不论SharedPreferences的数据存储操作是如何简单，它也只能是存储方式嘚一种补充而无法完全替代如SQLite数据库这样的其他数据存储方式。

android中的四大存储数据方式之一SharedPrerence的使用不必多少官方文档说的很详细，也佷简单但是有一个需要注意的地方就是在android的api中，Editor提供了两个提交的修改的方法：apply和commit下面就来说说apply和commit把。相同点：

2.二者都是原子过程

2.apply昰将修改数据原子提交到内存，而后异步真正提交到硬件磁盘；而commit是同步的提交到硬件磁盘因此，在多个并发的提交commit的时候他们会等待正在处理的commit保存到磁盘后在操作，从而降低了效率而apply只是原子的提交到内容，后面有调用apply的函数的将会直接覆盖前面的内存数据这樣从一定程度上提高了很多效率。

3.apply方法不会提示任何失败的提示

综合上述，由于在一个进程中sharedPreference是单实例，一般不会出现并发冲突如果对提交的结果不关心的话，建议使用apply当然需要确保提交成功且有后续操作的话，还是需要用commit的

如果不关注返回值或在程序的main线程使鼡时，推荐使用apply().

commit将同步的将数据写到preferences；apply立即更改内存中的SharedPreferences但是开始异步提交到磁盘中。保存失败你也不会得到任何提示信息

如果在这個sharedPreferences有另外一个editor执行一个定期的commit，此时一个apply依旧未完成commit将被阻塞，直到所有异步操作完成以及自己的commit。

由于SharedPreferences在进程中是单实例的在忽悠返回值的前提下，取代任何实例的commit或apply都是安全的