移动端性能监测工具篇之U-APM
背景
性能问题
通常情况下,App的性能问题并不会直接导致其不能使用,却会潜在的影响用户体验。在众多App"内卷"的当下,一个不好的体验甚至能导致用户的流失。比如:
?启动速度过慢
?CPU占用率高导致的手机发热、耗电快
?不明原因的闪退
?…等等
预防和检查
当然,作为一名开发者,在编写代码时就要做到避免一些性能问题的出现。比如:
?优化计算的复杂度从而减少CPU占用率
?编写单元测试
?...等等
当然,善用工具可以高效地去监控App的性能问题,帮助开发者及时修复产品体验上的缺陷。市面上APM工具很多,因为笔者曾在项目中使用过U-App进行过应用信息的统计,在此就友盟U-APM来说一些使用体验。
U-APM使用体检
集成
参照官方平台的集成说明,以iOS为例,这里做一个简述
1.在U-APM
创建应用,生成一个Appkey
2.推荐使用CocoaPods
来接入SDK pod 'UMCommon'
3.pod 'UMDevice'
4.pod ‘UMAPM’
在 AppDelegate.m
文件中,添加如下
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[UMConfigure initWithAppkey:@"61276660870a7a610a4f67f5" channel:@""];
// Appkey在步骤1中生成
// channel字段为自定义渠道区分,不填写则被默认为是"App store" return YES;
}
分析结果
1.崩溃分析 我仅仅是在项目中的首页手写了一个可主动触发的闪退Bug。分析结果图解如下:
文章图片
崩溃的曲线图对于开发者来说,算是一个统筹的展示。重要的是,在页面下方的错误列表中,可以查看某个错误发生的次数,类型,影响的用户数。这很方便作为开发者在修改Bug时能快速准确的判断优先级。另外,错误都有单独的错误明细页,大部分的Bug都可以被精准定位。
后来由于
U-APM
启动崩溃分析的启发,我在项目内的启动方法中-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
即配置
Appkey
的前后,都分别写了闪退Bug,并暂时用渠道名做了区分。结果显示,在配置
Appkey
前发生的闪退,并不能被捕获。有人会问:那这不是必然的么?你都还没配置呢...
这也正是我想说的问题。因为在许多时候,我们去配置一些第三方库时,由于集成方法过于简单,总是会很随意的根据官方教程去添加一行代码,并不去考究它在项目代码中应当所处的最佳位置。因为这并不影响项目运行,这种细节也很容易被忽略。我希望在任何时候,开发者们都应该养成每一行代码在敲下去之前都尝试去思考的习惯。
2.卡顿分析
文章图片
卡顿的列表与明细也是和崩溃一样,可以查询和定位。并且能够标记(未处理、修复中、已忽略、已修复)4种状态。
我还另外添加了卡顿告警计划,只要卡顿用户数占比超过5%,就会发邮件通知我。它成功的在一小时内触发告警信息并在邮件中提醒了我。
3.启动分析 我在启动时采用了随机数去随机放慢该项目的启动速度。默认首次启动/冷启动超过3秒为慢启动,热启动超过1秒为。这里以冷启动为例:
文章图片
在分析柱状图里也很好的展示了正常启动与慢启动的占比
文章图片
4.内存分析 在OOM的分析上,貌似对Android的支持更甚iOS。由于iOS的Jetsam机制,这里只分析当程序内存超出限制时造成的一种特殊的Crash。包括异常的捕获也不是全都能检测。
文章图片
5.分布分析 平台均能在以上四个模块(崩溃、卡顿、慢启动、OOM异常)分析中提供分布状况,包括设备分布、系统分布、运营商分布、版本分布、页面分布、渠道分布、地域分布。
文章图片
6.自定义配置模块
文章图片
U-APM
还提供了采集开关,需要在初始化前就在代码中配置好。以上就是我体验的
U-APM
的全部功能。还有一些我来不及体验的功能等待更多开发者去使用,比如“云真机”,"API上传符号表页面整体加载速度渲染"等等。
一些建议分享
在卡顿分析与崩溃分析的运营商模块中,出现了一个分析错误。我使用的是电信宽带与电信卡,分析结果却展示出我使用的是中国移动的运营商。当然对于这种问题,平台有另外的客服工单可以去提出,这里也不再赘述。(从过去使用其他友盟的产品来看,客服工单的反馈效率还是挺不错的)
另外值得一提的是,因为笔者在项目中已经将开发语言完全过渡到
Swift
,但在集成时,官方提示Swift
当前仅支持U-App统计,其他业务暂不支持Swift
。我也是连夜创建一个OC项目去体验,并没有尝试在Swift
项目中接入。而现如今,Swift
已成iOS开发主流语言,希望U-APM
能在未来能全面支持Swift
更加便利开发者。当然,这不妨碍它目前可以满足开发者们在OC项目中对性能监控的基本需求:
?集成方法简单、迅速
?追踪崩溃、卡顿的详细信息,轻松定位根源问题
?分析图解清晰明了,多状态方便管理
?识别设备类型(iPhone/iPad/iPod、操作系统版本、运营商类型),分类设备性能**
【移动端性能监测工具篇之U-APM】最后,我还是希望,适当使用工具可以提升开发效率,但也请不要过分依赖而忘了思考。
推荐阅读
- 基于微信小程序带后端ssm接口小区物业管理平台设计
- Node.js中readline模块实现终端输入
- django-前后端交互
- 移动端h5调试方法
- “沉溺”疫情
- Jsr303做前端数据校验
- 40under40|40under40|思想会-那什么拯救你,我的"高端"甲方"爸爸"
- 端银×八正道|端银×八正道 | 21天百万实操信用卡特训营045+Dodo第5次作业
- 7、前端--jQuery简介、基本选择器、基本筛选器、属性选择器、表单选择器、筛选器方法、节点操作、绑定事件
- 端午偶感