Android SharedPreferences 源码分析以及跨进程读写问题

概述

Android SharedPreferences 提供了下面的模式来支持跨进程读写数据问题。

@Deprecated
public static final int MODE_MULTI_PROCESS = 0x0004;

这种模式已经被官方标记为 Deprecated，关于废弃的原因，官方有解释：

* @deprecated MODE_MULTI_PROCESS does not work reliably in
* some versions of Android, and furthermore does not provide any
* mechanism for reconciling concurrent modifications across
* processes.  Applications should not attempt to use it.  Instead,
* they should use an explicit cross-process data management
* approach such as {@link android.content.ContentProvider ContentProvider}.

Google认为多个进程读同一个文件都是不安全的，不建议这么做。Android 不保证该模式总是能正确的工作，建议使用 ContentProvider 替代多进程之间文件的共享。
如果在某些条件下必须使用，则要注意下面介绍的几个坑。

测试案例

在测试的工程中创建一个 Activity，指定在另外一个进程和 Task 中启动：

android:process=":second"
android:launchMode="singleTask"
android:taskAffinity="com.example.heqiang.testsomething.SecondActivity"

然后在 MainActivity 中启动 SecondActivity 把当前时间写入到 SharedPreferences：

public void startSecondActivity(View v) {
    SharedPreferences preferences = getSharedPreferences("TEST_MULTI_PROCESS",Context.MODE_MULTI_PROCESS);
    String time = String.valueOf(System.currentTimeMillis());
    preferences.edit().putString("time", time).apply();
    Toast.makeText(this, time, Toast.LENGTH_SHORT).show();

    Intent intent = new Intent(this, SecondActivity.class);
    startActivity(intent);
}

在 SecondActivity 中添加一个按钮，点击可以跨进程获取 SharedPreferences 中 time 的值。
先看第一种实现方案：

public class SecondActivity extends Activity {
    private SharedPreferences mSharedPreferences;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        mSharedPreferences = getSharedPreferences("TEST_MULTI_PROCESS", Context.MODE_MULTI_PROCESS);
        Toast.makeText(this,"onCreate",Toast.LENGTH_SHORT).show();
    }


    public void getData(View view) {
        String time = mSharedPreferences.getString("time","null");
        Toast.makeText(this,time,Toast.LENGTH_SHORT).show();
    }
}

这种情况下 mSharedPreferences 实例只在 onCreate 中被初始化一次。
测试方法，启动 SecondActivity 后获取一次数据，然后将 SecondActivity 切回到后台，再次写入数据然后打开 SecondActivity 再次读取数据，你会发现，每次读取到的数据都是第一次的数据，虽然此时已经写入了新的数据，造成了写入和读取数据不同步的问题。
下面来测试一下下面的情况：

public class SecondActivity extends Activity {
    private SharedPreferences mSharedPreferences;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        Toast.makeText(this,"onCreate",Toast.LENGTH_SHORT).show();
    }


    public void getData(View view) {
        mSharedPreferences = getSharedPreferences("TEST_MULTI_PROCESS", Context.MODE_MULTI_PROCESS);
        String time = mSharedPreferences.getString("time","null");
        Toast.makeText(this,time,Toast.LENGTH_SHORT).show();
    }
}

这种情况下 mSharedPreferences 的初始化放在了每次获取数据的时候。这样读取数据是正常的。
为什么会是这样的？我们从源码里面找答案。

源码分析

获取 SharedPreferences 文件

private File getPreferencesDir() {
    synchronized (mSync) {
        if (mPreferencesDir == null) {
            mPreferencesDir = new File(getDataDir(), "shared_prefs");
        }
        return ensurePrivateDirExists(mPreferencesDir);
    }
}

在 ContextImpl.getPreferencesDir 方法中，会固定从 /data/data/<包名>/shared_prefs目录下获取对应名称的xml文件，如果想改变目录路径，则需要通过反射，在构造 SharedPreferencesImpl 时传入File参数来实现。

Class spiClass = Class.forName("android.app.SharedPreferencesImpl");
Constructor constructor = spiClass.getDeclaredConstructor(File.class, int.class);
constructor.setAccessible(true);
sp = (SharedPreferences) constructor.newInstance(file, mode);

获取 SharedPreferences 实例

@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
    checkMode(mode);
    SharedPreferencesImpl sp;
    synchronized (ContextImpl.class) {
        final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
        sp = cache.get(file);
        if (sp == null) {
            sp = new SharedPreferencesImpl(file, mode);
            cache.put(file, sp);
            return sp;
        }
    }
    if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
        getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
        // If somebody else (some other process) changed the prefs
        // file behind our back, we reload it.  This has been the
        // historical (if undocumented) behavior.
        sp.startReloadIfChangedUnexpectedly();
    }
    return sp;
}

private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
    if (sSharedPrefsCache == null) {
        sSharedPrefsCache = new ArrayMap<>();
    }

    final String packageName = getPackageName();
    ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
    if (packagePrefs == null) {
        packagePrefs = new ArrayMap<>();
        sSharedPrefsCache.put(packageName, packagePrefs);
    }

    return packagePrefs;
}

通过 ContextImpl.getSharedPreferences 方法可以看到，获取的 SharedPreferences 是 SharedPreferencesImpl 实例。这个实例保存在静态变量 SharedPreferencesImpl 中，因此，无论该包名的应用中有多少个 ContextImpl，他们共同使用同一个 SharedPreferencesImpl 实例。
在 MODE_MULTI_PROCESS 模式下，会调用 startReloadIfChangedUnexpectedly() 方法，区别也就在这里。
我们先来看一下 SharedPreferencesImpl 类。
该类就是一个简单的二级缓存，在启动时会将文件里的数据全部都加载到内存里。
先来看一下构造方法：

SharedPreferencesImpl(File file, int mode) {
    mFile = file;
    mBackupFile = makeBackupFile(file);
    mMode = mode;
    mLoaded = false;
    mMap = null;
    startLoadFromDisk();
}
private void startLoadFromDisk() {
    synchronized (this) {
        mLoaded = false;
    }
    // 开启后台线程进行从磁盘加载数据到内存的操作
    new Thread("SharedPreferencesImpl-load") {
        public void run() {
            loadFromDisk();
        }
    }.start();
}

private void loadFromDisk() {
    synchronized (SharedPreferencesImpl.this) {
        if (mLoaded) {
            return;
        }
        if (mBackupFile.exists()) {
            mFile.delete();
            mBackupFile.renameTo(mFile);
        }
    }

    ......

    Map map = null;
    StructStat stat = null;
    try {
        stat = Os.stat(mFile.getPath());
        if (mFile.canRead()) {
            BufferedInputStream str = null;
            try {
                str = new BufferedInputStream(
                        new FileInputStream(mFile), 16*1024);
                map = XmlUtils.readMapXml(str);
            } catch (XmlPullParserException | IOException e) {
                Log.w(TAG, "getSharedPreferences", e);
            } finally {
                IoUtils.closeQuietly(str);
            }
        }
    } catch (ErrnoException e) {
        /* ignore */
    }

    synchronized (SharedPreferencesImpl.this) {
        mLoaded = true;
        if (map != null) {
            mMap = map;
            mStatTimestamp = stat.st_mtime;
            mStatSize = stat.st_size;
        } else {
            mMap = new HashMap<>();
        }
        // 加载完毕，唤醒其他等待加载完毕的线程
        notifyAll();
    }
}

在构造 SharedPreferencesImpl 实例时，会从xml文件中通过 loadFromDisk() 把所有数据读取到 Map 中。

数据读取

以 getString 为例子介绍：
先来看数据的读取：

@Nullable
public String getString(String key, @Nullable String defValue) {
    // 同步代码块，保证 mMap 的线程安全
    synchronized (this) {
        // 等待加载操作时锁的释放
        awaitLoadedLocked();
        String v = (String)mMap.get(key);
        return v != null ? v : defValue;
    }
}

可以看到，数据的读取直接从内存的 Map 中获取，没有涉及到 xml 文件的读取。
这也就不难理解，跨进程读取和写入的时候，为什么会造成数据的不同步了，如果写入是在另外一个进程，写入后，如果读取进程不重新从加载xml文件到内存，那么读取进程的Map是不会更新的，就读取不到另外进程新写入的数据了。
get 方法使用了对象的同步锁，说明这个方法是线程安全的。

数据写入

再来看一下数据写入的情况，以 putString 为例子介绍：：

public Editor edit() {
    synchronized (this) {
        awaitLoadedLocked();
    }

    return new EditorImpl();
}

public final class EditorImpl implements Editor {
    // 存储提交之前需要修改的数据
    private final Map<String, Object> mModified = Maps.newHashMap();
    private boolean mClear = false;

    public Editor putString(String key, @Nullable String value) {
        //也使用了对象的同步锁，说明这个方法是线程安全的。
        synchronized (this) {
            // 暂时存储到 mModified 中
            mModified.put(key, value);
            return this;
        }
    }
    
    ...
    
    public boolean commit() {
        // 写入到内存Map中
        MemoryCommitResult mcr = commitToMemory();
        // 写入到本地xml文件
        SharedPreferencesImpl.this.enqueueDiskWrite(
            mcr, null /* sync write on this thread okay */);
        try {
            // 等待写入到本地xml文件结束
            mcr.writtenToDiskLatch.await();
        } catch (InterruptedException e) {
            return false;
        }
        // 通知通过 registerOnSharedPreferenceChangeListener 注册的监听器
        notifyListeners(mcr);
        return mcr.writeToDiskResult;
    }
    
    public void apply() {
        // 写入到内存Map中
        final MemoryCommitResult mcr = commitToMemory();
        // awaitCommit 和 postWriteRunnable 用来做一些线程间的同步操作
        final Runnable awaitCommit = new Runnable() {
                public void run() {
                    try {
                        // 等待写入到本地xml文件结束
                        mcr.writtenToDiskLatch.await();
                    } catch (InterruptedException ignored) {
                    }
                }
            };

        QueuedWork.add(awaitCommit);

        Runnable postWriteRunnable = new Runnable() {
                public void run() {
                    awaitCommit.run();
                    QueuedWork.remove(awaitCommit);
                }
            };

        // 写入到本地xml文件
        SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
        // 通知通过 registerOnSharedPreferenceChangeListener 注册的监听器
        notifyListeners(mcr);
    }

写入内存：

private MemoryCommitResult commitToMemory() {
    MemoryCommitResult mcr = new MemoryCommitResult();
    synchronized (SharedPreferencesImpl.this) {
        // mDiskWritesInFlight > 0说明内存中有未写入磁盘的数据
        if (mDiskWritesInFlight > 0) {
            // mMap 做一个 copy，保证写入磁盘过程中用的是不同的 Map 对象。
            //因为写入磁盘是个异步过程，这样在后一次调用commitToMemory时，
            //在更新mMap中的值时不会影响前一次的mapToWriteToDisk的写入磁盘。
            mMap = new HashMap<String, Object>(mMap);
        }
        mcr.mapToWriteToDisk = mMap;
        // mDiskWritesInFlight 加1，表示多了一个写操作。在写入磁盘后减1
        mDiskWritesInFlight++;

        boolean hasListeners = mListeners.size() > 0;
        if (hasListeners) {
            mcr.keysModified = new ArrayList<String>();
            mcr.listeners =
                    new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
        }

        synchronized (this) {
            // 是否需要清空 SharedPreferences 里面的数据
            if (mClear) {
                if (!mMap.isEmpty()) {
                    mcr.changesMade = true;
                    mMap.clear();
                }
                mClear = false;
            }

            for (Map.Entry<String, Object> e : mModified.entrySet()) {
                String k = e.getKey();
                Object v = e.getValue();
                // "this" is the magic value for a removal mutation. In addition,
                // setting a value to "null" for a given key is specified to be
                // equivalent to calling remove on that key.
                if (v == this || v == null) {
                    if (!mMap.containsKey(k)) {
                        continue;
                    }
                    mMap.remove(k);
                } else {
                    if (mMap.containsKey(k)) {
                        Object existingValue = mMap.get(k);
                        if (existingValue != null && existingValue.equals(v)) {
                            continue;
                        }
                    }
                    mMap.put(k, v);
                }

                mcr.changesMade = true;
                if (hasListeners) {
                    mcr.keysModified.add(k);
                }
            }
            // 清空临时缓存
            mModified.clear();
        }
    }
    return mcr;
}

整个方法用到了 SharedPreferencesImpl 类锁来同步。

写入磁盘：

private void enqueueDiskWrite(final MemoryCommitResult mcr,
                              final Runnable postWriteRunnable) {
    final Runnable writeToDiskRunnable = new Runnable() {
            public void run() {
                synchronized (mWritingToDiskLock) {
                    // 写入数据到磁盘
                    writeToFile(mcr);
                }
                synchronized (SharedPreferencesImpl.this) {
                    //减1标示完成了一个写磁盘操作
                    mDiskWritesInFlight--;
                }
                if (postWriteRunnable != null) {
                    postWriteRunnable.run();
                }
            }
        };
    // 如果是 commit 方法，postWriteRunnable为空，为同步操作
    final boolean isFromSyncCommit = (postWriteRunnable == null);

    if (isFromSyncCommit) {
        // 如果是同步操作，而且只有一次的内存写入操作
        // 直接在当前线程执行写入磁盘操作并返回
        boolean wasEmpty = false;
        synchronized (SharedPreferencesImpl.this) {
            wasEmpty = mDiskWritesInFlight == 1;
        }
        if (wasEmpty) {
            writeToDiskRunnable.run();
            return;
        }
    }
    // 如果是apply，或者是在commit的情况下有多个批次的写入等待写入磁盘
    // 就另起线程异步执行写入操作
    QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}

startReloadIfChangedUnexpectedly

void startReloadIfChangedUnexpectedly() {
    synchronized (this) {
        // 判断是否有意外的修改，比如其他进程的修改，如果没有就不用reload
        if (!hasFileChangedUnexpectedly()) {
            return;
        }
        startLoadFromDisk();
    }
}

这个方法主要是从新从磁盘上把数据加到到内存中，保存在前面提到的Map中。

private boolean hasFileChangedUnexpectedly() {
    synchronized (this) {
        if (mDiskWritesInFlight > 0) {
            // 如果 mDiskWritesInFlight 说明是我们自己的修改，是预期的，直接返回，不用reload
            // 这种情况也避免了同一个线程刚刚调用玩 apply 写数据，后面紧跟读数据时，
            // 如果数据还没有完全写入xml文件，这时候reload会导致数据出错
            return false;
        }
    }

    final StructStat stat;
    try {
        BlockGuard.getThreadPolicy().onReadFromDisk();
        stat = Os.stat(mFile.getPath());
    } catch (ErrnoException e) {
        return true;
    }

    synchronized (this) {
        // 比较文件的更新时间和大小是否和本地的一致，如果不一致就要重新load
        return mStatTimestamp != stat.st_mtime || mStatSize != stat.st_size;
    }
}

apply 和 commit

前面我们也分析了这两个方法的源码，下面来看一下这两个方法的差异点：

• apply 是没有返回值的，commit 有返回值
• apply 写入文件的操作是异步的，而commit 的写入文件的操作是在当前线程同步执行的

综合性能考虑，如果在主线程操作且不需要返回值的情况下，优先使用 apply 来提交修改。