Crash和Anr以及启动优化记录

Crash

通过Vcm捕捉到的崩溃信息和Firebase Crashlytics的崩溃信息和埋点日志，初步猜测定位问题可能是

• 广告

  刚好崩溃率上升大概跟广告位的上增长比较相近。于是就需要上线去广告灰度版本进行测试。

• Glide

  首页瀑布流图片很多是Webp，然后Vcm捕获到一部分Glide的解析崩溃

Anr

大量的Anr发生在FCM 的 FirebaseInstanceIdReceiver ，因为App里面使用的是透传通知，Fcm收到后台消息后需要后台启动App响应透传通知信息，怀疑启动过慢导致了FirebaseInstanceIdReceiver 的Anr，通过做差设备统计排除推送和启动优化修复此问题

启动优化

这次的启动优化大致先经历了本地修改、增加统计后 灰度测试 找到耗时比较久的初始化部分、再次优化。

拆分、埋点

首先要将现有的启动初始化拆分开尽量小的部分，给每个部分增加启动时间统计。然后可以统一埋点用于线上统计

移出不需要的部分

经过业务的长期发展，可能有一些sdk我们已经用不到了，但是我们没有移出掉相关代码（比如友盟、Flurry）我们需要排查出这些sdk并将其移出。

整理sdk初始化依赖路径图

有的sdk的初始化时时要求其他sdk已经初始化，我们需要整理一份启动依赖的有向图，将各个启动时机了然于胸，这样后面修改启动优化修改时才能降低出错的可能性

可以放子线程的放到子线程

根据我们的启动时间统计和上一步整理的初始化依赖图，我们在不改变启动依赖的前提下将可以放子线程的代码放到子线程去。

ContentProvider 自动初始化问题

有一些SDK使用ContentProvider 自动初始化，这就导致这一部分Sdk的初始化失去了控制，我们需要去看一下这些ContentProvider，可以移出掉（找到这个ContentProvider 的配置信息，然后复制到我们的AndroidManifest里，添加tools:node="remove"就可以移出掉了）的移出掉，然后我么自己进行手动初始化，根据业务判断可以放子线程的放子线程。

别忘了添加启动时间统计

灰度测试启动统计

经过以上几步我们本地可以修改的都差不多修改了，这时我们需要上线进行灰度测试了，由于第一步里面我们给各个sdk启动增加了统计埋点，我们就可以拿到线上的启动数据了，找到启动比较耗时的部分 （尤其是）进行更细致的启动优化修改

中台已经做了启动优化的sdk：

广告组件：adclient：0.5.3

归因组件：media-source:3.0.1

http路由组件：route:1.6.7-alpha2

注：还有一个比较极限的优化需要彻底修改启动的代码，引入第三方框架，但是还没有上线测试过。但是本地来看启动时间变为原来的一半

可以参考https://github.com/gdutxiaoxu/AnchorTask