CodeHub#1 回顾 | 敏捷开发与动态更新在支付宝 App 内的实践

做者介绍：古塘，目前主要负责支付宝框架和各个组件经过移动开发平台 mPaaS 对外输出工做，今天给你们分享的主题是敏捷开发与动态更新在支付宝 App 内的深度实践。

活动推荐：CodeDay#1 线下沙龙杭州站已上线，具体活动信息及报名地址见文章尾部。

支付宝App的架构演进

首先来快速看一下支付宝的架构演进，支付宝在移动端躬耕多年，从简单的工具型 App 到平台型、到如今的超级 App。与目前市面上大部分 App 的发展路线相似，目前咱们构建平台的同时，作了更多服务化、模块化的工做。

针对支付宝在超级 App 方面方向下的架构优点，咱们总结了以下特色：

• 多应用的生态：不限于形式，原生模块、离线包、小程序。 开放：底层同一个架构，业务很方便的迁移。
• 动态化：业务能够随时在线更新，无需发版，随时响应线上活动，好比双11、双十二，春节扫福等活动
• 高可用、高性能、高灵敏度：完善的监控运维体系、发现问题后多层次的修复技术、客户端良好的性能启动体验，强大的网络性能，防刷抗流量等。

工程化挑战

从工程化的角度来看，业务和团队的快速发展也会带来巨大的挑战。支付宝的业务量在 1五、16 年后有一个指数级的增加，包括团队人数、模块数量，你们看如今的支付宝也不只仅是一个简单的支付工具了，而是包含了各类各样的业务，服务咱们的生活的方方面面。因此咱们须要一个灵活开放的架构来支撑多团队的快速协同开发，须要创建超级 App 的运维体系。

业务复杂性带来的技术挑战 下面咱们快速看一下业务复杂性会带来怎样的技术挑战，整体来讲，分为 4 个方面。

一、基础能力要求更高：

好比支付宝的核心场景扫码支付，有更好的识别率和识别速度，push 就是你们听到的萌妹子语音：“支付宝到帐多少多少元”，这就涉及到要求咱们的框架怎么作保活，怎么提升推送到达率。 移动安全方面，做为金融级的App，要作到防范黑产，各类羊毛党。 应急和快速修复方面，这是咱们已经提到过的，框架须要快速响应线上问题，并提供相应的修复方案，能作到动态更新，最大程度的保证线上的稳定性。

2&三、性能和环境方面：

随着业务体量的不断增大，若是业务同窗无脑的把初始化放到启动过程当中，必然会形成启动时间的不断增长，在使用过程当中，也很容易会产生电量、流量、内存、存储等各类问题，形成线上舆情，网络环境也是同样，由于如今还在一些偏远地区可能网络不太好，弱网优化也是须要的，同时咱们也须要对千元机、低端机器保持友好，保证低端机的用户体验，因而乎，咱们急需良好的框架运维机制来支撑业务的快速发展和敏捷发布

四、多 App 生态

这也正是咱们基于 mPaaS 作的对外输出。支付宝这套框架不止是支付宝本身用，也须要快速赋能咱们的合做伙伴，你们都是统一的架构底层，支持业务之间的灵活联动和快速扩张，这也是前面提到的超级 App 的技术特色。

架构现状

接下来咱们来具体看一下支付App的架构现状：

从下到上，分别是「容器层、组件层、框架层、服务层和应用层」

• 容器层：最底层的基础层，管理这每一个模块 bundle 的加载和资源的处理，在 Android 上和如今流行的插件化框架相似
• 组件层：是咱们抽离出来的通用组件，提供一些通用能力，好比网络、缓存、日志、图像加载等等
• 框架层：这层和原生的 Android,iOS 系统 SDK 相似，是咱们定制的用来作每一个模块 bundle 之间解耦、交互和通讯的基础层，有 Native,H5 和图上没提到的小程序
• 服务层：咱们基于框架封装的一些业务服务层，提供登陆、支付、LBS 等服务
• 最上面的就是应用层了：即用户可见的具体业务，对于支付宝来讲就是扫码、转帐、余额宝等 因此说支付宝的框架有着明显的分层结构，除了支付宝自己，蚂蚁系内部的 App 也都是依托于此，好比网商银行、蚂蚁财富、口碑等，你们的 App 是底下这 4 层能够作到几乎同样，惟一区别就是在应用层搭建不一样的业务，并且由于是一样的架构底层，同一个业务很方便的作多端迁移，好比你们比较喜好的余额宝业务在支付宝里有，在蚂蚁财富App 里也能看到，这套框架也依托于 mPaaS 平台对外输出，也欢迎你们体验。

多种框架支撑

正如刚才所说的，在支付宝内部会有多种框架支撑不一样业务的并发开发和快速发布，大体可分为“Native 开发框架”、“Kylin H5 开发框架”以及“小程序开发框架”，具体的内容咱们会在后续展开。

灵活的开发框架

咱们认为在支付宝内部开发业务，就像搭积木同样轻松，具备不少特色：灵活性、扩展性等等

整体来讲，你们都是并行开发，互相不影响，谁的版本有问题，能够随时回滚到稳定版本：所以积木和积木之间能够作到很好的解耦，之间的交互就是经过前面讲到的定制的框架层来通讯，一样你也很方便地增长一块新积木，自由扩展业务。

OSGI

OSGI 是 Java 作动态化模块化的一系列思想规范，支付宝的框架设计也是借鉴了这个思想。

整体来讲，在支付宝内部的每一个模块工程咱们都称之为 bundle，在 Android 上的产物其实已是一个完整的 APK 安装包了，只不过不能独立运行，须要依赖底层框架和其余模块，在 iOS 上的产物也是一个具体的二进制 Framework 包，这样打最终安装包的过程其实就是前面提到的把各个积木搭起来的过程，只是二进制级别的合并，比较耗时的编译的过程已经分散到各类积木的产生过程当中了，这样作也能大大加快整个安装包的打包速度。

以支付宝为例，打完整的安装包包含几百个 bundle 的，在我这台 14 年版的 Mac 上耗时也在 1 分钟以内。

微应用和 service

接下来咱们来看看积木和积木之间，业务上是怎样作交互的。咱们经过封装 MicroApplication 和 service 来实现。

• MicroApplication：咱们认为每个独立的 bundle 其实就是一个小的 App，因此咱们也赋予了和系统 SDK 相似的生命周期代理方法，相似于 iOS 的应用 delegate 和 Android 的 application，经过 AppId 标识，能够随意跳转到不一样业务的 App，MicroApplication 相关的生命周期事件也会有相应的回调，不一样的 bundle 之间彻底不用知道你有什么 Activity 或者 viewController，只须要告诉我你的 AppId 标识，就能够跳转过去，就是说框架提供了全局的路由管理功能。
• Service：这个不一样于 Android 上原生的 service 组件，经过框架中接口包的概念思想，很方便的实现对外暴露功能接口，有点相似于单例类的感受，区别是框架提供了完整的加载和调用管理，不用开发本身重复写单例类造轮子。

Nebula

和市面上流行的 phoneGap (cordova)相似，都是 H5 混合开发解决方案，特色如图所示：

除了提供基本的 H5 页面的加载管理、和 Native 作通讯的 JSAPI 机制，还具有一些他们可能不具有的特色

• 1.离线包机制，解决 H5 加载的性能问题
• 2.统一的 UC 内核，解决 Android 上恶心的兼容性问题

体验改善

首先，咱们来看H5加载，传统意义上的H5，在进入的时候上面会有进度条或者转菊花，体验会不太好，咱们的容器是怎么解决这个问题的呢？

离线包

离线包是将 HTML、JavaScript、CSS 等页面内的静态资源打包到一个压缩包内，Nebula 使用一套基于 AppId 维度的本地文件管理方式，对离线包进行管理。这和前面提到的框架「积木的概念」一模一样，每个离线包都是一个小积木，这个小积木能够很方便的作到热插拔，实现动态更新。

小程序

接下来让咱们来看看小程序，看看标题仍是很唬人的，面向将来的研发方式。

你们有没有想过这样一个问题，为何 H5 技术已经发展的相对来讲比较成熟了，咱们还要推出小程序技术？

由于小程序能够完美解决如今 H5 存在的一些问题：安全、性能、开发效率等各个方面。

• 拿性能举例，虽然已经有了离线包技术能够大大提高 H5 的加载性能，可是始终渲染出来的仍是 H5 页面，受限于 webView，而小程序就彻底不同了，最终渲染的页面，能够是 H5，也能够是 Native 页面，能够集成 RN、weex 相似的技术，实现原生渲染，并且小程序有本身的框架，能够实现报活、资源预加载等各类优化手段，这些都是 H5 很难办到的

你们能够看如今支付宝里的蚂蚁森林，抢能量种树那个，你们应该都玩过吧，当前的版本就是小程序实现，能够体验一下页面的加载速度和滑动的效率等等，这已是一个比较复杂的带动画的业务了，均可以作到很好的用户体验。

小程序 IDE

同时小程序还有本身的 IDE，帮助开发者可以实现「编码实时预览、自动补全、语法提示」等，从而大大提高了开发效率：

研发流程

所以，基于前面介绍的各类开发框架，这里能够分享一下支付宝的研发流程，分为「开发、测试、集成发布」这些过程：

• 开发：建立本身的小积木
• 测试：验证，经过和不经过
• 发布：会有发布经理这个角色，简单的理解就是最终搭积木的那我的，会审批每一个积木到底能不能进最终的大架子，而后再进行各类灰度和发布流程

高效交付：并行研发流程 + 动态更新

从大版本集中发布到每一个小产品迭代开发，每一个小产品线维护本身的小版本，能够控制本身的研发和发布流程。

打包平台

内部也会有 CI/CD 打包平台的支撑，支撑着内部完成「多模块并行开发、业务功能动态部署、线上问题热修复」。

对于发布平台，咱们是怎么作的呢？

• 不一样的业务，能够建立不一样的发布任务，能够发布到不一样的版本
• 发布产物：支持原生的升级包、热修复包、离线包、小程序
• 发布类型：内部灰度、外部灰度、正式发布的维度展开灰度测试？
• 人群过滤：支持不一样维度的人群过滤，按白名单、机型、rom 版本等

这里还能够说一下的是，咱们对于离线包这种发布产物是支持差分机制。举个例子，咱们有一个业务原先是 200K，改个背景逻辑变 210K 了，不必由于这 210K 去完整下发覆盖，经过差分获得补丁。固然，这里的补丁大小不是 210K-200K 这样简单，但至少咱们能够经过补丁机制从而达到最大程度地减小数据冗余，提升总体覆盖率。

总结：技术架构升级驱动研发方式转变

总结来讲，技术升级驱动研发方式产生转变，从 Native 为主的研发方式向动态化的研发方式进行转变：

• 技术选型：原先咱们以 Native 为主，少许独立页面使用 H5；如今咱们更推荐核心组件使用 Native（用户高频使用的场景），二级业务尽可能使用 H5 或者小程序；
• 发布方式：目前基于“小步迭代”的选择，不依赖客户端发布点，从而达到随时发布的能力；
• 研发效率：目前使用 Web 技术可以达到更开放的效果，一套 Web 代码便可实现跨平台的能力；
• 安装包大小：相较于 Native，H5 可以有效地控制安装包的大小。

敏捷发布、保障稳定性

那么总结一下，支付宝是怎么敏捷发布，并保障稳定性的呢？

• 开发测试：经过接口解耦与业务解耦，开发者只需关心本身的业务作好业务迭代和测试，集成以后验证跑通便可。
• 灰度发布：提供多方位的灰度策略：白名单、时间窗、应用版本号、系统版本号、手机型号等。
• 监控：监控主要聚焦稳定性的问题，包括“闪退、卡顿、卡死、业务异常”等状况，当问题产生后咱们会基于动态修复的手段进行快速修复。相关的埋点监控模块近期也在支付宝开放平台开放出来，欢迎体验。
• 动态修复：进行 Native 热修复和配置下发。具体内容见后续展开。

超级 App 运维体系

所以咱们经过发布、监控、诊断协同做战，支持体系化运维，造成了所谓的超级 App 运维体系。

接下来咱们针对「诊断」展开，前面咱们提到的「监控」更多的是发现问题，而如何定位问题发生的缘由，是须要经过诊断来进行核验的。

诊判定位

参考这张图，咱们可以清晰地了解支付宝内部是如何进行问题诊断与定位：从“端到端的信息打通”到“全链路辅助到人”，“详细信息拉取”后在进行相应的“诊断分析”，同时会配备具体的诊断策略。

所以，咱们能够实现一键诊断用户 App 日志，具体界面以下：

AndFix

发现问题后，怎么去修复问题，就要用到一些热修复的手段了，好比这里提到的 AndFix。

在 Android 上，AndFix 彻底是支付宝同窗自研的一套 Android 热修复技术，15 年的时候已经在 GitHub 上开源。如今 star 数大概有 6000 多个，相信应该有同窗也接触了解过，不过开源的版本略老，可是原理不变。

AndFix 能够认为是开创了 Android 热修复 2 个流派之一的 Native 修复，原理是经过在 Native 端方法指针替换实现，修复的粒度是针对于方法，这样从原理上来讲至少有 2 大好处：

• 1 是补丁包比较小，由于是方法粒度；
• 2 是能够作到实时生效，比较适合修复紧急 bug 这种热修复场景；

另外一种比较流行的技术是经过类加载的机制，由于粒度是类级别，因此补丁包会相对来讲大一点，且可能存在 dex 合并的性能损耗，并且由于 Android 虚拟机没有类卸载机制，因此没法作到实时生效，必定要重启。

固然，没有一种技术是万能的，咱们内部也会存在着 dexPatch、instantRun 这种原理的修复技术，应对不一样的场景

在 iOS 上，从最先的lua脚本到大名鼎鼎的 JSPatch，咱们内部都会有相似的方案，这个在 iOS 上其实最重要的我以为不是技术问题，而是苹果爸爸的政策问题，这里就很少说了，你懂的。

多层次的修复技术

最后总结一下，必定要有多层次的修复技术，适应不一样的业务场景。如图所示：

移动开发平台 mPaaS：对外输出

最后，到了 One More Thing 的时候。前面咱们分享所涉及的全部技术手段目前都经过 mPaaS 平台对外输出：

「移动分析、消息推送、热修复」三款组件近期在支付宝开放平台上已独立放出。若是你是移动开发者，且对 mPaaS 感兴趣，赶忙上手试用吧：t.cn/ExXJGkP

| mPaaS 第一期线下沙龙 CodeDay#1 开放报名中：

• 活动主题：移动端高性能架构演进与跨平台开发实践

  本期邀请支付宝移动端技术专家，与你们面对面一同探讨在跨平台开发下的高可用、高性能架构演进与跨平台开发、动态化更新实践。

• 报名方式：进入活动页进行报名；没法到现场的同窗可经过钉钉搜索群号“23124039”当即加入技术交流群，届时获取直播地址，并有机会与讲师在群内深度交流。

期待你的参与。