如果说程序可以简单理解成“指令和数据的集合”，那么你在任何平台上编程都难以离开数据存储，在Android平台上自然也不会例外。说到数据的存储，对于Key-Value对应的数据存取，Android提供SharedPreferences的方式可以进行方便的操作。大家也都觉得它的使用很简单，但是有时候简单的地方也会发生问题，而且你很难查觉到问题根源在这个地方。
面试题：修改SharedPreferences后两种提交方式有什么区别？
SharedPreferences类是一个接口类，真正的实现类是SharedPreferencesImpl。修改SharedPreferences需要获取它的Editor，在对Editor进行put操作后，最后通过commit或者apply提交修改到内存和文件。当然有了两种都可以提交的方法，肯定要区别一下的。从实现类SharedPreferencesImpl的源码上看也很容易看出两者的区别：
commit这种方式很常用，在比较早的SDK版本中就有了，这种提交修改的方式是同步的，会阻塞调用它的线程，并且这个方法会返回boolean值告知保存是否成功（如果不成功，可以做一些补救措施）。
而apply是异步的提交方式，目前Android Studio也会提示大家使用这种方式。
还有一点用得比较少的，就是SharedPreferences还提供一个监听接口可以监听SharedPreferences的键值变化，需要监控键值变化的可以用registerOnSharedPreferenceChangeListener添加监听器。
public interface SharedPreferences {
/**
* Interface definition for a callback to be invoked when a shared
* preference is changed.
*/
public interface OnSharedPreferenceChangeListener {
void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key);
}
多进程操作和读取SharedPreferences的问题
前段时间，项目组里发现一个偶现的问题，从Http明明获取了正确的数据保存到SharedPreferences，但立即再从SharedPreferences读取这个值时发现是初始值。开始大家一直把精力放在Http的请求上，最后才发现是SharedPreferences多进程间数据共享会导致的问题。
在SDK 3.0及以上版本，可以通过Context.MODE_MULTI_PROCESS属性来实现SharedPreferences多进程共享。如下设置：
public static SharedPreferences getSharedPreferences(String name) {
if (null != context) {
if (Build.VERSION.SDK_INT >= 11) {
return context.getSharedPreferences(name, Context.MODE_MULTI_PROCESS);
} else {
return context.getSharedPreferences(name, Context.MODE_PRIVATE);
}
}
return null;
}
本来以为通过MODE_MULTI_PROCESS属性使用SharedPreferences就可以实现不同时程间共享数据，但是在真正使用中确发现有会有一定概率出现这个取值出错（变为初始值）问题。
最后发现在官网上Google也在SDK 6.0的版本将这个MODE_MULTI_PROCESS标识为deprecated（不赞成使用）。目前来说，越来越多的项目在不断的膨胀，为了降低单个进程的内存占用率，使用"android:process"配置一些组件在单独的进程中运行已经是司空见惯了，所以大家在遇到自己的项目有多进程时，要注意一下SharedPreferences的问题。
小结
在一个进程中，SharedPreference往往建单个实例就可以了，一般不会出现并发冲突，如果对提交的结果不关心的话，建议使用apply，当然需要确保提交成功且有后续操作的话，还是需要用commit的。
因为SharedPreferences在多进程方面的问题，大家也可以思考下能不能自己实现一个加强版的SharedPreferences解决这些问题，网上也有一些开源的替代方案，如Github上的tray。（建议大家先想一下，再看这个项目。）
