乐趣区

关于程序员:1个小时接入友盟-UAPM解决移动应用崩溃性能内存的云监控分析

背景和痛点

随着挪动我的项目的一直递进,用户使用量的减少,简单的机型、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 账号:漠上刀栈

退出移动版