如何迅速开发一款移动App？蚂蚁金服移动开发平台mPaaS已帮你写好了答案

小蚂蚁说：

时间倒推到两三年前，大家可能对刷支付宝乘公交车和地铁还感到惊奇。但如今，一个外来游客要是来到北上杭这些城市旅游的话，再也不用浪费时间在各个地铁票售卖处排长队买地铁票了。无论是用支付宝扫码进站，还是打开像上海地铁的“METRO大都会”这类App，这些应用的出现和存在最终都是为了方便消费者的日常出行体验。

与此同时，现在的年轻人可能对银行线下网点和人工柜台的服务越来越陌生，因为越来越多的转账、汇款等交易都发生在了线上。多年前春运期间一大清早去火车票网点排队购票的场景也逐渐消失，人们已经习惯用互联网来搞定一切，并习以为常。

但这也变化也不是一夜之间一蹴而就的，那些我们吐槽部分 App 和线上业务体验不佳的日子似乎还并不遥远。而这些体验的摩擦与交融可以说是各行各业走向数字化转型的一个缩影与阵痛。或许很多年之后回望 2017 年，人们会认为此刻是一个时间节点。在这一年，传统金融机构以及非金融行业都在纷纷发力开发或者革新自己的 App，以更好地适应互联网时代下用户的需求并提升用户体验。这些状况在不久之后就会得到改变，而这些改变背后少不了今天故事的主人公——蚂蚁金服移动开发平台 mPaaS。

潜心练功，mPaaS 的诞生与成长

mPaaS 是 mobile Platform-as-a-Service 的简称。如果你熟悉云计算的话，对 PaaS 这个概念一定不会陌生。如果你采用 PaaS 的服务，那么意味着你既不需要买服务器，也不需要自己装服务器软件，即可利用这个中间件平台进行定制化研发，开发自己的应用。

而 mPaaS 这个概念则由蚂蚁金服独创。它是在 PaaS 的基础上衍生出移动的平台概念，其中 m 代表的就是 mobile（移动）。类比与 PaaS 的概念，mPaaS 更专注于移动端的研发平台服务。开发者能够利用蚂蚁金服移动开发平台 mPaaS 做好移动 App 的开发、管理、发布，并做好 App 全生命周期的管理，其中包括了开发期的研发测试、打包构建、发布管理，还有发布之后的用户行为分析、闪退分析等。如果说 PaaS 平台是对企业后台服务的生命周期的管理，包括研发、发布、监控这一套流程，那么 mPaaS 就是对移动应用 App 一整套全生命周期的管理服务。

事实上，当传统金融行业将目光投向移动 App 开发的时候，前面是一条看似平坦却暗藏坑洼的一条路。而支付宝早在 2013 年以前，就开始了这趟淌坑之旅，并逐渐摸索出一条明路，最终基于 mPaaS 平台对外开放。这就像你刚开始准备学习这门课程，学霸支付宝同学已经早在几年前就学完并替你总结了一套学习方法和快速学习平台。可以说，目前 mPaaS 的所有技术服务和组件都是源于支付宝，并在支付宝的各种高并发等极端条件下和实际业务场景中经过重重检验的。

为了让你更好地理解 mPaaS 的过人之处，我们要先从支付宝这个国民级 App 的开发历程开始说起。2013 年开始，支付宝开始了 All In 无线战略。在那之前，支付宝还是一个单体应用的支付工具，只拥有一些非常基础的模块和工具库。2013 年，随着支付宝的 All In 无线战略之后，业务快速发展，支付宝 App 里所能提供的功能和应用也开始井喷式的发展。与此同时，支付宝 APP 用户数也开始指数级的增长，其后台支持的开发团队也日益庞大。这么一个数量庞大的开发团队如何高效地进行开发协作呢？这对支付宝 App 开发架构的设计的合理性提出了很高的要求。

在 2013 年到 2015 年期间，蚂蚁金服就对支付宝做了一个架构治理，整个支付宝 App 的开发架构被做了分层，支付宝 App 被改造成了一个平台型 App，它集成了各个应用，并实现了应用的服务化、模块化，开发工具走向组件化。这样一来，基于支付宝 App 上的每一个应用都可以独立的由一个团队来开发，而整个支付宝则用一个通用的底层平台框架进行管理。如此，支付宝 App 就从架构上允许支付宝能够快速扩展业务，每上一个新业务就相当于开发一个新的模块，只需要将新的模块插到这个框架里就可以运行了。

在这个期间，支付宝的开发团队还沉淀了模块开发的很多通用的能力，包括像消息推送、分析、网关等等。而这些通用能力几乎所有业务场景里的应用都会需要。与通用技术能力伴随而生的另一个简单的理念就是：我们能不能将在支付宝架构上沉淀的这一套经验和能力更好地对外输出，以服务更多的金融机构？

2015 年 9 月 14 日，蚂蚁金服宣布启动“互联网推进器”计划，计划将在 5 年内助力超过 1000 家金融机构向新金融转型升级。蚂蚁金服作为“互联网推进器”将推动平台、数据和技术方面的能力全面对外开放。同年 10 月，mPaaS 1.0 版本正式面世。

1.0 时期的 mPaaS 功能比较简单，主要包括三大核心功能：网关；用户行为分析；消息推送。在这一时期，mPaaS 就服务了网商银行和天弘基金两大客户。

很快到了 2016 年底，mPaaS 2.0 版本开始酝酿。mPaaS 2.0 最重要的特征是往共享的方向发展，并实现了框架和模块的拆分，即 mPaaS 上提供的功能都可以单独输出，这意味着客户可以比如只使用单项功能（如消息推送）而完全不用其它任何服务。共享模式也可以说是多租户模式，就是说开发者在公有云上可以拥有不止一份 mPaaS，不同用户可以通过逻辑隔离来用同一份 mPaaS，这可以有效的降低公有云上的使用成本。

此外，2.0 时期的 mPaaS 具有着更丰富的功能：一个是 MDS 功能，即发布功能，它可以在 APP 里提醒用户下载、升级新版本；另一个是热修复功能，热修复功能通过 MDS 发布到客户端，并在紧急情况下，如果代码有问题，开发者可以在不发布新版本的情况下，在运行期就将问题修复。

热修复功能一经推出即受到了市场的热烈欢迎，在这之前和之后，市场都很难找到同样提供同类服务的产品。2017 年 1 月，mPaaS 2.0 出现在了众人的视野里。这一次它服务的客户进一步扩展，除了苏宁金融这类金融客户之外，有了更多非金融行业的客户的加入，包括阿里健康、OFO 等等，还有我们前文提到的上海地铁。

2017 年 5 月，蚂蚁金服 mPaaS 技术团队开始进驻上海地铁，到 10 月份上海地铁“METRO 大都会”App 正式上线，并在上线一周以内该 App 注册人数超过百万，这背后所支撑的不过十几人的开发团队。上海地铁“METRO 大都会”App 加入了扫码进站的功能，这意味上海的用户不再需要在高峰期花半小时排队买地铁票。

在“METRO 大都会”App 的上线过程中，mPaaS 2.0 新上线的“热修复”功能还经历了一次生死时速的考验。为了做好 App 的数据运营和监测工作，该 App 开发时即使用了 mPaaS 的各项能力，在 App 上线之前就做好了全方位的埋点监控，相关人员能够密切关注用户的使用情况，这样能在出现任何问题的时候也能第一时间发现并修复。果然，在该 App 刚上线一周的时候，技术小哥敏锐地注意到，部分机型无法顺利的完成用户注册。在发现这个问题的一天之内，技术小哥们迅速的解决了这个问题，并利用接好的热修复功能快速修复，最大程度上保证用户的体验不受损害。想象一下，要是没有热修复功能，而是等到各个手机应用市场重新发布新版本的话，这其中所耗的审核和上线时间不可估量，而最终影响的用户也可能难以计数。

地铁，春运，银行—— mPaaS 接受挑战并完成到绝世高手的蜕变

2017 年 10 月开始，mPaaS 开始向 3.0 阶段蜕变。mPaaS 3.0 开始支持私有云，并推出了数据同步服务。数据同步是一个保持 mPaaS 跟客户端常连接的服务，该服务能够确保一些关键信息可以在秒级触达所有的在线用户，时效性和稳定性都得到了改善。

同时，mPaaS 小程序的功能也在 3.0 版本中被抽离了出来，做成了一个纯技术的方案，这意味着 mPaaS 的开发者可以利用小程序技术为自己的 App 开发小程序。以上海地铁为例，该 App 支持其他开发者、ISV 或商户能够围绕上海地铁开发更多小程序，并且这些小程序可以既运行在上海地铁里面，也可以运行在支付宝里面，为开发者们带来更多的流量和福利。

在向 3.0 过渡的 2017 年 9 月底，mPaaS 开始与 12306 展开合作。当时这支 mPaaS 开发团队还不知道就在短短 3 个月后，他们就要拿出一个新的产品，也就是部署并开发一个新的 12306 App 来应对一个巨大的难题——春运。

可春运作为一个老大难问题，按照 mPaaS 开发团队的话讲：“并不是开玩笑的”。事实上，做 12306 App 这么大的产品一般正常的开发周期要一年以上，而 mPaaS 技术团队面临的状况是在 9 月底进场，12 月份上春运，如此高的强度和如此难的技术挑战，在国内外都是没有先例的。

但最后 mPaaS 团队还是接受了这任务，10 多个人的团队再加上铁道部派来的团队加班加点，终于在 1 月 3 日，通过各轮的测试、压测后上线。最终 12306 的线上 App 很顺利的支持了春运，为国人顺利回家过年出了一份力。

此外，在 2.0 到 3.0 期间，mPaaS 还帮助苏州银行顺利完成了云端的部署，为直销银行多样化场景提供了强力的支撑；通过 mPaaS 离线包帮助广发银行提升了 APP 性能，使其“发现精彩”的启动时间从降低近 70%；印度的 Paytm 则利用 mPaaS 的这套能力更好的对在即的 App 内部进行数据监测与统计，从而更好地优化用户体验……

而至此，mPaaS 也完成了自己的蜕变，就 App 开发领域的某个单个问题的解决而言，或许还有一些对手能够与 mPaaS 勉强抗衡，但就客户端 App 移动维度的一个整体解决方案而言，金融行业已不再有对手能跟 mPaaS 相提并论。而 mPaaS 基于支付宝的能力沉淀而来，使得它更适合如出行类的高并发需求；或是金融行业所要求的强容灾和安全性。

承担责任，迎接新挑战的 mPaaS 3.0

回过头来看 mPaaS 的成长与蜕变，我们会看到 mPaaS 依托于支付宝掌握了如下关键技能：

1.依托于支付宝长期发展而积累下来的业务场景，成长为做 2C 端产品运营的大师。

很多传统金融，非金融机构也许并不知道应该如何做一个成功的面向大众消费者（to C）端的产品，更是在如何做业务运营，营销上缺乏经验。对于传统行业来说，无论是交通出行行业还是银行等金融机构，由于没有相关背景，即便将业务外包，当涉及到数字化转型这样大的场景需要成体系方案时，外包公司多由于没有能力给出完整方案而让传统行业继续面临困境。

mPaaS 由于依托支付宝这个经过长期技术积累，实力雄厚，有历史，技术经得起最各种极端挑战，并逐步成长为能够给出有前瞻性的解决方案来解决潜在的未来问题的专家，它能给传统行业提供完整的生命周期性的整套数字化解决方案。而这，形成了 mPaaS 和其他同类产品的代差。

2.从开发框架维度支持团队协同开发，效率更高。

回顾 mPaaS 的诞生历史，一开始它的出现就是为了服务各个团队协作而产生的，从而更好的支持业务的快速扩张和团队协作。此外，mPaaS 提供了很多现成的开发组件和模板，不用重复造轮子，进一步提升了开发者开发 App 的效率。这一点在 12306 的 3 个月快速开发案例上就是一个很好的例证。

3.强大的 App 性能优化能力，保证用户体验。

关于“如何实现 App 的秒开，缩短用户的等待时间”这一问题的探索，支付宝技术团队的钻研之深远超你想象。如今，借助 mPaaS 平台，支付宝将这一技术贡献给大家，让各位开发者们也能开发自己的高性能应用。目前，经过 mPaaS 优化过的银行类 App 打开时间由原来的十几秒到秒开，这与其背后的技术经验密切相关。

4.从小程序到人脸识别技术，支付宝的创新技术加持

目前 mPaaS 团队还在不断为在目前的基础上对外开放更多的功能。从当下几乎各个金融类 App 必备的人脸识别技术，到能够更好构建自身生态的小程序技术。这些你能想象到的前沿技术热点都在 mPaaS 上逐步实现，而未来基于蚂蚁 BASIC 技术战略的区块链技术等等，更是值得期待。

5.不仅是技术的输出，更是经验的输出，推广先进的经验从根本上改变研发方式

mPaaS 离线包，热修复，App 灰度发布，小程序等可以从根本上改变研发，发布方式，提高效率。比如离线包彻底解决了 H5 加载的性能问题及对网络的依赖，开发者可以更多的去关注业务逻辑而不必太过关心性能。下面是在某银行 App 上线灰度过程中，一线的运维工程师对灰度发布经验的高度认可，也是 mPaaS 对外服务的初衷。

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/MaXys-wQKX_WehLKnyhTmw