Flutter 在阿里淘系的体系化建设和业务实践

方滴云WEB2021-05-22 14:47

作为一个技术框架,Flutter 该有的功能都有了,但要把它应用到业务中去,还得解决工程问题、复用已有的技术积累、融入业务的工作流等,还要针对特定的业务场景做增强和扩展。所以,我们的核心目标是把 Flutter 从一个单点的技术框架,打造成完整的企业级解决方案。

Flutter 社区发展情况

在官方四月底的统计数据中,自发布以来的 16 个月内,已有 200 万开发者使用 Flutter,三月份的时候也有 10% 的增长,Google Play Store 中发布的 Flutter 应用约有 5 万个,仅在 2020 年 4 月就有近 1 万个应用上传。开发者所在的团队,初创公司最多,占了 35%,26% 是企业开发者,19% 是独立开发者,还有 7% 的设计机构。

Flutter 使用者数量排名前五的地区是印度、中国、美国、欧盟和巴西。很神奇,国内开发者对 Flutter 的热情比出生地美国还要高。从各种公开信息来看,头条、微信、QQ、美团、抖音、快手都对 Flutter 保持的密切的关注,而且已经不是小规模尝试了,有些公司已经铺开准备大规模建设了。

简单来讲,Flutter 的发展势头越来越猛,国内大公司都在建设,Flutter 更受新兴业务的青睐。

阿里淘系的业务背景

淘系业务面临较大的竞争压力,整个移动互联网的竞争也越来越激烈,为了吸引并留住用户,对产品的性能、使用体验和迭代效率都有更高的要求,像直播 / 短视频 / 沉浸式交互 /AR//3D 等新交互形式可以明显的提高业务竞争力,这些技术基本上都是原生能力,所以需要一个和原生技术结合度好,而且又能避免写重复代码的技术方案。Flutter 比较符合这个定位。

除了淘宝 App 本身,还有一系列淘系应用,如闲鱼、淘宝特价版、直播 App、躺平等新兴应用不断出现,整个阿里已经有 30+ App 在使用或者在尝试 Flutter 了,为了减少重复建设,需要沉淀出通用的技术能力,站在现存的技术积累之上,打造出完整的技术体系。

阿里在 Flutter 的技术积累

手淘从 Flutter 刚诞生以来就对它保持关注,2018 年开始就持续做技术探索,去年启动了 AliFlutter 的项目,希望可以拉通阿里内部 Flutter 相关的技术积累,有了一些初步的成果。

基础设施建设

首先标准化了 Flutter 的工程构建。有统一的代码仓库来管理 Flutter 的源码,有专门的升级发版节奏,确保可以跟进官方的迭代。客户端打包的环境配置比较复杂,还要和阿里自身的开发环境做融合,这些功能已经形成了平台和工具,也开放了部分功能让大家可以定制和扩展自己的引擎。

另外还提供了阿里内部的 pub 库实现包管理,类似前端的 npm,让 Flutter、Dart 的通用功能库有地方可以承接。

而且还与手淘的基础设施做了紧密结合。对接了内部的摩天轮(MTL)打包平台、性能稳定性监控的高可用平台,手淘基础的图片库、网络库、日志、埋点和一部分基础中间件。Flutter 的开发、测试、打包、集成、发布、运维监控等功能,都融入了客户端开发本身的工作流中。

完善 Flutter 的基础设施是后续所有工作的基础,让 Flutter 开发不再处于刀耕火种的工作环境。

内核增强与扩展

把 Flutter 落地到业务的过程,也不是一帆风顺的。性能倒不是瓶颈,但是包体积太大、内存占用高是经常遇到的问题,所以去年有一部分精力花在 Flutter Engine 本身的优化上,分析二进制产物的包结构,压缩 Flutter Engine 和 Dart AOT 编译产物的大小。分析 DartVM 的内存管理机制和 snapshot 功能,不断优化内存。而且有针对性的对图片库的内存、Engine 的启动流程做了优化。

在图形化方面,Flutter Engine 提供了一套兼容性和性能都比较好的图形接口,而且跨平台一致。所以基于 Flutter Engine 封装了 2D Canvas API 透出到 JS 环境,性能和稳定性相比之前的技术都有大幅提升。而且对接到了淘宝小程序的容器环境,支撑互动类的业务。

信息互通

在阿里内部建立了 AliFlutter 信息互通的虚拟组织,淘宝、闲鱼、特价版、飞猪、盒马、UC、钉钉、CBU/ICBU、优酷、本地生活、搜索、天猫精灵等 BU 都有接口人在参与,定期开会同步信息,避免出现重复建设。

另外在社区我们和 Google 官方团队也保持着联系,定期开语音会议。这个合作关系建立之后,在社区也可以混个脸熟,我们提的 issue 和 PR 说不定会被优先处理~

技术探索和实践

我们团队积累了 15+ 高质量的技术文章分享在内部的技术论坛,在原理分析、性能优化、应用和实践这三个大类里,分析 DartVM 的原理以及背后的 GC 和 Snapshot 机制,研究 Flutter 的渲染管线,思考 Web 生态和 Flutter 对接的方案,优化 Flutter Engine 的启动时间和包大小,解决实际业务中图片库接入、长列表内存占用高等问题。

目前待解决的问题

下图左侧是 Flutter 官方做过一次问卷调查,评选出了开发者实际开发过程中最关心的问题。


前六项任务摘录出来如下:

这是面向所有社区开发者的问卷,我们在实际业务中遇到的问题也类似,总结下来主要是对开发效率、调试测试、解决方案、功能复用的诉求比较强烈。说明 Flutter 作为一个新兴的研发模式,在工程、工具方面做得还不够成熟,生态还不够繁荣,尤其是贴合业务场景的解决方案比较少。

这些问题是我们下一步的工作重点,从实际的业务痛点出发,不断完善 Flutter 的内核能力和平台支撑,在保障产品质量和体验的同时,提升业务的交付效率。

总结与未来规划:Unicorn 独角兽

用「独角兽」项目孵化更多「独角兽」。快速迭代,野蛮增长!

解题思路

前面介绍了,这个项目的核心目标是:

  • 在业务视角,完善 Flutter 的研发模式和平台支撑,在保障产品质量和体验的同时,提升业务的交付效率。

  • 在技术视角,建设产品化的 Flutter 技术体系,将一个单点的技术框架,打造成完整的企业级解决方案。

为了实现上面的目标,我们从四个层面做建设,最下面是对 Flutter 本身内核的增强,然后再向上提供一站式的研发平台提升业务的迭代效率,同时也提供产品化的服务保障整个项目可持续迭代,最上面是业务支撑,解决在业务落地过程中实际遇到的问题。

这个项目并没有推翻任何积累,没有造新轮子,而是用更加体系化的方式,梳理在做的关于 Flutter 的事情,做一个整体规划,并且和集团内所有做 Flutter 技术的团队保持信息同步,以开放的心态做技术,技术成果互通互享。

整体规划

顺着上面的思路,把各项内容展开来看,是这个样子的:

整个项目是在之前的技术积累上进一步做建设,首要原则是降低对 Flutter 本身技术的侵入性,确保架构可持续迭代。因为 Flutter 还是一个快速迭代的技术,一旦开始分化,再跟进官方的进展就很难了,前期接入的业务就会成为历史包袱,要极力避免这种情况。

电商系的业务场景很复杂,不同场景的技术诉求也不一样,所以架构上要做到可灵活扩展,让垂直类的能力可以快速接进来,实现差异化。另外为了降低业务的使用成本,要保证功能的开箱即用,优化开发体验。

关于演进路线,Flutter 本身的技术特点也比较适合历史包袱比较少的新兴业务,所以优先考虑的是新型 App 和垂直类的业务,然后再推广到常规业务中。从技术角度是自底向上做建设,首先保障底盘的稳定性,而不是上来就搭花架子。对接好基础设施之后,下一步是为业务提效,然后再做扩展和对接,最后沉淀出靠谱的技术方案回馈社区。

基础能力增强

基础能力的建设和可以分为三层:

  • 应用层:这部分主要解决在业务实践过程中遇到的问题,提供解决方案。闲鱼是 Flutter 的技术先驱,在应用层有很多积累,比如 Boost(混合栈) 和 Candy(游戏化开发),除此之外我们还有正在做 DX Flutter 容器 (模板化 / 动态化渲染),卡片级嵌入 (multi-window) 等技术方案。

  • 引擎层:这部分逐渐走向技术的深水区,分别在启动链路、AOT 编译、DartVM、渲染管线、图形化 / 光栅化等领域做优化和增强,在业务无感的情况下,提升内核的性能和稳定性。

  • 对接层:这部分工作大部分已经完成,继续查漏补缺,不断完善使用体验。

一站式研发平台

回顾前面列的 Flutter 还存在的问题,大部分在于工程链路和生态不够成熟,这是业务使用 Flutter 时遇到的最大阻力。这部分带有业务属性的工作 Google 官方不会为你做,必须要企业自己来做。所以除了完善 Flutter 基础能力之外,面向业务场景,还要有全链路的平台和工具支撑,才能真正提升业务的迭代效率。

基于手淘首页在用的模板化的框架实现部分 UI 的动态化,加上 Flutter 的跨平台渲染能力,再结合 GAIA 端云一体化的研发模式,形成一个完整的研发闭环,从开发者视角整理工作流,用一个平台提供所有能力。目标是降低 Flutter 在业务中的使用成本,让开发者可以在 60 分钟内完成 App 首次接入,30 分钟内就可以开始写第一行代码。

业务支撑

整个项目首先支撑的是淘系 1+X 的 App,贴身解决业务遇到的实际问题。另一方面也会做一些产品化的事情,把可复用的技术方案沉淀下来,有地方承接和展示,而且会贡献代码和方案到社区,提升大家在公司内外的技术影响力。

产品化

整个技术产品的逻辑是 Cycle + Core,即「研发闭环」+「跨平台内核」。

跨平台内核是对 Flutter 本身的 Framework 和 Engine 持续做增强,保持和官方版本的同步,尽量将通用的代码合回官方仓库。研发闭环是根据当前的业务环境、结合已有的技术积累、提供平台支撑,把功能做得完备,而且好用。

核,深入研究引擎技术;环,不断提高迭代效率。

技术细节

前面是概述,其中几项具体的技术我可以简单介绍一下。

工程和效率

在真正的业务实践里,很少把一整个 App 都用 Flutter,基本上都是把 Flutter 当成一个模块引入,在开发和调试 时还依赖自身的各种库,如网络、图片、安全认证等。而 Flutter 的工具链是要基于壳工程来打包和调试的,很多情况下,在壳工程里没法实现完整的业务逻辑。

所以我们在 Flutter 工具链基础上提供了扫码开发的能力,直接使用完整的 App,如淘宝特价版,扫码连接本地环境,修改代码后可以实时在真机上预览实际效果。

除了对本地开发环境的增强,我们也在考虑和云平台的联动,借助 FaaS 的支持,实现在一个工程里、一套技术栈开发完整的应用逻辑。

模板化开发

Flutter 的动态化能力一直是比较弱的,然而电商系的应用对动态化有强诉求,在淘宝 App 首页和核心交易链路里使用到了一个模板化的渲染框架 DinamicX,可以动态下发模板来驱动页面渲染,使用到的组件以及绑定的业务逻辑是原生语言开发的,如 Java 和 Objective-C,不支持 JS 等依赖脚本引擎的语言,这样性能更好,审核风险更低。

我们正在把这一套成熟的模板化的渲染协议迁移到 Flutter 上来,既不破坏 Flutter 页面本身的性能体验,也在一定程度上提供了动态化的能力。

多 FlutterView 嵌入

在 Flutter 页面的某个区块使用原生组件可以用 PlatformView,还有一种情况是,在原生渲染的页面里,某一个区块是用 Flutter 实现的。也就是说,不拿 Flutter 写一个完整的页面,而是写一个(或多个)组件嵌入到原生页面中,这项能力在真实的业务场景中也是有诉求的。

Flutter 仓库的 issue 里也有人提出了 multi-window API 的需求,我们也在评估各种实现方案,关键问题是要不要在多个窗口间复用同一个 Engine 实例,以及如何管理多个 Scene 等。这方面我们也在开源社区里讨论技术方案,及时跟进这项功能的实现。

业务实践

闲鱼是使用 Flutter 技术的先驱,积累了比较丰富的实践经验,淘宝特价版也在大范围的使用 Flutter,期待业务开发者们给大家介绍更丰富的细节吧。