卷首语： Flutter 2.0 来了，而他们早已率先应用了 Flutter
作者：田晓旭
2020 年 3 月 4 日，谷歌发布了 Flutter 2.0，这个版本是 Flutter 的重大升级，开发人员可以基于此从同一代码库构建跨平台软件，并在任何平台上快速构建可移植的应用程序。
2018 年 12 月 5 日，Google 在 Flutter Live 上宣布正式发布 Flutter 1.0 。当时，Flutter 的主要目标还是 iOS 和 Android。而现在 Flutter 2.0 支持使用相同的代码库将本地应用程序发布到 5 个操作系统，分别是 iOS、Android、Windows、macOS 和 Linux，甚至它还可以嵌入到汽车、电视和智能家电中。
Flutter 2.0 的发布意味着 Flutter 已经从移动开发框架扩展为一个可移植框架，对于 Flutter 的应用，很多开发者都跃跃欲试。根据谷歌 2020 年公布的数据来看，截至 2020 年第一季度，Flutter 共吸引了超过 200 万开发者，每月活跃的开发人员数量有将近 50 万，Google Play Store 上的 Flutter 应用约为 5 万个。而现在，Google Play Store 上 Flutter 支持的应用程序已经增长到 15 万个了。
一个新技术的普及，企业级应用一定会先在头部互联网企业产生，并逐步优化降低门槛。那么国内都有哪些企业率先实践了 Flutter？他们具体是怎么应用的？下面我们总结了一些比较典型的企业应用案例。
贝壳 Flutter 混合容器实践
通常纯 Flutter 应用的页面路由直接由 Flutter 自身来管理，但是对于原生 App 要引入 Flutter 技术，就会涉及原生页面与 Flutter 页面之间切换，此时的页面路由需要单独管理和实现。
在实践 Flutter 混合容器时，贝壳对比了 Flutter 官方和闲鱼 FlutterBoost 两种实现方式。通过八个方面的对比，最终选择了在整体方案上采用官方 1.12 的共享引擎的方式，在路由管理的实现上借鉴闲鱼 FlutterBoost 的实现。
贝壳容器方案整体架构图
具体实践：《贝壳 Flutter 混合容器实践》
美团外卖 Flutter 动态化实践
美团外卖的用户端和商家端因为业务特点不同，因此采用的技术方案也不同。用户端的用户量庞大，对动态性要求更高，在低 PV 页面使用了 RN 来做页面级的跨端动态化，而在高 PV 页面使用了自研的区块级动态化和触达提升；商家端页面复杂度更高，用户端实现的小功能，在商家端配置时有很深的层级和复杂的联动组件，同时商家端还会关联到发配送等复杂逻辑，因此商家端在选型时更看重跨平台框架的性能瓶颈与双端一致性。
早期，美团外卖商家端也曾尝试使用 RN 作为跨平台的技术方案，但过渡版本无法达到预期的要求。这时，Flutter “多端一致”和“渲染性能”上的优势让美团外卖团队眼前一亮，因此决定选用 Flutter 方案。但当时 Flutter 仍处于发展阶段，很多功能和解决方案都不完善，尤其是在动态化方面，还没有成熟且大范围落地的方案，而美团外卖商家端业务发展对于动态化需求又非常强烈，因此美团外卖内部立项了 Flap 项目，专门来支撑 Flutter 动态化能力。
美团 Flap 项目是一套完整的业务解决方案，支持大厂应用的复杂业务，而不是重展示轻交互或是 UI 与动态模板的方案。Flap 项目使用纯 Dart 语言实现，在不引入其它技术栈的情况下，实现了视图与逻辑一体化的动态化方案。
据了解，截至 2020 年底，美团外卖业务已经真实上线了 100+ Flap 页面，40+业务模块。商家端的跨端与动态化覆盖度达到 90% 左右，同时在多个业务线实行需求动态发布流程，可动态上线的需求占比 60~80%。
具体实践：《纯 Dart 的挑战：美团外卖 Flutter 动态化实践》
京东技术中台的 Flutter 实践
京东很早就开始研究跨端的开发解决方案，最早使用的是 Hybrid App 技术方案，2015 年底开始转向 RN 技术栈，2018 年中，开始关注 Flutter 技术。
随着京东内部越来越多团队使用 Flutter，京东内部发布了 JDFlutter 引擎。在 Flutter 官方引擎的基础上，做了功能扩展和优化，包括 Flutter 工程改造、路由及多页面管理、扩展 UI 组件库、原生能力扩展和 Android 端动态化支持。
JDFlutter 整体框架结构
具体实践：《京东技术中台的 Flutter 实践之路》
飞猪 App 的 Flutter 实践
2013 年，随着阿里巴巴 All in Mobile，飞猪（当时还叫阿里旅行）也有了独立的 App。随着业务的不断发展，App 变得越来越臃肿，技术改造带来研发效率/性能体验提升的同时，也增加了维护的复杂度。由于旅行业务域逻辑复杂，在实际交付时会出现两端开发理解偏差引发的线上问题，例如机票交易链路因为漏测引发线上故障。
从技术方案来看，两端的具体实现依赖原生能力，系统平台层的差异带来了业务表现的差异，这需要更底层的技术方案来解决。在对比了 Native、动态模板、H5、Weex、Flutter 等多个方案之后，飞猪最终选择了 Flutter。
2019 年，飞猪开始在商家版 EBK 改造项目上试水 Flutter，在研发效率和用户体验上都有不错的收益。随着 Flutter 混合技术栈的完善，2020 年飞猪 Android 端在机票航变和酒店相关简单业务做了 Flutter 试水，对接的首个版本是 1.12，最终稳定性和性能都符合预期，类似机票航班详情页的需求一人就可以完成。
具体实践：《飞猪 Flutter 技术演进及业务改造实践》
Flutter 2.0 发布带来了更多的功能和特性，随着插件生态的丰富和社区生态的完善，相信 Flutter 的进入门槛会进一步降低，期待未来有更多的企业实践案例。
目录
热点 | Hot
又一个技术风口来了
Docker 起死回生了
观点 | Opinion
企业架构方法论可以简化吗？
推荐文章 | Article
从 0 开始构建核心业务微服务治理平台的实践
30 万行代码的平台升级：给跑着的汽车换轮胎
评论