友盟APM和bugly全面对比
前言:
bugly和apm都是比较成熟的应用性能监控的第三方插件了,bugly用的比较早,但是感觉最近维护力度很低,反馈的好多问题也都迟迟无法解决,推测也许是因为免费原因,所以腾讯对这块业务并不怎么上心。
APM算是性能异常监控领域的新起之秀吧,bugly所具有的功能基本上APM都也有,并且针对bugly的几个问题(例如6.0以上ANR无法捕获)等也都做了修复。主要还是一个维护力度吧,现在还处于不断的更新状态,出了问题感觉至少有保障。
两款产品都用过,所以这次就针对这两款产品做一个对比,供大家参考。
对比1:接入成本
两个接入成本都算是比较低的,毕竟都是成熟的商业产品了。
bugly接入首先需要后台申请一个appid,方式只需要build.gradle中引入两个aar,然后application中申明一下即可。
bugly中使用方式:1.后台添加应用申请appid2.app目录下的build.gradle文件中添加
implementation 'com.tencent.bugly:crashreport_upgrade:1.3.6'
implementation 'com.tencent.bugly:nativecrashreport:3.8.0'3.applcation中添加初始化操作Bugly.init(application, appid, true)//这里的appid替换成自己申请的
APM的接入方式类似
APM中使用方式:1.后台添加应用申请appid2.app目录下的build.gradle文件中添加
implementation(name: 'umeng-apm-v1.1.0', ext: 'aar')
implementation(name: 'umeng-asms-v1.1.4', ext: 'aar')3.applcation中添加初始化操作
UMConfigure.init(this, "appid", "umeng", UMConfigure.DEVICE_TYPE_PHONE, "");
接入成本这方便两者差不多,都是比较低的。
对比二.使用方便度
后台对比:
bugly的后台界面
APM的后台界面:
两个也是差不多的,但是单从后台来看,明显APM的功能项是多于bugly的,而且可筛选的维度上会更细一些。
单个异常处理:
bugly有个bug,如果处理单个错误的时候,进入到错误详情界面进行状态修改,列表页是存在一定概率无法同步状态的。APM试了下,目前没有遇到这个问题。
启动耗时统计:
APM添加了启动耗时统计这个功能,还是蛮不错的。bugly目前没有这功能。
对比三.捕获原理分析
捕获原理主要分为四个部分,java崩溃,java错误,native崩溃,anr采集
java崩溃:
java层崩溃这方面,两者实现原理都差不多,都是实现了Thread.UncaughtExceptionHandler接口来实现的。
APM的相关java崩溃采集文档说明:开发者中心
但是bugly是阻断式的,即我们先实现了自己的UncaughtExceptionHandler,然后调用了bugly的init方法后,bugly中会调用Thread.setDefaultUncaughtExceptionHandler()方法替换我们自己的那个UncaughtExceptionHandler,这样我们自己设置的就不生效了。具体解决办法可以参照我的另一篇文章:Android解决应用崩溃后重启的问题,以及与bugly的冲突_分享+记录-CSDN博客。
这方面APM应该是做了优化,同样的操作,APM没有发现这问题。
java错误:
bugly中的错误有的人不知道是什么意思,这个我解释下,错误在bugly中指的是那些已经捕获并且处理的异常。比如下面这段代码并不会导致崩溃,但是logcat中会抛一个异常出来,bugly的错误指的就是这一类的问题。
try{String str = null;boolean b = str.equals("");}catch (Exception e){e.printStackTrace();//去掉e.printStackTrace()则bugly中的错误也不会统计}
因为去掉e.printStackTrace();则bugly也捕获不到异常了,所以推测bugly应该是通过分析log或者通过native层替换掉原有的PrintStream对象来实现的。
APM的话没有这功能。
native崩溃:
这个两者差不多,都是通过注册未能处理的信号量的方式来实现。实际实验对比中,也都能采集相关的native崩溃。
anr采集:
这个对比下来,明显APM是占优势的。
bugly检测ANR的原理是基于traces.txt文件的修改监听,对应的详细原理可以看这一篇文档介绍:关于ANR异常捕获与分析,你所需要知道的一切_markvz的博客-CSDN博客
bugly实际验证下来,anr只能在安卓6.0及以下的版本生效。
APM的话对全版本都支持。原理基本上就是系统知道发生ANR的时候,会向应用进程发送一个native信号量从而捕获堆栈信息,只要监听这个信号量,就知道ANR的发生。
具体原理可以参照下面的文章。
一文教你轻松搞定ANR异常捕获与分析方法_umengplus的博客-CSDN博客
以及微信写的这一篇:
微信Android客户端的ANR监控方案
采集的信息如下图所示,不过根据日志去推断原因,通过类似下面的日志排查起来还是很吃力,希望这方便能有优化。
卡顿采集:
卡顿采集区别于anr,anr是只有出发程序无响应的时候才算是ANR,指的是输入事件(例如按键或屏幕轻触事件等)在 5 秒内没有响应。但是卡顿就是主线程阻塞,有可能还没有达到anr的程度,或者没有输入事件。
试下了bugly和APM。bugly是就没有卡顿采集这个功能。APM是有这个功能,但是没有生效,我线程sleep了10秒,实验多次,仍然没有统计到卡顿的发生。
目前网上开源主流的捕获主线程卡顿的框架就是BlockCanary,目前卡顿采集这块还是推荐这个。
上传实时性:
验证下来,应该都是发生异常后,第二次启动时上报的。两者差不多
对比四.功能配置
自定义异常上报:
两者都有这功能,
bugly使用的时候有个bug,只能使用CrashReport.postException方法,另外一个CrashReport.postCachedException方法是不生效的。
并且如果想使用bugly的自定义异常上报,还存在一定的bug,必须像下面这样调用才可以(PS:这种方式还是深入到bugly源码中调试才知道的),向正常使用缺乏必要的文档。
@Overridepublic void postCustomException(String errorType, String errorMsg, String stack, Map<String, String> params) {
//params是自定义参数CrashReport.setUserSceneTag(AppManagement.Companion.getApplication(), ConfigManager.getInstance().getBuglyConfig().getSelfExceptionTagId());//添加tag,这行可以省略CrashReport.postException(4, errorType, errorMsg, stack, params);//这里的4是必要条件}
APM:
使用UMCrash.generateCustomLog(e, "UmengException");方法进行上报,稳定性上没有问题。但是也有个缺陷,不支持自定义参数上报。比如我想上报一个自定义异常,并且带一些参数辅助排查,就是不支持的。现在只能把参数直接频道ExceptionName里面,这点还是希望后续能有优化。
后台报表导出:
这个两者均未实现
热修复能力:
bugly出身于腾讯,所以直接继承了tinker的功能,可以很方便的实现热修复功能。我们的线上产品也体验了下, 确实效果不错。但是如果apk使用了360或者爱加密的加固功能,则使用bugly的热修复就会失效。这个之前调试过,排查下来的原因是通过bugly下发的增量热修包,是否加固的标记会被标记未否,想用加固包使用热修复,还是要自己搭后台才行。
APM目前还不支持热修复。
对比五.后台稳定性
这个对比结果很明显,bugly使用了半年,后台崩溃了至少3次,每次都是半天以上的时间,这个对于开发者来说还是很致命的。这估计也是和腾讯对bugly的支持程度有关吧。
APM我体验下来,基本上还算是稳定的,后台的异常的查询速度也都是十分的迅速的。
总结
总结下来,bugly的功能点设计上还是很全的,几乎每个点都比较契合开发者的需求。只是因为后续一直缺乏维护和更新,稳定性上得不到保障,新的需求点也迟迟无法开发者的需求。
APM这个新起之秀,算是给予bugly做了进一步的升级改造,稳定性和全面性上要好了很多。另外APM具有云真机的优势,以及APM算是一站式的产品,不需要多次接入,后续功能接入成本极低。当然仍有部分需求还未能覆盖到,希望后续这样方面能有进一步的优化。
友盟APM和bugly全面对比相关推荐
- 使用友盟+的APM服务实现对移动端APP的性能监控
简介: 对于信息系统服务,一般我们的重点监控对象都是核心的后端服务,通常会采用一些主流的APM(Application Performance Management)框架进行监控.告警.分析.那么对于 ...
- 三大数据分析工具对比 - 友盟 GrowingIO 神策数据
三大数据分析工具对比 - 友盟 GrowingIO 神策数据 数据分析半年,title应该是数据分析专员.怎么说呢,如果是在稍大一点的公司,数据分析专员的要求一般并不止于excel,很有可能是要求熟练 ...
- JPush,友盟,百度云,个推Push服务在送达率上的对比
由于目前Android系统杀进程越来越厉害了,这对于应用在Push及时到达上有高要求的感到压力很大,所以前段时间在项目中考虑第三方Push服务时更多的想要有更强的保活功能. – 目前我们常用的几大Pu ...
- 教你玩转友盟应用性能监控U-APM平台
目录 前言 正文 一.U-APM 应用性能监控平台介绍 1. 大核心优势 2. U-APM 与其他产品功能对比 二.集成友盟 SDK 步骤 第一步.进入 ...
- Android友盟+U-APM快速集成与极致体验
文章目录 一.前言 二.快速集成 2.1 账号注册 2.2 创建应用 2.3 Demo下载 2.4 Demo导入 2.5 Demo试跑 三.极致体验 3.1 第一个App崩溃 3.2 查看后台崩溃信息 ...
- APP性能监测工具之友盟的 U-APM产品入门使用
前言: 最近公司做了一款新的APP,要求能够看到用户每天的新增量和活跃量,还有一些页面的点击量.停留时间等的监测,还有更重要的一点就是能够监测到app的异常情况.于是开始对第三方工具开始一番研究,对比 ...
- 友盟数据—值得手游创业者关注的玩家数据
友盟数据-值得手游创业者关注的玩家数据 你知道"辣妈"是什么游戏的忠诚玩家吗?你知道"大龄玩家"都喜好怎样的游戏?你知道哪类玩家最"多金"? ...
- 首发:友盟2015年Q2、Q3中国移动互联网趋势报告
报告要点: 截止至2015年第三季度,活跃设备数达8亿,与第二季度相比增长1.9%,增幅进一步放缓,新老设备更迭周期正在不断缩短. Android与iOS在线时长份额较为稳定,国产Android手机品 ...
- 友盟2015年Q2、Q3中国移动互联网趋势报告
报告要点: 截止至2015年第三季度,活跃设备数达8亿,与第二季度相比增长1.9%,增幅进一步放缓,新老设备更迭周期正在不断缩短. Android与iOS在线时长份额较为稳定,国产Android手机品 ...
最新文章
- django搭建示例-ubantu环境
- java开发支持类库
- RTC_WaitForSynchro()
- Vue项目多域名跨域
- 音视频技术开发周刊 56期
- 信息学奥赛一本通(2065:【例2.2】整数的和)
- WPF 中出现不同线程间操作的解决
- 华为哪款手表支持鸿蒙,华为Watch 3最早或于5月发布 采用鸿蒙系统并支持eSIM
- 21天学通java 3_《21天学通Java》PDF 下载
- 解读Unity中的CG编写Shader系列二
- IDEA 常用设置 与 常用操作(二)
- linux下赋予普通用户管理员权限
- 在Vista中用鼠标激活Flip 3D
- go用smpt包发送邮件, 被抄送收不到邮件bug
- Cookie或Token实现网站自动登录
- 正定方言—正定少占鱼欢迎您,快速做个正定人
- 详细分析MySQL的日志(一)本文原创地址:博客园骏马金龙https://www.cnblogs.com/f-ck-need-u/p/9001061.html
- JSP四大作用域属性范围
- 如何使用Domino实用程序(Updall, Compact, Fixup) 进行维护
- Python 切巧克力