性能优化：如何彻底解决SharedPreferences造成的卡顿

背景

在上线 ANR 监控平台后，线上收集到了较多的ANR日志，从火焰图信息上看，函数阻塞在了QueuedWork 相关函数上，本文主要介绍的这一现象的原因以及如何解决这一问题。

本文介绍的解决方案，已放到github 上https://github.com/Knight-ZXW/SpWaitKiller , 供参考实现

SP任务阻塞主线程导致ANR的原理

首先简单介绍下 QueuedWork这个类，QueuedWork主要是用来执行和跟踪一些进程全局的工作，但目前主要调度的SP相关的异步任务 ,当调用 SharedPreferences的 applay方法时，其所要执行的SP文件变更操作会被转化成对应的任务并调用QueuedWork.queue 方法发送到QueuedWork类中进行执行。

同时，系统为了保证这些任务在一些关键动作触发前(如页面跳转启动Activity) 已经被执行完成，设计了一个等待机制。简单描述一下这个机制

•SP的apply操作会产生2个Runnable对象，其实一个为具体文件修改的工作任务(Work Runnable)，另一个为等待任务(awitCommit), 当工作任务被执行完成时，会通过一个CountDownLatch^[1]对象通知等待任务，而awitCommit内部主要就是等待这个CountDownLatch计数器
•工作任务最终会通过 QueueWork的queue被发送到异步线程执行
•等待任务(awitCommit)会通过QueueWork的addFinisher函数被添加到 QueueWork内部的等待队列中
•最后，在系统的一些关键流程，比如ActivityThread执行handleStopActivity时会通过waitToFinish保证这些异步任务都已经被执行完成

而此时如果系统资源(cpu、io)比较紧张、或者是提交的异步任务较多，则可能导致onStop执行时间较长，从而导致ANR。

另外在Android 8.0.0 以上的版本，google 在 waitToFinish的实现中做了一些改动，在原有的等待所有异步任务执行完成的基础上，会通过调用 processPendingWork 将QueueWork中未执行的任务直接取出在当前线程直接执行。这个变更的原因是waitToFinish调用的时机一般是主线程，主线程的优先级会比QueueWork内部线程的优先级更高，因此未执行的任务重新分发到主线程直接执行，提高执行效率。

SP阻塞问题解决

反射替换 finishers队列对象

解决SP 造成的阻塞问题，有很多方式，比如将应用内使用SP的代码通过字节码插桩改为MMKV或其他更高效键值存储库实现。另一种方式是字节跳动在一篇分享的文章^[2]中提出的通过代理替换Queuework类内部的sFinishers对象，保证执行 waitToFinish时队列长度为空实现的。

这里 sFinishers.poll 函数的调用在整个类中，只有这一个地方调用，因此通过动态代理替换该对象，重写poll函数实现使其总是返回null对象，并不会对其他流程造成影响

sFinishers对象在不同的版本具体使用的类不同

•android 8.0以下版本使用的是 ConcurrentLinkedQueue
•android 8.0 之后使用的是LinkedList

以8.0以上版本为例,创建一个代理类，修改poll的实现

再通过反射替换掉该实现类。

解决processPendingWork调用

之前介绍过在 8.0及以上版本调用waitToFinish 时，除了在执行等待finishers队列之前，会在当前线程直接调用processPendingWork函数。以下是程序运行时主线程和异步工作线程之间的关系图。

因此processPendingWork可能在主线程执行也可能在异步线程中执行，在 8.0~11.0下 processPendingWork的调用可能存在两个block点

1.异步线程正在执行 processPendingWork函数，异步工作线程持有 sProcessingWork锁，因此主线程执行 processPendingWork时，因为获取不到 sProcessingWork锁，出现锁等待

2.当主线程成功获取到 sProcessingWork锁，调用clone函数时，sWork队列中确实存在未执行的任务，这部分任务将在主线程直接执行，如果此时IO操作较慢，则主线程因为慢IO出现阻塞甚至ANR

由于这两个原因，因此只代理clone函数是不可行的，因为如果异步线程正在执行processPendingWork函数,并且执行得比较慢，那么主线程还是会出现等待的情况。最终采取的方式是，无论是在哪个线程执行，代理的clone函数都返回空队列，这样保证了processPendingWork的调用不会出现互相阻塞，相当于processPendingWork实际上没有执行任何操作，并且通过反射获取QueuedWork的mHandler的Looper对象，创建一个新的Hander,并将sWork中的任务提交到这个Handler去执行，从而实现了无阻塞运行。

需要注意的是，由于hidden API的限制， sWork成员变量只能在 target sdk version小于以下的app中被反射得到，因此如果希望在target大于28 的app正常工作，还需要突破系统hidden api的限制，这里可以使用 LSPosed 提供 hiddenApiBypass^[3]库。

另外在Android 12 版本，这部分代码又发生了变更, 不再使用clone 和 clear的方式拷贝集合副本,而是直接替换 sWork的引用来实现.

这样，替换clone函数的方案就不可行了，并且由于 sWork变量指向的对象在每次调用processPendingWork 都会发生变更，因此动态代理替换sWork对象的操作不能只执行一次。继续寻找可以hook的点，对于

for (Runnable v: work)

这个代码在字节码层面其实会被转换为迭代器的调用，因此可以将之前的操作转换到 iterator函数中执行，返回一个空的迭代器对象，因此将之前的方案从代理 clone函数改为代理 iterator函数，并且需要保证每次调用获取迭代器函数后再次将sWork对象重新代理掉。

最后

上述方案代码量其实不多，因此我在github上建了一个工程用来模拟并解决QueueWork任务阻塞造成的ANR问题，可供参考 https://github.com/Knight-ZXW/SpWaitKiller . 在上线时，应当对使用到SP的业务进行相应的测试，比如如果存在跨进程组件依赖同一个SP文件的情况，由于我们取消了Activity 在Stop时的 SP文件变更的刷盘行为，因此如果跳转到其他进程的组件，而该组件又依赖于跳转前的SP变更的最新配置值，那么可能会出现问题。另外事实上，从收集ANR的其他上下文信息来看，虽然SP的操作阻塞导致了ANR操作，但是并不能说明真正的原因是因为SP导致的，比如可能由于物理内存紧张、频繁发生swa 操作影响了正常的io操作，影响了SP的刷盘速度，最终导致了ANR出现.

为了帮助到大家更好的全面清晰的掌握好性能优化，准备了相关的核心笔记（还该底层逻辑）：https://qr18.cn/FVlo89