多进程下的SharedPreferences情况
先启动主进程并获取SharedPreferences对象,然后对值进行修改,然后启动其他进程并获取SharedPreferences对象,能取得修改后的值,但此时如果再对此值进行修改,均不能对其他进程产生作用。
总结下来就是,其他进程在启动时获取到的SharedPreferences的值只能是这个进程启动前这个值的最后值,即在进程启动后对值的修改只对当前进程有效,须等到进程重启或者app重启才能与其他进程进行“同步”。
这里即使把获取SharedPreferences对象的模式改为MODE_MULTI_PROCESS,也仅仅是在Android3.0以下才有效,在Android3.0以上也是一样不行的。
那么为什么会这样子呢,笔者带大家从源码的角度来分析一下,我们来看一下关于SharedPreferences的源码。
源码分析
通常我们获取SharedPreferences对象一般是这样
实际上PreferenceManager.getDefaultSharedPreferences(context)方法也是对getSharedPreferences做了封装
所以不管通过哪种方式,最终都是通过Context中的getSharedPreferences方法来获取SharedPreferences对象,在Context中,getSharedPreferences方法是一个抽象方法,没有具体实现
我们知道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的话则会在当前线程进行写入。
总结
整个获取SharedPreferences对象过程的流程图如下
流程总结
- 当调用PreferenceManager的getSharedPreferences(String name,int mode)方法的时候,会通过该方法参数name(文件名)从ArrayMap中获取对应的File(无的话则创建ArrayMap或在ArrayMap中添加该键值对),然后调用重载方法getSharePreferences(File file,int mode)传入file,该方法中将通过包名从缓存中获取ArrayMap
,通过file获取返回SharedPreferencesImpl(接口SharedPreferences的实现类)对象,无则创建SharedPreferencesImpl并加入ArrayMap(若Android版本小于3.0并且mode为MODE_NULTI_PROCESS,则重新读取磁盘文件) - 当创建SharedPreferencesImpl的时候,会在构造方法中开启一个线程加载磁盘当中的文件并将内容赋值给了成员变量mMap(Map
集合),当调用getString等方法时,则是直接从mMap集合中取出值进行返回。 - 当需要进行写入的时候,则需获取接口Editor中的方法(其实现类为EditorImpl)提交方法apply()或commit()都会将所有put进去的值添加到SharedPreferencesImpl的mMap成员变量中,然后再将内容写入磁盘。
(写入的时候会写入内存和磁盘,而获取的时候则从内存中读取,除非重新创建或Android版本小于3.0并且mode为MODE_NULTI_PROCESS,因此造成多进程情况下修改数据后另一进程获取不到改变)
Android的SharedPreferences采用了这种模式,主要还是为了防止频繁通过IO读取磁盘带来的性能开销,毕竟SharedPreferences还是比较常用的,如果实时去磁盘文件进行读取,那么在性能上肯定有不容忽视的影响。
同时,MODE_MULTI_PROCESS的模式也已经被Google弃用,多进程之间的数据共享Google不推荐我们使用SharedPreferences,而是使用例如ContentProvider这种方式。
同时,通过源码我们发现,如果对存储的成功与否的结果并不关心的话,使用apply方法进行提交可以在性能上有一定的优化,因为apply方法是在线程池进行文件的写入,而commit方法则是直接在当前线程进行文件的写入的。