全景旅游网站项目建设,杭州微官网设计公司,外贸网站建站m,在线解压zip网站系列文章目录 提示#xff1a;这里可以添加系列文章的所有文章的目录#xff0c;目录需要自己手动添加 例如#xff1a;第一章 Python 机器学习入门之pandas的使用 文章目录 系列文章目录前言一、Trace日志分析二、业务分析1.Firebase源码分析2.Firebase官方查看官方文档Dem…系列文章目录 提示这里可以添加系列文章的所有文章的目录目录需要自己手动添加 例如第一章 Python 机器学习入门之pandas的使用 文章目录 系列文章目录前言一、Trace日志分析二、业务分析1.Firebase源码分析2.Firebase官方查看官方文档Demo中issue查看 三、问题分析3.1 打点数据统计分析3.2 冷启动时间测试3.3 应用启动分析3.4 启动优化3.5 三方SDK初始化禁用效果3.6 ANR优化效果3.7 问题根治3.8 问题复盘 总结 前言 一、Trace日志分析
如果您想降低 ANR 率首先要做的是找出错误的原因。最直接的方法是尝试分析 Google Play 中排名靠前的 ANR 组。当我们检查控制台时显示如下 占比靠前的几乎每个组都有一个标题“ Broadcast of Intent { actcom.google.android.c2dm.intent.RECEIVE } … ”包含该类型的ANR占比接近60%。Google Play 后台堆栈详情如下 主线程堆栈
从堆栈未找到该问题分析入口于是在项目中搜索“ Broadcast of Intent { actcom.google.android.c2dm.intent.RECEIVE } … ”得知该acttion为Firebase组件FCM发送通知拉活我们应用的广播。于是继续研究FCM内部实现。
二、业务分析
1.Firebase源码分析
搜索FirebaseSDK发现“ Broadcast of Intent { actcom.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 { actcom.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 添加人为延迟并检查不同的场景。发现如下
当用户使用launcher app手动触发app launch时Application.onCreate中的主线程阻塞即使阻塞几分钟也不会报ANR当使用广播接收器启动应用程序时主线程阻塞时间少于 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:namecom.google.firebase.provider.FirebaseInitProviderandroid:authorities${applicationId}.firebaseinitproviderandroid:exportedfalsetools:noderemove/!--FirebasePerformance初始化禁用 --providerandroid:authorities${applicationId}.firebaseperfproviderandroid:exportedfalseandroid:initOrder101android:namecom.google.firebase.perf.provider.FirebasePerfProvidertools:noderemove/!--阻止令牌自动生成防止Firebase Analytics及messaging自动初始化二者需同时禁用--meta-dataandroid:namefirebase_messaging_auto_init_enabledandroid:valuefalse /meta-dataandroid:namefirebase_analytics_collection_enabledandroid:valuefalse /!--Google MobileAds广告SDK自动初始化禁用--providerandroid:namecom.google.android.gms.ads.MobileAdsInitProviderandroid:authorities${applicationId}.mobileadsinitproviderandroid:exportedfalseandroid:initOrder100tools:noderemove/!--FaceBook 禁用 SDK 自动初始化功能--meta-data android:namecom.facebook.sdk.AutoInitEnabledandroid:valuefalse/providerandroid:namecom.facebook.internal.FacebookInitProviderandroid:authorities${applicationId}.FacebookInitProviderandroid:exportedfalsetools:noderemove/禁用后在启动阶段异步进行手动调用。 由于使用到的三方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 { actcom.google.android.c2dm.intent.RECEIVE } … ”类型ANR占比 优化后Google play后台“ Broadcast of Intent { actcom.google.android.c2dm.intent.RECEIVE } … ”类型ANR占比 遗留的17.3%后面通过把FCM放到独立进程进行解决。
3.7 问题根治
FCM独立进程可参考
!--FCM独立进程 start--
serviceandroid:namecom.google.firebase.messaging.FirebaseMessagingServiceandroid:directBootAwaretrueandroid:exportedfalseandroid:process:lighttools:nodereplaceintent-filter android:priority-500action android:namecom.google.firebase.MESSAGING_EVENT //intent-filter
/servicereceiverandroid:namecom.google.firebase.iid.FirebaseInstanceIdReceiverandroid:exportedtrueandroid:permissioncom.google.android.c2dm.permission.SENDandroid:process:lighttools:nodereplaceintent-filteraction android:namecom.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获取不到与应该相关堆栈时可参考本篇思路进行分析。
