共计 2201 个字符，预计需要花费 6 分钟才能阅读完成。
背景
性能问题
通常状况下，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、操作系统版本、运营商类型），分类设施性能**
最初，我还是心愿，适当应用工具能够晋升开发效率，但也请不要过分依赖而忘了思考。