iBox-面向Flutter的一站式研发工作台

一 前言

Flutter 一码多端的特性，解放了端上同学的人力，带来了研发效率的提升，淘特技术团队因为早期双端研发同学数量不匹配以及对研发效率的诉求，也是阿里集团内部比较早在业务上落地 Flutter 的团队之一。

虽然有了一码多端的便利，但是伴随而来的还有研发链路中的各种问题，例如研发环境搭建，双端工程环境，集成发布流程繁琐等等。为了深入了解开发同学们的痛点，我们在团队内部发起了一份问卷调查。

我们针对研发幸福感指数以及研发链路中遇到的各种问题进行了调查。结果如下：

在研发幸福感指数的打分中平均得分是 3.38（5分制）。我们针对影响研发幸福感的问题进行了分析，筛选出了一些大家普遍认为影响研发效率的问题。其中排名最高的是研发环境+工程环境（Flutter相关）的搭建，开发调试（Flutter相关）等问题。

接下来我们就来看看这些问题的具体痛点，以及解决这些问题的时候面临的一些挑战。

二 问题与挑战

1 问题

在影响研发幸福感的问题中，主要是以下三个方面的问题比较突出。

1）研发环境问题

研发环境配置是编码的前置工作，它也会影响新人落地对团队研发体验的第一印象。由于 Flutter 涉及 Android 与 iOS 双端的环境配置，导致不熟悉另一个端的同学配置起来，十分麻烦，上手难度高。另外，Flutter 本地版本不一致，缺乏 Flutter 版本管理工具，文档零散更新不及时，这些都极大的耗费了团队同学的精力。

2）工程环境问题

解决了研发环境问题，还需要解决工程环境问题，双端工程架构复杂，不熟悉某个端的同学面对编译问题难以解决。甚至很多同学就直接放弃了配置另外一个端的工程，平时开发只对着自己熟悉的端调试，违背了 Flutter 双端开发的理念。

点评：从团队的调研采访来看，一个新人同学搭建 Flutter 的研发环境和工程环境，先需要一天时间搭建好基础环境，后面的两三天时间折腾各种编译问题，特别是 iOS 的相关环境对于 Android 同学来说想要完整跑起来十分费力。

3）集成流程问题

等到代码开发测试完成以后，集成步骤多，平台间来回切换，集成流程割裂，没有形成完整的 SOP。整个集成流程既费时费力，又容易引发质量问题。

点评：现有的 Flutter 模块集成流程分为六步：1 模块分支代码合并 -> 2 模块生成新Tag版本 -> 3 主工程修改模块版本号 -> 4 主工程代码合并 -> 5 主工程生成版本号 -> 6 摩天轮提交正式包打包，步骤繁琐，需要在 Aone、MTL 等平台来回切换，而且手工操作各种版本号，很容易引发线上质量问题。

2 挑战

为了解决这些问题，之前也有沉淀一些文档和脚本，但是文档有很多步骤、命令，弄错任何一个就可能导致环境搭建出错，另外文档有时候也没有及时更新。

我们想如果能有一个桌面端 GUI 形式的研发工作台，研发同学日常研发遇到的各种问题都可以在这上面解决，新来的同学也可以借助这个研发工作台快速落地，那对研发的幸福感将是一个质的提升。

于是我们便决定打造一款桌面端的研发工作台，在实现这个目标的过程中我们也遇到了很多挑战。

1）如何降低开发同学的接入和使用成本

1. 接入和使用成本。研发工作台本来作为一款工具软件，它本身如果再操作复杂，需要看各种文档，那就背离了工具软件简单易用的初衷，所以复杂操作一键化是做相关功能时必须做到的，例如软件环境一键配置，工程环境一键配置，一键集成发布等，很多功能都是按照这个思路来做的。
2. 兼容现有的研发环境和工程环境。除了新来的同学，大部分开发同学的电脑上已经有了部分环境，如何与现有的环境共存，不改变开发同学现有的使用习惯，也是我们重点考虑的问题。

2）如何保障架构设计的合理性

我们想把研发工作台打造成一个人人都可以参与进来共建的开放平台，因为个人的时间是有限的，工作台本身作为一个工具集的聚合，需要更多的同学参与进来，更多的 idea 落地，所以如何做好仓库权限控制以及设计一个好的插件化框架就显得很重要。

3）新技术的落地，相关问题需要自己探索解决。

在桌面端研发工作台的开发中，我们使用的是 Flutter Desktop 技术（至于原因，技术调研部分会讲），国内目前 Flutter Desktop 技术在生产环境落地的并不多，相关经验还比较缺乏，遇到一些问题的时候，需要自己去探索解决。

接下来我们就来看一看我们为了解决这些问题，在 iBox 上设计了哪些核心的功能，以及这些功能是如何解决这些问题的。

三 技术全景

1 技术调研

业界的客户端研发工作台的发展现状。如下所示：

• 业界：EasyBox，MBox 等工具。这些工具的核心一方面在于解决 Native 环境搭建，开发效率低的问题。另一方面深度封装 Git、Cocoapods，统一开发模式。
• 淘特：也有一些零散的脚本工具。但是整体上没有解决研发环境配置，开发调试，集成发布等问题。

整体上看是一个客户端研发工作台落地的契机，业界有团队在尝试，淘特在 Flutter 研发链路也有痛点和需求。既然要进行桌面端开发，选择一个桌面端开发框架就成了首先要考虑的事情，当下比较流行的桌面端开发框架主要有以下两种：

• 面向前端的 Electron：使用 JavaScript、HTML 和 CSS 构建桌面端应用程序。
• 面向客户端的 Flutter Desktop：使用 Flutter 构建桌面端应用程序。

通常我们在做技术选型的时候会从问题解决，团队现状，技术领域，业务趋势等几个方面层层递进去思考。

• 问题解决：Electron 和 Flutter Desktop 这两套方案都能解决我们的问题，虽然性能上有差异，但是这个不是我们最关注的点。
• 团队现状：客户端同学对 Flutter 熟悉，客户端同学的上手成本更低，不依赖其他端的人力。从这个角度来看，Flutter Desktop 会更好。
• 技术领域：Electron 和 Flutter Desktop 都在向前发展，Flutter 团队今年推出的 Flutter 2.10 将 Windows 平台正式带入稳定版本的支持，今年也会陆续完成 Linux、MacOS 等平台的稳定版本的支持。
• 业务趋势：工作台未来可能会向全平台扩展。例如在桌面端是一个研发工作台，在移动端（Android&iOS）iBox 是一个应用小工具集或者是一个类似于蚂蚁伙伴的app，在 Web 端是一个数据看板。从这个角度讲，Flutter Desktop 会更好。另外我们还想在工作台上做 UI 等组件的展示，如果基于 Flutter 来做，那么就能做到所见即所得，这会是一个非常好的体验，

基于以上思考，我们最终选择了 Flutter Desktop。有了开发框架，我们接着来看看 iBox 的架构设计。

2 功能设计

iBox 的核心定位