本文由小声团队出品，小声团队是一个专注于音频&音乐技术的初创团队，深度使用Flutter构建跨平台应用，希望与大家一起共同探索Flutter在桌面端&移动端的可能性。
背景
我们计划研发一款全功能跨平台的音乐制作平台（DAW），从立项之初我们就已经明确了全平台的支持计划（即Windows / MacOS / Linux / iOS / Android ) ,也因此我们也是以这个为目标来寻找技术解决方案，经过一段时间的研究与学习，大致确定了几个可选项，内部的调研结果如下（本结果仅代表团队内部认知，如有差异还请包涵）：
| 技术方案 | 性能 | 研发效率 | 跨平台兼容性 | 扩展能力 | 原生代码交互能力 |
|---|---|---|---|---|---|
| HTML5 | 低 | 高 | 高 | 低 | 低 |
| QT | 高 | 极低 | 高 | 高 | 高 |
| React Native | 中 | 高 | 低 | 中 | 中 |
| Flutter | 高 | 高 | 高 | 中 | 高 |
为什么不使用基于HTML5打造的技术栈？
HTML5是众所周知的最易上手的跨平台UI解决方案，并且产业成熟，有众多可选的框架与开源组件可直接使用。但是DAW作为一款专业生产力工具并不适合完全在浏览器环境中运行，比如第三方插件系统浏览器则无法支撑，另外在内存资源上的使用也不是很便捷，通常一个音乐工程可能需要占据数G内存，运行时需要维护数万个对象，这对于Javascript来说还是浏览器来说都是很严重的负担。
从另一个方面来看，就算我们需要以一种阉割的形式支持Web,那么WASM技术则是我们更佳的选择。
因此，我们不考虑基于HTML5的技术方案。
为什么不选择QT & GTK 等老牌原生高性能框架？
在传统技术上来看，QT是最符合我们需求的技术方案，很多老牌工具厂商背后也都是基于QT技术栈完成。QT在运行效率上而言无疑是最佳的选择，我们的主要顾虑在对于CPP的掌控能力与研发效率，UI开发与引擎开发有一个很大的根本区别在于引擎开发通常使用单元测试来完成逻辑验证，而UI则很难使用单元测试来验证UI效果，也很少看到有团队真的依赖单元测试的方式来进行UI开发，而QT没有像Webpack类似的hot reload技术，UI的验证效率会非常的低下，甚至于不是我们一个小团队可以承受得起的。
而CPP也是入门门槛极高的编程语言，我们对于QT方案也存疑，但是没有完全放弃。
Flutter 的什么特性吸引了我们
- Flutter使用基于Skia绘图引擎直接构建组件，操作系统只需要提供像素级的绘图能力即可，因此也就保证了跨平台的UI一致性（像素级一致），而对React Native的兼容性吐槽一直充斥着社区。
- Dart对于UI开发也是非常舒服的。
- 对象默认引用传递。
- 支持HOT Reload。这为开发效率带来本质的提升，使得Flutter研发效率不弱于HTML5
- AOT支持，生产级代码运行效率飞升，不逊色于原生应用的表现。
- FFI 支持 。 可以直接与原生C & Cpp代码进行交互而几乎没有任何性能损失。
- Web 支持。 Flutter 即可直接编译到Web运行，这也为我们提供Web服务打下了可能性。
Flutter的这些特性都是直击我们需求的，所以我们决定尝试使用Flutter来构建我们的平台。
结论
如果你也在寻找一个技术技术方案兼顾研发效率与运行时效率，那么Flutter应该是一个很不错的选择。
