支付宝红包已经当之无愧是一个国民级的应用，在除夕夜就有2.2亿人参加扫五福活动，扫一扫的峰值达到了22万次每秒。但这样一个国民级的应用，支付宝只用了6个人3个月不到的时间开发出来了。这期间这6个人还支持了3个大的项目。看一下项目时间表：

- 2016年10月份，开始立项，那个时候什么都没有，一穷二白，只是一个单纯的想法。

- 2016年12月份，只用了一个多月的时间就把AR红包做了出来，并且支持了双12扫四宝的活动。

- 2017年1月初，跟可口可乐公司合作进行可口可乐包装瓶上扫福娃的活动，

- 2017年1月底，支持了规模更大的春节扫五福的活动。

6个人，3个多月，开发完成了这样一个复杂的功能，这可能吗？ 更神奇的是虽然在这么短的时间里开发出来， 但没有任何影响用户使用的故障，这是怎么做到的？今天带着这两个问题一起来看一下。

如何快速开发高质量App

短时间内开发一个复杂的功能，听起来可能有点神奇， 但这只是支付宝移动项目的正常节奏，每个APP的开发周期和时间点都是这样，有的甚至更紧一点。这个项目因为涉及到春节红包，时间点相对还比较长一点。工欲善其事，必先利其器，支付宝的移动项目之所以开发得这么快，主要得益于底层开发框架和工具的支持。

首先，支付宝的移动开发框架支持模块化、大团队协作开发的模式。这里不得不先说一下支付宝框架演进的历史。在2012年刚开始的时候，支付宝只是纯粹的支付工具，当时这个团队只有几十个人，从架构来讲也就十几个模块，就是一个简单的单应用支付工具。

到了2014年，随着支付宝业务的高速发展，业务越来越复杂，用户也越来越多， 开发团队扩张了10倍，底层的系统也更复杂，几十个系统之间的依赖变得很难以维护，几百个人的团队之间的合作本身也很难管理。这时候怎么办呢？我们借鉴了更加成熟的服务端开发的经验，熟悉JAVA的人听说过OSGi开发规范，简单说就是可以把一个应用分割成不同的模块，然后OSGi框架来管理模块之间的依赖关系、生命周期等。增加一个新功能，就是增加一个独立的模块跟相应的松散的依赖配置，十分简单。这种使用场景也十分适合移动端的开发，当时就大胆的使用。之后效果还是很明显的，在这个开发框架下支付宝的这样一个应用，这些紧耦合的功能被切分成几十个独立、松散的模块，模块之间的依赖关系由框架管理。增加一个新功能就插入一个新模块，因为模块之间的耦合性是比较松散的，所以可以方便的支持大团队协作。在AR红包这个场景下，也不外乎增加一个新的模块，开发者只需要去完成AR红包的逻辑就好了，剩下的都交给开发框架完成。

到了近两年支付宝里面更是达到了几百个大的功能，因为支付宝现在已经不光是蚂蚁金服的支付宝，而是一个开放的支付宝，不仅支持蚂蚁金服内部的业务，而且要支持生态伙伴，比如说滴滴打车，但跨公司的技术合作比较复杂， 这对支付宝的开发框架提出了更高的要求，需要支持开放性、动态化。这个后面会详细介绍。

其次，支付宝积累了很多通用的组件，允许开发者像搭积木一样可以把应用快速搭建起来。上面介绍的支付宝在我们的框架中被拆成了不同的模块，有些模块的功能是非常通用的，比如日志埋点，这些通用的模块沉淀成了核心组件，供各其他业务模块使用。比如， AR红包里面很重要的扫码／扫物体功能就是一个核心组件， 通过一些简单的适配就可以支持AR红包了。除了扫一扫，支付宝还提供了其他一些功能强大的基础组件（见下图）。这些组件都以标准化的接口为其他功能提供服务，让开发者能够专注开发业务逻辑，这也是支付宝能够支持快速开发的另外一个原因。

另外一点跟AR红包相关性不大，但在一些场景下也能够提高开发效率，就是上面提到的支付宝开发框架的开放性、动态性。熟悉Native开发的人都了解， 再简单的功能, 用户量再少都要开发两套 ( iOS, Android )。但在很多场景下，可以用其它的跨平台开发方式提高效率。在支付宝里面有两种跨平台动态开发模式，一种是H5，适用于低频，对交互要求不是很高的场景。H5的有一个明显的弱点，就是它的性能。H5对动画、长列表之类的支持，明显比Native差很多，但支付宝内部对H5做了很多性能上的优化，比如默认使用自制的对移动端做过优化的UC浏览器内核来做H5的渲染，而没有使用系统自带的浏览器内核。还使用了离线加载的技术，可以提前在有WIFI的情况下，把H5包推送到客户端，在使用的时候就可以秒开，这样就可以提供比较优质的H5使用体验。即使是这样H5的性能还是有它的局限性的，所以支付宝还自助研发了一个基于WEB开发技术来开发Native页面的框架，开发者只需要写一套简单的类似JavaScript的代码就可以在Android、IOS和H5三端运行。 基本原理就是在页面渲染的时候做了一层翻译，把JavaScript代码动态的渲染成目标平台的组件。这种模式在性能上远比H5好得多，加载速度提升50%，并且包的大小只是Native的一半。这两种跨平台开发的技术使支付宝在特定场景下可以更快速地开发一些功能。

跨平台开发技术在支付宝里面有很多的应用，比如蚂蚁森林、机票、火车票，就是用H5开发的。账单、部分口碑的页面都是用JavaScript动态渲染的模式开发的。 随着JavaScript动态渲染技术的成熟，会有越来越多的应用使用这种方式开发。

如何确保新系统稳定运行

快速开发App只是第一步，最重要的是要给用户极致的体验。尤其是性能，是体验的底线，不能有半点妥协。AR红包虽然只有6个人在短时间内开发的，但是它没有遇到任何大的性能上的、大的故障影响到用户的使用，这一点又是怎么做到的呢？

首先，前面提到的支付宝里面的基础通用组件都是经过几百个工程师五六年的时间打磨出来的，并且经历了亿级海量用户的不断检验，在稳定性，成功率上是经得起考验的。举个例子，支付宝这样体量的App，如果有 1%的闪退率就意味着几百万人会遇到，这对业务有巨大的影响，是不能容忍的。支付宝App的闪退率一直要求低于万分之几，这对通用组件有及其苛刻的要求。再举个例子，扫一扫的功能看似简单，但其实很复杂，需要在弱光下，图片位置不正的情况下都能作出快速的反应。

其次，质量再高的代码不可避免的也会有问题，但支付宝有一个监控跟容灾平台可以快速发现问题，解决问题。这个平台整合了支付宝所有的日志，并根据分析模型去实时发现问题，同时提供基础的自我修复能力。比如说有些时候可能是日志相关的问题，那可以把日志自动清除掉。自动修复不能解决的问题， 可以利用平台提供的分析工具，去发现问题，定位问题。在一些特殊的场景下，还可以提供代码出错的上下文，让开发者快速发现问题。生成修复包之后，可以用支付宝自主研发的动态修复技术，不需要发版，就快速地修复Native代码中的问题，而且可以秒级推送到90%以上的用户，并且做到让用户无感知的热替换。

举一个具体的例子，AR红包中有一个福字识别模块，为了性能的要求，这个模块分为两个部分，一部分客户端，一部分服务端。首先在客户端识别福字，如果无法识别会去功能更强大的服务端去识别。但汉字比较特殊，有各种各样不同的字体，对识别算法的要求很高，在用户不断的使用过程中，识别算法也不断的得到了优化。期间支付宝对客户端算法做出了多次动态的升级，但完全没有影响用户的正常使用。这种修复包一般来说只有2-3K，所以可以快速触达很多的用户。

支付宝开发平台产品化 - mPaaS

刚才介绍了很多支付宝内部使用的技术，之前都是没有开放的。但随着支付宝生态的发展，越来越多的生态伙伴需要具备同样的开发能力，所以在2016年我们把支付宝的移动技术产品化，在云上提供服务。这个产品就是mPaaS。

mPaaS不光继承了前面提到的各种强大的功能，同时还做了很多的优化。尤其在使用体验上做了很多的提高。我们的目标就是在一个平台上用统一的方法把所有的组件融合起来，提供标准化的接口方式，让开发者快速开发稳定高质量的App。

使用流程也很简单，首先在云上控制台创建一个App并下载App配置文件，然后在mPaaS IDE插件中打开配置文件就可以使用所有的组件了，开发完成之后利用云上控制台中提供的发布工具发布APP，发布之后可以进行实时用户行为分析、 APP性能分析，针对分析结果对App做快速调整。

mPaaS的支持系统也很完备，我们在文档、开发工具、技术支持上都做了很多的努力，确保做好对开发者的支持，做到不留坑，不让开发者去趟坑。

支付宝内部还有一个说法叫吃自己的狗粮，mPaaS在产品化的过程中就经过了内部开发者的检验。蚂蚁聚宝、网商银行、优酷、天弘基金都使用了mPaaS的一些功能来开发自己的App。目前在被海量的用户使用中。

最后总结一下，mPaaS是支付宝的移动开发技术的产品化，帮助开发者快速开发稳定高质量的App 。