1个小时接入友盟+ U-APM：解决移动应用崩溃、性能、内存的云监控分析

背景和痛点

随着移动项目的不断递进，用户使用量的增加，复杂的机型、Android版本等等，让公司的移动应用开始频频出现投诉、不稳定等问题。
其实这些问题在早起也有出现过，不过都因为用户量少，出现问题都可以快速解决。但是产品上依然面临着如下问题：
1、公司的手机型号不全，一般的云真机很难模拟出来所有的场景。
2、公司自己研发的日志捕捉功能不全，一方面对于瞬间崩溃很难捕捉，另一方面则是捕捉的时候部分机型当时的内存、设备快照获取不对，导致开发不断的更新完善日志机制。
3、虽然也做了钉钉的群机器人告警业务，但是只能做简单的监控，无法起到预警作用，都是事后告警，这个时候往往用户端已经出现严重错误。
4、Android和IOS需要各自研发一套，并且IOS的信息获取更加困难，导致我们IOS端功能也相对保守，很多新研发的功能都不敢在IOS上推广。

需求分析

面临这些问题，我们需要抽丝剥茧找到一个核心的解决方案。
1、公司永远不可能把所有手机购置一遍，云真机是主流，需要找到一个海量稳定机型的市场。
2、对于日志采集、性能监控找到第三方解决。把专业的问题交给专业的团队，公司的团队把核心能力应用在公司的业务开发。
3、需要能够做到：
①java、Swift、ANR、Native都可以做崩溃分析。
②对于Android、IOS能够设置指标进行卡顿分析。
③对于热启动、冷启动、首次启动可以做独立的分析，定点解决启动慢问题。
④对内存占用进行分析，特别是卡顿、崩溃时候的整体内存和本应用内存的分析。
⑤能够自定义监听一些日志，自定义推送到微信、钉钉等。
⑥这些数据最好不要只是原始数据，通过监控平台可以形成报表。

维度分析

老板首先看中的是成本，从成本上来说，自主研发是一个持续性投入的过程。未来可能还会有更多的研发投入，以及机型购置。
而从技术角度上来说，研发更倾向于不断打造完善公司自己的APM，不过在深入了解了友盟+的APM之后觉得除了我们能够长期存储日志，其他真的不具备优势。而60天的日志分析记录，也足够使用了。
所以综合来看，我们开始决定使用友盟+的APM监控系统以及友盟+的真机调试。

技术实现

1、注册友盟+会员

这点略过，大家自行注册，注册完成之后选择友盟+U-APM产品

2、新建应用

填写应用信息，并选择平台（平台支持Android+IOS，但是Android和IOS平台需要独立添加应用）

3、集成U-APM的SDK

以Android Studio，Maven 自动集成为例
配置maven： maven { url 'https://repo1.maven.org/maven2/' }
引入SDK以及对应的版本：（使用时候注意最好用最新版）
dependencies {

implementation  'com.umeng.umsdk:common:9.4.2'
implementation  'com.umeng.umsdk:asms:1.4.1'
implementation 'com.umeng.umsdk:apm:1.4.2'

4、配置必要的权限清单

建议把位置权限要加上去，U-APM会在SDK内集成了防作弊的位置判断，更加准确的获取位置信息。

5、初始化接入

接入的时候需要几个注意点：
AndroidManifest.xml需要配置appkey和channel，即便是在onCreate的时候设置了key

6、集成平台

就可以看到自己的应用了

功能简介：

分析

对于ANR有独立的分析页面
卡顿分析、启动分析、内存分析等等都可以精确到小时、天等维度。同时可以针对不同的版本、操作系统、设备等进行详细的统计。

云真机测试

应用可以一站式接入云真机，从华为、小米等一线品牌到魅族联想甚至诺基亚都有涵盖。Android版本也包含了最低的Android4.4和最高的Android11。
直接上传安装包，就可以进行一键测试了。

总结和体验：

本文主要是一次产品需求讨论之后的功能论证，公司正式的APP接入友盟+ U-APM还未上线。而本文也是花了一个小时尝试接入U-APM的一种实验，过程比较顺利，而产品部对于这种性能指标的监控方式也比较认可，毕竟一次接入之后就可以实现多种应用。
而友盟+ U-APM的功能不止于此，后续对于U-APM的深入对接也不会止步。
下一步会继续尝试：
例如，U-APM可以分别分级控制内存、卡顿、崩溃等开关和捕获级别，自定义Activity 预埋手动采集控制，等等。

作者：小七
CSDN账号：漠上刀栈