友盟APM和bugly全面对比

前言：

bugly和apm都是比较成熟的应用性能监控的第三方插件了，bugly用的比较早，但是感觉最近维护力度很低，反馈的好多问题也都迟迟无法解决，推测也许是因为免费原因，所以腾讯对这块业务并不怎么上心。

APM算是性能异常监控领域的新起之秀吧，bugly所具有的功能基本上APM都也有，并且针对bugly的几个问题（例如6.0以上ANR无法捕获）等也都做了修复。主要还是一个维护力度吧，现在还处于不断的更新状态，出了问题感觉至少有保障。

两款产品都用过，所以这次就针对这两款产品做一个对比，供大家参考。

对比1：接入成本

两个接入成本都算是比较低的，毕竟都是成熟的商业产品了。

bugly接入首先需要后台申请一个appid，方式只需要build.gradle中引入两个aar，然后application中申明一下即可。

bugly中使用方式：

1.后台添加应用申请appid


2.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.后台添加应用申请appid


2.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源码中调试才知道的），向正常使用缺乏必要的文档。

 @Override
    public 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算是一站式的产品，不需要多次接入，后续功能接入成本极低。当然仍有部分需求还未能覆盖到，希望后续这样方面能有进一步的优化。