使用背景
作为开发人员，日常不是在写BUG，就是在写BUG的路上。尤其是中小型公司，通常人手不够，开发流程不完善，测试场景无法覆盖全部。尽管在每次修改旧功能和做新功能时都暗示自己要少写BUG，上线前测试同学也会回测，但仍然无法避免一些漏网之鱼。如何在上线后快速发现问题、定位问题、解决问题，这是我们开发人员面临的挑战。
学宝是一款专门面向中小学学生的语文、数学、英语全科同步学习工具APP。 从2014年第一版上线开始，Android 和 iOS 端同时接入友盟统计SDK，用于日常的数据统计和留存分析，借助这些服务，为公司节省了很多成本。友盟统计SDK同时也能收集 APP 的崩溃信息，在产品上线后帮助我们第一时间发现问题，快速定位问题，而我们开发人员要做的就是快速的解决问题，提升用户体验。SDK集成
以下以学宝APP iOS 端为例，示例在日常使用 U-APM 发现与解决 BUG 的流程。首先没有账号的要注册一个友盟账号，创建你的应用拿到 appkey。如果你是第一次集成，推荐使用Cocoapods 来集成，然后在你工程的 Podfile 文件添加以下内容，最后在终端进入工程的根目录，执行 pod install 命令。因为 UMAPM 依赖 UMCommon 和 UMDevice 组件，所以要放进去。 第一次集成建议加上UMCCommonLog，通过查看控制台的日志确认是否集成成功，成功后就可以移除出了。
pod 'UMAPM', '~> 1.4.2'
pod 'UMCommon', '~> 7.3.5'
pod 'UMDevice', '~> 2.0.4'
pod 'UMCCommonLog', '~> 2.0.2'
在 AppDelegate.m 文件中引入头文件 #import ，只需要一行代码，就可以把U-APM 成功的集成到工程中。如果集成了UMCCommonLog 组件，加上 [UMConfigure setLogEnabled:YES] 在控制台查看log，这样就很简单的完成了U-APM的集成.
[UMConfigure initWithAppkey:@"xxxxxxxx" channel:@"App Store"];
[UMConfigure setLogEnabled:YES];
U-APM 默认开启 Crash监控、卡顿监控 、启动监控、内存监控和 OOM监控，也可通过控制属性值关闭一些功能，根据自己需求来。
[UMAPMConfig defaultConfig].crashAndBlockMonitorEnable = YES; // crash&卡顿监控
[UMAPMConfig defaultConfig].launchMonitorEnable = YES; // 启动监控
[UMAPMConfig defaultConfig].memMonitorEnable = YES; // 内存监
[UMAPMConfig defaultConfig].oomMonitorEnable = YES; // OOM监控
整个接入流程十分简单 更多方式以及问题课跳转到官方文档 https://developer.umeng.com/docs/193624/detail/194595 ?&utm_source=w_MKT_dswz_dxf_wz解决问题
可根据版本、时间、设备等多维度过滤出如下错误列表。
以一个常见数组越界的Crash举例，这是一个非必现的BUG，在自测和测试同学测试期间都没发现这个问题，上线后再 U-APM 后台收到多条记录。
Application threw exception NSRangeException: * -[__NSArrayM objectAtIndexedSubscript:]: index 2 beyond bounds [0 .. 1]
开错误详情页，可以看到发送同样的问题都统计在这里了，根据行为日志，看到崩溃前浏览的最近10个页面，就知道用户走过的路径，知道大概在哪个页面发生的。
虽然知道在哪个页面闪退，但是这些还不够，一个页面可能会有多个子页面，如何知道具体哪个类和哪一行，就需要我们再上传符号表。在我们打包的 Archive 文件中找到dSYM文件拷贝到桌面，然后点击错误明细右边的符号表管理，上传拷贝出来的dSYM文件。
上传成功后，无法立马看到解析结果，需要几分钟的解析，通常五分钟左右就好。
解析好之后就很明确定位到具体的哪个类哪一行。在touchesBegan:withEvent: 有一个数组取值操作未做安全校验，加上就好。
总结
年初在升级友盟统计 SDK 的时候，发现收集 Crash 的功能，已从友盟统计组件中抽出来，并做了重构独立成一个组件，并多维度进行收集闪退日志，在错误明细里列出最近 10 个页面路径功能太棒了，非常有利于去复现这些问题。
作为开发人员，在写逻辑要细心严谨的同时，也要借助一些辅助工具，收集没有考虑到的 Crash，提升APP稳定性。针对移动端，友盟 SDK 以及一些列工具是一个不错的选择，在节省人力的同时也能节省成本，在使用中遇到一些问题客服的响应速度也是真快，可能是国内目前唯一一家SDK经常维护更新，还有客服的商家了，而且还免费。小的建议
U-APM 正在迭代，作为深度用户，在使用中也会遇到一些不顺手的地方，虽也不影响使用，但是相信大家都一样的感受，还是期待能优化一下下面问题。 1、进入 U-APM 面板能默认展示最近24小时的崩溃数据，而不是最近一小时的数据
拿我们自己举例：我们用户活跃时间集中在夜晚七点到九点之间，如果某天早上到工位后我来查看APP崩溃情况，点进来后据可能是0，需要再去筛选一些，如何不是联调或者灰度的时候，正常来说这个默认一小时意义不大。
2、崩溃信息详情面板机型和和使用时长能够直观一些
如下图，在错误明细里 iPhone10,3 对应日常熟悉的型号是iPhone X，如果不去查一下资料是不知道 iPhone10,3 是具体哪一款型号，这里更希望看到的是常见型号类型。
有时候想去了解用户使用时间的时候，在看到 6345s 的时候还是要打开手机的计算器去换算一下。期望时间超过一分钟小于一小时的转换成分钟（比如：3分钟、20分钟），超过一小时小于一天的时间转换成小时（比如：23小时48分钟），超过1天的就显示天数（比如：3天 10小时 ）。
3、能够支持自定义的错误
有一些问题不会导致崩溃，但是用户看到的就是有问题的，可能是后台返回的个别数据有问题，这个时候就有来自定义错误这个需求。就像示例中解决数组越界的问题，后天返回的字段中本应该有两个长度一样的数组，但是是因为个别数据录入导致问题，导致返回的数组大小不一样。
4、解决 iOS 新项目中集成 SDK 时闪退问题
用Xcode 11 以上版本新建一个工程， 集成 SDK 运行直接闪退了。当然有经验的搜一搜也能很快解决，但是对一个刚接触的新手来说这个闪退还是挺突然的，期望能在文档中说明，更好的方案是能在 SDK 内部做兼容修复。
作者：杜鑫峰