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

背景

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第1张图片

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

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第2张图片

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第3张图片

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第4张图片

性能优化:如何彻底解决SharedPreferences造成的卡顿_第5张图片

SP阻塞问题解决

反射替换 finishers队列对象

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第6张图片
这里 sFinishers.poll 函数的调用在整个类中,只有这一个地方调用,因此 通过动态代理替换该对象,重写poll函数实现 使其总是返回null对象,并不会对其他流程造成影响

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

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第7张图片

再通过反射替换掉该实现类。性能优化:如何彻底解决SharedPreferences造成的卡顿_第8张图片

解决processPendingWork调用

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第9张图片

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

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第10张图片

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

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

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

性能优化:如何彻底解决SharedPreferences造成的卡顿_第14张图片

这样,替换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

性能优化核心笔记:https://qr18.cn/FVlo89

启动优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第15张图片
内存优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第16张图片
UI优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第17张图片
网络优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第18张图片
Bitmap优化与图片压缩优化https://qr18.cn/FVlo89
性能优化:如何彻底解决SharedPreferences造成的卡顿_第19张图片
多线程并发优化与数据传输效率优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第20张图片
体积包优化
性能优化:如何彻底解决SharedPreferences造成的卡顿_第21张图片

《Android 性能监控框架》:https://qr18.cn/FVlo89

性能优化:如何彻底解决SharedPreferences造成的卡顿_第22张图片

《Android Framework学习手册》:https://qr18.cn/AQpN4J

  1. 开机Init 进程
  2. 开机启动 Zygote 进程
  3. 开机启动 SystemServer 进程
  4. Binder 驱动
  5. AMS 的启动过程
  6. PMS 的启动过程
  7. Launcher 的启动过程
  8. Android 四大组件
  9. Android 系统服务 - Input 事件的分发过程
  10. Android 底层渲染 - 屏幕刷新机制源码分析
  11. Android 源码分析实战

性能优化:如何彻底解决SharedPreferences造成的卡顿_第23张图片

你可能感兴趣的:(性能优化,Android,Framework,性能优化,binder,android,Framework,架构)