前言：这一年来我基本处于断更的状态，我知道在AI时代，编码的成本已经变得越来越低，技术分享的流量必然会下降。但这依然是一个艰难的过程，日常斥责自己没有成长，没有作品。
除了流量问题、巨量的工作，更多的原因是由于技术栈的变化。我开始使用Electron编写一个重要的AI产品，并且在 Flutter 与 Electron 之间来回拉扯......
背景
我们对 Flutter 技术的应用，不仅是在移动端APP，在我们的终端设备也用来做 OS 应用，跨Android、Windows、Linux系统。
在 Flutter 上，我们是有所沉淀的，但是当我们决定研发一款重要的PC应用时，依然产生了疑问：Flutter 这门技术，真的能满足我们在核心桌面应用的研发需求吗？
最终，基于官方能力、技术生态、roadmap等一系列原因，我们放弃在核心应用上使用 Flutter，转而代之选择了 Electron ！
这篇文章将从这几个月使用 Electron 的切实体验，从不同角度，对 Flutter 和 Electron 这两款支持跨端桌面应用开发技术，做一个详细的对比。
Flutter VS Electron
| 维度 | Flutter | Electron |
|---|---|---|
| 发布时间 | 2021 年 3 月 宣布支持桌面端 | 2013 年 4 月发布，发布即支持 |
| 核心场景 | 移动APP跨端 | 桌面应用跨端 |
| 官方网站 | flutter.dev | www.electronjs.org |
| 开发文档 | docs.flutter.dev | www.electronjs.org/docs |
| 插件包管理 | Pub（pub.dev），提供大量 UI 组件、工具类库 | npm（www.npmjs.com），依赖前端生态，插件丰富（如 electron-builder 打包工具） |
| 研发组织 | Github |
方案成熟度
毫无疑问，在方案成熟度上 Electron 是碾压 Flutter 的存在。
1. 多进程能力
- Flutter 目前还是单进程的能力，只能通过创建 isolate 来实现部分耗时任务，但是内存也是不共享的。
- Electron 集成了 Nodejs 服务，
自带多进程的能力，且提供了完整的跨进程机制（IPC「Inter-Process Communication」）。
2. 多窗口支持
- Flutter 目前不支持多窗口 。由于其是自绘引擎，本身还是依赖原生进程提供的桌面窗口，所以需要原生与 Flutter 引擎不断的进行沟通对接，才能很好的使用多窗口能力。
目前官方只是提供了 demo 来验证多窗口的可行性，但截止发文还没有办法在公版试用。 - Electron 将 Chromium 的核心模块打包到发行包中，
借助浏览器的能力，可以随意开辟新的窗口（如： BrowserWindow）
3. 开发语言
- Flutter 使用dart语言开发，采用声明式UI进行布局，插件管理使用官方的 pub 社区，学习和使用成本不算高。
- Electron 使用JavaScript/TypeScript + HTML/CSS 的前端技术栈进行开发，社区也完全跟前端一致，
非常丰富但鱼龙混杂。
4. 原生能力的支持
- Flutter 本质是一个 UI 框架，原生能力需要通过编写插件去调用 ，或者通过 FFI 调用，成本是很高的，你很难找到一个懂多端原生技术的开发。
- Electron 有 node 环境，node.js 很多原生模块，可以直接调用到系统的能力，非常的高效。
开发体验和技术生态
1. 调试工具
- Flutter 的调试工具，主要是依赖 IDE 本身的断点调试能力，以及自研的Flutter Inspector、devTools。
在UI定位、性能监控方面，基本可以满足。但由于是个 UI 框架，对于原生容器是无法进行调试的，这在混合开发过程中是个比较大的痛点。 - Electron 就是个浏览器，对于主进程和node子进程，有 Inspect 的机制； UI 层就更方便了，就是浏览器的调试器一模一样。生产环境下调试成本也低。
2. 打包编译
Flutter 是通过自绘引擎生成原生应用包，而 Electron 是将网页技术（HTML/CSS/JS）包裹在 Chromium 内核中。
底层技术架构的区别，直接决定了 Electron 的打包相对 Flutter 有些困难，且包体积很大。
| 对比维度 | Flutter | Electron |
|---|---|---|
| 打包原理 | 编译成目标平台的原生二进制代码，搭配自绘引擎（Skia） | 封装 Chromium 内核 + Node.js 环境，运行网页资源 |
| 最终产物 | 与原生应用格式一致（如 .apk/.ipa/.exe） | 包含浏览器内核的独立应用包 |
| 跨平台方式 | 一份代码编译成多平台原生包，需分别打包 | 一份代码打包成多平台包，内核随应用分发 |
| 应用体积 | 较小（基础包约 10-20MB） | 较大（基础包约 50-100MB，内核占主要体积） |
3. 官方和社区的活跃性
- Flutter 官方在桌面端的推进很慢，很多基础能力都没有太多的推进。同时在 roadmap 中，重心都偏向移动端和 web 端。
- Electron 由于产品的体量和成熟度，稳定的在更新，每个版本都会带来一些新的特性。
4. 研发团队
| 技能维度 | Flutter | Electron |
|---|---|---|
| 核心语言 | Dart，需理解其异步逻辑、Widget 组件化思想 | JavaScript/TypeScript，前端开发者可无缝衔接 |
| UI 技术 | Flutter 内置 Widget 体系，需学习其布局（Row/Column）、状态管理（Provider/Bloc） | HTML/CSS，可复用前端生态（Vue/React/Element UI 等） |
| 原生交互 | 需了解 Android（Kotlin/Java）、iOS（Swift/OC）基础，复杂功能需写原生插件 | 依赖 Node.js 模块或现成插件，无需深入原生开发 |
| 工程化工具 | 依赖 Flutter CLI、Android Studio/Xcode（打包配置） | 依赖 npm/yarn、webpack/vite（前端构建工具） |
可以看出，Flutter至少需要 1-2 名熟悉 Dart 的开发者，还需要有原生开发能力，技术门槛是比较高的 ；而 Electron 以前端开发者为主，熟悉 Node.js 即可完成所有开发，是可以快速上手的 。
同时前端开发也比 Flutter 开发要更容易招聘。
结语
笔者本身是 Flutter 的忠实维护者，我认为 Flutter 的 Impeller 图形渲染引擎将不断完善，能在各个端达到更好的渲染速度和效果；同时 Flutter 目前的多窗口方案，让我们可以充分的相信可以多个窗口共用一份内存，而不需要通过进程间通信机制
但是，在 Flutter 暂未成熟的阶段，桌面核心产品还是用 Electron 进行开发会更加合适。我们 也期待未来 Electron 可以多集成WebAssembly来提升计算密集型任务的性能，减少 Chromium 内核的高内存占用。