本文是对蚂蚁金服技术专家洪峰的采访。洪峰先生将在QCon上海2019分享《支付宝App移动研发的实施实践》，欢迎关注。

微软MSDN上的一篇文章有​​这样一段话：“移动应用程序的理想环境需要满足两个条件，一是可以知道客户脑海中立即出现的需求，二是为满足这些需求而编写的代码对于这些客户来说，简单地说，客户的需求、开发和交付之间不存在任何差距。”

本段提到的移动应用开发的理想环境是可以满足的。因此，一些超大型APP的研发模式，尤其是项目式研发协作、多模块研发的APP，已经开始慢慢研究体系。那么，移动构建和网页构建有什么区别呢？移动施工有哪些难点？移动如何面对新技术的冲击？ ……为了回答这些问题，我们采访了蚂蚁金服技术专家洪峰。

移动和网络

近两年已经成为企业软件研发的主流，被很多企业所采用。相关的实践分享也很多，但大多集中在网络上。相比之下，移动端的实践分享相对较少。

之所以会出现这种情况，是因为Web拥有更加稳定的执行和验证环境，所有的开发、验证、交付等流程通常都可以直接在服务器上执行。移动最大的问题是移动应用没有稳定的验证环境。大多数移动应用程序可以在多个设备上使用，这意味着要处理各种技术规格、操作系统版本、屏幕尺寸等。目前有两种主流的移动操作系统，即iOS和iOS。其中，他们以孤立的方法而闻名。每个设备制造商都创建了自己的操作系统。现有的设备有很大不同。 iOS也有多种变体，现有设备的操作系统版本也多种多样。此外，移动应用还具有人机交互的特点，比如目前流行的扫码、人脸识别等技术。那么如何在移动动作过程中尽量减少人工干预，让整个事情变得更加流畅，提高整体的研发效率，这是我们要思考的。

虽然移动建设存在一些困难，但移动开发其实和移动开发是天生契合的，因为客户端开发，尤其是智能终端，是一个新兴领域。技术的迭代更新比较快。再加上终端产品的特殊性，如无法实时回滚、降级等，因此客户端产品的核心建设主要集中在研发协作、研发效率、新技术落地、质量保障等方面，与建设目标不谋而合。

除了是否适合移动开发之外，相信很多人都会关心什么时候构建。 Ryuk认为：“主要目的是提高整体研发效率，因此应用它的最佳时机是当公司业务发展有多个业务并行发展，规模达到数十人时。”因为这个时候，公司的研发效率和质量就会成为瓶颈。为了突破这个瓶颈，很多员工会投入工具研发，实现一定程度的自动化。难免会有大量重复造轮子的工作。这时候建设统一关闭就可以了。避免重新发明轮子。”

支付宝移动建设

与企业的发展密切相关。没有业务场景的空谈就是空谈，所以支付宝的建设只有业务发展到一定阶段才开始。

Ryuk介绍，支付宝的技术和业务发展大致可以分为以下几个流程：

一个仓库，一套代码，然后是工具化和组件化，最后是动态生态和智能。早期，开发人员数量可能只有个位数，业务功能并不复杂。这时候，几次开发、几次测试就可以完成整个研发。这时建设的投资远远大于产出，就没有建设的必要了。

随着业务的快速发展和客户端技术的爆炸，支付宝也实现了组件化、模块化技术。此时，研发人员数量已达到数十人。人与人之间的沟通和协作以及质量保证都发生了变化。非常困难，也是在这个时候进行统一建设的。

早期，一个代码仓库、一套代码的模式，随着代码量的增加，带来了很多问题，包括相互耦合严重、一次编译构建时间过长、以及当时的业务发展等。带来的线上问题需要在线修复能力，因此支付宝开发了自己的模块化解决方案，实现模块隔离、提前编译、动态更新等能力。

在建设过程中，支付宝主要关注三个方面：研发协作、研发效率和质量保证。

以质量保证为例。当代码量从一个仓库增长到数百个仓库、数百万代码时，简单的单一测试或黑盒测试已经不能保证整体质量。因此，Ryuk团队分析了支付宝的业务特点和业务场景，结合支付宝的技术框架，进行了深度定制开发，实现了很多静态和动态的质量保证能力。其中，静态质量保证能力包括定制化的静态代码分析、依赖分析等，动态质量保证能力包括真机性能稳定性测试、用例记录和回放等。

作为最终产品的生成者，支付宝团队也承担了构建工作，因为大型APP对于性能和包大小有着极致的追求，每一点性能的提升和包大小的减小都可能直接影响用户留存。通过深度构建挖掘，支付宝团队开发了文件重排、代码重排、删除等构建技术，并通过线上灰度逐步验证，直至最终正式上线。

移动施工难点

研究总监Wong曾在博客中指出：“并非所有公司都会使用它来进行移动开发。根据调查结果，只有42%的实施者表示会使用它来支持移动应用程序开发。”为什么在移动应用开发场景中实践的少之又少？

Ryuk认为，主要原因在于投入产出比。除了超级应用外，大多数移动应用都是小团队、小步骤开发的。开发人员和测试人员很少，几乎是个位数。但由于移动应用的特殊性，要实现自动化用例测试、真机测试等CI能力​​，往往需要比较大的人力和资金成本，如建立实验室、购买大量终端等设备，并安装全套自动化系统。构建等。相比之下，小型应用程序并不是很复杂。大多数场景下，可以通过开发人员和测试人员的单元测试、手动用例编写和测试来保证应用程序的质量。

在移动的具体建设中，Ryuk认为存在以下难点：

首先，移动应用技术栈碎片化。和iOS是两个完全不同的技术栈。如何统一两个技术栈的研发流程是一个挑战。支付宝的解决方案是抽象出一个移动研发模型，比如统一抽象模块化构建、统一依赖管理模型、统一迭代研发流程等，具体区别放在各个模型的实现路线上。例如，模块构建将通过路由配置配置到服务器，iOS模块构建则通过路由配置到Mac物理机。

其次，移动应用的验证非常复杂，尤其是支付宝的百万级代码，是上千人开发的。每次代码更改都会影响大量代码和功能。在代码层面，支付宝通过深度编译和自研深度定制的框架层代码扫描和依赖分析能力，精准追踪每次变更的影响，并通过评估体系控制每次变更带来的风险。在真机验证环境中，支付宝拥有一套完整的真机实验室，全面监控移动应用的整体兼容性、稳定性、性能等。

第三，持续集成也是移动建设的难点之一。持续集成需要快速、稳定的反馈能力，所以在持续集成节点上，支付宝选择了单点突破，做了很多优化，比如构建性能等； UI自动化测试方面，支付宝搭建了自研实验室和定制硬件，从而支持更多设备，提高稳定性和吞吐量；面对集团内部各种验证服务能力的对接，我们还借鉴了行业CI、CI等CI工具，开发了自己的CI编排工具，为开发和测试同学提供超高的体验；任务执行 DSL 我们直接使用，无需重新发明轮子。

另外，近年来移动应用新技术的发展非常迅速，比如生态、以及最近流行的华为方舟编译器和鸿蒙系统。对于移动来说，由于很多场景都是基于技术场景和技术层面定制的，因此新技术的出现对生态和技术选择影响较大。

为了面对新技术的变化，移动施工需要将新技术的耦合部分和非耦合部分分开，以尽量减少影响。例如，在终端技术相关的质量工程方面，支付宝会提前进行预研和技术储备。比如静态分析领域，之前只有Java和OC语言。然而，随着小程序的出现，语言逐渐被使用。引入后，还会进行前端语言的静态分析和分析，保证整个客户端产品的质量；在与终端技术无关的方面，会有相关的团队协作能力，包括需求管控、分支管理、依赖管理等。 、人事管理等