Flutter深入淺出(二)Flutter的發展歷程

NO IMAGE

昨天我們剛說完《什麼是Flutter》,想了解的可直接點擊鏈接去查看我上篇文字。今天我們講Flutter的發展歷程。

Flutter 的發展歷程

1. 移動開發演進

第一階段 原生時代

Flutter深入淺出(二)Flutter的發展歷程

移動應用(即我們日常所說的「原生」應用程序),通常是指某一移動平臺所特有的應用程序。通過使用特定平臺所支持的開發工具和語言進行開發,你可以直接調用系統提供的一些 SDK API。當下流行的移動操作系統中,我們使用 Java 或 Kotlin 調用 Android SDK 開發 Android 應用,或通過 Objective-C 或 Swift 調用 iOS SDK 開發可以上架 App Store 的應用。
優點
1.原生開放能力,gps、藍牙、攝像頭等;
2.性能高、體驗好。
缺點:
1.特定平臺開發,綜合成本高,每個平臺都需要開發成員。
2.動態化能力弱,緊急問題修復或者新功能只能發版

從開發成本的角度出發,同時開發多端的成本很高,所以就有了一個迫切的需求,能否開發一套在多個平臺上運行,這樣可以大大降低開發成本。 所以也推動了下一階段的技術。

第二階段 H5時代

Flutter深入淺出(二)Flutter的發展歷程

這個階段h5興起,主要採用 Webview 容器(廣義)進行內容渲染,並藉助原生代碼預置用以暴露給 JavaScript 調用的一部分系統能力,而這類協議則為我們通常說的 JavaScript Bridge;這個時代的框架在 Web 與 Native 間還有比較明顯的界限,大家各司其職(UI 渲染與系統功能調用)。
甚至有一段時間大家覺得h5會替代Android原生開發,當時也出現了很多的開源框架來實現H5與底層的交互框架:Cordova,Ionic。

優點:
1.開發成本低,簡單,跨平臺
缺點:
1.性能問題

所以這種現象持續了沒有多久,那,能不能有一種既能跨平臺,性能又高的架構解決這個問題呢?

第三階段 RN時代

Flutter深入淺出(二)Flutter的發展歷程

在這個階段我們仍然用 JavaScript 開發,但繪製已經交由 Native 接管,展現在用戶面前的 UI 藉助的是 JavaScript VM 的解析與 Native Widgets 的組合展示。
其實採用這種技術的不止RN,還有weex等目前的跨平臺方案,他們的原理大同小異,只是上層採用的語言不同,中間採用的橋有差異而已,但是整個架構思想是一樣的。

優點
1.性能提升很大
缺點
1.RN本身的成本增加。

當人們滿足於這種開發帶來的便利的同時,又有了新的問題產生了,就是橋的成本太高,當涉及到頻繁的跨橋調用的時候,就會出現性能問題,還有個更嚴重的問題就是,維護成本也很高,

當人們認為RN能節省一半工程師的時候,其實RN的維護需要更多的工程師參與進來,
RN的整體思想是一處學習到處使用,所以在Android和Ios的使用方式上還是有差異的,而且在開發插件的時候,還是需要開發android ios兩套插件,能達到像H5一樣,一處編寫,到處運行還是有很大的差異的,所以除了android和ios團隊外還需要一個團隊維護RN,RN架構的維護成本要比android和ios的開發的難度高多了。所以成本比原來還高,還有很多Rn架構本身沒有辦法結局的問題,對於小團隊來說簡直就是噩夢。

第四階段 Flutter時代

Flutter深入淺出(二)Flutter的發展歷程

它在第三階段的基礎上,增加了一個dart虛擬機,減少了橋的交互,所以性能方面會更加優秀,還有一點就是維護上,flutter有Google維護,所以他的插件開發將會更加規範,所以理論上很容易實現跨平臺代碼複用的情況。

  • 2018.2 / Beta 1
  • 2018.5 / Beta 3
  • 2018.6 / Preview
  • 2018.12 / Flutter Live with 1.0.0
  • 2019.5 / Flutter 1.5 (Flutter for Web 正式開啟了 Flutter 的全平臺 UI 框架之路)
  • 2019.12.12/ Flutter 1.12(解決了很多性能上的問題。繪製更加流程)

相關文章

Spring自定義標籤的實現

2019年年終總結

雲原生安全更安全的密文管理VaultonACK

前端世界中的路由