纯 Dart 的挑战：美团外卖 Flutter 动态化实践 _Flutter

“一套代码，多端运行。”是很多开发团队的梦想，直到 2018 年 12 月 5 日，谷歌正式发布 Flutter 1.0 版本，前端开发者向这一梦想前进了一大步。Flutter 仅用了不到一年的时间就在 GitHub 和 StackOverflow 上获得了比 React Native 更高的知名度。Flutter 提供了一整套从底层渲染逻辑到上层开发语言的完整方案，有跨平台、高保真、高性能等优点。也正因为这些革命性的优点，从发布到现在，它的热度一路攀升，受到了很多开发者的热切青睐。目前各大公司的 Flutter 落地实现各有不同，此次 InfoQ 采访人员采访到了美团外卖的技术专家，Flap动态化项目的负责人董尚先，为我们分享了美团外卖采用 Flutter 的实践与经验。（相关视频分享已在线上录制完毕，预计在1月左右放出）

选择技术栈要看业务特点美团外卖的用户端（下文用 C 端表示）和商家端（下文用 B 端表示）分别采用了不同的技术方案，原因是两端的业务特点不尽相同。二者均有美团标准化的 web 容器，但 C 端的用户量更大，对动态性要求更高，在低 pv 页面用 React Native 来做页面级的跨端动态化较多，在高 pv 页面使用美团外卖自研的区块级动态化和触达提示，最终支撑外卖 C 端的动态性业务需求。
相比之下，B 端的页面复杂度更高，C 端商品上的一些小标签，小按钮，在 B 端配置时有很深的层级和复杂的联动组件。此外，B 端需要关联到发配送，打印机等复杂逻辑，在实际开发时更加耗时。所以，B 端在技术选型时更看重跨平台框架的性能瓶颈与双端一致性。初期，美团外卖商家端也曾尝试过用 React Native 作为跨平台的技术方案，但过渡版本无法达到预期的要求，所以后期站队 Flutter 技术栈。
确定技术栈后的思考Flutter 的“多端一致”和“渲染性能”上的优势让其他跨端方案很难比拟。虽然 Flutter 的成长曲线和未来前景看起来都很好，但不可否认的是，目前 Flutter 仍处在发展阶段，很多大型互联网企业都无法毫无顾虑地让全线 App 接入，而其中最主要的顾虑是包大小与动态化。
首先是包的体积问题，有很多大厂都做过 Flutter 的产物瘦身与包体积瘦身，美团也对此进行了尝试，最终优化后 Android 的包体积降低了 95% 左右，IOS 降低了 30% 左右。
其次是动态化，其实动态化与包体积之间是存在联系的：动态化可以带来动态性，从而可以动态下发 bundle，就可以间接地减少包的体积。目前尚未看到成熟且大范围落地的动态化方案。与此同时，美团外卖商家版的业务发展对动态化的诉求越发强烈，因此美团内部立项了 Flap 项目，目标就是支撑 Flutter 动态化能力。
为什么要用纯 Dart 的动态化方案可能基于其他语言做动态化的惯性思考来看，相对方便点的实现是用 Dart 做视图 UI 部分，采用 JAVAScript 处理逻辑，事件回调的时候用 callbackid 来标识，这样的做法会带来很多限制：

开发时要分开写；
将存量的Flutter普通页面迁移到动态化成本太大;
运行时跨端通信损耗；
并且视图和逻辑需要完全隔离的，视图中的逻辑部分很难处理。

美团 Flap 项目的基本目标是做一套完整的业务解决方案，支持大厂应用的复杂业务，而不是一些重展示轻交互或是 UI 与动态模板这样的方案。因此仅使用纯 Dart 语言去做，在不引入其他技术栈的情况下，攻克视图与逻辑一体化的动态化方案。这么做的好处基本就是上面列出的那些限制的反面：

可以保持开发习惯与普通 Flutter 一致；
写完后的代码可以在 Flutter 动态化和 Flutter 普通（AOT）上同时运行；
并且在运行时没有跨端通信的损耗；
最大的优点是可以迁移存量页面。Flutter 已经发展了一段时间，各个大厂都有大量的 Flutter 存量页面，使用常规方案迁移至动态化就需要重写代码，使用此方式可以接近 0 成本将其迁移至动态化，不用更换语言重新开发。

纯 Dart 所带来的挑战Dart 是一种强类型、跨平台的客户端开发语言。具有专门为客户端优化、高生产力、快速高效、可移植（兼容 ARM/x86）和原生支持响应式编程（Stream & Future）等优秀特性。Dart 语言既有静态语言的特性，也支持部分动态语言的特性。
使用纯 Dart 的方式开发动态化的难点在视图逻辑一体化。相当于在 Dart 侧开发一个针对 Flutter 语言特性的解释器，需要对 Dart 整个语法特性有非常全面的认识。这里面的工作量也是很多的，我们在前期需要做很多的评估与拆解：