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

1911次阅读  |  发布于4年以前

作者 | 稻子

时间线

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

大概的时间线如下：

实践路线

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

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

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

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

路线规划阶段

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

关键行动：

技术储备阶段

demo 验证

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

建立规范

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

人员准备

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

业务验证阶段

降级方案

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

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

代码量减少

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

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

多端一致性

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

人效提升

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

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

业务价值通

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

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

持续集成阶段

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

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

手工发布

脚本发布

这个阶段主要是通过脚本实现 插件发布 和 编译产物发布 的半自动化，但依然没有集成到 App 发布的 CI 系统。

这个阶段也是在不断完善发布脚本，最终效果是根据 pubspec.yaml 文件的描述，自动发布有更新的插件，并最终发布编译产物。

一键发布

将现有的发布脚本集成到 App 发布的 CI 系统，效果就是一键打包，彻底将这块活自动化。

架构 1.0的建设

架构建设方面，我们需要解决的三个主要问题：

在解决这三个问题的过程中，我们大致经历了从 架构 1.0 到 架构 2.0，除了页面模块化基本保持不变，页面间通信、页面栈管理从 架构 1.0 到 架构 2.0 的变化是非常大的。

页面状态管理 在我们的业务上还不是一个主要问题，我们也尝试过引入 bloc，但还未进行足够探索，所以这里不做展开。

页面模块化1.0

模块化的定义，根据业务域划分不同的业务模块，为了避免与 WebComponent 的区别，不使用组件化这个名词。

如何划分模块这可能需要另外一篇文章来说明，简单来说就是业务域的划分。要保持模块的内聚，每个模块的初始化需要独立进行，要做到这点，我们的方案是将所有模块挂载到模块树上，类似文件夹的树形结构。

页面模块化 1.0 主要提供以下能力：

挂载完成之后，初始化 root 模块，会将所有挂载在树上的模块都进行初始化。这个树形结构在叶子节点就是页面，页面的路径天然可作为页面的 url。

模块划分本质上是根据业务域对页面进行组织。不管是单一仓库还是多仓库，都可以通过这种简单的树形结构来实现模块挂载和初始化。

页面间通信 1.0

模块间通信，本质上主要是页面间通信。

移动端很多模块化的方案，都会将模块间通信作为主要能力进行建设，我们在原生端也有一套这类方案，但在 Flutter 嵌入原生应用中，并不能简单复用这套方案，如果生搬硬套会带来很多的编码量，并不是一个很轻量的解决方案。

页面间通信的能力，需要重头开始建设，早期我们抽象了一个状态同步的方案，开发一个插件 topic_center 专门用来给原生和 dart 进行状态同步。

topic_center 提供的能力：

topic_center Flutter 端按需同步原生状态的数据流：

topic_center 提供如下的 API，topic_center 遵循 Flutter 的多端一致性原则，我们在三端提供了一样的 API，下图仅展示 dart 的 API 定义：

dart
void putValue<T>(T value, String topic);

Future<T> getValue<T>(String topic);

Stream<T> getValueStream<T>(String topic);

void putListValue<E>(E value, String topic);

Future<List<E>> getListValue<E>(String topic);

Stream<List<E>> getListValueStream<E>(String topic);

void putMapValue<K, V>(Map<K, V> value, String topic);

Future<Map<K, V>> getMapValue<K, V>(String topic);

Stream<Map<K, V>> getMapValueStream<K, V>(String topic);

void putTuple2Value<T0, T1>(Tuple2<T0, T1> value, String topic);

Future<Tuple2<T0, T1>> getTuple2Value<T0, T1>(String topic);

Stream<Tuple2<T0, T1>> getTuple2ValueStream<T0, T1>(String topic);

void putTuple3Value<T0, T1, T2>(Tuple3<T0, T1, T2> value, String topic);

Future<Tuple3<T0, T1, T2>> getTuple3Value<T0, T1, T2>(String topic);

Stream<Tuple3<T0, T1, T2>> getTuple3ValueStream<T0, T1, T2>(String topic);

void putTuple4Value<T0, T1, T2, T3>(Tuple4<T0, T1, T2, T3> value, String topic);

Future<Tuple4<T0, T1, T2, T3>> getTuple4Value<T0, T1, T2, T3>(String topic);

Stream<Tuple4<T0, T1, T2, T3>> getTuple4ValueStream<T0, T1, T2, T3>(String topic);

void putTuple5Value<T0, T1, T2, T3, T4>(Tuple5<T0, T1, T2, T3, T4> value, String topic);

Future<Tuple5<T0, T1, T2, T3, T4>> getTuple5Value<T0, T1, T2, T3, T4>(String topic);

Stream<Tuple5<T0, T1, T2, T3, T4>> getTuple5ValueStream<T0, T1, T2, T3, T4>(String topic);

topic_center 是我们在 架构 1.0 时提供的页面间通信解决方案，后面会讲到我们在进行架构升级之后提供的更轻量级的解决方案。

页面栈管理

1.0如果没有混合栈管理，我们在原生应用上引入 Flutter 将是一个极为麻烦的事情，我们可能为此维护比较混乱的 Channel 通信层。

flutter_boost 是闲鱼开源的优秀的 Flutter 混合栈管理解决方案，也是当时社区唯一可选的解决方案。

flutter_boost 的优势：

如果不使用 flutter_boost，我们的页面结构可能是这样的：

使用了 flutter_boost 之后可以是这样的：

架构 1.0 的问题

页面间通信 1.0 的问题

topic_center 插件能解决页面间通信的问题，但有一个不算问题的问题，对 topic 的管理成本过高。为了避免全局 topic 重复的问题，每个页面状态的同步都需要在 topic 上带上各种前缀，一般就是 模块、子模块、功能、页面作为前缀，然后这个 topic 最后长得跟页面的 url 极为相似。为了解决这个问题，需要想办法去掉这个 topic 的管理成本。

topic_center 这个库的投入产出比实在是不高，源码过于复杂 带来不只是解决方案的复杂，也带来 维护成本推高 很多。

页面栈管理 1.0 的问题

比如，项目上需要实现关闭到某个页面的场景，或者删除当前页面之下的某个页面，我们需要在 flutter_boost 上自行扩展，且难于维护，如何跟官方的 flutter_boost 保持代码同步是一个艰难的事情。

我们在项目上大量使用页面回传参数的能力，但是该 API 在新版本上被移除了。

flutter_boost iOS 端的实现方案，在实际项目上使用时，我们只能将每一个 Flutter 页面都套在一个原生的 FlutterViewController 中 ，这直接导致每打开一个 Flutter 页面的内存占用高出 10M 左右。

为了解决这些问题，我们开始了 架构 2.0 的建设。

架构 2.0 的建设

架构 2.0 主要是解决 页面间通信 1.0 和 页面栈管理 2.0 的解决方案存在的一些问题而演变出来的，同时对 页面模块化 做更细致的职能分解。

页面模块化 2.0

方案可以参考 ThrioModule，ThrioModule 的 API 也遵守多端一致性。

相比于 页面模块化 1.0，功能的变迁如下：

以上功能均提供三端一致的 API 2.0

页面栈路由 2.0

我们开发了 thrio，主要是解决 页面间通信 1.0 和 页面栈管理 1.0 中存在的问题。

thrio 的页面栈结构thrio

的原理上改善点是除了复用 FlutterEngine，还复用了原生的页面容器，页面栈结构如下：

thrio 的路由 thrio 提供了三端一致的路由 API

页面的 push

dart
ThrioNavigator.push(url: 'flutter1');
// 传入参数
ThrioNavigator.push(url: 'native1', params: { '1': {'2': '3'}});
// 是否动画，目前在内嵌的 dart 页面中动画无法取消，原生 iOS 页面有效果
ThrioNavigator.push(url: 'native1', animated:true);
// 接收锁打开页面的关闭回调
ThrioNavigator.push(
    url: 'biz2/flutter2',
    params: {'1': {'2': '3'}},
    poppedResult: (params) => verbose('biz2/flutter2 popped: $params'),
);
objc
[ThrioNavigator pushUrl:@"flutter1"];
// 接收所打开页面的关闭回调
[ThrioNavigator pushUrl:@"biz2/flutter2" poppedResult:^(id _Nonnull params) {
    ThrioLogV(@"biz2/flutter2 popped: %@", params);
}];
kotlin
ThrioNavigator.push(this, "biz1/flutter1",
        mapOf("k1" to 1),
        false,
        poppedResult = {
            Log.e("Thrio", "native1 popResult call params $it")
        }
)

页面的 pop

dart
ThrioNavigator.pop(params: 'popped flutter1'),
objc
[ThrioNavigator popParams:@{@"k1": @3}];
kotlin
ThrioNavigator.pop(this, params, animated)

页面的 popTo

dart
ThrioNavigator.popTo(url: 'flutter1');
objc
[ThrioNavigator popToUrl:@"flutter1" animated:NO];
kotlin
ThrioNavigator.popTo(context, url, index)

页面的 remove

dart
ThrioNavigator.remove(url: 'flutter1', animated: true);
objc
[ThrioNavigator removeUrl:@"flutter1" animated:NO];
kotlin
ThrioNavigator.remove(context, url, index)

thrio 的页面通知

页面通知作为解决页面间通信的一个能力被引入 thrio，以一种非常轻量的方式解决了 topic_center 所要解决的问题，而且不需要管理 topic。

发送页面通知

dart
ThrioNavigator.notify(url: 'flutter1', name: 'reload');
objc
[ThrioNavigator notifyUrl:@"flutter1" name:@"reload"];
kotlin
ThrioNavigator.notify(url, index, params)

接收页面通知

使用 NavigatorPageNotify 这个 Widget 来实现在任何地方接收当前页面收到的通知。

dart
NavigatorPageNotify(
      name: 'page1Notify',
      onPageNotify: (params) =>
          verbose('flutter1 receive notify: $params'),
      child: Xxxx());

UIViewController实现协议NavigatorPageNotifyProtocol，通过 onNotify 来接收页面通知：

objc
- (void)onNotify:(NSString *)name params:(NSDictionary *)params {
  ThrioLogV(@"native1 onNotify: %@, %@", name, params);
}

Activity实现协议OnNotifyListener，通过 onNotify 来接收页面通知：

kotlin
class Activity : AppCompatActivity(), OnNotifyListener {
    override fun onNotify(name: String, params: Any?) {
    }
}

因为 Android activity 在后台可能会被销毁，所以页面通知实现了一个懒响应的行为，只有当页面呈现之后才会收到该通知，这也符合页面需要刷新的场景。

架构 2.0 的优势

在我们的业务上存在很多模块，进去之后是，首页 -> 列表页 -> 详情页 -> 处理页 -> 结果页，大致会是连续打开 5 个 Flutter 页面的场景。

这里会对 架构 1.0 和 架构 2.0 我们所使用的解决方案做一些优劣对比，仅表示我们业务场景下的结果，不一样的场景不具备可参考性。

在此仅列出两个比较明显的改善措施，这些改善主要是原理层面的优势带来的，不代表 thrio 的实现比 flutter_boost 高明，另外数据仅供参考，只是为了说明原理带来的优势。

thrio 在 iOS 上的内存占用

同样连续打开 5 个页面的场景，boost 的方案会消耗 91.67M 内存，thrio 只消耗 42.76 内存，模拟器上跑出来的数据大致如下：

thrio 在 Android 上的页面打开速度

同样连续打开 5 个页面的场景，thrio 打开第一个页面跟 boost 耗时是一样的，因为都需要打开一个新的 Activity，之后 4 个页面 thrio 会直接打开 Flutter 页面，耗时会降下来，以下单位为 ms：

总结

总的来说，引入 Flutter 是一个很明智的选择，人效提升是非常明显的。如果你的 App 对包大小不敏感，那完全可以尝试在项目中引入 Flutter。

当然过程中也遇到了非常多的问题，但相对于人效提升来说，解决这些问题的成本都是可接受的。

如果你想要无缝的将 Flutter 引入现有项目，thrio 可能会节省你很多精力。当然 thrio 是个非常年轻的库，相比于前辈 flutter_boost 还有很长的路要走，也欢迎有兴趣的同学给 thrio 贡献代码。

作者：稻子，就职于哈啰出行。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8