今日头条 ANR 优化实践系列 - 告别 SharedPreference 等待

简述

前面系列文章中介绍了安卓系统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及如下版本分析）：

总体的思路简单梳理以下：

1. sp.apply()，写入内存同时获得须要同步写入文件的数据集合MemoryCommitResult：

2. 将MemoryCommitResult封装成Runnable抛到子线程queued-work-looper中；

3. 在子线程中将MemoryCommitResult中的mapToWriteToDisk对应的key-value写入到文件中去；

4. 文件写入完成之后，会执行MemoryCommitResult的setDiskWriteResult方法，关键的步骤writtenToDiskLatch.countDown() 出现了；

5. 以下当主线中执行到QueuedWork.waitToFinish()的时候；

6. 主线程到底在干什么，这个时候得从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为何要这么设计，提出了本身的几个猜测：

1. Google但愿作到数据可能尽量及时的写入文件，可是这样等待没有任何意义，主线程直接等待并不会提高写入的效率；

2. 指望sp实时写入文件，以方便跨进程的时候能够实时的访问到sp内的文件，这种异步写入方式自己就没办法确保实时性；

3. 多是在组件发生状态切换的时候，这个时候若是进程内没有啥组件，进程的优先级可能下降，存在进程会在系统资源吃紧的时候被系统干掉，这种几率极低，几乎能够忽略不计；

4. 感受最大的可能性就是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 优化实践系列(1)-设计原理及影响因素

今日头条ANR 优化实践系列(2)-监控工具与分析思路

今日头条ANR 优化实践系列(3)-实例剖析集锦

今日头条ANR 优化实践系列(4)- Barrier 致使主线程假死

Android 平台架构团队

咱们是字节跳动 Android 平台架构团队，以服务今日头条为主，面向 GIP，同时服务公司其余产品，在产品性能稳定性等用户体验，研发流程，架构方向上持续优化和探索，知足产品快速迭代的同时，追求极致的用户体验。

若是你对技术充满热情，想要迎接更大的挑战和舞台，欢迎加入咱们，北京，深圳均有岗位，感兴趣发送邮箱：tech@bytedance.com ，邮件标题：姓名 - GIP - Android 平台架构。

---

欢迎关注 「字节跳动技术团队」