启动、内存、卡顿三大分析，用户体验就用它？

关注

发布于: 16 小时前

随着大量应用涌入市场加入“App 内卷之战”，终端用户们对应用质量的要求是愈发地挑剔。端上研发同学光关注崩溃类 bug 解决已无法应对用户对 App 体验的诉求，很多用户也会反馈与性能有关的问题，比如 App 启动时间太长、页面卡死、闪退等。随时线上用户诉求的提高，很多开发同学也从线下测试性能演变到更关注线上性能问题，以此保障用户体验。

友盟+应用性能监控平台 U-APM 从去年底免费上线后，得到行业众多开发者的接入和支持。友盟+也非常重视开发者面对应能监测的各类问题，在近几个月，基于原有稳定性功能优化的基础上，U-APM 又新增启动分析、内存分析、卡顿分析三大性能模块，全面助力开发者提升用户体验。

启动分析

启动场景是用户使用 App 的第一道关卡，启动慢、启动闪退都会直接从源头阻断客户使用，甚至会造成启动不成功新客户卸载的情况。很多技术团队都会以启动耗时作为重点性能监控指标。U-APM 中启动分析包含启动趋势、慢启动分析和启动崩溃分析三大功能模块。

启动分析支持通过预置采集和个性化自定义两种方式定义启动阶段，可以分别查询首次启动、冷启动、热启动的情况效果，并可以与设备、系统、版本、地域等维度做交叉筛选查询。

用户也可以分别对首次启动、冷启动和热启动设置慢启动的业务定义。一般情况下，热启动的时间要远低于冷启动、首次启动的时间。慢启动分析可以分别监控三种情况下的慢启动设备数量，以及设备系统分布等信息，并且支持单一设备定点查询启动时序，精准定位问题。

启动阶段的崩溃应当是日常开发中首要需要解决的问题，避免用户短时间遇到崩溃无法继续使用。启动崩溃分析中筛选出自定义的启动时限下的崩溃列表，更便于定位启动问题。

内存分析

U-APM 的内存分析提供线上 OOM 异常的监控与分析，帮助开发者及时发现与定位线上 OOM 问题。同时，提供 App 运行阶段内存占用情况，为应用内存优化提供关键指标数据。

在 Android 异常中，并不是所有的 OOM 问题都是可以简单查看错误摘要是否包含 Out of Memory 就可以判断的。

此次内存分析 OOM 异常的模块中，将内部沉淀使用多年的智能诊断技术对外透出。可以通过智能读取错误堆栈进行匹配，挖掘到那些不是 OOM 但实际是由 OOM 引起的异常问题并加以聚类，OOM 异常的判断率直接提升 20%～30%。iOS 应用此次也新增了 OOM 异常的捕获。

内存占用模块中展示了内存关键指标信息，并且配以设备情况分布用作统计参考。还提供了渠道、版本、系统、设备型号的分布情况。

卡顿分析

U-APM 中通过主线程的响应时间，将有卡顿体验的设备信息、卡顿日志进行上报。免费提供了 iOS 全部采集以及 Android 双端卡顿采集，且如此大量的日志数据不用按流量付费。

除此之外，如果开发者觉得一条条看错误堆栈非常麻烦，可以使用 U-APM 利用聚合算法提供了卡顿模块的功能，约等于 1 分钟看到 200 条堆栈的内容，有效节省开发者大量挖掘问题的时间。卡顿模块支持正序、倒序两种聚合形式：

•正序聚合：筛选影响用户量大的 200 个堆栈从栈顶到栈底进行聚合，帮助客户挖掘造成卡顿问题的最核心问题

•倒序聚合：筛选影响用户量大的 200 个堆栈从栈底到栈顶进行聚合，帮助客户挖掘造成卡顿问题的最核心问题

两种方法均展示出现频率前 10 的模块，子树深度最多支持 50 层，帮助客户下挖详细的卡顿模块信息

利用 OpenAPI 自助调用错误数据

U-APM 后台的错误数据在开发者日常的业务中还有很多的应用。比如，定期将应用质量数据灌入技术组周报中发给公司各部门，或者在公司自有后台中展示今日实时错误率等性能指标。此次新上的 OpenAPI 可以解决灵活获取应用采集的错误数据的需求，支持实时/离线 90 天内的数据灵活调用，免费开通权限即可使用。