【Android】SharedPreferences阻塞问题深度分析

前言

Android中SharedPreferences已经广为诟病，它虽然是Android SDK中自带的数据存储API，但是因为存在设计上的缺陷，在处理大量数据时很容易导致UI线程阻塞或者ANR，Android官方最终在Jetpack库中提供了DataStore解决方案，用来替代SharedPreferences。

总结起来，SharedPreferences有以下几个缺点：

• 在初始化SharedPreferences对象时，会将文件中所有数据都读取到内存，非常浪费内存，并且是同步操作，如果在主线程中操作就会导致页面启动慢或者卡顿问题。
• 在调用SharedPreferences对象的edit()方法时会一直阻塞直到数据从磁盘上读取完毕。
• 每次调用apply和commit都会将内存的数据一并同步到磁盘，影响性能。
• 在调用Activity和Service的生命周期时，会阻塞等待SP数据写出完毕，因此导致页面出现卡顿甚至ANR。

下面来从源码的设计角度来深入分析一下这些问题存在的根源。

笔者原创，转载请注明出处：https://blog.youkuaiyun.com/devnn/article/details/138086118

本文基于Android 30源码。

SharedPreferences的初始化

一般我们会使用context的getSharedPreferences(String name, int mode)方法获取一个SharedPreferences对象，而context一般直接使用当前Activity对象。Activity虽然继承了Context但其实它是一个代理Context，真实的Context是通过attachBaseContext方法传入的，实际上就是ContextImpl。对这个不熟悉的同学可以去看看ActivityThread中Activity创建过程。

我们看看ContextImpl中getSharedPreferences方法是如何实现的。

//android.app.ContextImpl
  @Override
    public SharedPreferences getSharedPreferences(File file, int mode) {
        SharedPreferencesImpl sp;
        synchronized (ContextImpl.class) {
            final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
            sp = cache.get(file);
            if (sp == null) {
                checkMode(mode);
                if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {
                    if (isCredentialProtectedStorage()
                            && !getSystemService(UserManager.class)
                                    .isUserUnlockingOrUnlocked(UserHandle.myUserId())) {
                        throw new IllegalStateException("SharedPreferences in credential encrypted "
                                + "storage are not available until after user is unlocked");
                    }
                }
                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;
    }

这里从缓存中取出SharedPreferencesImpl对象，缓存没有会新建一个SharedPreferencesImpl：

//android.app.SharedPreferencesImpl
   SharedPreferencesImpl(File file, int mode) {
        mFile = file;
        mBackupFile = makeBackupFile(file);
        mMode = mode;
        mLoaded = false;
        mMap = null;
        mThrowable = null;
        startLoadFromDisk();
    }
    
   private void startLoadFromDisk() {
        synchronized (mLock) {
            mLoaded = false;
        }
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();
            }
        }.start();
    }

构建SharedPreferencesImpl会在子线程中读取xml文件,同时将标记位mLoaded置为了false。

//android.app.SharedPreferencesImpl
 private void loadFromDisk() {
        synchronized (mLock) {
            if (mLoaded) {
                return;
            }
            if (mBackupFile.exists()) {
                mFile.delete();
                mBackupFile.renameTo(mFile);
            }
        }

        // Debugging
        if (mFile.exists() && !mFile.canRead()) {
            Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission");
        }

        Map<String, Object> map = null;
        StructStat stat = null;
        Throwable thrown = null;
        try {
            stat = Os.stat(mFile.getPath());
            if (mFile.canRead()) {
                BufferedInputStream str = null;
                try {
                    str = new BufferedInputStream(
                            new FileInputStream(mFile), 16 * 1024);
                    map = (Map<String, Object>) XmlUtils.readMapXml(str);
                } catch (Exception e) {
                    Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);
                } finally {
                    IoUtils.closeQuietly(str);
                }
            }
        } catch (ErrnoException e) {
            // An errno exception means the stat failed. Treat as empty/non-existing by
            // ignoring.
        } catch (Throwable t) {
            thrown = t;
        }

        synchronized (mLock) {
            mLoaded = true;
            mThrowable = thrown;

            // It's important that we always signal waiters, even if we'll make
            // them fail with an exception. The try-finally is pretty wide, but
            // better safe than sorry.
            try {
                if (thrown == null) {
                    if (map != null) {
                        mMap = map;
                        mStatTimestamp = stat.st_mtim;
                        mStatSize = stat.st_size;
                    } else {
                        mMap = new HashMap<>();
                    }
                }
                // In case of a thrown exception, we retain the old map. That allows
                // any open editors to commit and store updates.
            } catch (Throwable t) {
                mThrowable = t;
            } finally {
                mLock.notifyAll();
            }
        }
    }

读取xml文件完成之后获取mLock对象锁，然后将mLoaded置为true，最后将WaitSet队列中的阻塞线程唤醒。

笔者原创，转载请注明出处：https://blog.youkuaiyun.com/devnn/article/details/138086118

SharedPreferences的edit方法

//android.app.SharedPreferencesImpl
   @Override
    public Editor edit() {
        // TODO: remove the need to call awaitLoadedLocked() when
        // requesting an editor.  will require some work on the
        // Editor, but then we should be able to do:
        //
        //      context.getSharedPreferences(..).edit().putString(..).apply()
        //
        // ... all without blocking.
        synchronized (mLock) {
            awaitLoadedLocked();
        }

        return new EditorImpl();
    }

获取mLock的锁，这里如果子线程读取xml时未释放锁，这时就会阻塞等待，如果比子线程先获取锁，也会阻塞直到子线程读取完毕。看awaitLoadedLocked方法：

//android.app.SharedPreferencesImpl
   @GuardedBy("mLock")
    private void awaitLoadedLocked() {
        if (!mLoaded) {
            // Raise an explicit StrictMode onReadFromDisk for this
            // thread, since the real read will be in a different
            // thread and otherwise ignored by StrictMode.
            BlockGuard.getThreadPolicy().onReadFromDisk();
        }
        while (!mLoaded) {
            try {
                mLock.wait();
            } catch (InterruptedException unused) {
            }
        }
        if (mThrowable != null) {
            throw new IllegalStateException(mThrowable);
        }
    }

可以看到一个while循环，当mLoaded字段为false时就会阻塞当前线程，直到被唤醒。

从以上获取SharedPreferences对象然后调用edit方法的过程，一般我们都会在onCreate中或者控件onClick中获取sp数据，因此可以得出结论：
在主线程中获取SharedPreferences.Editor，必须等待xml文件所有数据读取完毕才会进行后续操作，如果xml中数据越多，那么主线程等待的时间就会越长。

Editor.apply方法

//android.app.SharedPreferencesImpl
 public void apply() {
            final long startTime = System.currentTimeMillis();

            final MemoryCommitResult mcr = commitToMemory();
            final Runnable awaitCommit = new Runnable() {
                    @Override
                    public void run() {
                        try {
                            mcr.writtenToDiskLatch.await();
                        } catch (InterruptedException ignored) {
                        }

                        if (DEBUG && mcr.wasWritten) {
                            Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
                                    + " applied after " + (System.currentTimeMillis() - startTime)
                                    + " ms");
                        }
                    }
                };

            QueuedWork.addFinisher(awaitCommit);

            Runnable postWriteRunnable = new Runnable() {
                    @Override
                    public void run() {
                        awaitCommit.run();
                        QueuedWork.removeFinisher(awaitCommit);
                    }
                };

            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

            // Okay to notify the listeners before it's hit disk
            // because the listeners should always get the same
            // SharedPreferences instance back, which has the
            // changes reflected in memory.
            notifyListeners(mcr);
        }

先调用commitToMemory方法将需要修改的数据封装到了MemoryCommitResult类型的对象mcr中：

//android.app.SharedPreferencesImpl
       // Returns true if any changes were made
        private MemoryCommitResult commitToMemory() {
            long memoryStateGeneration;
            boolean keysCleared = false;
            List<String> keysModified = null;
            Set<OnSharedPreferenceChangeListener> listeners = null;
            Map<String, Object> mapToWriteToDisk;

            synchronized (SharedPreferencesImpl.this.mLock) {
                // We optimistically don't make a deep copy until
                // a memory commit comes in when we're already
                // writing to disk.
                if (mDiskWritesInFlight > 0) {
                    // We can't modify our mMap as a currently
                    // in-flight write owns it.  Clone it before
                    // modifying it.
                    // noinspection unchecked
                    mMap = new HashMap<String, Object>(mMap);
                }
                mapToWriteToDisk = mMap;
                mDiskWritesInFlight++;

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

                synchronized (mEditorLock) {
                    boolean changesMade = false;

                    if (mClear) {
                        if (!mapToWriteToDisk.isEmpty()) {
                            changesMade = true;
                            mapToWriteToDisk.clear();
                        }
                        keysCleared = true;
                        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 (!mapToWriteToDisk.containsKey(k)) {
                                continue;
                            }
                            mapToWriteToDisk.remove(k);
                        } else {
                            if (mapToWriteToDisk.containsKey(k)) {
                                Object existingValue = mapToWriteToDisk.get(k);
                                if (existingValue != null && existingValue.equals(v)) {
                                    continue;
                                }
                            }
                            mapToWriteToDisk.put(k, v);
                        }

                        changesMade = true;
                        if (hasListeners) {
                            keysModified.add(k);
                        }
                    }

                    mModified.clear();

                    if (changesMade) {
                        mCurrentMemoryStateGeneration++;
                    }

                    memoryStateGeneration = mCurrentMemoryStateGeneration;
                }
            }
            return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified,
                    listeners, mapToWriteToDisk);
        }

这个方法主要是更新之前从xml中加载到内存的mMap集合，哪些字段被修改了就更新一下。

回到apply方法。

apply方法将要修改的数据包装成mcr，然后将mcr.writtenToDiskLatch.await方法封装成了Runnable，并添加到了QueuedWork当中，这一步很关键，后面再分析。

然后又创建了一个Runnable用来执行前面这个Runnable…

然后调用SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable)将mcr和postWriteRunnable传给了enqueueDiskWrite方法。

//android.app.SharedPreferencesImpl
private void enqueueDiskWrite(final MemoryCommitResult mcr,
                                  final Runnable postWriteRunnable) {
        final boolean isFromSyncCommit = (postWriteRunnable == null);

        final Runnable writeToDiskRunnable = new Runnable() {
                @Override
                public void run() {
                    synchronized (mWritingToDiskLock) {
                        writeToFile(mcr, isFromSyncCommit);
                    }
                    synchronized (mLock) {
                        mDiskWritesInFlight--;
                    }
                    if (postWriteRunnable != null) {
                        postWriteRunnable.run();
                    }
                }
            };

        // Typical #commit() path with fewer allocations, doing a write on
        // the current thread.
        if (isFromSyncCommit) {
            boolean wasEmpty = false;
            synchronized (mLock) {
                wasEmpty = mDiskWritesInFlight == 1;
            }
            if (wasEmpty) {
                writeToDiskRunnable.run();
                return;
            }
        }

        QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
    }

这个方法又创建了一个Runnable类型的writeToDiskRunnable，writeToDiskRunnable先执行写出操作再调用传进来的Runnable，然后判断是否是同步执行还是异步操作，同步执行直接在当前线程执行writeToDiskRunnable，异步的话将其丢进QueuedWork中，因为apply是异步，因此我们继承看QueuedWork.queue方法。

//android.app.QueuedWork
 public static void queue(Runnable work, boolean shouldDelay) {
        Handler handler = getHandler();

        synchronized (sLock) {
            sWork.add(work);

            if (shouldDelay && sCanDelay) {
                handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);
            } else {
                handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);
            }
        }
    }

该方法比较简单，主要是将传进来的任务放进了sWork队列中，然后发送消息将工作线程唤醒执行队列中的任务。

//android.app.QueuedWork
    private static class QueuedWorkHandler extends Handler {
        static final int MSG_RUN = 1;

        QueuedWorkHandler(Looper looper) {
            super(looper);
        }

        public void handleMessage(Message msg) {
            if (msg.what == MSG_RUN) {
                processPendingWork();
            }
        }
    }

继续看processPendingWork做了什么。

//android.app.QueuedWork
private static void processPendingWork() {
        long startTime = 0;

        if (DEBUG) {
            startTime = System.currentTimeMillis();
        }

        synchronized (sProcessingWork) {
            LinkedList<Runnable> work;

            synchronized (sLock) {
                work = (LinkedList<Runnable>) sWork.clone();
                sWork.clear();

                // Remove all msg-s as all work will be processed now
                getHandler().removeMessages(QueuedWorkHandler.MSG_RUN);
            }

            if (work.size() > 0) {
                for (Runnable w : work) {
                    w.run();
                }

                if (DEBUG) {
                    Log.d(LOG_TAG, "processing " + work.size() + " items took " +
                            +(System.currentTimeMillis() - startTime) + " ms");
                }
            }
        }
    }

很简单，就是将sWork克隆一份，将原来的sWork清空，for循环执行克隆队列中的任务。

到这里apply流程已经分析完毕，主要就是先更新mMap中的数据，然后放到工作线程中执行IO写出操作。

QueuedWork.waitToFinish方法

但是之前调用 QueuedWork.addFinisher(awaitCommit)是做什么的呢？看代码是要等待写出完毕操作，在哪里等待呢？

//android.app.QueuedWork
 public static void waitToFinish() {
        long startTime = System.currentTimeMillis();
        boolean hadMessages = false;

        Handler handler = getHandler();

        synchronized (sLock) {
            if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {
                // Delayed work will be processed at processPendingWork() below
                handler.removeMessages(QueuedWorkHandler.MSG_RUN);

                if (DEBUG) {
                    hadMessages = true;
                    Log.d(LOG_TAG, "waiting");
                }
            }

            // We should not delay any work as this might delay the finishers
            sCanDelay = false;
        }

        StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();
        try {
            processPendingWork();
        } finally {
            StrictMode.setThreadPolicy(oldPolicy);
        }

        try {
            while (true) {
                Runnable finisher;

                synchronized (sLock) {
                    finisher = sFinishers.poll();
                }

                if (finisher == null) {
                    break;
                }

                finisher.run();
            }
        } finally {
            sCanDelay = true;
        }

        synchronized (sLock) {
            long waitTime = System.currentTimeMillis() - startTime;

            if (waitTime > 0 || hadMessages) {
                mWaitTimes.add(Long.valueOf(waitTime).intValue());
                mNumWaits++;

                if (DEBUG || mNumWaits % 1024 == 0 || waitTime > MAX_WAIT_TIME_MILLIS) {
                    mWaitTimes.log(LOG_TAG, "waited: ");
                }
            }
        }
    }

QueuedWork.waitToFinish方法即是阻塞当前线程等待apply写出任务完毕。

这个方法先是清空handler的中的消息，然后直接在当前线程执行processPendingWork方法，接着遍历之前addFinisher添加进来的任务进行执行。看这情况，相当于如果之前调用apply方法在工作线程中执行的队列任务中还有未完成的就不让它执行，并且将这些任务拿到当前线程进行执行，同时阻塞当前线程等待工作线程中任务执行完毕！

好家伙，相当于强行接管了工作线程中的后续任务，自己亲自来执行，同时等待当前工作线程正在执行的任务执行完毕。

那么QueuedWork.waitToFinish在哪里调用的呢？经过分析是在ActivityThread中执行组件生命周期函数前后：

这个地方是先执行Activity的onPause方法，然后如果系统小于Android 11则执行QueuedWork.waitToFinish，否则不执行QueuedWork.waitToFinish。看来现在市面上的机型基本在onStop不执行这个方法。

这个地方先执行Activity的onStop方法，然后如果系统大于Android 11则执行QueuedWork.waitToFinish，否则不执行QueuedWork.waitToFinish。看来现在市面上的机型基本会在onStop之后执行这个方法。

这个地方是先执行Service的onStartCommand方法，然后执行QueuedWork.waitToFinish。

这个地方是先执行Service的onDetroy方法，然后执行QueuedWork.waitToFinish。

经过对SP的apply方法分析可以看出，它是一个异步操作，并且会将sp文件中所有数据一并写出，如果只有一个字段更新，它也会将这些数据写出到磁盘。另外，如果页面即将要关闭，还会阻塞主线程直到sp数据写出完毕。很显然，当sp中数据量很大或者apply操作频繁调用，很容易引发主线程长时间阻塞甚至ANR。

笔者原创，转载请注明出处：https://blog.youkuaiyun.com/devnn/article/details/138086118