简述
前面系列文章中介绍了安卓系统ANR设计原理以及我们在实际工作中对ANR进行监控得到的一些方案，基于这些常规的监控治理，ANR问题得到了有效的抑制。但是有些系统组件的设计初衷与开发人员在实际使用过程中的背离，导致的问题亟待解决。当前文章针对实际开发过程中滥用sp导致的ANR问题，如何从系统层面跳过Google设计缺陷，规避ANR问题。
Google在设计之初为了方便开发者，实现了一套轻量级的数据持久化方案——SharedPreference（以下简称sp），因为其简便的API，方便的使用方式，得到开发者的青睐，对其依赖越来越重。在应用版本不断迭代过程中发现Google说的轻量级的数据存储是有原因的，越是重量级的应用出现的ANR问题越严重。本文从源码层面分析sp文件的加载解析和写入过程出发，分析导致ANR问题的原因分析以及相关的优化解决方案。
SP导致ANR原因分析
经常会遇到两类关于SharedPreference问题，以下分别介绍导致这两类ANR问题的原因和优化方案。
问题一：sp创建以后，会单独的使用一个线程来加载解析对应的sp文件。但是当UI线程尝试访问sp中内容时，如果sp文件还未被完全加载解析到内存，此时UI线程会被block，直到sp文件被完全加载到内存中为止。具体ANR线程堆栈如下：
主要原因是sp文件未被加载或解析到内存中，此时无法直接使用sp提供的接口。sp被创建的时候会同时启动一个线程加载对应的sp文件，执行startLoadFromDisk();
在startLoadFromDisk()时，标记sp不可使用状态，后期无论是尝试读数据或者写数据，读写线程都会被直接block，直到sp文件被全部加载解析完毕。
线程在读或写时，都会走到awaitLoadedLocked()逻辑，在上图的mLoaded为false即sp文件尚未加载解析到内存，此时读写线程会直接被block在mLock锁上，直到loadFromDisk()方法执行完毕。
sp文件完全加载解析到内存中，直接唤起所有在等待在当前sp的读写线程。
问题二：Google系统为了确保数据的跨进程完整性，前期应用可以使用sp来做跨进程通信，在组件销毁或其他生命周期的同时为了确保当前这个写入任务必须在当前这个组件的生命周期完成写入，此时主线程会在组件销毁或者组件暂停的生命周期内等待sp完全写入到对应的文件中，如下图UI线程被block在了QueuedWork.waitToFinish()处，接下来基于源码从apply开始到最后写入文件整体流程梳理找出问题根源。
具体需要等待文件写入的消息在AcitivtyThread的H中，具体消息类型如下：
public static final int SERVICE_ARGS = 115;
public static final int STOP_SERVICE = 116;
public static final int PAUSE_ACTIVITY = 101;
public static final int STOP_ACTIVITY_SHOW = 103;
public static final int SLEEPING = 137;
由于Google官方设计之初是轻量级的数据存储方式，这种等待行为不会有什么问题，但是实际使用过程中由于sp过度使用，这个等待的时间被不可控的拉长，直到最后出现ANR，这种问题越在业务繁重的应用上体现越明显。具体问题堆栈如下，全是系统堆栈，接下来从waitToFinish入手分析，剖析这个ANR的根源。具体ANR堆栈如下：
前期sp接口只有commit接口，接口同步写入文件，这个接口直接影响开发者使用，于是Google官方对外提供了异步的apply接口，由于开发者认为这个异步是真正意义上的异步，大规模的使用sp的appy接口，就是这种apply的实现方式导致了业务量大的APP深受这个apply设计缺陷导致的ANR问题影响。
apply接口整体的详细设计思路如下图（基于Android8.0及以下版本分析）：
整体的思路简单梳理如下：
- sp.apply()，写入内存同时得到需要同步写入文件的数据集合MemoryCommitResult：
-
将MemoryCommitResult封装成Runnable抛到子线程queued-work-looper中；
-
在子线程中将MemoryCommitResult中的mapToWriteToDisk对应的key-value写入到文件中去；
-
文件写入完成以后，会执行MemoryCommitResult的setDiskWriteResult方法，关键的步骤writtenToDiskLatch.countDown() 出现了；
-
如下当主线中执行到QueuedWork.waitToFinish()的时候；
- 主线程到底在干什么，这个时候得从QueuedWork.add(Runnable finisher)入手，具体Runnable如下图，这个地方就是啥也没干，直接等在了mcr.writtenToDiskLatch.await()上，这里大家应该有点印象，就是步骤4中子线程在写完文件以后直接释放的那个锁
*结论
*：尽管整体API的流程分析异常的复杂，把一个runnable封装了一层又一层，从这个线程抛到那个线程，子线程执行完写入文件以后会释放锁，主线程执行到某些地方得等待子线程把写入文件的行为执行完毕，但是整体的思路还是比较简单的。造成这个问题的根源就是太多pending的apply行为没有写入到文件，主线程在执行到指定消息的时候会有等待行为，等待时间过长就会出现ANR。
比较简单的。造成这个问题的根源就是太多pending的apply行为没有写入到文件，主线程在执行到指定消息的时候会有等待行为，等待时间过长就会出现ANR。
