项目中多次操作SharedPreferences导致ANR场景的解决 anrsdk移动端

项目背景：随着时代的进步，移动端广告的投放变得越来越多样化，为了接近市场，不少公司自己研发了SDK去收集用户的一些信息以及行为用于分析，根据分析结果使用自定义广告(自定义View)的方式继续向用户进行展示，以提高展示率和点击率。
目前关于广告商方面的选择，国内的广告变现普遍较低，首选应该是接入谷歌广告。随着业务的发展，在一段时间后，公司开始转变成广告接收方，并靠自己的SDK来进行广告的投放，以及优化。
以定位来获取广告的方式为例：
· 首先利用用户的定位等权限来获取经纬度

文章图片

· 将经纬度上传至国内某定位SDK，获取具体信息。

文章图片

· 最后根据定位信息来获取广告并预加载为广告展示做准备。

文章图片

所遇到的挑战：在项目功能完成后准备上架前，会对项目进行一系列的测试，但是ANR问题在测试过程中很难完成复现，在使用多个机型测试的过程中几乎没有ANR问题的记录。但是在用户的实际使用过程中，由于Android碎片化的严重，加上用户的一些操作的习惯等，会导致出现ANR的问题。面对一些大型的厂家，ANR出现时会弹窗引导用户关闭软件，会导致使用体验不好，造成用户的流失。
解决问题的步骤：
在项目一个多月的异常收集中，出现过几次ANR的问题。
· 分析异常收集中ANR日志将问题锁定在SharedPreferences 上，排查过程比较麻烦，在锁定了问题后，开始对问题进行分析。
· 查看Android文档：在项目中，团队使用SharedPreferences读写配置文件，均采用了官方的推荐做法，调用apply来提交，调用这个方法时，先写入内存中，再将任务加入队列中，会在异步线程中做落盘的操作，这个操作理论上来说是没有问题的，也是google官方推荐的做法。
· 阅读源码：

文章图片

在此过程中发现谷歌官方注释:
If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.
翻译：如果SharedPreferences上的另一个编辑器执行常规的commit()，而apply()仍然未完成，则commit()将阻塞，直到所有异步提交以及提交本身都完成。
· 锁定问题：主线程调用了 QueuedWork.waitToFinish(),没有待执行的任务，直接执行 finisher，进行阻塞等待, 直到写入文件成功后恢复执行, 这时候如果等待时间过长，在一些市面上性能差的中低端机型上就会很容易出现ANR。（8.0以下）
问题的解决
当时的优化：

减小sp对应的文件的大小，按照分类去读写对应的sp文件。
sp的读写轻量的、小的配置信息，将类似JSON的数据交给其他方式保存。
当需要多次调用Put系列方法，当逻辑确认不需要立即读取时，在最后一次调用commit或apply即可。

最近朋友推了一篇字节的博客(以下文字以及图片来源于字节今日头条团队)。
· 思路：如果能让sPendingWorkFinishers.poll()返回为null，则这里的等待行为直接就跳过去了，sPendingWorkFinishers是个ConcurrentLinkedQueue集合，可以直接动态代理这个集合，覆写poll方法，让其永远返回null，这个时候UI永远不会等待子线程写入文件完毕，事实证明这种方式简单有效。

文章图片

· 针对这种写入等待的ANR问题，还有一种就是全局替换写入方式，通过插桩的方式，替换所有的API实现，采用其他的存储方式，这种方式修复成本和风险较大，但是后期可以随机的替换存储方式，使用比较灵活。
友盟平台相关SDK初体验：
由于ANR的比较难复现，于是写一个方法，反复对SharedPreferences进行操作，以达到类似情况的复现。

文章图片

出现问题，通过友盟U-APM平台定位：

文章图片

找到问题后，进行文中思路的操作即可。
总结
在情景中，由于Android太过碎片化，又不得直接舍弃低版本用户，采用接入类似友盟U-APM平台的方式去更快的解决问题是必不可少的。但对于一些小型手机的低版本可能还是会出现ANR的问题，针对类似收集用户行为的情景，可采取进行多种方式去进行收集，例如对于低版本的系统，降低对收集数据的完整性等。
【项目中多次操作SharedPreferences导致ANR场景的解决】作者：计蒙不吃鱼