Flutter 在数字生活的发展与天翼云盘落地实践

Flutter 是当前 IT 行业跨平台技术中最热门的选型，可在不同设备保持一致的用户交互，同时借助渲染引擎以及高性能代码运行时达到跨平台设备的高质量用户体验，并有效解决降低人工成本。

天翼数字生活始终致力于新型技术的积极探索和实践，核心技术的开发和应用均使用市面上前沿的技术，于是希望把 Flutter 打造成新一代研发移动端开发体系，支撑众多项目的各种业务场景，满足人民日益增长的美好数字生活需要，激发数字化应用潜力，赋能千行百业数字化转型。

1 Flutter 在数字生活的现状

1.1 跨平台的发展历程

随着移动互联网和项目的不断发展，越来越多的业务功能都要求满足不同设备和场景，且需要保持功能交互的一致，于是跨平台技术就应运而生了，下面我们就一起来了解一下跨平台开发技术的重要性。

移动端的跨平台技术发展主要分为六个个阶段，这些阶段代表主要分为：HTML、Cordova、lonic、React Native、Weex 和 Flutter 等，如下表所示：

1.2 跨平台的优势

上面介绍了跨平台技术的发展历程，那么跨平台究竟存在什么好处？

• 开发高效性

使用跨平台解决方案，开发者通常只使用一套代码就可以兼容运行在 iOS、Android 或 WEB 平台上，而不需要分别开发。跨平台 APP 可以在不同平台之间重用代码是大多数项目选型时最主要的优势。

• 性能优越性

通过“自绘 UI+原生系统”实现高帧率的流畅 UI，性能更接近原生。使用 Skia 作为 2D 渲染引擎，使用 Dart 语言作为运行，以及使用 Text 作为文字排版引擎。

• 维护便捷性

同一套代码不仅降低了初始构建期间的成本，而且对你的应用程序的使用寿命也将是有益的，还可以共享单元测试。

• 交互一致性

在跨平台开发中，可会处理大多数流行的 UI 差异。在原生开发中，Android 和 iOS 的开发者在实现功能方面也可能会有一些差异。在跨平台开发中，这种情况很少发生，因为平台使用同一套代码，达到交互一致的效果。

1.3 为什么选择 Flutter

跨平台开发就是只用一套代码就可以在 Android、iOS 等多个平台运行，避免了过高的维护成本，节省了大量时间与资源。跨平台开发是当下最受欢迎、应用最广泛的框架之一。能实现跨平台开发的框架也五花八门，比如 HTML、Cordova、lonic、React Native、Weex 和 Flutter 等。有很多框架因为性能不佳等各种原因已经渐渐退出历史舞台。下面对各个跨平台技术进行横向对比。

从横向对比的结果图可以看出，Flutter 无论从性能体验与开发效率中，都优于其他的技术框架，所以我们技术团队便选择了它。Flutter 是由谷歌开发的强大开源应用开发框架，于 2017 年正式亮相，据 Statista 研究报告，Flutter 目前在 39% 的开发者中被评为首选跨平台应用程序开发框架。

性能体验与开发效率作为官方一直在宣传的两个重点，这里就不过多赘述。除此之外，我们还看中了 Flutter 的交互一致性，这里的高度一致性不仅仅指各平台 UI 一致，更重要的是各个平台运行的是同一份代码。于是我们想以较小的成本、较短的时间、较少的代码快速迭代项目需求，Flutter 无疑是最佳的解决方案！

我们来看一致性，上面是 Flutter 写的一个天翼云盘服务页面（Android 和 iOS），在 Android 和 iOS 几乎一样。UI 小姐姐设计 UI 时往往希望多端体验一致，它可以做到高度一致。

本文结合天翼云盘团队在 Flutter 改造的实际，从架构改造、基础能力、能力拓展和开放赋能四个方面，分享了在落地过程中天翼云盘是怎么做，实施的主要过程是怎样的，在实施过程中会遇到哪些问题又是如何解决的，本文将和大家一起探讨这些问题，希望对你有所帮助。

2 天翼云盘的 Flutter 架构

2.1 天翼云盘如何与 Flutter 结合

天翼云盘经过分析现有工程的特点以及结合 Flutter 的特征构建一套可扩展，分离松耦合的结构体系。其中 UI 与业务代码作为独立 Flutter 工程，部分功能采用库形式加入到 Flutter 的独立项目中。原生 Android 与 iOS 分别使用独立的工程，用独立的构建工具编译原生代码。

而 Flutter 构建项目通过特定脚本生成库成品，推送到特定的制品库，原生工程通过中台获取后编译。也可以通过修改引用方式，引用本地代码，方便开发调试，具体的结构如下：

2.2 天翼云盘开发架构

天翼云盘采用 MVVM 设计模式，通过统一路由器驱动，其中 ViewModel 部分作为整体的核心控制页面，View 则是组件和页面内容负责显示，Model 则是结合业务和模型的组件，通过 Plugin API 与原生进行交互，具体如下图：

其中，Page 通过 PageState 的 build 方法，渲染整个页面，Page 接收到参数将会传递到 PageState 中，而 PageState 要渲染其他控件，可以直接包含其他的 widget 到 build 中，而 widget 提供 controller 给 PageState 控制这个控件的数据交互。

对于某些页面的操作，可以通过 Helper 类进行操作，例如底部的菜单栏，可以抽取到 Helper 类中，只要使用到底部菜单的页面，都只需要引入对应 Helper 就可以了。

对于页面自身的业务逻辑，通过 ViewModel 去管理，ViewModel 最终会调用业务类 Business 类进行操作，其中业务类主要有两类操作，一类是网络请求 Domain，一类是原生桥接操作 Plugin。

剩余工具类和消息总线，都是可以用于任意位置，方便减少重复的代码和冗余问题。具体可以参考下面的图示：

2.3 天翼云盘技术全景图

天翼云盘 Flutter 技术全景主要把业务与基础功能分离，具体业务作为顶层，下方是 Dart 构成的能力层，包括 UI 组件能力，通用能力如网络传输、图片加载、消息总线等等，还有日志控制，异常处理。

而对应原生的能力通过虚拟机采用统一路由管理和 PluginAPI 两部分处理页面跳转与能力互换。

与之平衡的包括自动构建部署能力、打包加固发布中台能力。运营运维则包括远端策略下发，布局配置、消息推送、升级配置与全链路日志等等。其结构如下图：

2.4 天翼云盘建设规划路线

由于天翼云盘业务功能多，项目周期紧张，往往需求的工作量均集中在界面 UI 部分，而 Flutter 的一致性和高效率恰好能解决天翼云盘项目组的难题，于是我们针对效率提升高和改动成本低的功能模块进行改造，达到 Android 和 iOS 统一交互的效果。

针对于云盘庞大的工程改造我们制定了三步走的计划去重构现有工程，一期主要是包含主要功能模块的基础能力构建和 UI 组件重构，二期主要包含了日常的监控运维模块、安全加固、自动部署构建，三期主要包含了现有路由的重构、移动中台组件库的输出以及输出技术能力。经过这三期的改造计划天翼云盘已经完成了可改造功能的全部 Flutter 化，大大缩减了人员后续维护和开发的时间。

后续还会实现全平台大一统的目标，适配最新的 Flutter 3.0、Plugin API 2.0，改造 Flutter 的容器实现全平台兼容、模块化分离、热更新等技术。

3 天翼云盘的工程实践与演进

3.1 一期-基础能力建设

3.1.1 网络传输能力

由于天翼云盘请求接口场景十分复杂，首先要保护用户的隐私，然后要确保用户数据安全，解决用户连接传输速度问题。加上原来的原生已经实现了一套完整的网络框架核心，它的稳定性无容置疑，经历了时间的考验。

为此我们在原有的核心基础上，增加了 Cronet 处理 Http3 请求，Okhttp 处理 Http1/2 请求，中间采用 MdHttpClient 作为代理是屏蔽底层实现。而协议方面采用 Restful API，通过 retrofit 方式接入。其中上层接口则是通过 Mdmp 中台容器接口与 Flutter 插件接口转发 Flutter 的网络请求，达到一套应用，同一套网络框架，减少问题产生，方便排查问题。

其架构如下图：

3.1.2 图片加载与缓存设计

由于天翼云盘的图片接口是定制的，并且图片请求中包含了加密和部分安全问题，导致目前 Flutter 官方提供的组件不满足我们平时开发的需求，所以我们封装了一套契合自己加密需求和缓存需求的框架。

由于天翼云盘有图片列表或图片墙这种图片很多的模块，我们需要对目前已有的 Flutter 图片 组件进行优化和封装，因此我们封装了一套自己的图片请求框架 robust_image。本框架做了以下的优化。

• 对网络图片进行三级缓存，并采用 LRU 算法管理缓存

• 优化异常处理机制

• 针对多图加载提供了多任务加载图片的机制

• 提供不同平台本地图片 uri 的解析问题

• 针对于请求时的加密和安全问题进行了处理

框架主要流程图和架构图

结合 robust_image 云盘的很多图片类的业务需求也能够很快的迭代开发，同时减少了团队人员重复开发的，节约了大量人力成本。

3.1.3 统一 UI 组件

由于业务需要，UI 组件设计日新月异的变化，每次改版之后，控件可能都需要大量的修改。只有通过统一组件才能解决这些问题。由于 Flutter 是新使用的平台，所以我们设计了一套统一的 UI 组件来解决这个问题。

这套组件分为三个部分，设计规范与工具、设计基本组件、高度集成组件。

其中设计规范工具包括色彩配置文件、字体家族、国际化、全局样式控制、暗黑模式等等。

设计基础组件包括 Base、Animation、Layout、Navigation、View 五部分，其中 Base 主要包括一些基本的图标、按钮等；而 Layout 则是构成页面的布局体系，其中包括容器布局、线性布局、流式布局、弹性布局、堆栈布局、卡片等；Navigation 主要包括导航相关的控件，包括底部按钮集合、文件菜单、全局导航、模态与非模态加载；View 包括全局弹窗等。

而高度集成组件通过基础组件扩展出来，包括页面状态控制器，下拉刷新列表，文件列表、TabBar 控制器、帧动画、Lottie 动画容器、各种业务分离的独立功能组件。

实现可配置、易修改、可扩展的简易通用组件体系，其组织如下图：

3.1.4 统一消息总线

由于原有原生中存在一套通讯总线，而 Flutter 中又有一套自研总线，为了达到两个消息统一，我们设计了 Flutter 端采用一个 bus agent 负责处理原生发送过来的消息，通过 Virtual Publisher 进行发送到 Flutter 端总线。而 Flutter 的事件会通知一个 Virtual Subcriber 然后通知 Bus Agent 发送到原生处理。

原生侧则通过 PluginAPI 进行交互，利用 Message Plugin 的 invoke 与 onChannel 操作分别处理原生的通知与接收事件。

所有转换逻辑通过 BusAgent 或者 Plugin 转换，达到通知一致性。其结构如下图：

3.2 二期-能力拓展

3.2.1 动态配置下发

由于采用的 Flutter 设计页面布局，不像传统 HTML 页面可以随时通过修改代码更新用户展示的数据，但是运营又希望获得更加自由的配置方式。

为此诞生了一种动态配置的方案：首先通过把所有的界面组件分离独立，每个组件类型分开设计，通过一个布局配置排序组件展示结果，而每个组件独立请求接口获取显示的数据，从而极大丰富了页面配置的能力。

下面我通过服务页面的流程图分析一下如果实现此类方案，首先通过用户打开页面后展示默认或者缓存的布局，通过请求布局接口，省份运营接口获取当前省份的运营信息，展示对应的布局，然后各自组件请求接口刷新渲染，最终展示给用户。

通过一系列改造后，天翼云盘的首页达到自由配置的方式，运营哥哥姐姐都非常满意。

3.2.2 全链路异常处理

对于一个应用最重要的是要保证应用的稳定性。其中稳定性要保障首先是研发过程中保证充分测试之后才上线，但是现实上线后往往会出现意想不到的情况，对于这些问题的查看，我们希望通过一个链路完整去还原用户的行为，分析用户的数据，准确地解决这些问题。

为此我们设计了一套日志与异常处理全链路跟踪模型，其中包括一个跟踪代理，主要负责埋点与用户行为统计，而日志反馈代理则通过记录 Flutter 与原生日志，其中异常日志、Http 请求信息，音视频播放信息统统汇聚到日志收集器中，通过脱敏过滤清洗之后存储到本地，等待上报。最终在后端可以看到对应的质量视图、用户画像、自定义事件、请求追踪等等。具体的层级划分如下图：

3.2.3 自动部署与持续构建

对于部署与构建一直都是一个麻烦的问题，加入了 Flutter 之后，不同端之间如果继续采用各自打包模式，将会大量耗费时间，以及产生不一致行为。

为了解决这个问题，我们引入了自动部署与持续构建架构。首先通过 Gitlab 源代码中心，结合配置中心与脚本、CI 配置信息，加入到构建环境中自动打包出制品 APK 与 AAR 等成品，然后推送到远端资源此，安全加固后分发给研发与测试中心送测。

此部分都可以通过 Jenkins 平台全自动部署与构建，支持后续追踪与还原脚本与编译信息，具体的架构设计如下图：

3.3 三期-开放赋能

3.3.1 全局统一路由

新版很多地方会跳转不同的页面，建议设计一个原生路由器，结构如下：

先判断是否为原生，如果是 Flutter 的，则使用原有的统一路由器进行跳转即可，如果是原生的页面，通过桥接到原生的路由器，在原生侧也开发类似统一路由器的路由器，这个路由器日后其他部分也可以使用。它可以通过统一的 URI 去跳转不同的页面，包括小程序、原生页面、H5 页面或者其他特殊的操作。

设计的统一 URI 示例如下：

3.3.2 移动中台组件输出

中台建设的目的是通过在开发基础层面以必要的技术手段形成开发工程体系的规范化及通过自动化等技术手段解决以上问题，移动中台建设也是目前业界的发展趋势。

移动中台由组件化开发框架、组件化工具链及基础能力/服务三大部分组成。其中组件化开发框架提供了组件化开发模式的技术的规范和支持，主要体现为组件容器技术及相关的服务治理、生命周期管理以及应用集成及启动 Pipeline 等技术。

组件化工具链主要是贯穿移动端产品开发、集成、发布整个研发周期的组件化开发及项目工程维护管理配套的相关自动化工具集合，用于为组件化开发的高效性、规范性提供必要的基础工具及质量保障。基础能力/服务则是对移动客户端累积的一些公共基础服务和能力的标准化复用，与组件化工程紧密结合，实现基础能力/服务的按需自动集成和减少必要的接入及维护成本。

4 总结和展望

4.1 往事回顾

历经三个月的 Flutter 改造，天翼云盘 V9.0 版本于 2021 年 10 月改造完成，实现了 Flutter 全面化，成绩斐然，同时也实现了部分性能优化和结构优化的目标，即 App 页面渲染性能显著提升，界面代码实现两端 95%的复用率，较纯原生开发效率提升 40%，还原度问题修改平均响应时间提升为 13 个/人日，较纯原生开发平均提升 86%, iOS 支持苹果 Metal 图形驱动，实现 UI 渲染流畅度平均提升 50%。

这次 Flutter 重构改造期间，超复杂业务场景验证 Flutter 模式的逻辑跨端可行性，性能上的优越性，以及人员上的复用性。

4.2 Flutter 在数字生活的技术演进

• Flutter@天翼数字生活

• 已经成为了新业务的首选技术栈之一

• 建设方向覆盖了引擎、应用框架、基础服务等方面

• 业务实践

• 覆盖更多的业务场景，提高业务复用率

• 支持更多的终端设备

• 实现“大一统”，横跨 iOS、Android、Web、Windows、macOS 和 Linux 六大平台

• 适配 Flutter 3.0，向桌面端 PC、大屏终端 TV 和 Mac 端演进

4.3 未来展望

截至目前，天翼数字生活已实现 Flutter 各产品全面落地，已完成 5 款原生 APP 的 Flutter 改造（天翼云盘、天翼企业云盘、189 邮箱、天翼看家行业版和天翼云眼），且在开发模式、产品运营和生态合作方面有明显的改善及突破。

“国之大者”，事关人民幸福，事关民族复兴。在未来的日子里，天翼数字生活将持续发布 Flutter 相关的知识文章，包括但不限于框架技术、案例实践和开源组件等内容，推进 Flutter 技术栈更新，完成 Flutter 集成效率、代码精简和人员复用的优化，发挥云网融合优势，加大科技创新投入，更好地发挥数字中国建设主力军作用，不断为人民的美好生活添彩，持续推动数字经济高质量发展，在建设社会主义现代化强国的道路上贡献自己的科技力量。

如想要了解更多 Flutter 知识，请持续关注天翼数字生活！