【导语】面对移动端应用研发的一系列技术挑战，饿了么开启了移动基础设施的建设工程实践，以应对未来在移动端所面临的变化以及更多的挑战。本文作者从用户体验分级、基础设施概念与建设等方面着手，细谈饿了么移动基础设施建设的实践。

引言
自 iOS 及 Android 操作系统面世以来，移动端的浪潮以极快的速度席卷了整个世界。而在这样的时代演进过程中，技术的不断进步和创新给移动端的开发者们带来了一次又一次的挑战，比如不断增长的日活用户、不断刷新的版本分布、不断碎片化的机型分布以及不断碎片化的操作系统分布等。其中，随着日活用户的不断增长，微小概率的闪退使越来越多的用户在体验上大打折扣。同时， App 版本分布的不断增加亦加剧了代码的碎片化，致使功能管理愈加复杂。

另一方面，手机型号与操作系统版本增多，也给移动端开发者造成了不少困扰。特别是 Android 平台，由于其开放性，导致了大量专项开发与优化，增加了代码管控的难度与复杂度，这也给移动开发者提出了更高的挑战。

面对这一系列技术挑战，饿了么开启了移动基础设施的建设工程，以应对未来在移动端所面临的变化以及更多挑战。本文将从以下几个方面细谈饿了么移动基础设施建设的实践：

• 移动端用户体验的分级；
• 移动基础设施的概念；
• 饿了么移动基础设施的建设实践。

移动端用户体验的分级
在这样一个以用户体验为王的时代，追求极致的用户体验往往是产品经理们追逐的最高梦想。因此，更简化的流程、更炫酷的动画总是成为每次产品更新迭代的主角，从不会褪去其“No.1”的光环。

然而事实上，App 和过去 Web 时代的产品有着分明且本质的区别，比如用户更新意愿低、存在故障时难修复、视觉要求更高等。因此，在这样一场追求 App 极致体验的战争中，移动端的程序员兄弟们也应该是并肩作战的团队成员之一。因为技术上的用户体验，重要程度其实并不亚于以上的主角。

Level 1 能用
“能用”是每个用户对于使用 App 最基本的诉求。但当我们钟爱的 App 在使用过程中遇到诸如内存访问越界等特殊异常时，它往往会表现出一种最让我们反感的现象——闪退，移动端工程师们称之为“Crash”。

这种让 App 完全无法使用的情况是用户最为恼火的场景。因此，如何最大限度地降低 App 的 Crash 率便成为了移动端技术人员们追求的用户体验最高核心。一款无法稳定运行的 App 当然无法得到用户的青睐！

Level 2 可用
“可用”，来自为用户提供稳定可靠的服务表述，这是比较容易理解的。设想一下，当我们正在选择美食时，却提示网络不可用；又或是页面上的菊花转了一分钟也没有出现想要的菜单，这些都会让我们对这样一款 App 产品失望。然而，“可用”却又是比较难实现的一个等级。当用户量少、业务简单时，网络的流量并不会对服务器端造成过大压力；而随着用户量的增长，不同地域、运营商、网络环境的一点点小的抖动，都会导致用户网络请求的不确定性。

因此，如何最大限度地保障网络数据的稳定性，让我们的 App“可用”，是每天都在面临的挑战。

Level 3 好用
当我们的 App 达成了“能用”和“可用”的体验后，便来到了第三个层次——“好用”。

与前两者体验需求的不同之处在于，“好用”除了在产品上要求流程简单便捷外，同时也对动画效果提出了更高的要求。在技术上这往往表现为每秒刷新的“FPS”帧率达到一定数值，页面切换无卡顿感，同时 App 能够在第一时间响应用户的触摸操作等。

“好用”是对产品经理以及应用开发者在页面性能优化上的极致挑战，是一个长期追求，并不断努力的终极目标。

移动基础设施的概念
在以上的用户体验分层概念中，我们可以看到，这种用户体验的提升是不断打怪升级的战役，自然也少不了坎坷。在很长一段时间内，由于缺乏相应的测试和监控工具，App 端的问题一度只能通过后端监控来推断。
为了更好地应对这样一系列与 App 相关的问题，我们提出了建设移动基础设施的构想。本节先来谈谈什么是移动基础设施。

我们都知道，一款 App 的研发流程大致可以总结为：

• 产品提出设计原型，UED 设计好视觉效果稿；
• 工程师针对设计稿件进行编码、Debug，完成开发；
• 工程师将开发好的程序进行打包、发布；
• App 产品正式上线并发布。

而在最近几年，随着 iOS 和 Android 的技术进步，又出现了一系列线上热修复技术，因此在以上的 App 研发流程中再添一员——“HotPatch 修复”。

再简单一点，可以直接归纳为：产品→开发→发布→线上→修复。

而移动基础设施（Mobile Infrastructure，我们称之为“Minfra”）提供了除产品流程以外的一整套 App 研发管控的 SaaS 服务，即涉及开发、发布、线上和修复的全生命周期管控平台。

饿了么移动基础设施建设的实践
饿了么移动技术团队在面对以上流程时，搭建了名为“Grand”的总体管控平台，并分别建立相应的管控模块来进行保障工作。接下来将分模块谈谈每个流程的具体细节。

持续集成
持续集成是每个互联网公司基本都会部署的一道开胃菜，通过代码仓库的“Webhook”操作来自动触发一次编译构造，从而快速定位该代码集成是否会导致整个项目崩溃。这一步，是一项“掌控代码”的操作。

对于持续集成的平台搭建来说，业内最常用的便是“Jenkins”。通过简单的“job”配置就可以轻松跑起一款 App 的持续集成。同时它还具备强大的可扩展性、简便的集群管控能力。也正因为这些优点，我们最终选择了“Jenkins”。

然而在饿了么，由于 App 数量众多，且随时可能会有新的 App 成员加入。于是乎，在这样一种业务场景下，为每款 App 都单独进行一次自定义配置就成了奢望。如何使用一个“job”就能让所有 App 都跑起来，是我们首要解决的问题。

得益于“Jenkins”平台的高度可自定义性，我们使用自己的 Python 脚本完成了持续集成的管控工作（如图 1 所示），同时使用“Grand”平台实现前端状态的监控工作。每款 App 使用一个预定义好的配置，来配合脚本内预定义的不同打包行为，最终汇总结果于“Grand”平台。

持续集成平台的搭建，让团队合作的代码最终趋于稳定状态。完全自定义的脚本代码，让未来“静态代码检测分析”、“自动化测试平台”的加入成为可能，真正实现了对代码的掌控。


Release
代码已经 OK，功能也已完备，接下来就是接受千万用户检验的时刻了。在此，“发布”这个看起来最寻常、最微乎其微的功能服务，却是发挥极大作用的功臣。我们前面提到，由于用户量巨大，99.99%的 Crash 率也能给成千上万的用户带来困扰。为了最大限度地减少这种困扰，一个具备“灰度发布”的服务被赋予了非凡的意义。


通过向特定的手机、城市甚至人群发送升级提醒，让部分、少量的用户升级至新 App（如图 2 所示），以观察这部分用户的 Crash 率成为了我们防止大规模 Crash 最主要的解决方案之一。在灰度的过程中，一旦发现 Crash 率快速上升，则可通过关闭“发布”渠道来防止事态的进一步升级，让“能用”这一用户体验等级得到掌控。

看到这里，一定有读者会产生疑问，对于 Android 操作系统而言，以上方案或许可行，但对于 iOS 是否有更加可行的方案？

的确如此，对于 iOS 平台而言，由于 App Store 的存在，往往很难达到灰度控制的目的。事实上，如果有条件的话，可以适当地采用 iOS 企业版来做灰度。不过这种方案并不被推荐，企业版也不是为该种目的而生，所以我们也并未完全采取这种方案。

另一种 iOS 的灰度渠道方案，则是在各大越狱社区进行分发，同样可以绕过某些监管。当然，由于安全性原因，也具备一定风险。因此，如何取舍还是得看读者自己衡量。

HotPatch
上文提到，在我们的 App 发布过程中，一般会让部分用户进行升级，通过观察其 Crash 率来决定是否最终全量该版本。在过去，这部分用户被“牺牲”后，如果其不主动再次升级自身软件版本，阴影将永远笼罩在他们的头顶。然而数据告诉我们，移动 App 用户的主动升级率一直处在低位，因此总会有这样一些用户不断被这团阴霾所困扰，最终选择离开我们。

在这种历史情景下催生的“HotPatch”技术，拯救了一大批这样的 App 用户，同时也拯救了在移动端默默奋斗的程序员们。只需通过“HotPatch”服务有针对性地下发修复 Bug 的 Patch 包，就能达到降低 Crash 率的目的（如图 3 所示），从而很好地提升用户的基本体验。也就难怪该项技术出现后，各大厂商都趋之若鹜。


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

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

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

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

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



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

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

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

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

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