背景性能问题通常情况下|体验移动端性能监测工具篇之友盟＋U-APM 应用性能产品背景

背景
性能问题
通常情况下， App的性能问题并不会直接导致其不能使用，却会潜在的影响用户体验。在众多App"内卷"的当下，一个不好的体验甚至能导致用户的流失。比如：
启动速度过慢
CPU占用率高导致的手机发热、耗电快
不明原因的闪退
…等等
预防和检查
当然，作为一名开发者，在编写代码时就要做到避免一些性能问题的出现。比如：
优化计算的复杂度从而减少CPU占用率
编写单元测试
...等等
当然，善用工具可以高效地去监控App的性能问题，帮助开发者及时修复产品体验上的缺陷。市面上APM工具很多，因为笔者曾在项目中使用过U-App进行过应用信息的统计，在此就友盟U-APM来说一些使用体验。
U-APM使用体检
集成
参照官方平台的集成说明，以iOS为例，这里做一个简述
在U-APM创建应用，生成一个Appkey
推荐使用CocoaPods来接入SDK
pod'UMCommon'
pod'UMDevice'
pod‘UMAPM’
在AppDelegate.m文件中，添加如下
-(BOOL)application:(UIApplication*)applicationdidFinishLaunchingWithOptions:(NSDictionary*)launchOptions{
[UMConfigureinitWithAppkey:@"61276660870a7a610a4f67f5"channel:@""];
//Appkey在步骤1中生成
//channel字段为自定义渠道区分，不填写则被默认为是"Appstore"returnYES;
}
分析结果
1、崩溃分析
我仅仅是在项目中的首页手写了一个可主动触发的闪退Bug 。分析结果图解如下：

文章图片
崩溃的曲线图对于开发者来说，算是一个统筹的展示。重要的是，在页面下方的错误列表中，可以查看某个错误发生的次数，类型，影响的用户数。这很方便作为开发者在修改Bug时能快速准确的判断优先级。另外，错误都有单独的错误明细页，大部分的Bug都可以被精准定位。
-6350
-314325
后来由于U-APM启动崩溃分析的启发，我在项目内的启动方法-(BOOL)application:(UIApplication*)applicationdidFinishLaunchingWithOptions:(NSDictionary*)launchOptions中，即配置Appkey的前后，都分别写了闪退Bug ，并暂时用渠道名做了区分。
结果显示，在配置AppKey前发生的闪退，并不能被捕获。
有人会问：那这不是必然的么？你都还没配置呢...
这也正是我想说的问题。因为在许多时候，我们去配置一些第三方库时，由于集成方法过于简单，总是会很随意的根据官方教程去添加一行代码，并不去考究它在项目代码中应当所处的最佳位置。因为这并不影响项目运行，这种细节也很容易被忽略。我希望在任何时候，开发者们都应该养成每一行代码在敲下去之前都尝试去思考的习惯。
2、卡顿分析

文章图片
卡顿的列表与明细也是和崩溃一样，可以查询和定位。并且能够标记(未处理、修复中、已忽略、已修复)4种状态。
我还另外添加了卡顿告警计划，只要卡顿用户数占比超过5% ，就会发邮件通知我。它成功的在一小时内触发告警信息并在邮件中提醒了我。

文章图片
3、启动分析
我在启动时采用了随机数去随机放慢该项目的启动速度。默认首次启动/冷启动超过3秒为慢启动，热启动超过1秒为。这里以冷启动为例：

文章图片
在分析柱状图里也很好的展示了正常启动与慢启动的占比