Flutter 在哈啰出行 B 端创新业务的实践

时间线

Flutter 在我们团队的起步算是比较晚的，直到 Flutter 要出 1.0 版本前夕才开始实践。

大概的时间线如下：

• 2018 年 11 月初，在 B 端小范围尝试接入 Flutter；
• 2018 年 12 月 5 日，Flutter 发布了 1.0；
• 2019 年 4 月中旬，开始大范围使用；
• 2019 年 6 月中旬，Flutter 在业务上的效率提升效果开始体现出来；
• 2019 年 7 月中旬，我所在的业务线的 B 端基本上全员转 Flutter 进行移动端开发；
• 2020 年 1 月初，我们用 Flutter 开发了非常多的页面，积累超过 10 万行 Flutter 代码；
• 2020 年 3 月中旬，开源 Flutter 嵌入原生移动 App 混合栈解决方案。

实践路线

作为一个创新业务的团队，要做一门全新技术栈的技术储备面临以下几个问题：

• 团队可投入时间少，要保证业务迭代；
• 团队成员没有 Flutter 技术栈的基础；
• 如何验证引入 Flutter 能带来什么业务价值。

这三个问题都是非常现实的问题，如果没有明确的路线规划盲目的引入 Flutter 的，踩坑过多最终会导入投入产出比太低而在业务上无法接受。

我把实践路线主要分一下四个阶段：

• 路线规划
• 技术储备
• 业务验证
• 持续集成

下面介绍在每个阶段我们做了哪些事以及获得的成果和经验。

路线规划阶段

目标设定：提升人效 50% ~ 100%

关键行动：

• 能用 Flutter 进行开发的优先使用 Flutter 来开发，不大范围使用 Flutter 进行开发是很难达成提升人效的目标的；
• Flutter 方案不成熟的直接使用原生开发，避免踩坑过多降低人效，比如地图，存在地图的页面，我们还是直接用原生进行开发；
• 不在早期引入状态管理的库，避免入门成本上升，也避免引入之后代码量变多；
• 团队成员分批入坑 Flutter，不过于保守也不能太过于激进，避免在引入 Flutter 阶段对业务迭代的影响；
• 做好降级，异常监控等稳定性相关的工作。

技术储备阶段

demo 验证

在技术储备阶段，主要是准备最小可验证的 demo，验证以下几点：

• 验证 Flutter 嵌入现有 iOS 和 Android App 的方案，最终采用 Flutter 官方提供的解决方案；
• 验证 Flutter 包管理中的 开发模式 和 发布模式，虽然作为创新业务，但哈啰出行的 B 端集合了几乎所有业务线的功能，我们在实践 Flutter 的时候不能影响其它业务线的正常开发，所以我们需要一个发布模式，避免其它的开发者也要安装 Flutter 的开发环境；
• 验证 包大小，内存占用，以及 性能 是否满足，作为创新业务的 B 端 App，在这方面我们可能要求并不高，不做展开；
• 解决 Flutter 异常收集和监控 的问题，底裤是一定要穿上的，考虑各种方案之后，最终选择 Sentry 作为早期的解决方案；
• 验证 混合栈 管理的方案是否可行，最终采纳 flutter_boost 的方案；
• 解决原生和 dart 状态同步 的问题，为了避免开发过多的插件来做状态的同步，抽象了一个通用的状态同步插件；
• 验证持续集成的方案。

建立规范

没有规范，会增加后续人员的入门成本

• 包和分支管理的规范，作为一个多业务线的 App，包管理一定要考虑后续其它业务线接入的情况；
• dart 编码规范，主要是 dart linter 的接入，考量每个规则以及规则之间存在的冲突，解决这些规则上的冲突，因为最终要求每一个 linter 的警告都必须解决掉；
• 建立 最佳实践 的积累方式，让团队每个人能避免他人踩过的坑。

人员准备

团队分成两组，先后入坑 Flutter，主要做以下准备：

• 了解 dart 语言，能用 dart 进行基本的页面开发；
• 了解 开发规范，包括包和分支管理、编码等规范
• 尽量查阅相关的最佳实践

业务验证阶段

降级方案

虽然我们是创新业务，但出于对线上敬畏之心，我们依然准备了降级的方案，一旦 Flutter 上线之后影响到 App 的稳定性，可以随时降级。

所以我们选择了既有的模块，将这些模块用 Flutter 重新开发一遍。同时也为后续的人效对比提供数据支撑。

代码量减少

仅供参考，我们 Flutter 的代码量实践下来会比任何一端的代码量都少一些，相对于 iOS，我们一般是纯代码布局，代码量减少更多。

更少的代码，一定程度上表示更少的 bug，更少的 bug 表示花在修复 bug 上的时间也减少了。

多端一致性

Flutter 渲染的多端一致性，让我们在 UI 布局上所花费的时间更少了。当然早期的 Flutter SDK 在处理字体、光标等方面略有差异，甚至有 bug，但都不是很大的问题。

人效提升

仅供参考，毕竟每个团队的情况不尽相同，业务复杂度也不尽相同。

这里给出我们早期的三个数据的对比，19 年我们下半年的时间基本上进入了纯 Flutter 开发的阶段，但 iOS 和 Android 两端还是需要分别打包、测试、上线，这会一定程度上降低人效提升的百分比，所以我们综合的人效提升会在 90%左右。

#	Flutter 人天	双端人天	人效提升
账单管理	18.5	26	40%
自助还车	12.5	21	68%
19 年综合	–	–	90%

业务价值

通过引入 Flutter，我们在业务上能更快的进行迭代，使用 Flutter 开发的部分人效提升接近 90% 左右，因为我们总归是有一些功能需要用原生进行开发的，这部分工作量不好做对比。

这达成了我们最初引入 Flutter 设定的目标，提升了整个团队的人效，完美的支撑了业务的快速迭代。

持续集成阶段

在业务验证阶段，我们达成了提升人效 90% 的目标之后，欠缺的持续集成需要被提上日程，最紧迫的两个事情就是 插件发布 和 编译产物发布。

作为一个业务团队，我们依然没有太多精力投入到工程建设上，所以很多工程化相关的能力，最开始都是手工的方式进行的，大概可