嗯。。。這個問題十分不好回答啊(捋下魚須)。閒魚作為flutter領域的先驅者，以及fish_redux、flutter_boost等當紅flutter庫的作者，當然是歡迎廣大的開發者多多使用flutter相關技術棧 逃~:)。咳咳，不過呢，我們還是正經得聊一下React Native(下面簡稱RN)和flutter之前的異同：
React Native
React Native是Facebook開源的一款基於react思想、使用JS、能夠給移動平臺帶來native般體驗的框架，官網最新的版本是0.5.9。
flutter
flutter來自Google，上層使用dart語言構建跨平臺應用，透過平臺相關的embedded層接入到使用c++編寫的engine層，再透過skia庫直接與GPU進行互動。透過對dart程式碼的AOT編譯，擁有優異的計算(CPU)、渲染(GPU)效能。官網最新的版本為1.2。
開發者們使用跨平臺技術棧，首要的目的是為了能夠省事兒，所以跨平臺能力是首先要被衡量的指標。
Build native mobile apps using JavaScript and React
這意味著開發者可以複用龐大的JavaScript生態和優雅的react思想來書寫RN的程式碼，給開發提供很多的便利性。
從實現原理上來說，RN進行完排版之後會把最終的渲染交給native view，這種方式帶來的是如native般的UI效能，但同時也給給平臺一致性帶來了一些問題。除開渲染層的不一致，在iOS和Android沒有使用同一個JavaScript虛擬機器也會帶來一些暗坑。
手勢的處理上兩個平臺不好統一，RN官方也沒有提供一個抹平差異的庫，雖然開源社群有react-native-gesture-handler。
Beautiful native apps in record time
flutter官方的口氣很大，說自己是”空前“的。是不是”空前“，我們得來評估一下。
程式語言層面，flutter使用dart語言構建應用，這門語言對大多數人來說應該是比較陌生，好在dart的語法並不複雜，與Java等強型別oop語言非常相似，還加入了函式式的特性，使用起來還是挺方便的。
flutter提供類似React思想的響應性UI程式設計模型，讓UI開發變得更加fancy。
原理上來說，flutter在各個平臺上使用統一的vm(dart vm)，自帶GDI(skia)。skia是一個已經發展多年成熟度相當高的2D圖形庫，也是Android系統和Chrome一直在使用的圖形庫。
flutter從邏輯計算到渲染繪圖，都是自己的，使得它在跨平臺一致性上有良好的表現。dart提供的AOT特性也可以保證應用在線上有一個好的效能表現。
多平臺支援
RN目前支援iOS和Android兩個平臺，另外有個非官方的ReactNativeX的專案旨在讓RN執行到其他平臺。
flutter早期支援iOS和Android，desktop的支援目前尚不完善。近期flutter團隊釋出了Hummingbird，旨在讓flutter編寫的應用可以執行在瀏覽器端。
從多平臺支援的角度看，兩邊差距不大。相比RN，flutter在desktop的支援上有些優勢，但目前都是不怎麼可用狀態。
工具鏈
RN在打包釋出方面有被前端廣泛使用的webpack支援，官方自己提供了基於瀏覽器的debug工具，與前端同學管用的除錯方式並無二致。
flutter基於iOS和Android已有的打包工具添加了flutter產物打包功能，同樣debug工具也由官方自己提供，除了剛釋出的基於瀏覽器的除錯工具外，flutter團隊提供的除錯工具可以直接在Android Studio或者VScode這類IDE上直接使用。
除錯便利性
JS的除錯方式已經很成熟了，這裡不多做展開。 flutter在debug階段可以使用集成於IDE外掛中的hot reload功能做到亞秒級的新程式碼載入速度，十分適合與設計師坐在一起結(ya)對(li)編(tiao)程(shi) ：）。
第三方庫
在RN上你可以使用JS的大部分庫，平臺相關的plugin也相對豐富。
flutter在這方面稍顯欠缺，庫的數量上無法與JS生態相比較。flutter/plugins專案提供了大量的平臺相關外掛供開發者使用，倒也是滿足了日常開發的需求，另外dart pubs上的公開庫數量也日趨上升。
在混合開發和大型app業務框架上，閒魚技術開源的flutter_boost提供了與native混合開發的可能，而fish_redux使得大型app中的複雜頁面的開發在flutter中變得更加容易。
開發者選擇一個技術，都是壓了”身家性命“在上面，誰也不想剛入門就發現這門技術即將被淘汰。
RN是個很好的專案，在釋出之初給移動開發帶來了一陣旋風。但不得不說，Airbnb宣佈放棄使用RN技術棧對於整個社群有不小的打擊，而文章中對原因的闡述也相當有說服力。
flutter在1.0釋出之後趨於成熟，被欽定為Google Fuchsia系統的應用層框架。從團隊2019 roadmap中可以看到，flutter當前重點在於完善一些現有功能上的細節與bugfix，另外對於廣受期待的動態化特性，flutter團隊也在開發code push功能。從flutter團隊目前的方向和筆者在閒魚開發中實際使用的flutter的感受來看，整體上flutter在框架層面目前已經基本上穩定。
從桌面端跨平臺框架發展的歷程來看，Java GUI從最初使用peer(對等設計模式)的AWT，到基於Java圖形繪製介面效能巨慢無比的Swing，再到公認效能最好目前應用最廣泛的基於目標平臺繪製介面的SWT，我們可以從中窺見一些歷史規律。
peer(對等設計模式)，即AWT中的一個控制元件，對應目標平臺(如Windows)上的一個控制元件(是不是看起來跟RN有一些相似)，最終AWT被放棄是因為peer模式傳輸層級過多造成效率低下，GUI部分為了保證可移植性只能保留各個平臺公共的介面。
SWT與QT(另一個被廣泛使用的桌面端跨平臺GUI框架)，犧牲了一部分可移植性(主要是因為直接呼叫了目標平臺的圖形繪製介面)，帶來了GUI的高效能。flutter也採用了類似技術棧，skia來抹平各個平臺的繪製介面差異，並向上提供統一的圖形介面。
從這個角度來說，無疑flutter可能會是一個更有未來的跨平臺框架。
當然Facebook官方對於RN正在進行重構，包括把大部分邏輯移動到c++層來減少執行緒切換的開銷提升效能等。
選擇一個框架需要考慮的實際情況比框架的優劣比較更加重要，比如你的專案大小、開發人員構成等， RN和flutter作為目前移動平臺上炙手可熱的框架，兩者並不是孰優孰劣的對立關係。
嗯。。。這個問題十分不好回答啊(捋下魚須)。閒魚作為flutter領域的先驅者，以及fish_redux、flutter_boost等當紅flutter庫的作者，當然是歡迎廣大的開發者多多使用flutter相關技術棧 逃~:)。咳咳，不過呢，我們還是正經得聊一下React Native(下面簡稱RN)和flutter之前的異同：
0x00 簡單介紹一下React Native
React Native是Facebook開源的一款基於react思想、使用JS、能夠給移動平臺帶來native般體驗的框架，官網最新的版本是0.5.9。
flutter
flutter來自Google，上層使用dart語言構建跨平臺應用，透過平臺相關的embedded層接入到使用c++編寫的engine層，再透過skia庫直接與GPU進行互動。透過對dart程式碼的AOT編譯，擁有優異的計算(CPU)、渲染(GPU)效能。官網最新的版本為1.2。
0x01 跨平臺性開發者們使用跨平臺技術棧，首要的目的是為了能夠省事兒，所以跨平臺能力是首先要被衡量的指標。
Build native mobile apps using JavaScript and React
這意味著開發者可以複用龐大的JavaScript生態和優雅的react思想來書寫RN的程式碼，給開發提供很多的便利性。
從實現原理上來說，RN進行完排版之後會把最終的渲染交給native view，這種方式帶來的是如native般的UI效能，但同時也給給平臺一致性帶來了一些問題。除開渲染層的不一致，在iOS和Android沒有使用同一個JavaScript虛擬機器也會帶來一些暗坑。
手勢的處理上兩個平臺不好統一，RN官方也沒有提供一個抹平差異的庫，雖然開源社群有react-native-gesture-handler。
Beautiful native apps in record time
flutter官方的口氣很大，說自己是”空前“的。是不是”空前“，我們得來評估一下。
程式語言層面，flutter使用dart語言構建應用，這門語言對大多數人來說應該是比較陌生，好在dart的語法並不複雜，與Java等強型別oop語言非常相似，還加入了函式式的特性，使用起來還是挺方便的。
flutter提供類似React思想的響應性UI程式設計模型，讓UI開發變得更加fancy。
原理上來說，flutter在各個平臺上使用統一的vm(dart vm)，自帶GDI(skia)。skia是一個已經發展多年成熟度相當高的2D圖形庫，也是Android系統和Chrome一直在使用的圖形庫。
flutter從邏輯計算到渲染繪圖，都是自己的，使得它在跨平臺一致性上有良好的表現。dart提供的AOT特性也可以保證應用在線上有一個好的效能表現。
多平臺支援
RN目前支援iOS和Android兩個平臺，另外有個非官方的ReactNativeX的專案旨在讓RN執行到其他平臺。
flutter早期支援iOS和Android，desktop的支援目前尚不完善。近期flutter團隊釋出了Hummingbird，旨在讓flutter編寫的應用可以執行在瀏覽器端。
從多平臺支援的角度看，兩邊差距不大。相比RN，flutter在desktop的支援上有些優勢，但目前都是不怎麼可用狀態。
0x02 開發便利性工具鏈
RN在打包釋出方面有被前端廣泛使用的webpack支援，官方自己提供了基於瀏覽器的debug工具，與前端同學管用的除錯方式並無二致。
flutter基於iOS和Android已有的打包工具添加了flutter產物打包功能，同樣debug工具也由官方自己提供，除了剛釋出的基於瀏覽器的除錯工具外，flutter團隊提供的除錯工具可以直接在Android Studio或者VScode這類IDE上直接使用。
除錯便利性
JS的除錯方式已經很成熟了，這裡不多做展開。 flutter在debug階段可以使用集成於IDE外掛中的hot reload功能做到亞秒級的新程式碼載入速度，十分適合與設計師坐在一起結(ya)對(li)編(tiao)程(shi) ：）。
第三方庫
在RN上你可以使用JS的大部分庫，平臺相關的plugin也相對豐富。
flutter在這方面稍顯欠缺，庫的數量上無法與JS生態相比較。flutter/plugins專案提供了大量的平臺相關外掛供開發者使用，倒也是滿足了日常開發的需求，另外dart pubs上的公開庫數量也日趨上升。
在混合開發和大型app業務框架上，閒魚技術開源的flutter_boost提供了與native混合開發的可能，而fish_redux使得大型app中的複雜頁面的開發在flutter中變得更加容易。
0x03 未來的發展開發者選擇一個技術，都是壓了”身家性命“在上面，誰也不想剛入門就發現這門技術即將被淘汰。
RN是個很好的專案，在釋出之初給移動開發帶來了一陣旋風。但不得不說，Airbnb宣佈放棄使用RN技術棧對於整個社群有不小的打擊，而文章中對原因的闡述也相當有說服力。
flutter在1.0釋出之後趨於成熟，被欽定為Google Fuchsia系統的應用層框架。從團隊2019 roadmap中可以看到，flutter當前重點在於完善一些現有功能上的細節與bugfix，另外對於廣受期待的動態化特性，flutter團隊也在開發code push功能。從flutter團隊目前的方向和筆者在閒魚開發中實際使用的flutter的感受來看，整體上flutter在框架層面目前已經基本上穩定。
從桌面端跨平臺框架發展的歷程來看，Java GUI從最初使用peer(對等設計模式)的AWT，到基於Java圖形繪製介面效能巨慢無比的Swing，再到公認效能最好目前應用最廣泛的基於目標平臺繪製介面的SWT，我們可以從中窺見一些歷史規律。
peer(對等設計模式)，即AWT中的一個控制元件，對應目標平臺(如Windows)上的一個控制元件(是不是看起來跟RN有一些相似)，最終AWT被放棄是因為peer模式傳輸層級過多造成效率低下，GUI部分為了保證可移植性只能保留各個平臺公共的介面。
SWT與QT(另一個被廣泛使用的桌面端跨平臺GUI框架)，犧牲了一部分可移植性(主要是因為直接呼叫了目標平臺的圖形繪製介面)，帶來了GUI的高效能。flutter也採用了類似技術棧，skia來抹平各個平臺的繪製介面差異，並向上提供統一的圖形介面。
從這個角度來說，無疑flutter可能會是一個更有未來的跨平臺框架。
0x04 寫在最後當然Facebook官方對於RN正在進行重構，包括把大部分邏輯移動到c++層來減少執行緒切換的開銷提升效能等。
選擇一個框架需要考慮的實際情況比框架的優劣比較更加重要，比如你的專案大小、開發人員構成等， RN和flutter作為目前移動平臺上炙手可熱的框架，兩者並不是孰優孰劣的對立關係。