对1个anr率高的问题的优化
问题：在谷歌商店后台看到清理结果界面anr率最高，发生在handleStopActivity的时候等待sharedPreferences数据写入的时候，进入此界面需要主界面-->扫描界-->清理结果界面，anr率不正常
1.分析场景环境
- 清理界面：扫描文件后点清-->做动画+线程删除文件-->跳转清理结果界面
- 清理结果界面：主要就是加载显示1个广告
- anr发生操作路径：用户清理文件结束-->进入到结果界面—>看到结束立刻按返回-->卡住-->anr
2.检查sharedPreferences
- 清理模块代码是从安全中心的清理模块移植过来的，检查引入代码里面的sharedPreferences数据保存，没发现有保存操作。
- 反编译apk搜索发现公司广告sdk里面和谷歌/fb广告sdk里面有数据保存操作，查看对应代码处大致逻辑+手机模拟操作导出sharedPreferences文件查看，admob广告存的数据较大有比较大的嫌疑，但是如果对其处理可能会影响广告收入，而且主界面也有相同的广告，只因为这个点anr应该主界面anr率更高才对。
3.检查ui线程卡顿
- 清理界面界面卡顿主要是谷歌/fb广告主线程拉取耗时、生成/显示广告view耗时，谷歌/fb广告拉取修改到了子线程,广告view布局做了优化,此界面anr没有可分辨变化，总的anr率的变化可能是因为其他界面的优化。
4.检查资源占用的影响
- 因为以前听别人对anr的分享，说过即使应用自身没有问题，也可能会因为系统负载高，导致系统很多东西运行慢，事件分发慢触发事件分发超时anr。猜想有没有可能是因为系统资源占用的影响，特别是自身的占用系统资源
- 清理结果界面只有广告相关的东西，检查清理界面逻辑：多线程扫描文件-->点击清理-->做动画+后台删除文件-->跳转新界面。点击清理以后做动画的时间是固定的，没有等到删除文件完成就跳转了之后的界面，应该是为了视觉上的清理速度，相当于是跳转界面以后可能还在进行连续的io操作。
5.处理
- 清理文件的时候判断文件量大就把动画时间延长且动画结束预留1秒的时间再跳转之后界面，修改后视觉效果合理，优化效果是应用anr率从0.10%降到0.08~0.09%（谷歌商店后台分辨不出来单界面减少多少，可以手动算单界面的，但是计算对比复杂，所以以总的为参考，此次修改不涉及其他优化，至少没有其他有意做的优化）
- 再前一步尝试修改有效基础上对逻辑进行优化，点清理以后循环做动画，等删除完成以后结束动画，然后再等1秒再跳转新界面。修改后从视觉上看连贯性没有问题，但是如果删除耗时长，时间上给人感觉可能显得长，对比了猎豹、腾讯之类的清理应用，发现他们正常清理一个文件也做很长时间动画，所以决定就这么改。
- 对于view相关耗时想尝试通过子线程加载view解决，去网上又搜索看了下，偶然看到一个博客说用asynclayoutinflater子线程加载view,又搜索了下asynclayoutinflater相关的，对比了下代码，最终把asynclayoutinflater的代码拷进来对应用内主列表和广告view做了子线程加载的操作（一开始还按照网上有个博客的多线程优化实验了下，发现卡顿还增加了，猜想主要是回调到主线程还要1个接1个，在加载列表item的时候多线程可能会又概率连续回调到主线程，连续往列表上加会增加主线程连续耗时，后来改成单线程了）
6.结果
- 5.2和5.3的优化在一起把应用总anr率从0.08~0.09%降到0.05%。又一部分降低来自其他界面，清理结果界面的anr降低了差不多50%，但是还是排第一，还是不正常
- 因为用户看到清理结果界面以后基本会立刻结束，界面展示时间短，又有广告拉取，view生成和展示这种耗时或者可能耗时的操作，所以暂时想到的可以继续优化的点：1..把清理结果界面跟清理界面合成1个activity，删除广告过程中拉取广告、生成广告view，延长显示广告相关的时间跨度，减小拉取广告过程中用户就结束界面的概率 2. 可以修改产品设计，把广告放到比如扫描清理列表里面，因为用户看到清理结束自然反应就是返回，目前清理结果界面广告收入并不高，放到清理扫描界面里面预期可能还可以增加收入。
清理流程优化：