迈向Flutter深水区：美团外卖Web-App一体化架构实践

　　今年 1 月，一篇《让 Flutter 在鸿蒙系统上跑起来》的文章引起了社区的关注，为了解更多美团外卖的 Flutter 落地进展，近日，我们采访了美团外卖商家终端团队负责人陈航，他透露，美团外卖商家 App 的鸿蒙适配正在推进落地中，不仅如此，最近半年他们也在探索基于 Flutter Web 体系的 Web-App 一体化架构，这两个部分目前在业务上都有比较大的进展，相关的技术案例也将分别在 ArchSummit 全球架构师峰会（上海站）2021 和 GMTC 全球大前端技术大会（北京站） 2021 跟大家分享。

　　1美团外卖 Flutter 落地的 4 个阶段

　　InfoQ：老师可否跟大家介绍一下 Flutter 现阶段在美团外卖的落地情况？谈谈你们的落地规模、做了哪些优化。

　　陈航：我们围绕 Flutter 所做的工作主要可以分成 4 个阶段：美团终端研发生态打通、自建动态化、Web-App 一体化架构、鸿蒙适配。

　　早期我们关注点在于移动端复用，所以工作重心更多集中在如何小成本整合美团已有的终端基建资源，去搭建公司级的研发生态 MTFlutter（包括工具链、组件库、插件等等），快速推进 Android、iOS 页面基于 Flutter 技术体系的大规模复用，同期我们搭建的 MTFlutter 生态也支持了公司内多个不同体量业务的线上应用。

　　处于合规和安全考虑，Flutter 官方是不支持动态化的。Flutter 在业务上试点效果满意，为了确保技术体系的延续性，实现流程优化和协作解耦，我们也花了一些精力去探索在 Flutter 上做动态化，确定了的方案。特点是保留原有开发习惯，不涉及技术栈切换成本，可快速迁移现存页面。我们目前 90%+ 的业务实现了双端复用 + 动态化，保守估计总需求的 60%（部分业务线需求近 100%）可以实现按需发布，从实际运转的效果上看，走动态发布的需求，从需求评审到最终上线，比之前客户端跟版平均缩短了 50～60%。

　　最近半年我们在探索基于 Flutter Web 体系的 Web-App 一体化架构，同期也在关注鸿蒙的适配，这两个部分目前在业务上都有比较大的进展：在 Web 领域，我们实现了美团已有的前端基建与 MTFlutter 研发生态的打通，有两条 Web 业务线实现了和 App 的一体化复用，还有 20 多个 App 页面具备了外链能力，可以支持分享到微信，这块内容会在 6 月份的 GMTC 北京 2021 上与大家分享；在鸿蒙上，我们基于 Flutter 1.22 版本，成了鸿蒙 API 的实现，适配的 Demo 已经跑通，自有 App 的适配也在推进落地中，这块的最新进展也会在 4 月份的 AS 上海 2021 向大家介绍。

　　InfoQ：为什么选择在 B 端大规模落地呢？

　　其实原因很简单，我们 B 端的终端类型足够多，业务提效诉求很强。美团外卖商家端业务围绕数百万商家，在 PC 和 APP 上分别提供了交易履约、运营、广告、营销等一系列功能，并且经常有外投 H5 的场景（如外卖学院、商家社区、营销活动等）。在这种多形态的业务场景下，如何保障多端体验一致性、如何提升多端迭代效率一直是产研关注的重点。正因为终端类型足够多，所以对于我们而言，提升产能的核心是找到可以实现低成本跨多端的官方框架。最低要求是跨安卓和 iOS，最好是能把 Web 也跨了，Flutter 就正好满足我们的诉求，我们的四个端他全官方支持，甚至 Windows、Linux、Mac 和嵌入式系统都支持，像鸿蒙这类官方不支持新系统我们也能低成本支持，后续只要业务有场景，我们可以快速迁移到新的平台上（比如智能硬件）。

　　InfoQ：在这个过程中，你们遇到过一些比较大的问题吗？

　　技术的问题有很多，小的像早期 SDK 的兼容适配问题、内存问题、指标口径对齐问题、引擎优化问题等等。我们自己内部也 Fork 了一套官方 SDK，把大部分问题都解决（或者绕过）了，少数疑难问题也基本上随着 Flutter 版本的升级得到了缓解。

　　大一点的问题主要是涉及到 Flutter 引擎深度介入的部分。比如在做自研动态化时，运行时语法支持完整性和视图逻辑联动的工作量巨大，给团队带来了很大挑战。在分析了语言底层特性和工具特性后，我们运用官方工具（Analyzer、BuildRunner、Reflectable、 Visitor），通过对语言特性（万能方法、仿真函数、注解）进行适当的抽象聚合，减少了 60% 以上的工作量。整体架构遵循敏捷原则设计，让功能完善类似搭积木，且能够应对变化。

　　非技术的问题主要还是在现有终端技术体系之下，确定 Flutter 的定位。前期我们做了比较充分的技术调研和储备，通过大量灰度测试和验证，从原理、实践以及数据角度明确了技术的可行性。后期我们结合业务实践反哺技术打磨，逐步推进了业务的复用扩量。研发效率的提升让业务侧也尝到了新技术带来的收益，我们工程师向 PM 最初夸下的海口最终都说到做到，积累了不错的口碑，也建立了稳固的信任，一路走来节省的人力和稳定的线上表现足够抵消新技术引入带来的忧虑。

　　InfoQ：今年你们还计划重点做哪些事情？

　　陈航：主要还是现有工作的延续，大的方向是扩大 Web-App 一体化架构的业务落地场景、完成自有 App 在鸿蒙系统的适配，以及完善对应的工具链、建立新终端的指标基线、性能优化等等。

　　2MTFlutter：Web-App 一体化实现

　　InfoQ：老师在前面提到，你们在 Flutter 上还做了很多新的尝试，除了在鸿蒙落地之外，还将 Flutter Web 落地到了 B 端。为什么选择在 B 端落地 Flutter Web 呢？

　　陈航：这块比较明确。Flutter 能跨的端足够多，我们外卖商家端的四个端（Android、iOS、PC 和 H5）他全官方支持。早期 Flutter Web 还不太稳定，我们的注意力更多在移动端。在我们已经通过 Flutter 技术体系，把业务共性最多的 Android 和 iOS 实现了 90%+ 的代码复用之后，同期 Flutter Web 也进入了 Stable 状态，因此我们很自然的会把复用的思路延伸到 Web 体系上：一方面把 PC 和 App 有业务共性的部分复用了，保持 Web 的灵活同时实现 App 端原生的体验；另一方面 H5 可以直接复用 App 页面，实现外链分享。

　　InfoQ：美团本身有动态化技术，这部分跟 Flutter Web 的适用范围是怎么区分的？

　　陈航：这两个技术都有能动态发布的特征，但关注的不是同一件事。动态化是面向 App 技术体系的，目标是做 App 研发流程优化和协作解耦，实现业务需求能够真正按需发布，而不用跟版解决。Flutter Web 是面向 Web 技术体系的，目标是拓宽业务代码复用的边界，实现 Web 项目与 App 项目的代码共享。

　　InfoQ：目前应用来看 Flutter Web 最大的收益是什么？落地成果是否达到了你们的预期？开发效率怎么样？在做的过程中，遇到过哪些挑战？是否找到了合适的解决手段？

　　陈航：刚才有提到，我们外卖商家端的客户端类型比较多，Flutter Web 能够帮助我们把 Android/iOS 的代码复用延伸到 Web 体系里，实现 Web-App 一体化架构。过去我们关注 Android 和 iOS 的复用，目前 Flutter 技术栈已经覆盖了 App 90%+ 的业务，具备 Flutter 开发能力的同学占比也达到了 90%+，所以我们已经有了很好的技术储备，能够基于 Flutter 去做全平台（Android、iOS、PC、H5）复用的探索。毕竟花同样的研发成本，复用 App 之后能顺带把 Web 相似的页面也一起复用了，ROI 是很高的。

　　从现有的成果上看是符合预期的：我们目前有两个业务线实现了基于 Flutter Web 的一体化架构，还有一些 App 页面简单改造后就具备了外链 H5 的能力，这些业务的代码在 Web 和 Native 是完全复用的；性能上我们经过 SDK 的优化定制后，Flutter Web 与现有 Web 项目在页面滚动上的指标差距已不大，可满足日常业务要求，首次加载的时间还有一定优化空间，我们也会持续对其进行探索。

　　我们的 Flutter Web 在项目设立之初，就定位为 MTFlutter 研发生态的一部分。所以除了 Web 基础设施的搭建对接、项目的构建部署之外，在容器桥、页面路由、请求封装、前端监控等方面上也尽可能的去复用 Native 的设计，减少多端的技术差异性。目前在试点项目的研发上， Flutter Web 的开发效率和 Flutter App 基本保持一致，人力大致节约了一半。考虑到 Web 体系与 App 体系的实际差异性，有 10% 左右的适配兼容的成本，整体上还是还是很不错的。

　　挑战主要有两点：

• 　　加载性能问题：Flutter Web 项目构建只暴露了 Flutter Build Web，我们无法直接进行更细粒度的个性化定制。并且构建产物也比较简陋（只有一个 main.dart.js），缺少对静态资源的优化，影响页面加载性能。我们对编译流程进行了干预，补齐了这部分功能，使得项目能满足基本的投产要求

• 　　滚动性能问题：在 HTML 编译模式下，Flutter Web 实现了一套页面滚动机制，页面滚动过程中，会引起滚动区域中的 Canvas 被频繁创建，最终导致页面滚动性能较差。我们对 Flutter SDK 进行了改造，页面滚动时，Canvas 是被缓存起来而不是重新创建，对滚动性能有比较明显的提升，足以应对大部分业务场景

　　3Flutter Web 是否值得尝试？

　　InfoQ：你认为 Flutter Web 还有哪些想象空间？如果其他团队也想实践，你有什么建议可以给到他们吗？

　　陈航：3 月 4 日 Google 官方发布了 Flutter 2.0，至此我们可以说 Flutter 真正做到了以应用为中心，达成了全平台的支持。Flutter 2.0 的发布，稳定了对 Web 渠道产品级可用的能力，同时默认采用 CanvasKit 编译模式，对页面滚动性能有较大提升。但由于 canvaskit.wasm 文件过于庞大 (2.5m)，降低了加载性能，因此目前不是很建议在 Web 项目中直接使用 CanvasKit。不过官方承诺会在 2021 年对性能进行整体优化，还是值得期待的，我们也将保持跟进和沟通。另一方面，Google 官方目前对 Flutter Web 的工作主要还集中在 Dart:ui（Web）的对齐，Web 工程化的事项做的还比较少，为此在实际的业务落地中，为了接近常规 Web 项目的体验，我们也对 Flutter Web 的引擎和 SDK 做了一些改造工作。也期望在未来的更新里，官方 SDK 能够将构建打包暴露出更多定制化的接口和时机，让开发者可以通过构建工具对产物进行预处理（比如资源文件 Hash 化、CDN 化、按需加载处理等），提升页面的加载和渲染性能。

　　Flutter 的核心竞争力是多终端平台代码复用，Flutter Web 是 Flutter 技术体系的一部分，我们不能脱离这个体系去只谈 Web 渠道的应用。所以是否实践，取决于项目中之前是否已经应用了 Flutter。如果项目里已经有一个 Flutter 移动应用：

• 　　对于没有 Web 版本的项目，可以直接使用同样的代码来构建其 Web 版本，然后把应用的用户群从移动扩展到 Web 渠道

• 　　对于有 Web 版本的项目，可以收敛 Web 渠道与移动渠道的视觉 & 交互差异性，在 Web 上尝试去复用移动应用的代码，减少多端开发的成本

　　目前在产品级应用上，Flutter Web 的表现已经比较稳定，和常规的 Web 项目差距并不大。不过 Flutter Web 官方依赖的开发生态比较新，实际业务为了兼容低端机和旧操作系统，开发生态往往比较陈旧，因此在性能体验兼容度上，大型项目实践中还是需要有一定的备选或降级方案。从原理上看，Flutter Web 本身已经不是问题，只是为了性能和兼容性考虑，还是需要做一些深入细致的优化工作。

　　陈航，美团高级技术专家，曾就职于雅虎北研和新浪微博，2015 年加入美团，经历了外卖用户端和商家端发展的多个阶段，推动了外卖移动端架构演进、线上运维及终端技术栈融合等相关工作，致力通过终端技术的发展演变提升团队研发效率与交付质量。最近两年作为外卖商家终端团队负责人，带领团队完成了基于 Flutter 的自研动态化技术在业务全面部署，同时沉淀了美团研发生态 MTFlutter，支撑了公司多个业务发展。

　　陈航也是 AS 上海 2021【Flutter 一线实战】专题的出品人，他在文章中提到的两个最新技术方案，将分别在 AS 上海 2021 和 GMTC 北京 2021 分享给大家，除此以外，这两个会议上还有更多 Flutter 的最新实践，比如阿里的 Kraken、Google 的混合集成 PlatformViews 解析应用、闲鱼的企业级 Flutter 落地思考。主编悄悄告诉大家，还有更多重磅内容正在打磨，很快上线官网，感兴趣的同学可以期待一下。