本文由小聲團隊出品岂贩，小聲團隊是一個專注于音頻&音樂技術的初創(chuàng)團隊，深度使用Flutter構建跨平臺應用巷波，希望與大家一起共同探索Flutter在桌面端&移動端的可能性萎津。
背景
我們計劃研發(fā)一款全功能跨平臺的音樂制作平臺（DAW），從立項之初我們就已經明確了全平臺的支持計劃（即Windows / MacOS / Linux / iOS / Android ) ,也因此我們也是以這個為目標來尋找技術解決方案抹镊，經過一段時間的研究與學習锉屈，大致確定了幾個可選項，內部的調研結果如下（本結果僅代表團隊內部認知垮耳，如有差異還請包涵）：
| 技術方案 | 性能 | 研發(fā)效率 | 跨平臺兼容性 | 擴展能力 | 原生代碼交互能力 |
|---|---|---|---|---|---|
| HTML5 | 低 | 高 | 高 | 低 | 低 |
| QT | 高 | 極低 | 高 | 高 | 高 |
| React Native | 中 | 高 | 低 | 中 | 中 |
| Flutter | 高 | 高 | 高 | 中 | 高 |
為什么不使用基于HTML5打造的技術棧颈渊？
HTML5是眾所周知的最易上手的跨平臺UI解決方案，并且產業(yè)成熟氨菇，有眾多可選的框架與開源組件可直接使用儡炼。但是DAW作為一款專業(yè)生產力工具并不適合完全在瀏覽器環(huán)境中運行，比如第三方插件系統(tǒng)瀏覽器則無法支撐查蓉，另外在內存資源上的使用也不是很便捷乌询，通常一個音樂工程可能需要占據數G內存，運行時需要維護數萬個對象豌研，這對于Javascript來說還是瀏覽器來說都是很嚴重的負擔妹田。
從另一個方面來看唬党，就算我們需要以一種閹割的形式支持Web,那么WASM技術則是我們更佳的選擇。
因此鬼佣，我們不考慮基于HTML5的技術方案驶拱。
為什么不選擇QT & GTK 等老牌原生高性能框架？
在傳統(tǒng)技術上來看晶衷，QT是最符合我們需求的技術方案蓝纲，很多老牌工具廠商背后也都是基于QT技術棧完成。QT在運行效率上而言無疑是最佳的選擇晌纫，我們的主要顧慮在對于CPP的掌控能力與研發(fā)效率税迷，UI開發(fā)與引擎開發(fā)有一個很大的根本區(qū)別在于引擎開發(fā)通常使用單元測試來完成邏輯驗證，而UI則很難使用單元測試來驗證UI效果锹漱，也很少看到有團隊真的依賴單元測試的方式來進行UI開發(fā)箭养，而QT沒有像Webpack類似的hot reload技術，UI的驗證效率會非常的低下哥牍，甚至于不是我們一個小團隊可以承受得起的毕泌。
而CPP也是入門門檻極高的編程語言，我們對于QT方案也存疑嗅辣，但是沒有完全放棄撼泛。
Flutter 的什么特性吸引了我們
- Flutter使用基于Skia繪圖引擎直接構建組件，操作系統(tǒng)只需要提供像素級的繪圖能力即可辩诞，因此也就保證了跨平臺的UI一致性（像素級一致）坎弯，而對React Native的兼容性吐槽一直充斥著社區(qū)。
- Dart對于UI開發(fā)也是非常舒服的译暂。
- 對象默認引用傳遞。
- 支持HOT Reload撩炊。這為開發(fā)效率帶來本質的提升外永，使得Flutter研發(fā)效率不弱于HTML5
- AOT支持，生產級代碼運行效率飛升拧咳，不遜色于原生應用的表現伯顶。
- FFI 支持 。 可以直接與原生C & Cpp代碼進行交互而幾乎沒有任何性能損失骆膝。
- Web 支持祭衩。 Flutter 即可直接編譯到Web運行，這也為我們提供Web服務打下了可能性阅签。
Flutter的這些特性都是直擊我們需求的掐暮，所以我們決定嘗試使用Flutter來構建我們的平臺。
結論
如果你也在尋找一個技術技術方案兼顧研發(fā)效率與運行時效率政钟，那么Flutter應該是一個很不錯的選擇路克。
