Android 项目 Anr和崩溃的优化

首先两张来自Google 控制台真实项目的截图

程序老鸟都知道，一个项目的这两个参数(设备崩溃率 和 设备Anr率)的重要性，这俩个参数也能间接代表项目程序的质量。

上面图清楚的展示了项目优化前后的参数变化，最终也都达到Google官方定义的阈值。下面分享下，我都做了哪些优化。

 （1）流程清晰化

优化前的项目初始化流程混乱，主要有 登陆SDK的初始化 广告SDK的初始化  各种统计分析服务。我们项目用的引擎框架是 Cocos2dx lua。 所有的初始化基本都放在AppActivity 的 onCreate时段。由于的登陆的SDK也比较复杂聚合了goolge 、Facebook、 邮箱登录、游客登录，广告也是用了一个市面上的聚合广告SDK，还有各种统计分析服务有 Adjust firebase。由于本身功能的复杂性，让AppActivity onCreate变得臃肿。出现的结果就是有挺多的崩溃就产生在项目启动几秒。

在保留原有功能的前提下做了以下优化：

让流程线性化，

(1)登录SDK 初始化  如果初始化失败继续初始化，直到初始化成功再进行下一步。

(2)调出登录框，登录不成功，继续暂停在该部，继续登录

(3)广告SDK初始化，失败，继续初始化知道成功

(4)登录服务器，进入游戏

基本主要分成了这四步。由于我们广告只有激励广告，在广告初始化成功后，调用广告的SDK加载一个激励广告备用，给游戏播放广告准备。

 （２）不同性能的设备逻辑分开处理

由于我们项目本身的资源还是挺大的，比如一个抽卡流程用的的资源有１００Ｍ，这对低性能的机器就是负担。还有挺多类似的流程，逻辑没有区分设备。导致设备本身内存不错，产生了一些崩溃和ANR

这边具体做的优化

（１）根据设备的Android版本和机器运行位数（６４位　３２位），分成低端机和高端机。具体项目可以分成更多的类型

（２）我们游戏的主要资源是特效和角色，就特效和角色做成高模和低模。我们的资源基本都是Spine做的２ｄ资源，高模和低模不一样的就是spine的输出比例不一样，低端机加载低模

（３）游戏复杂流程的可以简化流程，比如上面说的抽卡流程，低端机器就抽卡流程就是点击按钮直接弹出给物品界面。

（４）注册onTrimMemory函数，对项目的内存状态实时监控。等达到TRIM_MEMORY_COM　PLETE　时，弹窗，要求玩家主动清楚内存。我们做的就是弹出让玩家调到登录界面，清空内存，重新进入游戏。