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在数字生活的技术演进

• [email protected]天翼数字生活

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

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

• 业务实践

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

• 支持更多的终端设备

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

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

4.3 

未来展望

截至目前，天翼数字生活已实现Flutter各产品全面落地，已完成

5款

原生APP的Flutter改造（

天翼云盘

、

天翼企业云盘

、

189邮箱

、

天翼看家行业版

和

天翼云眼

），且在开发模式、产品运营和生态合作方面有明显的改善及突破。

“国之大者”，事关人民幸福，事关民族复兴

。在未来的日子里，天翼数字生活将

持续发布Flutter相关的知识文章，包括但不限于框架技术、案例实践和开源组件等内容

，推进Flutter 技术栈更新，完成Flutter集成效率、代码精简和人员复用的优化，发挥云网融合优势，加大科技创新投入，更好地发挥数字中国建设主力军作用，不断为人民的美好生活添彩，持续推动数字经济高质量发展，

在建设社会主义现代化强国的道路上贡献自己的科技力量

。

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