SharedPreferences深入了解—关于跨进程SharedPreferences

在日常开发中SharedPreferences想必肯定是经常被我们使用的了，通常情况下使用它并不会发生什么问题，但是假如遇到了在不同进程中使用SharedPreferences（例如指定了process的activity/service），那坑就来了。

这里我们可以实验一下，创建两个Activity，在AndroidManifest其中一个将其process指定为second进程

代码比较简单，就是将输入框的内容存入到SharedPreferences中，并显示到TextView上，点击跳转按钮跳转到SecondActivity

SecondActivity就是点击按钮获取SharedPreferences的值并显示到TextView，不过这里要注意它是运行在不同的进程中的。

这里我们将值改为hello，然后点击修改，可以看到SharedPreferences的值已经改成功了。

然后我们跳转到SecondActivity并获取值，

一切正常，好现在我们回到MainActivity，并再次修改SharedPreferences中的值，

可以看到SharedPreferences的值已经再次被修改成功，这时我们再跳转到SecondActivity并获取值，

不管怎么获取都是之前的值，然后重启app，再进入SecondActivity，便又能获取到正确的值了。

这里我们先总结一下结论

• 先启动主进程并获取SharedPreferences对象，然后启动其他进程并获取SharedPreferences对象，那么此时对SharedPreferences的数值进行修改均不能对其他进程产生作用。

• 先启动主进程并获取SharedPreferences对象，然后对值进行修改，然后启动其他进程并获取SharedPreferences对象，能取得修改后的值，但此时如果再对此值进行修改，均不能对其他进程产生作用。

总结下来就是，其他进程在启动时获取到的SharedPreferences的值只能是这个进程启动前这个值的最后值，即在进程启动后对值的修改只对当前进程有效，须等到进程重启或者app重启才能与其他进程进行“同步”。

这里即使把获取SharedPreferences对象的模式改为MODE_MULTI_PROCESS，也仅仅是在Android 3.0以下才有效，在Android 3.0以上也是一样不行的。

那么为什么会这样子呢，笔者带大家从源码的角度来分析一下，我们来看一下关于SharedPreferences的源码。

2源码分析

通常我们获取SharedPreferences对象一般是这样

SharedPreferences sharedPreferences =        PreferenceManager.getDefaultSharedPreferences(this);//或者这样SharedPreferences sharedPreferences =         getSharedPreferences("name", Context.MODE_PRIVATE);

实际上PreferenceManager.getDefaultSharedPreferences(context)方法也是对getSharedPreferences做了封装

所以不管通过哪种方式，最终都是通过Context中的getSharedPreferences方法来获取SharedPreferences对象，在Context中，getSharedPreferences方法是一个抽象方法，没有具体实现

public abstract SharedPreferences             getSharedPreferences(String name, int mode);

我们知道Context的实现类其实就是ContextImpl，所以这里我们直接去到ContextImpl的getSharedPreferences方法中，

这里比较简单，先判断了ArrayMap中是否存在该File对象，不存在则创建一个并放入ArrayMap，然后调用getSharedPreferences的重载方法getSharedPreferences(file, mode)，我们看一下这个方法的源码

可以看到，这里将SharedPreferences的实例对象SharedPreferencesImpl缓存起来，以后每次获取如果内存中已经存在那么直接返回，如果不存在才会进行重新创建;

那么这里我们可以有个猜想，即是否只有在创建SharedPreferences对象的时候才会从磁盘中进行读取，读取后的值保存在了内存中，获取SharedPreferences对象优先从缓存中获取，再次创建时才会重新从磁盘中再次读取文件。

我们直接看一下SharedPreferencesImpl的源码，验证一下我们的猜想。

可以看到，在SharedPreferencesImpl的构造方法中调用了startLoadFromDisk，startLoadFromDisk方法中开启了一个线程加载磁盘中的文件，loadFromDisk源码如下

看到这里，已经逐步验证了我们之前的猜想，在构造方法中读取了磁盘文件的内容并赋值给了成员变量mMap集合，我们只需要看看所有的get方法是不是从mMap成员变量中获取值就能完全验证我们的猜想是否正确，因为get方法都大同小异，所以我们就只分析一下getString方法就可以了。

可以看到，果然是这样的，从mMap集合中直接取出值进行返回，那么看到这里肯定会有个疑问，为什么在同个进程却又没有问题呢，或者其他进程对SharedPreferences的获取在值修改完毕之后也没有问题，这里我们看一下SharedPreferencesImpl的内部类EditorImpl的源码，EditorImpl是Editor的实现类。

可以看到，EditorImpl内部有一个mModified的Map成员变量，我们所有的修改在调用了commit或者apply方法后才会执行保存，可以看到，不管调用哪个方法都会调用commitToMemory()和enqueueDiskWrite方法，那么我们看一下这两个方法的源码

其实通过方法名我们也可以猜到，就是将值提交到内存，从代码上也可以看出来，就是将Editor的所有put进去的值添加到SharedPreferences的mMap成员变量中。

那么最后将内容写入磁盘的方法就是enqueueDiskWrite了，我们看一下它的源码

源码比较简单，其中最主要的就是区分了apply方法调用和commit的调用,apply调用的话会将写入磁盘的任务加入到一个线程池中在后台运行，直接commit的话则会在当前线程进行写入。

3总结

整个获取SharedPreferences对象过程的流程图如下

Android的SharedPreferences采用了这种模式，主要还是为了防止频繁通过IO读取磁盘带来的性能开销，毕竟SharedPreferences还是比较常用的，如果实时去磁盘文件进行读取，那么在性能上肯定有不容忽视的影响。

同时，MODE_MULTI_PROCESS的模式也已经被Google弃用，多进程之间的数据共享Google不推荐我们使用SharedPreferences，而是使用例如ContentProvider这种方式。

同时，通过源码我们发现，如果对存储的成功与否的结果并不关心的话，使用apply方法进行提交可以在性能上有一定的优化，因为apply方法是在线程池进行文件的写入，而commit方法则是直接在当前线程进行文件的写入的。

转载自http://chuansong.me/n/1814019051024