简述
前面系列文章中介绍了安卓系统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。
尽管Google官方在Android8.0及以后版本对sp写入逻辑进行优化，期望是在上述步骤6中UI线程不是傻傻的等，而是帮助子线程一起写入，但是由于是主线程保守协助，并没有很好的解决这个问题。
解决方案
问题一：针对加载很慢的问题，一般使用的比较多的是采用预加载的方式来触发到这个sp文件的加载和解析，这样在真正使用的时候大概率sp已经加载解析完毕了；真正需要处理的是核心场景的sp一定不能太大，Google官方的声明还是有必要遵守一下，轻量级的数据持久化存储方式，不要存太多数据，避免文件过大，导致前期的加载解析耗时过久。
问题二：至于Google为什么要这么设计，提出了自己的几个猜想：
-
Google希望做到数据可能尽可能及时的写入文件，但是这样等待没有任何意义，主线程直接等待并不会提升写入的效率；
-
期望sp实时写入文件，以方便跨进程的时候可以实时的访问到sp内的文件，这种异步写入方式本身就没办法确保实时性；
-
可能是在组件发生状态切换的时候，这个时候如果进程内没有啥组件，进程的优先级可能降低，存在进程会在系统资源吃紧的时候被系统干掉，这种概率极低，几乎可以忽略不计；
-
感觉最大的可能性就是Google官方当时是为了从commit无缝的切换到apply，依然模拟原来的commit行为，只是将原来的每次写入文件一次改成多次commit行为最后一次性apply在主线程等待所有的写入行为一次性全部写入。
通过以上假设，发现这里的主线程等待子线程写入根本没有什么意义，因此希望可以通过一些必要的手段跳过这种无用的等待行为，在研究了所有的SharedPreference相关的逻辑后找到以下入手点。以下是8.0以下版本的优化策略，8.0及以上版本处理方式类似：
如果需要主线程在waitToFinish的时候直接跳过去，让toTinish.run()不执行，显然不可能，如果能让sPendingWorkFinishers.poll()返回为null，则这里的等待行为直接就跳过去了，sPendingWorkFinishers是个ConcurrentLinkedQueue集合，可以直接动态代理这个集合，覆写poll方法，让其永远返回null，这个时候UI永远不会等待子线程写入文件完毕，事实证明这种方式简单有效。
针对这种写入等待的ANR问题，还有一种就是全局替换写入方式，通过插桩的方式，替换所有的API实现，采用其他的存储方式，这种方式修复成本和风险较大，但是后期可以随机的替换存储方式，使用比较灵活。
方案收益
通过在字节系多个产品的验证，方案稳定有效，相应堆栈导致的ANR问题消灭殆尽，ANR收益明显，相应的界面跳转等场景流畅性得到了明显的改善。
展望
Google 新增加了一个新 Jetpack 的成员 DataStore，未来可能用来替换 SharedPreferences， DataStore 应该是开发者期待已久的库，DataStore 是基于 Flow 实现的，一种新的数据存储方案。详细介绍网上有很多参考资料。
优化实践更多参考
今日头条ANR 优化实践系列(4)- Barrier 导致主线程假死
Android 平台架构团队
我们是字节跳动 Android 平台架构团队，以服务今日头条为主，面向 GIP，同时服务公司其他产品，在产品性能稳定性等用户体验，研发流程，架构方向上持续优化和探索，满足产品快速迭代的同时，追求极致的用户体验。
如果你对技术充满热情，想要迎接更大的挑战和舞台，欢迎加入我们，北京，深圳均有岗位，感兴趣发送邮箱：[email protected] ，邮件标题：姓名 - GIP - Android 平台架构。
欢迎关注 「字节跳动技术团队」