跨端技术一直是移动端开发领域的热门话题，Flutter 作为一种领先的移动跨端技术之一，凭借其快速的渲染引擎、丰富的UI组件库和强大的开发工具，成为了开发人员的首选之一。
从 Flutter 诞生之初，我们就一直关注着它的发展，Flutter 早期版本变更较为频繁，并且经常伴随着 Breaking Change，另外可用的三方插件较少且不稳定。直到2019年，Flutter 的热度暴涨，国内不少团队陆续把 Flutter 引入到了生产环境使用，社区也涌现出不少优秀的开源项目，我们也决定在这个时候做一些技术上的尝试。
经过这几年在 Flutter 技术上的不断学习、探索和积累，Flutter 已经成为了客户端技术体系中的重要组成部分。
回顾整个过程，我们大致经历了这么几个阶段：可行性验证、基建一期建设、小范围试验、基建二期建设、大范围推广、前端生态的探索，下文将分别对每个阶段展开进行介绍。
其实在这之前我们已经做过了一些调研，但许多结论都是来源于网上的一些文章或者其它团队的实践，这些结论是否靠谱是否真实还有待商榷，另外，网上的文章大都千篇一律，要么使劲吹捧，要么使劲贬低，要得出相对客观的结论还是得需要我们自己通过实践才能得出。
我们确定了以下几个维度，用来评估 Flutter 是否值得我们进一步投入：
由于前期对 Flutter 的熟练度不高，基础设施也还没有搭建起来，所以在开发效率上，我们期望的 Flutter 的开发耗时能保持在原生开发耗时的 1.5 倍以内，不然虽然实现了跨端，但是需求的开发周期反而被拉长了，这样得不偿失。在UI一致性上，我们期望同一份代码在两端的表现要基本达到一致，不需要额外的适配成本。在性能方面，尽量保证崩溃、卡顿、内存、帧率这些指标在可控范围内。
我们希望用较小的代价完成上述维度的评估，所以在试验期间的架构及基础设施方面我们做的比较简单。
当时我们正在做一个叫切克的 App，用户量级比较小，工程架构也相对简单一些，正好可以用来做一些技术方面的探索和验证。
我们选择的是切克的商品详情页，用 Flutter 技术实现了一个一模一样的商详，按1:1的流量分配给 Native 和 Flutter。
由于我们的工程不是一个全新的项目，所以采用的是 Native 与 Flutter 混合开发的方式，Native 主工程只依赖 Flutter 产物即可，同时也尽量避免对原有工程的影响。
关于混合页面栈的问题，我们没有额外处理，因为暂时只测试一个页面，不会涉及到多页面混合栈的问题，所以暂时先忽略。
为了降低验证成本，我们没有对接现有的 Native 的持续集成流程，而是直接在本地构建 Flutter 产物，然后上传到远程仓库。
经过一段时间的线上验证，我对 Flutter 技术基本有了一个比较全面的了解：
在开发效率上由于基础库和基建的缺失，在处理 Flutter 业务跟 Native 业务的交互时需要更多的适配成本，包括像页面跳转、埋点上报、接口请求、图片加载等也需要额外的处理，但我们评估随着后续基建的不断完善，这部分的效率是可以逐步得到改善的；而在涉及UI开发方面，得益于热重载等技术，Flutter 的开发效率是要优于原生开发的。整体评估下来，在开发效率方面 Flutter 是符合我们的预期的。
在UI一致性上，除了在状态栏控制和文本在某些情况下需要特殊适配下外，其它控件在两端的表现基本一致。
在性能表现上，Flutter 会额外引入一些崩溃，内存占用也有所上涨，但还在可接受范围内。
Flutter 的学习成本相对还是比较高，毕竟需要单独学习一门语言，另外 Flutter 的渲染原理也跟原生有很多差异，需要转变思维才能更快的适应，此外 Flutter 还提供了众多的 Widget 组件，也需要较长时间学习。
在发展趋势上，Flutter 无疑是当时增长最快的跨端技术之一，社区的活跃程度以及官方的投入都非常高，国内不少团队也都在积极推进 Flutter 技术的发展，Flutter 正处在一个快速的上升期。
整体来说，Flutter 是满足我们团队对跨平台技术的需求的，我们计划在接下来的一段时间投入更多资源，把 Flutter 的基础设施逐渐建立起来。
基建一期内容主要包括以下几个方面：
在基建一期完成后，我们的目标是要达到：
工程架构指的是原生工程与 Flutter 工程之间的关系，以及 Flutter 工程与 Flutter 工程之间的关系。
我们知道，使用 Flutter 开发通常有两种情况，一种是直接使用 Flutter 开发一个新的App，属于纯 Flutter 开发；一种是在已有的 Native 工程中引入，属于混合开发。我们当然属于后者。
而混合开发又可分为两种：源码集成和产物集成。源码集成需要改变原工程的项目结构，并且需要 Flutter 开发环境才能编译，而产物集成则不需要改动原工程的项目结构，只需把 Flutter 的构建产物当作普通的依赖库引入即可，原有 Native 工程和 Flutter 工程从物理上完全独立。显而易见的我们选择产物集成的方式，引入 Flutter对于原工程以及非 Flutter 开发人员来说，基本上是毫无感知的。
所以原生工程与 Flutter 工程之间的关系如下图所示：
原生工程与Flutter工程之间的关系
根据已有的客户端基建的开发经验，我们将所有 Flutter 工程分为了四层：
容器层负责提供 Flutter 的基础运行环境，包括 Flutter 引擎管理、页面栈管理、网络框架、KV存储、数据库访问、埋点框架、Native 与 Flutter 通信通道和其它基础功能。
公共层包含一些通用的开源库、自定义UI组件、部分通用业务等。
业务层包含用户信息、商品、发布等业务组件。
壳工程负责集成各业务组件，最终构建出产物集成到 Native 主工程。
其中业务层、公共层、容器层都是由若干个独立的工程所组成，整体结构如下：
Flutter分层架构
开发框架是为了提高开发效率、规范代码结构、减少维护成本等考虑而设计的一套软件框架，包括：基础能力、状态管理、页面栈管理等。
开发框架需要提供各种必要的能力，比如：页面跳转、埋点、网络请求、图片加载、数据存储等，为了最大化减少研发成本，我们在底层定义了一套通用的数据交互协议，直接复用了现有的 Native 的各项能力，也使得 Native 的各种状态与 Flutter 侧能够保持统一。
相信了解 Flutter 的同学一定知道状态管理，这也是跟 Native 开发区别较大的地方。在开发较为复杂的页面时，状态维护是非常繁琐的，在不引入状态管理框架的情况下，开发效率会受很大影响，后期的维护成本以及业务交接都是很大的问题。
另外，在开发框架设计之初，我们就期望从框架上能够在一定程度上限定代码结构、模块之间的交互方式、状态更新方式等，我们期望的是不同的人写出来的代码在逻辑、结构和风格上都能保持比较统一，即在提高开发效率的同时，也能保证项目后续的可维护性和扩展性，减少不同业务间的交接成本。
基于上述这些需求，在我们对比了多个开源项目后，FishRedux 的整体使用感受正好符合我们的要求。
如下图，两个页面的代码结构基本一致：
收藏详情和个人主页
在早期版本，Flutter 引擎的实例占用内存较高，为了减少内存消耗，大家普遍采用单实例的模式，而在 Native 和 Flutter 混合开发的场景下就会存在一个问题，就是 Native 有自己的页面栈，而 Flutter 也维护着一套自己的页面栈，如果 Native 页面与 Flutter 页面穿插着打开，在没有特殊处理的情况下，页面栈会发生错乱。在调研了业内的各种开源方案后，我们选择引入 FlutterBoost 用来管理页面混合栈。
为了方便开发同学搭建 Flutter 的开发环境，同时能够管理使用的 Flutter 版本，我们开发了 zflutter 命令行工具，包含以下主要功能：
如图：
zflutter
客户端使用的是自研的 Beetle 平台（集工程管理、分支管理、编译、发布于一体），短时间内要支持上 Flutter 不太现实，基于此，我们先临时自己搭台服务器，通过 gitlab 的 webhook 功能结合 zflutter 工具简单实现了一套自动化构建的服务，待 Beetle 支持 Flutter 组件化开发功能后，再将工作流切回到 Beetle 平台。
在完成基建一期的开发工作后，我们决定通过开发几个实际业务来试验目前的基础设施是否达到既定目标。
我们以不影响主流程、能覆盖常见UI功能、并且能跟 Native 页面做AB测试（主要是方便在出问题时能够切换到 Native 版本）为条件挑选了个人资料页和留言列表页进行了 Flutter 化改造，如下图所示：
个人资料页/留言列表页
这两个页面涵盖了网络请求、图片加载、弹窗、列表、下拉刷新、上拉加载更多、左滑删除、埋点上报、页面跳转等常见功能，足以覆盖日常开发所需的基础能力。
经过完整的开发流程以及一段时间的线上观察，我们得出如下结论：
目前已具备的基础能力已经足够支撑普通业务开发（开发过程中补足了一些缺失的能力）。
整个开发过程在工程依赖管理和分支管理方面的支持还比较缺失，比较依赖人工处理。
我们在开发前根据页面功能同时做了纯 Native 开发排期和 Flutter 开发排期，按单人日的成本来对比的话，Flutter 实际开发耗时跟 Native 排期耗时比为 1.25:2，Native 是按照 Android+iOS 两端各一人算的，也就是1.25人/日比2人/日，如果后续对 Flutter 技术熟悉度提升后相信效率还可以进一步提升。
线上两个 Flutter 页面的体验效果跟 Native 对比基本感觉不到差别，但是首次进入 Flutter 页面时会有短暂的白屏等待时间，这个是由于 Flutter 环境初始化导致的延迟，后续可以想办法优化。
在引入 Flutter 之后，转转的安装包体积在两端都分别有所增加：
试验结果基本符合预期，包体积的增量也在我们的可接受范围内，接下来将进行基建二期的建设，补足目前缺失的能力。
基建二期的内容主要包含以下工作：
为了能让大家更清晰的了解 Beetle 的工程管理机制，这里先简单介绍下客户端的工程类型：
举个例子，当有一个新版本需要开发时，先从 Native 主工程创建一个版本同时创建一个 Release 分支，即版本分支，然后从版本分支根据具体需求创建对应 Native 组件的版本分支，Flutter 主工程此时可看作是一个 Native 组件，比如此时创建了一个 Flutter 主工程的版本分支后，可以进入 Flutter 主工程再根据需要创建对应的 Flutter 组件工程的版本分支。
Beetle 目前已支持 Flutter 工程管理、分支管理、组件依赖管理以及组件的发布、Flutter 产物的构建等，Beetle 的作用贯穿从开发到上线的整个工作流。
为了让大家更快的熟悉 Flutter 开发，我们在客户端内部组织了5次 Flutter 快速入门的系列分享：
在完成基建二期的建设后，整体基础设施已经能够支撑我们常见的业务，开发工作流也基本顺畅，于是我们开始了在内部大范围推广计划。
我们先后改造和新开发了个人主页、我发布的页面、微商详、奇趣数码页等业务，基本涵盖了常见的各种类型的页面和功能，整体开发效率与原生单端开发效率持平，但是在特别复杂的页面的性能表现上，Flutter 的表现相对要差一些。
部分页面如下图所示：
个人主页
微详情页/我发布的/奇趣数码
在跨端技术领域我们知道 Web 技术是天然支持的，如果能把前端生态引入到 Flutter 中，那么对客户端来说，在业务的支持度上会更上一个台阶，Web 的体验得到提升的同时客户端也具备了动态化，基于此背景我们开始探索 Flutter 在 Web 上的可能性。
当时可选的开源方案有：Kraken、MXFlutter、Flutter For Web。
Kraken 是一款基于 W3C 标准的高性能渲染引擎。Kraken 底层基于 Flutter 进行渲染，通过其自绘渲染的特性，保证多端一致性。上层基于 W3C 标准实现，拥有非常庞大的前端开发者生态。
Kraken 的最上层是一个基于 W3C 标准而构建的 DOM API，在下层是所依赖的 JS 引擎，通过 C++ 构建一个 Bridge 与 Dart 通信。然后这个 C++ Bridge 把 JS 所调用的一些信息，转发到 Dart 层。Dart 层通过接收这些信息，会去调用 Flutter 所提供的一些渲染能力来进行渲染。
Kraken 是不依赖 Flutter Widget，而是依赖 Flutter Widget 的底层渲染数据结构 —— RenderObject。Kraken 实现了很多 CSS 相关的能力和一些自定义的 RenderObject，直接将生成的 RenderObject 挂载在 Flutter RenderView 上来进行渲染，通过这样的方式能够做到非常高效的渲染性能。
MXFlutter 是一套使用 TypeScript/JavaScript 来开发 Flutter 应用的框架。
MXFlutter 把 Flutter 的渲染逻辑中的三棵树（即：WidgetTree、Element、RenderObject ）中的第一棵（即：WidgetTree），放到 JavaScript 中生成。用 JavaScript 完整实现了 Flutter 控件层封装，实现了轻量的响应式 UI 框架，支撑JS WidgetTree 的 build逻辑，build 过程生成的UI描述， 通过Flutter 层的 UI 引擎转换成真正的 Flutter 控件显示出来。
Flutter 在 Web 平台上以浏览器的标准 API 重新实现了引擎。目前有两种在 Web 上呈现内容的选项：HTML 和 WebGL。
HTML 模式提供了最佳的代码大小，CanvasKit 则提供了浏览器图形堆栈渲染的最快途径，并为原生平台的内容提供了更高的图形保真度。
我们对以上方案从接入成本、渲染性能、包体积、开发生态、学习成本等多维度进行了对比：
最终选择了 Kraken 作为我们的首选方案。
为了使 Kraken 顺利接入转转App，我们做了以下几个方面的工作：
上线后，我们对页面的各项指标进行了对比，使用 Kraken 容器加载比使用 WebView 加载，在首屏加载耗时的指标上平均增加了281毫秒，原因为：当前版本的 Kraken 容器不支持直接加载 HTML，且只能加载单个 JsBundle，导致加载效率比 WebView 差。
通过跟前端同学沟通，从开发效率上来看，Kraken 工程的开发周期会比实现同样需求的普通 Web 工程增加1.5到2倍的时间，主要原因是受到 CSS 样式、Api 差异，无法使用现有UI组件，另外 Kraken 的调试工具目前还不够完善，使用浏览器调试后还须在客户端容器中调试，整体下来导致开发 Kraken 工程会比开发普通Web工程耗费更多时间。
由于之前选择的 Web 页面太过简单，不具备代表性，所以我们重新选定了“附近的人”页面做为改造目标，再次验证 Kraken 在实际开发过程中的效率及性能体验。页面如图所示：
存在的问题包括但不限于下面列举的一些：
CSS 定位、布局表现与浏览器表现不一致
部分 API 表现与浏览器不一致(getBoundingClientRect等)
iOS，Android系统表现不一致
重大 Bug
页面初始化渲染完成，动态修改元素样式，DOM不重新渲染
滑动监听计算导致 APP 崩溃
调试成本高
不支持 vue-router，单项目单路由
不支持热更新，npm run build 预览
不支持 sourceMap，无法定位源代码
真机调试只支持 element 和 network；dom 和 element 无法互相选中；无法动态修改 dom 结构，无法直接修改样式.......
页面白屏，假死
安全性问题
无浏览器中的“同源策略”限制
兼容性
npm 包不兼容等
通过这一系列的探索和尝试，我们了解到了 Kraken 目前还存在许多不足，如果继续应用会带来高额的开发调试以及维护成本，所以暂时停止了在 Kraken 方向上的投入，但我们仍然在这个方向上保持着关注。
目前转转在Flutter方向上的实践和探索只是一个起点，我们意识到仍然有很多工作需要去做。我们坚信Flutter作为一项领先的跨端技术，将为转转业务的发展带来巨大的潜力和机会。我们将持续努力，加强技术建设，不断完善实践经验，推动Flutter在转转的应用和发展，为用户提供更好的产品和体验。
最新文章
