Flutter深刻淺出--（二）Flutter 的發展歷程

時間 2020-01-08

標籤 flutter 深刻發展歷程简体版

原文原文鏈接

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

Flutter 的發展歷程

1. 移動開發演進

第一階段原生時代

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

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

第二階段 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等目前的跨平臺方案，他們的原理大同小異，只是上層採用的語言不一樣，中間採用的橋有差別而已，可是整個架構思想是同樣的。post

優勢：
1.性能提高很大
缺點：
1.RN自己的成本增長。性能

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

當人們認爲RN能節省一半工程師的時候，其實RN的維護須要更多的工程師參與進來，
RN的總體思想是一處學習處處使用，因此在Android和Ios的使用方式上仍是有差別的，並且在開發插件的時候，仍是須要開發android ios兩套插件，能達到像H5同樣，一處編寫，處處運行仍是有很大的差別的，因此除了android和ios團隊外還須要一個團隊維護RN，RN架構的維護成本要比android和ios的開發的難度高多了。因此成本比原來還高，還有不少Rn架構自己沒有辦法結局的問題，對於小團隊來講簡直就是噩夢。開發工具