作者简介

辛贵，携程无线研发总监。主要负责App基础框架研发相关工作，关注App开发框架、性能、质量、效率和新技术。

1、背景介绍

APM全称为Application Performance Management，即应用性能管理，对于一款成熟的App，各项性能指标的监控是必不可少的。公司内部早前有个1.0版本的APM系统，主要存以下问题：筛选功能薄弱、缺少日报和告警功能、功能混杂、且只支持单一App。鉴于以上问题，我们发起了APM2.0版本的重构，在开始之前，我们重新梳理了APM的定位，以及该做哪些功能。

最终，确定APM定位为数据报表+性能日报+监控告警+排障入口，具体如下：

• 数据报表

• • 端到端精准数据报表

  • 多维度筛选功能支持

  • 多App报表支持

  • 实时报表

• 性能日报

• • 核心性能指标提供邮件日报功能

  • 支持订阅功能

• 监控告警

• • 适合告警的核心指标，进行告警

  • Crash率，JSError等告警

• 排障入口

• • 支持多维度的异常数据、错误数据采样

  • 采样数据和内部系统打通

功能模块上，主要包括网络性能、页面性能、崩溃卡顿和专项性能四部分，下面章节会继续介绍。

2、主要功能

2.1 网络性能

网络请求性能是App的核心性能指标之一，APM平台以端到端的数据为基准，进行性能统计，这样最能反映用户的真实感受。

2.1.1 网络架构模型

如下图所示，App中的动态网络请求，都是通过自研的网络通讯框架发送到后端Gateway，Gateway再将服务转发给真实业务服务器。

几点简单说明：

• 网络通讯框架和Gateway之间会通过TCP长连接进行通讯；

• 网络通讯框架和Gateway之间数据协议为自定义契约格式协议；

• 网络通讯框架可以将HTTP协议转换成自定义协议进行代理转发；

• Gateway本身业务逻辑较少，只负责链路管理和请求路由转发，为了让用户有好的体验，我们做了全球部署；

• 所有动态请求都通过网络框架发送，在这个点做好采样埋点，即可为APM报表提供精准数据源；

2.1.2 错误监控维度

端到端的网络请求异常数据，大多数是发生在链路的建立和数据传输上。由于我们是自己管理的TCP链路，因此对请求链路的可控性更加强，我们梳理了整个请求链路，对整个链路上存在异常的点，都定义了对应的code。参考下图：

主要以下code：

Code	定义	说明
-202	请求序列化失败	极小概率出现
-203	无可用链路	比例较高，无法连接到服务器，即为常见的网络不稳定
-204	发送请求失败	socket send失败，极小概率
-205	读取响应出错	链路异常，读不到指定长度的响应头
-206	响应反序列化失败	极小概率出现
-212	链路异常断开	包括客户端网络异常和后端主动断开
-213	读取不到响应	比例较高，即为常见的超时

以上错误code，主要是聚焦在自建TCP链路层面的异常，对于标准的HTTP Error，比如HTTP的4xx，5xx也会记录，一般出现这些错误的时候链路本身并不会出现错误（限TCP通道）。

2.1.3 监控的维度与目标

主要监控端到端请求的成功率和耗时两个数据维度。

• 请求成功率

• • 计算方式：请求成功次数/(请求成功次数+请求失败次数)

  • 目标 - 用户交互场景：目标99%+

  • 目标 - 整体平均：目标98%+，包含启动、后台场景的请求，这部分请求成功率相对较低

• 请求耗时

• • 计算方式：客户端发起请求为起始点，收到响应并序列化完成为结束点

  • 目标 - 用户交互场景：后端处理耗时+300ms(RTT时间)

2.1.4 APM报表

下面几张截图是网络性能模块设计的报表：

上图是分版本，业务部门的性能概览数据，蓝色的字体，都是可以点击进行过滤筛选的。

上图是按照具体服务号，列出该服务的成功率、总耗时、服务端处理耗时、样本量、还有错误code分布。

每个表格后面都有一个采样功能，点击该按钮，即可进行采样，选择一批错误或者是耗时较长的设备ID，点击设备ID，可以跳转到内部排障系统，查看更多详细信息，进行整个问题的排查。

上图是内部排障系统中的一个小工具，可以根据一条链路ID来把该链路上的所有请求有序排列展示， 这对于日常排障非常有帮助，可以极大的提高网络问题的排障效率。

2.1.5 性能优化实践

以下是我们在进行端到端网络性能优化过程中的一些实践经验，简单介绍几个效果较好的优化方案。

• 自定义通讯协议 使用自定义通讯协议，自管理链路，可以对请求中的每一个环节都做到完整的控制，对于故障排查和后续的性能优化会更加有价值。

• 合理选择ServerIP 实际上包含两个场景的serverIP选择，一个是App刚启动时候默认使用的ServerIP，另一种是Server端下发适合的ServerIP之后的使用策略；几点经验， 国内场景，同一运营商效果较好，海外场景，服务器在海外部署，比通过加速通道回到国内源站效果要好，启动场景，根据timezone选择ServerIP比较合适；

• 合理设置超时时间 超时时间设置过小，比如3s，成功率会比设置成15s的明显要低，所以可以根据服务的时效性，合理设置超时时间；

• 支持重试 符合幂等性的服务，设置可以重试，可以大幅度提升成功率；

2.2 页面性能

2.2.1 页面性能统计方案

页面性能是关系到用户替换最重要的性能指标，如何去度量一个页面的性能，是没有一个通用的标准的。

一般在收到统计页面性能需求的时候，开发人员最常规的做法是在页面初始化的时候，设置一个时间点，然后在渲染所需的一个(组)服务发送完，页面渲染之后，设置一个结束点，两者相减，就是页面的可交互时间。

这种做法的统计是准确的，但是需要每个页面都去做这个逻辑，对于一些复杂页面，对于不同的业务逻辑，需要做多套这样的性能埋点处理。且后续随着业务的迭代，性能统计的逻辑还需要确保没有问题。

对于业务开发来说，这无疑是大大增加了工作量，我们希望能有一个框架层的方案，去统计页面渲染完成或者是可交互时间点(Time To Interactive)的性能，以便让业务开发人员从性能埋点中解放出来。

首先考虑到了页面截屏+像素点检测的方案去检测页面渲染完成时间点，思路如下：

• 页面截屏，按照一定比例，去掉头部+底部部分

• 将中间部分分隔成6块

• 每个小块随机取点，检测像素点的相似度

按照这个思路实现并灰度上线了这套检测方案，基本准确的检测出页面渲染时间，但是也存在一些问题：

• 性能损耗严重，每次截屏时间100ms

• 对于一些骨架屏类的页面，会被当做页面渲染完成

• 因为是随机取像素点，对于简单页面，页面检测的次数有一定的随机性

由于以上问题，这个数据上线之后，没能推广给业务开发同事去使用。继续优化，我们发现：

• 页面渲染完成的时候，一般都有文本

• 文本扫描的性能损耗比页面截屏低

在这两个观点支撑下，我们对检测方案做起了重构，将页面截屏+像素点的随机选取，替换成页面组件扫描+文案检查。大致流程如下：

• 页面初始化开始，遍历页面所有元素，检测text

• 如果text所在坐标在页面头部(20%)/尾部(25%)区域，忽略 Text >= 2组， 认为检测成功

• 一轮检测之后，未检测成功，等待50ms进行下一轮检测

• 总共检测10s，否则超时

以下视频是我们检测的demo，三个页面分别不同的技术栈，Native/CRN/H5, 可以看到，基本都是在内容加载完成的时候，toast弹出来提示页面检测完成。

该方案虽无法确认页面内元素是否完全渲染完成，但可以确定页面已经有内容，用户可以进行交互。所以我们将文案检测成功的时间点当做页面可交互的时间点，以此来作为页面的TTI（Time To Interactive, 后文使用TTI缩写）性能。

2.2.2 页面性能报表

上线之后，我们看到APM报表的数据，能比较真实的反映页面性能。

下图是APM平台上的页面TTI性能报表，支持多维度的筛选过滤，也支持采样功能。

对于每一个（组）页面，还能显示页面的TTI耗时分布，这对业务BU进行性能优化非常有帮助，简单相加就可以计算出页面TTI性能的95线，90线耗时。

在TTI性能表格的第一列，有一个页面类型，我们给每一个页面一个类型，每种类型设置一个TTI性能基准，TTI性能如果在基准之内的，显示绿色，超过基准20%的，显示红色，表示需要优化。以下是我们定义的基准，业务部门研发同事的页面性能优化以此为标准。

2.2.3 页面TTI性能优化

在配合业务团队研发同事进行页面TTI性能优化的过程中，积累了一些经验和优化方案。

• 主线程耗时任务异步化

• • 将一些耗时，且在主线程操作的任务，调度到后台线程异步执行，可提升页面加载性能

• 网络请求prefetch可大幅度降低页面TTI时间

• • 网络请求预取，即在页面跳转之前，将下一个页面需要的数据，预先获取回来，进入页面时候，只需要使用已经获取到的缓存数据

  • 可以大幅度提升页面性能，机票，酒店列表页面采用之后，页面TTI性能够有约40%左右的提升；

• 预执行下一页面必须执行的任务

• • 对下一个页面必须执行的任务，在当前页面提前执行掉

  • 在下一个页面会下载离线包，优化为在当前页面下载下一页面可能使用的离线包；

• CRN框架层的一些优化

• • 如果有使用ReactNative框架的话，强烈建议升级到0.61及其以上版本，并在Android平台开启hermes引擎；

  • RN提供的接口，大多是异步的，但异步接口在首屏加载，通讯频繁的场景，耗时不可控，可以换成同步API；

• PreRender

• • 简单来说就是延迟页面跳转，利用延迟的时间进行页面的加载；

  • 只要延迟时间控制的好，对用户感知来说，就是页面在平滑的切换；

2.3 崩溃卡顿

崩溃卡顿系统，和大家常用的崩溃采集系统基本一致，这里不过多介绍。经常有用户投诉说遇到了闪退，但工程师在后台Crash收集系统里面却搜索不到对应的Crash日志。

技术的角度来说，是可以理解的，因为没有哪个Crash收集 SDK能够捕获所有的Crash，即便是操作系统也有一些不能捕获的，在iOS上也经常遇到App Crash之后在系统的设置里面，找不到对应的Log。

2.3.1 用户行为Crash

为了辅助统计用户遇到Crash的情况，我们在App启动的时候，去检测用户上次使用过程中是否有遇到Crash，如果有则上报上来，再开发成如下的用户行为Crash报表：

判断用户是否有Crash策略大致如下：

• 启动App或者页面切换时候，持久化页面信息；

• App被切换到后台时候，清空掉持久化的页面信息；

• 启动App时候，检查上次的页面信息，如果上次页面启动时间和当前时间相差较短，则认为出现了Crash；

以上方案不能完全准确的统计用户是否遇到Crash，有些Case无法捕获，但多个版本纵向对比还是有意义的, 且随机采样几个用户行为进行分析，发现确实有Crash出现；

2.3.2 自定义异常上报

在开发过程中，经常会有各种Exception需要处理。大多时候开发人员直接将exception print出来，不做其他处理，也有部分Exception的处理需要单独埋点，后续再开发报表，这样做是比较严谨的，但是工作量偏高。

为了解决这些问题，我们提供了logException的API，以及如下的报表，方便开发人员直接上报Exception。上报之后，APM的报表会按照title(图中的Category)和subTitle(图中的Message)两级的方式组织报表，并提供采样功能，方便问题的排查分析。

3. 总结

本文主要介绍了我们为了监控App的网络性能、页面性能和稳定性这三个核心性能指标而开发的APM系统，实践下来，发现APM系统在以下几个方面对比较有价值：

• 让我们对线上App的实际运行的性能数据有了更加清晰直观的了解；

• 各项核心指标的监控和性能日报对线上App的稳定运营提供保障；

• 为我们各项性能优化提供了标准和数据支撑，按照标准去优化，优化之后有报表数据支撑；

• 推动业务开发团队进行性能优化，让业务开发团队更加重视自己的产品性能质量；

本文介绍的只是APM系统的核心部分，实际上还有大量定制功能无法一一展开，比如告警和性能日报、自定义报表、各类专项性能等。希望我们在网络性能、页面性能和稳定性方面的实践经验对大家有所启发。

注：“携程技术”微信公众号后台回复“apm”，可下载讲师分享PPT。

【推荐阅读】

• 近万字长文详述携程大规模应用RN的工程化实践

• Node.js在携程的落地和最佳实践

• 携程 Trip.com App 首页动态化探索

• 加载速度提升15%，携程对RN新一代JS引擎Hermes的调研

• 《携程技术2019年度合辑》，送给爱学习的你

 “携程技术”公众号

  分享，交流，成长