1、前言

跨平臺(tái)一直是老生常談的話題，cordova、ionic、react-native、weex、kotlin-native、flutter等跨平臺(tái)框架的百花齊放，頗有一股推倒原生開發(fā)者的勢(shì)頭。

為什么我們需要跨平臺(tái)開發(fā)？ 本質(zhì)上，跨平臺(tái)開發(fā)是為了增加代碼復(fù)用，減少開發(fā)者對(duì)多個(gè)平臺(tái)差異適配的工作量，降低開發(fā)成本，提高業(yè)務(wù)專注的同時(shí)，提供比web更好的體驗(yàn)。嗯～通俗了說就是：省錢、偷懶。

目前移動(dòng)端跨平臺(tái)開發(fā)中，備受關(guān)注的方案大致歸納為以下幾種情況：

1）react native、weex均使用JavaScript作為編程語(yǔ)言，目前JavaScript在跨平臺(tái)開發(fā)中，可謂占據(jù)半壁江山，大有“一統(tǒng)天下”的趨勢(shì)；

2）kotlin-native開始支持 iOS 和 Web 開發(fā)，（kotlin已經(jīng)成為android的一級(jí)語(yǔ)言）也想嘗試“一統(tǒng)天下”；

3）flutter是Google跨平臺(tái)移動(dòng)UI框架，Dart作為谷歌的親兒子，毫無(wú)疑問Dart成為flutter的編程語(yǔ)言。作為巨頭新生兒，在flutter官網(wǎng)也可以看出，flutter同樣“心懷天下”（可支持Web端、Android端、iOS端等）。

本篇主要以react-native、weex、flutter，深入聊聊當(dāng)前最火的這3種跨平臺(tái)移動(dòng)開發(fā)方案的實(shí)現(xiàn)原理、現(xiàn)狀與未來。至于為什么只講它們，因?yàn)閷?duì)比ionic、phoneGap，它們更于 “naive” (? ⁻? ?)。看完本篇，相信你會(huì)對(duì)于當(dāng)下跨平臺(tái)移動(dòng)開發(fā)的現(xiàn)狀、實(shí)現(xiàn)原理、框架的選擇等有更深入的理解。

（本文同步發(fā)布于：http://www.52im.net/thread-1870-1-1.html）

2、React Native的原理與特性介紹

React Native技術(shù)關(guān)鍵詞：

1）Facebook 出品；

2）JavaScript語(yǔ)言；

3）JSCore引擎；

4）React設(shè)計(jì)模式；

5）原生渲染。

2.1 理念架構(gòu)

“Learn once, write anywhere” ，代表著 Facebook對(duì) react native 的定義：學(xué)習(xí) react ，同時(shí)掌握 web 與 app 兩種開發(fā)技能。 react native 用了 react 的設(shè)計(jì)模式，但UI渲染、動(dòng)畫效果、網(wǎng)絡(luò)請(qǐng)求等均由原生端實(shí)現(xiàn)。開發(fā)者編寫的js代碼，通過 react native 的中間層轉(zhuǎn)化為原生控件和操作，比ionic等跨平臺(tái)應(yīng)用，大大提高了的用戶體驗(yàn)。

總結(jié)起來其實(shí)就是：React Native是利用 JS 來調(diào)用 Native 端的組件，從而實(shí)現(xiàn)相應(yīng)的功能。

如下圖所示，react native 的跨平臺(tái)是實(shí)現(xiàn)主要由三層構(gòu)成，其中 C++ 實(shí)現(xiàn)的動(dòng)態(tài)連結(jié)庫(kù)(.so)，作為中間適配層橋接，實(shí)現(xiàn)了js端與原生端的雙向通信交互。這里最主要是封裝了 JavaScriptCore 執(zhí)行js的解析，而 react native 運(yùn)行在JavaScriptCore中，所以不存在瀏覽器兼容的問題。

其中在IOS上直接使用內(nèi)置的javascriptcore， 在Android 則使用webkit.org官方開源的jsc.so。

2.2 實(shí)現(xiàn)原理

和前端開發(fā)不同：react native 所有的標(biāo)簽都不是真實(shí)控件，JS代碼中所寫控件的作用，類似 Map 中的 key 值。JS端通過這個(gè) key 組合的 Dom ，最后Native端會(huì)解析這個(gè) Dom ，得到對(duì)應(yīng)的Native控件渲染，如 Android 中 標(biāo)簽對(duì)應(yīng) ViewGroup 控件。

在 react native 中，JS端是運(yùn)行在獨(dú)立的線程中（稱為JS Thread ）。JS Thread 作為單線程邏輯，不可能處理耗時(shí)的操作。那么如 fetch 、圖片加載 、 數(shù)據(jù)持久化 等操作，在 Android 中實(shí)際對(duì)應(yīng)的是 okhttp 、Fresco 、SharedPreferences等。而跨線程通信，也意味著 Js Thread 和原生之間交互與通訊是異步的。

可以看出，react native 跨平臺(tái)的關(guān)鍵在于C++層，開發(fā)人員大部分時(shí)候，只專注于JS 端的代碼實(shí)現(xiàn)。 在原生端提供的各種 Native Module 模塊（如網(wǎng)絡(luò)請(qǐng)求，ViewGroup控件），和 JS 端提供的各種 JS Module（如JS EventEmiter模塊），都會(huì)在C++實(shí)現(xiàn)的so中保存起來，雙方的通訊通過C++中的保存的映射，最終實(shí)現(xiàn)兩端的交互。通信的數(shù)據(jù)和指令，在中間層會(huì)被轉(zhuǎn)為String字符串傳輸，雙向的調(diào)用流程如下圖。

2.3 打包加載

最終：JS代碼會(huì)被打包成一個(gè) bundle 文件，自動(dòng)添加到 App 的資源目錄下。react native 的打包腳本目錄為/node_modules/react-native/local-cli，打包最后會(huì)通過 metro 模塊壓縮 bundle 文件。而bundle文件只會(huì)打包js代碼，自然不會(huì)包含圖片等靜態(tài)資源，所以打包后的靜態(tài)資源，其實(shí)是被拷貝到對(duì)應(yīng)的平臺(tái)資源文件夾中。

其中圖片等存在資源的映射規(guī)則，比如放在 react native 項(xiàng)目根目錄下的 img/pic/logo.png 的資源，編譯時(shí)，會(huì)被重命名后，根據(jù)大小 merged 到對(duì)應(yīng)的是drawable目錄下，修改名稱為img_pic_logo.png。

打包Android和IOS，肯定需要相應(yīng)的平臺(tái)項(xiàng)目存在，在 react-native init 時(shí)創(chuàng)建的項(xiàng)目，就已經(jīng)包含了 android 和 ios 的模版工程，打包完的工程會(huì)加載bundle文件，然后啟動(dòng)項(xiàng)目，如下圖。這里就不展開了，有興趣的可以看QQ空間移動(dòng)開發(fā)團(tuán)隊(duì)分享的《React Native For Android 架構(gòu)初探》。

▲ react native完成啟動(dòng)流程圖（圖片來源于QQ空間移動(dòng)開發(fā)團(tuán)隊(duì)）

3、WEEX的原理與特性介紹

WEEX技術(shù)關(guān)鍵詞：

1）Alibaba 出品；

2）JavaScript語(yǔ)言；

3）JS V8引擎；

4）Vue設(shè)計(jì)模式；

5）原生渲染。

3.1 理念架構(gòu)

“Write once, run everywhere”：weex的定義就像是：寫個(gè) vue 前端，順便幫你編譯成性能還不錯(cuò)的 apk 和 ipa（當(dāng)然，現(xiàn)實(shí)有時(shí)很骨感）。基于 Vue 設(shè)計(jì)模式，支持 web、android、ios 三端，原生端同樣通過中間層轉(zhuǎn)化，將控件和操作轉(zhuǎn)化為原生邏輯來提高用戶體驗(yàn)。

在 weex 中，主要包括三大部分：JS Bridge、Render、Dom，分別對(duì)應(yīng)WXBridgeManager、WXRenderManager、WXDomManager，三部分通過WXSDKManager統(tǒng)一管理。其中 JS Bridge 和 Dom 都運(yùn)行在獨(dú)立的 HandlerThread 中，而 Render 運(yùn)行在 UI 線程。

JS Bridge 主要用來和 JS 端實(shí)現(xiàn)進(jìn)行雙向通信，比如把 JS 端的 dom 結(jié)構(gòu)傳遞給 Dom 線程。Dom 主要是用于負(fù)責(zé) dom 的解析、映射、添加等等的操作，最后通知UI線程更新。而 Render 負(fù)責(zé)在UI線程中對(duì) dom 實(shí)現(xiàn)渲染。

3.2 實(shí)現(xiàn)原理

和 react native一樣——weex 所有的標(biāo)簽也不是真實(shí)控件，JS 代碼中所生成存的 dom，最后都是由 Native 端解析，再得到對(duì)應(yīng)的Native控件渲染，如 Android 中 標(biāo)簽對(duì)應(yīng) WXTextView 控件。

weex 中文件默認(rèn)為 .vue ，而 vue 文件是被無(wú)法直接運(yùn)行的，所以 vue 會(huì)被編譯成 .js 格式的文件，Weex SDK會(huì)負(fù)責(zé)加載渲染這個(gè)js文件。Weex可以做到跨三端的原理在于：在開發(fā)過程中，代碼模式、編譯過程、模板組件、數(shù)據(jù)綁定、生命周期等上層語(yǔ)法是一致的。不同的是在 JS Framework 層的最后，web 平臺(tái)和 Native 平臺(tái)，對(duì) Virtual DOM 執(zhí)行的解析方法是有區(qū)別的。

實(shí)際上，在 Native 中對(duì) bundle 文件的加載大致經(jīng)歷以下階段：

1）weex 接收到 js 文件以后，JS Framework 根據(jù)文件為 Vue 模式，會(huì)調(diào)用weex-vue-framework 中提供的 createInstance方法創(chuàng)建實(shí)例。(也可能是Rax模式)；

2）createInstance 中會(huì)執(zhí)行 Js Entry 代碼里 new Vue() 創(chuàng)建一個(gè)組件，通過其 render 函數(shù)創(chuàng)建出 Virtual DOM 節(jié)點(diǎn)；

3）由JS V8 引擎上解析 Virtual DOM ，得到 Json 數(shù)據(jù)發(fā)送至 Dom 線，這里輸出 Json 也是方便跨端的數(shù)據(jù)傳輸；

4）Dom 線程解析 Json 數(shù)據(jù)，得到對(duì)應(yīng)的 WxDomObject，然后創(chuàng)建對(duì)應(yīng)的WxComponent 提交 Render；

5）Render在原生端最終處理處理渲染任務(wù)，并回調(diào)里JS方法。

得益于上層的統(tǒng)一性，只是通過 weex-vue-framework 判斷是由Vue.js 生成真實(shí)的 Dom ，還是通過 Native Api 渲染組件，weex 一定程度上上，用JS 實(shí)現(xiàn)了  vue 一統(tǒng)天下的效果。

weex 在原生渲染 Render 時(shí)，在接收到渲染指令后，會(huì)逐步將數(shù)據(jù)渲染成原生組件。Render 通過解析渲染數(shù)據(jù)的描述，然后分發(fā)給不同的模塊。

比如：控件渲染屬于 dom 模塊中，頁(yè)面跳轉(zhuǎn)屬于navigator模塊等。模塊的渲染過程并非一個(gè)執(zhí)行完，再執(zhí)行另一個(gè)的流程，而是類似流式的過程。如上一個(gè) 的組件還沒渲染好，下一個(gè)

weex 比起react native，主要是在JS V8的引擎上，多了 JS Framework 承當(dāng)了重要的職責(zé)，使得上層具備統(tǒng)一性，可以支持跨三個(gè)平臺(tái)。

總的來說JS Framework主要負(fù)責(zé)的是：

1）管理Weex的生命周期；

2）解析JS Bundle，轉(zhuǎn)為Virtual DOM，再通過所在平臺(tái)不同的API方法構(gòu)建頁(yè)面；

3）進(jìn)行雙向的數(shù)據(jù)交互和響應(yīng)。

3.3 打包

weex 作為 react-native 之后出現(xiàn)的跨平臺(tái)實(shí)現(xiàn)方案，自然可以站在前人的肩膀上優(yōu)化問題，比如：Bundle文件過大問題。

Bundle文件的大小，很大程度上影響了框架的性能，而 weex 選擇將 JS Framework 集成到 WeexSDK 中，一定程度減少了JS Bundle的體積，使得 bundle 里面只保留業(yè)務(wù)代碼。

打包時(shí)，weex 是通過 webpack 打包出 bundle 文件的。bundle 文件的打包和 entry.js 文件的配置數(shù)量有關(guān)，默認(rèn)情況下之后一個(gè) entry 文件，自然也就只有一個(gè)bundle文件。

在 weex 項(xiàng)目的 webpack.common.conf.js 中可以看到，其實(shí)打包也是區(qū)分了 webConfig 和 weexConfig 的不同打包方式。如下圖，其中weexEntry 就是 weex 打包配置的地方，可以看到本來已經(jīng)有 index 和 entry.js 存在了。如果有需要，可配置上你需要的打包頁(yè)面，具體這里就不詳細(xì)展開了。有興趣可看《Weex原理之帶你去蹲坑》。

4、Flutter的原理與特性介紹

Flutter技術(shù)關(guān)鍵詞：

1）Google 出品；

2）Dart語(yǔ)言；

3）Flutter Engine引擎；

4）響應(yīng)式設(shè)計(jì)模式；

5）原生渲染。

Flutter 是谷歌2018年發(fā)布的跨平臺(tái)移動(dòng)UI框架。相較于本人已經(jīng)在項(xiàng)目中使用過 react native 和 Weex，F(xiàn)lutter目前僅僅是簡(jiǎn)單運(yùn)行過Demo，畢竟還是beta 階段，這里更多的聊一下它的實(shí)現(xiàn)機(jī)制和效果。

與 react native 和 weex 的通過 Javascript 開發(fā)不同，F(xiàn)lutter 的編程語(yǔ)言是Drat，所以執(zhí)行時(shí)并不需要 Javascript 引擎，但實(shí)際效果最終也通過原生渲染。

如上圖，F(xiàn)lutter 主要分為 Framework 和 Engine，我們基于Framework 開發(fā)App，運(yùn)行在 Engine 上。Engine 是 Flutter 的獨(dú)立虛擬機(jī)，由它適配和提供跨平臺(tái)支持，目前猜測(cè) Flutter 應(yīng)用程序在 Android 上，是直接運(yùn)行 Engine 上 所以在是不需要Dalvik虛擬機(jī)（這是比kotlin更徹底，拋棄JVM的糾纏？）

如下圖，得益于 Engine 層，F(xiàn)lutter 甚至不使用移動(dòng)平臺(tái)的原生控件， 而是使用自己 Engine 來繪制 Widget （Flutter的顯示單元），而 Dart 代碼都是通過 AOT 編譯為平臺(tái)的原生代碼，所以 Flutter 可以 直接與平臺(tái)通信，不需要JS引擎的橋接。同時(shí) Flutter 唯一要求系統(tǒng)提供的是 canvas，以實(shí)現(xiàn)UI的繪制。咦？這么想來，支持web端也沒問題吧！

在Flutter中，大多數(shù)東西都是widget，而widget是不可變的，僅支持一幀，并且在每一幀上不會(huì)直接更新，要更新而必須使用Widget的狀態(tài)。無(wú)狀態(tài)和有狀態(tài) widget 的核心特性是相同的，每一幀它們都會(huì)重新構(gòu)建，有一個(gè)State對(duì)象，它可以跨幀存儲(chǔ)狀態(tài)數(shù)據(jù)并恢復(fù)它。

Flutter 上 Android 自帶了 Skia，Skia是一個(gè) 2D的繪圖引擎庫(kù)，跨平臺(tái)，所以可以被嵌入到 Flutter的 iOS SDK中，也使得 Flutter Android SDK要比 iOS SDK小很多。

熱門話題：為什么Flutter會(huì)選擇 Dart作為開發(fā)語(yǔ)言？

八卦消息認(rèn)為：“是因?yàn)?Drat 項(xiàng)目組就在 Flutter 隔壁而被選上”。

實(shí)際上真實(shí)的原因是：早期的Flutter團(tuán)隊(duì)評(píng)估了十多種語(yǔ)言，并選擇了Dart，因?yàn)樗纤麄儤?gòu)建用戶界面的方式。

Dart之所以成為Flutter不可或缺的一部分，根本原因還是因?yàn)槠渚哂幸韵绿匦裕?/span>

1）Dart是AOT（Ahead Of Time）編譯的，編譯成快速、可預(yù)測(cè)的本地代碼，使Flutter幾乎都可以使用Dart編寫。這不僅使Flutter變得更快，而且?guī)缀跛械臇|西（包括所有的小部件）都可以定制；

2）Dart也可以JIT（Just In Time）編譯，開發(fā)周期異常快，工作流顛覆常規(guī)（包括Flutter流行的亞秒級(jí)有狀態(tài)熱重載）；

3）Dart可以更輕松地創(chuàng)建以60fps運(yùn)行的流暢動(dòng)畫和轉(zhuǎn)場(chǎng)。Dart可以在沒有鎖的情況下進(jìn)行對(duì)象分配和垃圾回收。就像JavaScript一樣，Dart避免了搶占式調(diào)度和共享內(nèi)存（因而也不需要鎖）。由于Flutter應(yīng)用程序被編譯為本地代碼，因此它們不需要在領(lǐng)域之間建立緩慢的橋梁（例如，JavaScript到本地代碼）。它的啟動(dòng)速度也快得多；

4）Dart使Flutter不需要單獨(dú)的聲明式布局語(yǔ)言，如JSX或XML，或單獨(dú)的可視化界面構(gòu)建器，因?yàn)镈art的聲明式編程布局易于閱讀和可視化。所有的布局使用一種語(yǔ)言，聚集在一處，F(xiàn)lutter很容易提供高級(jí)工具，使布局更簡(jiǎn)單；

5）開發(fā)人員發(fā)現(xiàn)Dart特別容易學(xué)習(xí)，因?yàn)樗哂徐o態(tài)和動(dòng)態(tài)語(yǔ)言用戶都熟悉的特性。

并非所有這些功能都是Dart獨(dú)有的，但它們的組合卻恰到好處，使Dart在實(shí)現(xiàn)Flutter方面獨(dú)一無(wú)二。因此，沒有Dart，很難想象Flutter像現(xiàn)在這樣強(qiáng)大。

有關(guān)此話題的詳細(xì)文章請(qǐng)見《為什么Flutter會(huì)選擇 Dart ？》。

5、React Native、weex、Flutter 3種方案橫向?qū)Ρ?/h1>

這算是互相傷害的環(huán)節(jié)了吧。(///▽///)

5.1 最終程序大小

以Android平臺(tái)為例，上面Apk大小是通過 react-native init、weex create 和 flutter 創(chuàng)建出的工程后，直接不添加任何代碼，打包出來的 release 簽名 apk 大小。從下圖可以看出，其中大比例都是在so庫(kù)。

5.2 社群支持

react native 作為 Facebook 主力開源項(xiàng)目之一，至今已有各類豐富的第三方庫(kù)，甚至如 realm、lottie 等開源項(xiàng)目也有 react native 相關(guān)的版本，社群實(shí)際無(wú)需質(zhì)疑。當(dāng)然，因?yàn)椴⑼耆y(tǒng)開發(fā)平臺(tái)，第三庫(kù)的健壯性和兼容性有時(shí)候總是良莠不齊。

weex 其實(shí)有種生錯(cuò)在國(guó)內(nèi)的感覺。其實(shí) weex 的設(shè)計(jì)和理念都很優(yōu)秀，性能也不錯(cuò)，但是對(duì)比 react native 的第三方支持，就顯得有點(diǎn)后媽養(yǎng)的。2016年開源至今，社區(qū)和各類文檔都顯得有點(diǎn)疲弱，作為跨平臺(tái)開發(fā)人員，大多時(shí)候肯定不會(huì)希望，需要頻繁的自己增加原生功能支持，因?yàn)檫@樣的工作一多，反而會(huì)與跨平臺(tái)開發(fā)的理念背道而馳，帶來開發(fā)成本被維護(hù)難度增加。

Flutter 目前還處理beta階段，但是谷歌的號(hào)召力一直很可觀，這一點(diǎn)無(wú)需質(zhì)疑。

5.3 性能區(qū)別

理論上 flutter 的性能應(yīng)該是最好的，但是目前實(shí)際體驗(yàn)中，卻并沒有感受出來太大的差距，和 react native（0.5.0之后）、weex 在性能上個(gè)人體驗(yàn)差異不是很大。當(dāng)然，這里并沒有實(shí)測(cè)渲染的毫秒時(shí)間和幀率數(shù)據(jù)。

5.4 其他區(qū)別

Weex的多頁(yè)面實(shí)現(xiàn)問題：

weex 在 native 端是不支持 的，這一點(diǎn)和 react-native 不同在與，如果在 native 需要實(shí)現(xiàn)頁(yè)面跳轉(zhuǎn)，使用 vue-router 將會(huì)慘不忍睹：返回后頁(yè)面不做特別處理時(shí)，是會(huì)空白一片。參考官方Demo playground，native 端 的采用 weex.requireModule('navigator') 跳轉(zhuǎn) Activity 是才正確實(shí)現(xiàn)。

同時(shí)，weex中 navigator 跳轉(zhuǎn)的設(shè)計(jì)，也導(dǎo)致了多頁(yè)面的頁(yè)面間通訊的差異。weex在多頁(yè)面下的數(shù)據(jù)通訊，是通過url實(shí)現(xiàn)的，比如file://assets/dist/SecondPage.js?params=0，而vuex和vue-router在跨頁(yè)面是無(wú)法共用的；而 react native 在跨 Actvity 使用時(shí)，因?yàn)槭峭粋€(gè)bundle文件，只要 manager 相同，那么 router 和 store 時(shí)可以照樣使用的，數(shù)據(jù)通信方式也和當(dāng)個(gè) Actvity 沒區(qū)別。

項(xiàng)目模板：

weex 和 react native 模板代碼模式也不同。weex 的模板是從 cordova 模式修改過來的，根據(jù)platform需求，用命令添加固定模塊，而在 .gitignore 對(duì) platforms 文件夾是忽略跟蹤。 react native 在項(xiàng)目創(chuàng)建時(shí)模版就存在了，特別是添加第三方插件原生端支持時(shí)，會(huì)直接修改模板代碼，git代碼中也會(huì)添加跟蹤修改。

6、未來趨勢(shì)展望

我們選擇框架的時(shí)候，很多時(shí)候會(huì)關(guān)注框架的成熟度和生命力不是么(◐‿◑)。

6.1 React Native

“Airbnb 宣布放棄使用 React Native，回歸使用原生技術(shù)” : Airbnb 作為 react native 平臺(tái)上最大的支持者之一，其開源的lottie 同樣是支持原生和 react native。

Airbnb 在宣布放棄的文中，也對(duì) react native 的表示了很大量的肯定，而使得他們放棄的理由，其實(shí)主要還是集中于項(xiàng)目龐大之后的維護(hù)困難，第三方庫(kù)的良莠不齊，兼容上需要耗費(fèi)更多的精力導(dǎo)致放棄。

ps： Lottie庫(kù)Airbnb出的是一個(gè)能夠幫助解析AE導(dǎo)出的包含動(dòng)畫信息的json文件。這很好的解決了一個(gè)矛盾，設(shè)計(jì)師可以更專注的設(shè)計(jì)出各種炫酷的動(dòng)畫效果，而開發(fā)只需要將其加入支持即可。

Facebook 正在重構(gòu) React Native，將重寫大量底層。在經(jīng)歷了開源協(xié)議風(fēng)波后，可以看出 Facebook 對(duì)于 react native 還是很看重的。

這些底層重構(gòu)優(yōu)化的地方，主要集中于：

1）首先：改變線程模型。UI 更新不再需要在三個(gè)不同的線程上執(zhí)行，而是可以在任意線程上同步調(diào)用 JavaScript 進(jìn)行優(yōu)先更新，同時(shí)將低優(yōu)先級(jí)工作推出主線程，以便保持對(duì) UI 的響應(yīng)；

2）其次：將異步渲染功能引入 React Native 中，允許執(zhí)行多個(gè)渲染并簡(jiǎn)化異步數(shù)據(jù)處理；

3）最后：簡(jiǎn)化橋接，讓它更快、更輕量。原生和 JavaScript 之間的直接調(diào)用效率更高，并且可以更輕松地構(gòu)建調(diào)試工具，如跨語(yǔ)言堆棧跟蹤。

其他React Native相關(guān)文章：

從Android到React Native開發(fā)（一、入門）

從Android到React Native開發(fā)（二、通信與模塊實(shí)現(xiàn)）

從Android到React Native開發(fā)（三、自定義原生控件支持）

從Android到React Native開發(fā)（四、打包流程和發(fā)布為Maven庫(kù)）

6.2 Weex

沒有死！阿里公開Weex技術(shù)架構(gòu)，還開源了一大波組件。 2018年初的新聞可以看出，weex 的遭遇有點(diǎn)類似曾經(jīng)的 Duddo（Dubbo因?yàn)閮?nèi)部競(jìng)爭(zhēng)被阿里一度放棄維護(hù)），這波詐尸后 weex 被托管到了Apache，而github的 weexteam 如今也還保持著更新，希望后續(xù)能有多好的發(fā)展，拭目以待吧。

6.3 Flutter

Flutter 是 Google 跨平臺(tái)移動(dòng)UI框架，Dart作為谷歌的親兒子在 Flutter 中使用，并且谷歌新操作系統(tǒng) Fuchsia 支持 Dart，使用 Flutter 作為操作UI框架。這些集合到一起難免讓你懷疑 Android 是否要被谷歌拋棄的想法。

或者如今先 Android 等平臺(tái)上推廣 Flutter 與 Dart，就是為了以后跟好的過渡到新系統(tǒng)上，畢竟開發(fā)者是操作系統(tǒng)的生命源泉之一。而 Java 與 JVM 或者可以被谷歌完全拋開。當(dāng)然，目前看起來 Flutter 貌似還缺少一些語(yǔ)法糖，嵌套下來的代碼有點(diǎn)不忍直視，或者到正式版之后，我們更能感受出它的美麗吧。

（原文鏈接：https://www.jianshu.com/p/7e0bd4708ba7，內(nèi)容有改動(dòng)）

附錄：更多移動(dòng)端開發(fā)精華文章

《通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《從客戶端的角度來談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》

《基于社交網(wǎng)絡(luò)的Yelp是如何實(shí)現(xiàn)海量用戶圖片的無(wú)損壓縮的？》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《為什么說即時(shí)通訊社交APP創(chuàng)業(yè)就是一個(gè)坑？》

《字符編碼那點(diǎn)事：快速理解ASCII、Unicode、GBK和UTF-8》

《全面掌握移動(dòng)端主流圖片格式的特點(diǎn)、性能、調(diào)優(yōu)等》

《最火移動(dòng)端跨平臺(tái)方案盤點(diǎn)：React Native、weex、Flutter》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-1870-1-1.html）