1.什麼是flutter？
1.1原生開發
移動端的原生開發，比如Android，對應的開發語言java或kotlin；IOS，對應的開發語言Objective-C或者Swift。原生開發具有速度快，效能高，可實現自定義複雜動畫，使用者體驗較好；還能夠訪問平臺全部功能（例如GPS、攝像頭）。但是人力成本較高，需要兩個特定的團隊維護同樣的產品。版本迭代，開發，測試成本都會變大。
1.2跨平臺開發
針對原生面臨的問題，人們一直都在尋找好的解決方案，所以就有跨平臺的框架，先實現一處開發，可以執行在多個平臺上，看看下面都有哪些跨平臺技術：
- H5+原生（Cordova、Ionic、微信小程式）
- JavaScript開發+原生渲染 （React Native、Weex、快應用）
- 自繪UI+原生(QT for mobile、Flutter)
H5+原生混合開發
這類框架主要原理就是將APP的一部分需要動態變動的內容通過H5來實現，通過原生的網頁載入控制元件WebView (Android)或WKWebView（iOS）來載入。這樣以來，H5部分是可以隨時改變而不用發版，動態化需求能滿足；同時，由於h5程式碼只需要一次開發，就能同時在Android和iOS兩個平臺執行
混合開發原理
而混合框架一般都會在原生程式碼中預先實現一些訪問系統能力的API， 然後暴露給WebView以供JavaScript呼叫，這樣一來，WebView就成為了JavaScript與原生API之間通訊的橋樑，主要負責JavaScript與原生之間傳遞呼叫訊息，而訊息的傳遞必須遵守一個標準的協議，它規定了訊息的格式與含義，我們把依賴於WebView的用於在JavaScript與原生之間通訊的工具稱之為WebView JavaScript Bridge, 簡稱JsBridge，它也是混合開發框架的核心。
react native(RN)
React Native 是React在原生移動應用平臺的衍生產物，那兩者主要的區別是什麼呢？其實，主要的區別在於虛擬DOM對映的物件是什麼？React中虛擬DOM最終會對映為瀏覽器DOM樹，而RN中虛擬DOM會通過 JavaScriptCore 對映為原生控制元件樹
- React中提出一個重要思想：狀態改變則UI隨之自動改變，而React框架本身就是響應使用者狀態改變的事件而執行重新構建使用者介面的工作，這就是典型的響應式程式設計正規化
JavaScriptCore 是一個JavaScript直譯器，它在React Native中主要有兩個作用：
- 為JavaScript提供執行環境。
- 是JavaScript與原生應用之間通訊的橋樑，作用和JsBridge一樣，事實上，在iOS中，很多JsBridge的實現都是基於 JavaScriptCore 。
React Native 便實現了跨平臺。 相對於混合應用，由於React Native是原生控制元件渲染，所以效能會比混合應用中H5好很多，同時React Native使用了Web開發技術棧，也只需維護一份程式碼，同樣是跨平臺框架
Weex
Weex是阿里巴巴於2016年釋出的跨平臺移動端開發框架，思想及原理和React Native類似，最大的不同是語法層面，Weex支援Vue語法和Rax語法，Rax 的 DSL(Domain Specific Language) 語法是基於 React JSX 語法而創造。與 React 不同，在 Rax 中 JSX 是必選的，它不支援通過其它方式建立元件，所以學習 JSX 是使用 Rax 的必要基礎。而React Native只支援JSX語法。
快應用
快應用是華為、小米、OPPO、魅族等國內9大主流手機廠商共同制定的輕量級應用標準，目標直指微信小程式。它也是採用JavaScript語言開發，原生控制元件渲染，與React Native和Weex相比主要有兩點不同：
- 快應用自身不支援Vue或React語法，其採用原生JavaScript開發，其開發框架和微信小程式很像，值得一提的是小程式目前已經可以使用Vue語法開發（mpvue），從原理上來講，Vue的語法也可以移植到快應用上。
- React Native和Weex的渲染/排版引擎是整合到框架中的，每一個APP都需要打包一份，安裝包體積較大；而快應用渲染/排版引擎是整合到ROM中的，應用中無需打包，安裝包體積小，正因如此，快應用才能在保證效能的同時做到快速分發。
JavaScript開發+原生渲染的優缺點
優點：
- 採用Web開發技術棧，社群龐大、上手快、開發成本相對較低。
- 原生渲染，效能相比H5提高很多。
- 動態化較好，支援熱更新。
不足：
- 渲染時需要JavaScript和原生之間通訊，在有些場景如拖動可能會因為通訊頻繁導致卡頓。
- JavaScript為指令碼語言，執行時需要JIT(Just In Time)，執行效率和AOT(Ahead Of Time)程式碼仍有差距。
- 由於渲染依賴原生控制元件，不同平臺的控制元件需要單獨維護，並且當系統更新時，社群控制元件可能會滯後；除此之外，其控制元件系統也會受到原生UI系統限制，例如，在Android中，手勢衝突消歧規則是固定的，這在使用不同人寫的控制元件巢狀時，手勢衝突問題將會變得非常棘手。
QT
Qt是一個1991年由Qt Company開發的跨平臺C++圖形使用者介面應用程式開發框架。2008年，Qt Company科技被諾基亞公司收購，Qt也因此成為諾基亞旗下的程式語言工具。2012年，Qt被Digia收購。2014年4月，跨平臺整合開發環境Qt Creator 3.1.0正式釋出，實現了對於iOS的完全支援，新增WinRT、Beautifier等外掛，廢棄了無Python介面的GDB除錯支援，整合了基於Clang的C/C++程式碼模組，並對Android支援做出了調整，至此實現了全面支援iOS、Android、WP，它提供給應用程式開發者構建圖形使用者介面所需的所有功能。但是，QT雖然在PC端獲得了巨大成功，備受社群追捧，然而其在移動端卻表現不佳，在近幾年，雖然偶爾能聽到QT的聲音，但一直很弱，無論QT本身技術如何、設計思想如何，但事實上終究是敗了，沒火起來感覺有一下原因：
- QT移動開發社群太小，學習資料不足，生態不好
- 官方推廣不利，支援不夠。
- 移動端發力較晚，市場已被其它動態化框架佔領（Hybrid和RN)。
- 在移動開發中，C++開發和Web開發棧相比有著先天的劣勢，直接結果就是QT開發效率太低。
終於引出了本文重點-flutter
Flutter是Google釋出的一個用於建立跨平臺、高效能移動應用的框架。Flutter和QT mobile一樣，都沒有使用原生控制元件，相反都實現了一個自繪引擎，使用自身的佈局、繪製系統。那麼，我們會擔心，QT mobile面對的問題Flutter是否也一樣，Flutter會不會步入QT mobile後塵，成為另一個烈士？要回到這個問題，我們先來看看Flutter誕生過程：
- 2017 年 Google I/O 大會上，Google 首次推出了一款新的用於建立跨平臺、高效能的移動應用框架——Flutter
- 2018年2月，Flutter釋出了第一個Beta版本，同年五月， 在2018年Google I/O 大會上，Flutter 更新到了 beta 3 版本。
- 2018年6月，Flutter釋出了首個預覽版本，這意味著 Flutter 進入了正式版（1.0）釋出前的最後階段。 觀其發展，在2018年5月份，Flutter 進入了 GitHub stars 排行榜前 100 名，已有 27k star。而今天(2019年5月29日)，已經有65K的Star。經歷了短短2年多的時間，Flutter 生態系統得以快速增長，由此可見，Flutter在開發者中受到了熱烈的歡迎，其未來發展值得期待！
現在，我們來和QT mobile做一個對比：
- 生態：從Github上來看，目前Flutter活躍使用者正在高速增長。從Stackoverflow上提問來看，Flutter社群現在已經很龐大。Flutter的文件、資源也越來越豐富，開發過程中遇到的很多問題都可以在Stackoverflow或其github issue中找到答案。
- 技術支援：現在Google正在大力推廣Flutter，Flutter的作者中很多人都是來自Chromium團隊，並且github上活躍度很高。另一個角度，從今年上半年Flutter頻繁的版本釋出也可以看出Google對Flutter的投入的資源不小，所以在官方技術支援這方面，大可不必擔心
- 開發效率：Flutter的熱過載可幫助開發者快速地進行測試、構建UI、新增功能並更快地修復錯誤。在iOS和Android模擬器或真機上可以實現毫秒級熱過載，並且不會丟失狀態。這真的很棒，相信我，如果你是一名原生開發者，體驗了Flutter開發流後，很可能就不想重新回去做原生了，畢竟很少有人不吐槽原生開發的編譯速度。
自繪UI+原生的優缺點
繪UI+原生。這種技術的思路是，通過在不同平臺實現一個統一介面的渲染引擎來繪製UI，而不依賴系統原生控制元件，所以可以做到不同平臺UI的一致性。注意，自繪引擎解決的是UI的跨平臺問題，如果涉及其它系統能力呼叫，依然要涉及原生開發。這種平臺技術
優點：
- 效能高；由於自繪引擎是直接呼叫系統API來繪製UI，所以效能和原生控制元件接近。
- 靈活、元件庫易維護、UI外觀保真度和一致性高；由於UI渲染不依賴原生控制元件，也就不需要根據不同平臺的控制元件單獨維護一套元件庫，所以程式碼容易維護。由於元件庫是同一套程式碼、同一個渲染引擎，所以在不同平臺，元件顯示外觀可以做到高保真和高一致性；另外，由於不依賴原生控制元件，也就不會受原生布局系統的限制，這樣佈局系統會非常靈活。
不足：
- 動態性不足；為了保證UI繪製效能，自繪UI系統一般都會採用AOT模式編譯其釋出包，所以應用釋出後，不能像Hybrid和RN那些使用JavaScript（JIT）作為開發語言的框架那樣動態下發程式碼。
對比
