Android -- 每日一问：修改 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 的问题。

你的朋友是不是也在准备面试呢？你可以“请朋友读”，把今天的题目分享给好友，或许你能帮到他。