本文由小聲團隊出品,小聲團隊是一個專注于音頻&音樂技術的初創團隊,深度使用 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 應該是一個很不錯的選擇。
"開發者說·DTalk" 面向
中國開發者們征集 Google 移動應用 (apps & games) 相關的產品/技術內容。歡迎大家前來分享您對移動應用的行業洞察或見解、移動開發過程中的心得或新發現、以及應用出海的實戰經驗總結和相關產品的使用反饋等。我們由衷地希望可以給這些出眾的中國開發者們提供更好展現自己、充分發揮自己特長的平臺。我們將通過大家的技術內容著重選出優秀案例進行谷歌開發技術專家 (GDE) 的推薦。
原文標題:我們為什么選擇了Flutter Desktop | 開發者說·DTalk
文章出處:【微信公眾號:谷歌開發者】歡迎添加關注!文章轉載請注明出處。
審核編輯:湯梓紅
-
移動
+關注
關注
1文章
427瀏覽量
38815 -
操作系統
+關注
關注
37文章
6545瀏覽量
122753 -
功能
+關注
關注
3文章
587瀏覽量
29118
原文標題:我們為什么選擇了Flutter Desktop | 開發者說·DTalk
文章出處:【微信號:Google_Developers,微信公眾號:谷歌開發者】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論