我们通过提供“持续集成”、“Release”以及“HotPatch”三项服务，使用掌控代码、掌控灰度以及掌控闪退的方式，来避免技术原因所造成的闪退，让用户体验的第一维度——“可用”，这一最基本的诉求得到了满足。

　　对于用户体验的第二维度，在去年一个很火的词——“APM”，让其成为了可能。

　　APM

　　在用户体验第二维度的世界里，网络问题是最主要的问题。事实上，网络问题归根到底也基本就是两个问题——网络延迟与网络错误。

　　在没有移动 APM 基础设施之前，遇上网络问题时，基本只能求助于后端的监控系统。但当用户的请求并未到达我们自身的 IDC 机房时，比如因运营商劫持、某省网络抖动等产生的延迟和错误，大多只能靠经验或猜想来解决。这时如果能从 App 端的视角来看待其发生的网络情况和问题，就能更有针对性地了解其产生症状的根本。

　　为了达到收集每款 App 所有网络请求的目的，我们采用了移动端的“AOP”技术，来获取该 App 中发生的每个网络请求的时间信息。这些时间主要包括网络协议栈上的“首包时间”、“DNS 时间”、“TCP 时间”、“SSL 时间”和“请求时间”。当然，我们也同时获取网络层的错误信息，主要包括 HTTP 层的网络错误码，以及网络链路层的错误代号。

　　图 4 服务响应数据一览

　　分析以上网络数据中的各个时间序列，基本能够了解从用户设备到机房的各项网络时间，从而更方便地确认导致用户网络请求缓慢的原因是来自于网络的延迟，还是后端的响应超时。如果后者是主因，还能再通过该请求的唯一标示符去查询后台的监控系统，追本溯源，最后有针对性地优化与解决。而通过上面的网络错误码，可以在第一时间了解用户端大量发生的网络链路问题情况，为服务器端出现的问题提供宝贵的数据支撑（如图 4 所示）。

　　通过“APM”的网络层错误的收集，可以实时发现某个域名主机所发生的问题。这时，如果能同时结合该域名主机的响应时间，以及后端的监控系统，便能够达到整条网络链路监控打通的目的，让每一次的服务请求都有迹可循有源可溯，真正做到让我们的 App 能够持续地“可用”。

　　俗话说得好，没有度量就无法提高。网络监控提供给我们的数据便是提升用户体验最好的度量，让我们能够持续不断地提升“可用”服务的质量。

　　未来

　　现在，我们的 App“能用”、“可用”，那么如何更进一步让它“好用”？这便是我们接下来所追求的最终目标。我们设想，如果能够实时了解 App 用户在使用过程中的各项流畅度体验数值，就可以在接下来的版本中有针对性地对相应的功能进行优化；同时，如果能够了解到我们的用户在研发实验室中没有的机型以及 OS 版本上的各项数值，也就可以帮助我们的研发人员有针对性地对该机型或操作系统进行相应的优化，从而提升用户的流程度体验。

　　另一方面，更好的代码质量检查也是“Grand”接下来所需进行的工作之一。且随着我们移动自动化测试平台“Stellar”的研发和加入，相信“Grand”会在不久的将来，能够成为综合一键打包、发布、自动化监控和告警的智能移动基础服务平台。

　　作者简介：王朝成，饿了么移动技术移动基础架构组负责人、移动架构师，负责饿了么移动技术的远景规划、技术架构选型、外部技术方案评估等工作。目前关注领域包括移动端架构、安全、自动化测试及移动大数据等。

　　责编：唐小引，技术之路，共同进步。欢迎技术投稿、给文章纠错，请发送邮件至[email protected]。

　　声明：本文为《程序员》原创文章，未经允许请勿转载，更多精彩文章请订阅 2017 年《程序员》。