ANR实战案例 - FCM拉活启动优化

系列文章目录

提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
例如：第一章 Python 机器学习入门之pandas的使用

---

---

前言

---

一、Trace日志分析

如果您想降低 ANR 率，首先要做的是找出错误的原因。最直接的方法是尝试分析 Google Play 中排名靠前的 ANR 组。当我们检查控制台时，显示如下：

占比靠前的几乎每个组都有一个标题“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”，包含该类型的ANR占比接近60%。Google Play 后台堆栈详情如下：

主线程堆栈：

从堆栈未找到该问题分析入口，于是在项目中搜索“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”，得知该acttion为Firebase组件FCM发送通知拉活我们应用的广播。于是继续研究FCM内部实现。

二、业务分析

1.Firebase源码分析

搜索FirebaseSDK，发现“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”是内部的一个静态注册广播，如下图所示：

该意图属于FirebaseInstanceIdReceiver广播，考虑是否广播这里出现了耗时？

查看其父类CloudMessagingReceiver中onMessageReceive调用方式：

可以看到onReceive方法内部虽然进行了混淆，但可以看到大概逻辑，是通过一个线程池中子线程进行处理返回的广播结果。好像处理的也没有毛病。

源码的这个方向没发现问题，继而换个思路查看官方文档及Demo。

2.Firebase官方查看

官方文档

通过源码查看，发现CloudMessagingReceiver属于messaging库。
官方文档地址：
https://firebase.google.com/support/release-notes/android#messaging_v23-0-7

messaging库升级为23.0.7后，Google play后台标题为“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”类型的ANR比例没有明显下降。
然后查看Cloud Messaging更新记录，包括23.1.1等一共有5个版本致力于解决ANR，依次升级测试后仍然没有解决我们的问题。

Demo中issue查看

从官方提供Demo的issue查看，不少开发者也遇到了这个ANR：

然后做了如下尝试：
https://github.com/firebase/firebase-android-sdk/issues/3990

参考issue-3990中描述的方法，将广告初始化移到Activity阶段，似乎依然没有缓解问题。

https://github.com/firebase/firebase-android-sdk/issues/3468

参考issues-3468将基础库降级，以及新的Bom方式配套引入，均没有解决问题。

三、问题分析

基于前面的途径都没有解决问题，于是我决定自己根据该问题现象进行深入研究。

3.1 打点数据统计分析

首先，我对Firebase后台发生ANR时间点的打点数据进行了统计分析，发现大部分集中在Application.onCreate 阶段。
这让我好像看到了一点曙光，于是向 Application.onCreate 添加人为延迟并检查不同的场景。发现如下：

1. 当用户使用launcher app手动触发app launch时，Application.onCreate中的主线程阻塞，即使阻塞几分钟也不会报ANR
2. 当使用广播接收器启动应用程序时，主线程阻塞时间少于 10 秒时不会报告 ANR。

3.2 冷启动时间测试

于是让测试帮忙找了线上ANR发生率比较高的具有代表性的机型，进行了冷启动时间测试，发现很多中低端机型的冷启动时间超过10s。
ps：由于业务主要是非洲国家，线上包含了大量的低端机及平均使用5-7年的手机。
于是我开始思考，是否启动时间跟该ANR具有相关性？

3.3 应用启动分析

最终利用kotlin的init特性获取了冷启动阶段的.trace文件

class App: MusicApplication() {init {if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {Debug.startMethodTracingSampling("startup", 8 * 1024 * 1024, 100)}}override fun onCreate() {super.onCreate()Debug.stopMethodTracing()}
}

trace概览如下：

详细：

由函数调用耗时发现，启动阶段的大部分耗时都是因为三方库使用contentProviders调用初始化代码，在Provider阶段产生的耗时。
查看系统源码可知，

先执行完installContentProviders方法，才会执行到callApplicationOnCreate。于是接下来就想办法处理三方库的自动初始化。

3.4 启动优化

对相关三方SDK使用的Provider初始化进行禁用，使用tools:node=“remove”，示例如下：

<!--禁用FirebaseApp初始化--><providerandroid:name="com.google.firebase.provider.FirebaseInitProvider"android:authorities="${applicationId}.firebaseinitprovider"android:exported="false"tools:node="remove"/><!--FirebasePerformance初始化禁用 --><providerandroid:authorities="${applicationId}.firebaseperfprovider"android:exported="false"android:initOrder="101"android:name="com.google.firebase.perf.provider.FirebasePerfProvider"tools:node="remove"/><!--阻止令牌自动生成，防止Firebase Analytics及messaging自动初始化，二者需同时禁用--><meta-dataandroid:name="firebase_messaging_auto_init_enabled"android:value="false" /><meta-dataandroid:name="firebase_analytics_collection_enabled"android:value="false" /><!--Google MobileAds广告SDK自动初始化禁用--><providerandroid:name="com.google.android.gms.ads.MobileAdsInitProvider"android:authorities="${applicationId}.mobileadsinitprovider"android:exported="false"android:initOrder="100"tools:node="remove"/><!--FaceBook 禁用 SDK 自动初始化功能--><meta-data android:name="com.facebook.sdk.AutoInitEnabled"android:value="false"/><providerandroid:name="com.facebook.internal.FacebookInitProvider"android:authorities="${applicationId}.FacebookInitProvider"android:exported="false"tools:node="remove"/>

禁用后在启动阶段异步进行手动调用。
由于使用到的三方SDK较多，上面只列举了部分SDK，还有其它：

• 融云SDK的Provider初始化禁用，通过反射调用。
• AutoSize库的Provider初始化禁用，通过AutoSize.checkAndInit调用。
• 其它

3.5 三方SDK初始化禁用效果

三方SDK使用的Provider初始化禁用后，优化效果如下：

图1-三方SDK自动初始化优化前，k7机型测试，应用进程创建耗时4.04s
图2-三方SDK自动初始化优化后，k7机型测试，应用进程创建耗时0.12s

3.6 ANR优化效果

优化前Google play后台，“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”类型ANR占比：

优化后Google play后台，“ Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } … ”类型ANR占比：

遗留的17.3%后面通过把FCM放到独立进程进行解决。

3.7 问题根治

FCM独立进程可参考：

<!--FCM独立进程 start-->
<serviceandroid:name="com.google.firebase.messaging.FirebaseMessagingService"android:directBootAware="true"android:exported="false"android:process=":light"tools:node="replace"><intent-filter android:priority="-500"><action android:name="com.google.firebase.MESSAGING_EVENT" /></intent-filter>
</service><receiverandroid:name="com.google.firebase.iid.FirebaseInstanceIdReceiver"android:exported="true"android:permission="com.google.android.c2dm.permission.SEND"android:process=":light"tools:node="replace"><intent-filter><action android:name="com.google.android.c2dm.intent.RECEIVE" /></intent-filter>
</receiver>
<!--FCM独立进程 end-->

继承FirebaseInstanceIdReceiver的自定义类也得改为独立进程，否则收不到FCM推送消息。
然后通过跨进程广播传递FCM通知。

3.8 问题复盘

回顾第二小节的Firebase源码分析，已知Firebase的Messaging库内部是通过广播的形式来发送消息，实现业务App的拉活，查看常见ANR超时场景，前台广播的超时时间为10s，所以问题的根源还是应用被拉起的启动时间过久，导致该广播超时，从而产生了ANR。

---

总结

一般做海外业务的同学才会用到Firebase库，但解决问题的思路类似。当碰到此类疑难ANR问题，trace.txt获取不到与应该相关堆栈时，可参考本篇思路进行分析。