Flutter 的發展歷程

1. 移動開發演進

第一階段 原生時代

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

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

第二階段 H5時代

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

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

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

第三階段 RN時代

在這個階段我們仍然用 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時代

它在第三階段的基礎上，增加了一個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（解決了很多效能上的問題。繪製更加流程）