インタビュアーは私に尋ねました: SharedPreference ソース コードの適用とコミットの原則、ANR の理由

記事 3 部作を忘れずに読み、「いいね！」、コメント、転送してください。WeChatで「プログラマー シャオアン」を検索し、今もモバイル開発の現場で活躍する先輩プログラマーに焦点を当てた「インタビューシリーズ」記事を公式アカウントで同時公開します。

1 はじめに

数年前にSharedPreferenceのソースコードに関する記事を書きましたが、applyメソッドやcommitメソッドの説明が十分ではありませんでした。外見に責任のある優秀な若者として、どうしてその奥深くまで踏み込めないのでしょうか。それは一度ですか？

2. テキスト

ソースコードに慣れるために、仕事が終わってから同僚のXiaoxueに話し合ってもらうように頼みましたが、結局のところ、私の先生には3人が必要です。3人がどこの出身かは関係なく、Xiaoxueと一緒に学問を学ぶことがより重要です。

Xiaoan 先輩、前回の記事を読みました: Android SharedPreference ソース コード分析 (1) apply() と commit() の基本原理、特にスレッドといくつかの同期ロックがそれらの中でどのように使用され、どのような下で使用されているかがまだ理解できません。状況は登場しますか？

apply() と commit() の基本原理について説明しますが、これは古いステップであるはずなので、ソース コードに進みます。適用ソースコードは次のとおりです。

public void apply() {
            final long startTime = System.currentTimeMillis();

            final MemoryCommitResult mcr = commitToMemory();
            final Runnable awaitCommit = new Runnable() {
                    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");
                        }
                    }
                };
			// 将 awaitCommit 添加到队列 QueuedWork 中
            QueuedWork.addFinisher(awaitCommit);

            Runnable postWriteRunnable = new Runnable() {
                    public void run() {
                        awaitCommit.run();
                        QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除
                    }
                };

            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);
        }
复制代码

大量のコードが失われており、理解できません。

心配しないでください、この長い夜にはまだたくさんのことが残っています、私の話を少し聞いてください、あなたは満足するでしょう。

apply() メソッドは Android をやったことがある人なら誰でも知っています (Android をやったことがないなら、なぜ私のブログをクリックするのでしょう。死んでも送れないでしょう)。apply メソッドを使用することをお勧めします。ファイルはローカル ディスクに非同期で保存されるため、頻繁にファイルを書き込む場合に最適です。では、具体的なソースコードがどのように動作するのか、パンツを持ち上げてみましょう、いや、表面から本質を見てみましょう。

我们从下往上看，apply方法最后调用了SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);我长得帅我先告诉你，enqueueDiskWrite方法会把存储文件的动作放到子线程，具体怎么放的，我们等下看源码，这边你只要知道他的作用。这个方法的第二个参数 postWriteRunnable做了两件事：
1）让awaitCommit执行，及执行 mcr.writtenToDiskLatch.await();
2）执行QueuedWork.remove(awaitCommit);代码

writtenToDiskLatch是什么，QueuedWork又是什么？

writtenToDiskLatch是CountDownLatch的实例化对象，CountDownLatch是一个同步工具类，它通过一个计数器来实现的,初始值为线程的数量。每当一个线程完成了自己的任务调用countDown()，则计数器的值就相应得减1。当计数器到达0时,表示所有的线程都已执行完毕,然后在等待的线程await()就可以恢复执行任务。
1）countDown(): 对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。
2）await(): 阻塞当前线程，将当前线程加入阻塞队列。 可以看到如果postWriteRunnable方法被触发执行的话，由于 mcr.writtenToDiskLatch.await()的缘故，UI线程会被一直阻塞住，等待计数器减至0才能被唤醒。

QueuedWork其实就是一个基于handlerThread的，处理任务队列的类。handlerThread类为你创建好了Looper和Thread对象，创建Handler的时候使用该looper对象，则handleMessage方法在子线程中，可以做耗时操作。如果对于handlerThread的不熟悉的话，可以看我前面的文章：Android HandlerThread使用介绍以及源码解析

觉得厉害，那咱就继续深入。
enqueueDiskWrite源码如下所示：

private void enqueueDiskWrite(final MemoryCommitResult mcr,
                                  final Runnable postWriteRunnable) {
        final boolean isFromSyncCommit = (postWriteRunnable == null);

        final Runnable writeToDiskRunnable = new Runnable() {
                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);
    }
复制代码

很明显postWriteRunnable不为null，程序会执行QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);从writeToDiskRunnable我们可以看到，他里面做了两件事：
1）writeToFile():内容存储到文件；
2）postWriteRunnable.run()：postWriteRunnable做了什么，往上看，上面已经讲了该方法做的两件事。

QueuedWork.queue源码：

    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);
            }
        }
    }
复制代码

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();
            }
        }
    }
复制代码

这边我默认你已经知道HandlerThread如何使用啦，如果不知道，麻烦花五分钟去看下我之前的博客。
上面的代码很简单，其实就是把writeToDiskRunnable这个任务放到sWork这个list中，并且执行handler，根据HandlerThread的知识点，我们知道handlermessage里面就是子线程了。

接下来我们继续看handleMessage里面的processPendingWork()方法：

 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克隆给work，然后开启循环，执行work对象的run方法，及调用writeToDiskRunnable的run方法。上面讲过了，他里面做了两件事：1）内容存储到文件 2）postWriteRunnable方法回调。 执行run方法的代码：

 final Runnable writeToDiskRunnable = new Runnable() {
                public void run() {
                    synchronized (mWritingToDiskLock) {
                        writeToFile(mcr, isFromSyncCommit);//由于handlermessage在子线程，则writeToFile也在子线程中
                    }
                    synchronized (mLock) {
                        mDiskWritesInFlight--;
                    }
                    if (postWriteRunnable != null) {
                        postWriteRunnable.run();
                    }
                }
            };
复制代码

writeToFile方法我们不深入去看，但是要关注，里面有个setDiskWriteResult方法，在该方法里面做了如下的事情：

void setDiskWriteResult(boolean wasWritten, boolean result) {
            this.wasWritten = wasWritten;
            writeToDiskResult = result;
            writtenToDiskLatch.countDown();//计数器-1
        }
复制代码

如何上面认真看了的同学，应该可以知道，当调用countDown()方法时，会对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。也就是说，当文件写完时，UI线程会被唤醒。

既然文件写完就会释放锁，那什么情况下会出现ANR呢？

Android系统为了保障在页面切换，也就是在多进程中sp文件能够存储成功，在ActivityThread的handlePauseActivity和handleStopActivity时会通过waitToFinish保证这些异步任务都已经被执行完成。如果这个时候过渡使用apply方法，则可能导致onpause，onStop执行时间较长，从而导致ANR。

private void handlePauseActivity(IBinder token, boolean finished,
            boolean userLeaving, int configChanges, boolean dontReport, int seq) {
       ......
            r.activity.mConfigChangeFlags |= configChanges;
            performPauseActivity(token, finished, r.isPreHoneycomb(), "handlePauseActivity");

            // Make sure any pending writes are now committed.
            if (r.isPreHoneycomb()) {
                QueuedWork.waitToFinish();
            }

           ......
    }
复制代码

你肯定要问，为什么过渡使用apply方法，就有可能导致ANR？那我们只能看QueuedWork.waitToFinish();到底做了什么

 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: ");
                }
            }
        }
    }
复制代码

看着一大坨代码，其实做了两件事：
1）主线程执行processPendingWork（）方法，把之前未执行完的内容存储到文件的操作执行完，这部分动作直接在主线程执行，如果有未执行的文件操作并且文件较大，则主线程会因为IO时间长造成ANR。
2）循环取出sFinishers数组，执行他的run方法。如果这时候有多个异步线程或者异步线程时间过长，同样会造成阻塞产生ANR。

第一个很好理解，第二个没有太看明白，sFinishers数组是在什么时候add数据的，而且根据writeToDiskRunnable方法可以知道，先写文件再加锁的，为啥会阻塞呢？

sFinishers的addFinisher方法是在apply（）方法里面调用的，代码如下：

        @Override
        public void apply() {
            ......
            // 将 awaitCommit 添加到队列 QueuedWork 中
            QueuedWork.addFinisher(awaitCommit);

            Runnable postWriteRunnable = new Runnable() {
                    @Override
                    public void run() {
                        awaitCommit.run();
                        QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除
                    }
                };
            ......
        }
复制代码

正常情况下其实是不会发生ANR的，因为writeToDiskRunnable方法中，是先进行文件存储再去阻塞等待的，此时CountDownLatch永远都为0，则不会阻塞主线程。

final Runnable writeToDiskRunnable = new Runnable() {
                @Override
                public void run() {
                    synchronized (mWritingToDiskLock) {
                        writeToFile(mcr, isFromSyncCommit);//写文件，写成功后会调用writtenToDiskLatch.countDown();计数器-1
                    }
                    synchronized (mLock) {
                        mDiskWritesInFlight--;
                    }
                    if (postWriteRunnable != null) {
                        postWriteRunnable.run();//回调到awaitCommit.run();进行阻塞
                    }
                }
            };
复制代码

但是如果processPendingWork方法在异步线程在执行时，及通过enqueueDiskWrite方法触发的正常文件保存流程，这时候文件比较大或者文件比较多，子线程则一直在运行中；当用户点击页面跳转时，则触发该Activity的handlePauseActivity方法，根据上面的分析，handlePauseActivity方法里面会执行waitToFinish保证这些异步任务都已经被执行完成。
由于这边主要介绍循环取出sFinishers数组，执行他的run方法造成阻塞产生ANR，我们就重点看下sFinishers数组对象是什么，并且执行什么动作。

private static final LinkedList<Runnable> sFinishers = new LinkedList<>();
   @UnsupportedAppUsage
    public static void addFinisher(Runnable finisher) {
        synchronized (sLock) {
            sFinishers.add(finisher);
        }
    }
复制代码

addFinisher刚刚上面提到是在apply方法中调用，则finisher就是入参awaitCommit，他的run方法如下：

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");
                        }
                    }
                };
复制代码

不难看出，就是调用CountDownLatch对象的await方法，阻塞当前线程，将当前线程加入阻塞队列。也就是这个时候整个UI线程都阻塞在这边，等待processPendingWork这个异步线程执行完毕，虽然你是在子线程，但是我主线程在等你执行结束才会进行页面切换，所以如果过渡使用apply方法，则可能导致onpause，onStop执行时间较长，从而导致ANR。

小安学长不愧是我的偶像，我都明白了，那继续讲讲同步存储commit()方法吧。

commit メソッドは実際には比較的単純で、メモリとファイルが UI スレッド内にあるだけです。確認するためにコードを見てみましょう。

 @Override
        public boolean commit() {
            long startTime = 0;

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

            MemoryCommitResult mcr = commitToMemory();//内存保存

            SharedPreferencesImpl.this.enqueueDiskWrite(
                mcr, null /* sync write on this thread okay */);//第二个参数为null
            try {
                mcr.writtenToDiskLatch.await();
            } catch (InterruptedException e) {
                return false;
            } finally {
                if (DEBUG) {
                    Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
                            + " committed after " + (System.currentTimeMillis() - startTime)
                            + " ms");
                }
            }
            notifyListeners(mcr);
            return mcr.writeToDiskResult;
        }
复制代码

enqueueDiskWrite の 2 番目のパラメータが null であることがわかります。enqueueDiskWrite メソッドは、上で適用を説明したときにすでに掲載されています。上にスクロールしないように、引き続き enqueueDiskWrite メソッドを見てみましょう。

   private void enqueueDiskWrite(final MemoryCommitResult mcr,
                                  final Runnable postWriteRunnable) {
        final boolean isFromSyncCommit = (postWriteRunnable == null);//此时postWriteRunnable为null，isFromSyncCommit 则为true

        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) {  //当调用commit方法时，isFromSyncCommit则为true
            boolean wasEmpty = false;
            synchronized (mLock) {
                wasEmpty = mDiskWritesInFlight == 1;
            }
            if (wasEmpty) {
                writeToDiskRunnable.run();//主线程回调writeToDiskRunnable的run方法，进行writeToFile文件的存储
                return;
            }
        }

        QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
    }
复制代码

キー コードはコメント化されており、postWriteRunnable が null であるため、isFromSyncCommit は true であり、コードはメイン スレッドで writeToDiskRunnable の run メソッドをコールバックして writeToFile ファイルを保存します。アクションのこの部分はメイン スレッドで直接実行されるため、ファイルが大きい場合、メイン スレッドでも IO 時間が長くなり ANR が発生します。

では、SharedPreference が commit() メソッドであるか apply() メソッドであるかに関係なく、ファイルが大きすぎる場合や多すぎる場合には ANR のリスクが生じるため、それを回避するにはどうすればよいでしょうか?

きっと解決策があるはずです。次の記事では SharedPreference の代替となる mmkv の原理を紹介します。今夜はちょっと遅いです。朝は寝ましょう、いえ、早く帰りましょう~~~