React native充分利用了Facebook的現(xiàn)有輪子，是一個(gè)很優(yōu)秀的集成作品，并且我相信這個(gè)團(tuán)隊(duì)對前端的了解很深刻，否則不可能讓Native code「退居二線」。

對應(yīng)到前端開發(fā)，整個(gè)系統(tǒng)結(jié)構(gòu)是這樣：

JSX vs HTML

CSS-layout vs css

ECMAScript 6 vs ECMAScript 5

React native View vs DOM

無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個(gè)界面就全變了。

多數(shù)布局代碼都是JSX，所有Native組件都是標(biāo)簽化的，這對于前端程序員來說，降低了不少學(xué)習(xí)成本，也大大減少了代碼量。不信你可以看看JSX編譯后的代碼。

復(fù)用React系統(tǒng)，也減少了一定學(xué)習(xí)和開發(fā)成本，更重要的是利用了React里面的分層和diff機(jī)制。js層傳給Native層的是一個(gè)diff后的json，然后由Native將這個(gè)數(shù)據(jù)映射成真正的布局視圖。

css-layout也是點(diǎn)睛之筆，前端可以繼續(xù)用熟悉的類css方式來編寫布局，通過這個(gè)工具轉(zhuǎn)換成constrain布局。

系統(tǒng)只有js-objc的單向調(diào)用，就是把原生UI組件的方法通過javascritcore或者webview（低版本iOS）映射到j(luò)s中來，整個(gè)調(diào)用過程是異步的，這樣的設(shè)計(jì)令React native可以讓js運(yùn)行在桌面chrome中，通過websocket連接Native code和桌面chrome，極大地方便了調(diào)試。對其中的機(jī)制Bang的一篇文章寫得很詳細(xì)，我就不拾人牙慧了：React Native通信機(jī)制詳解 laquo;  bang’s blog 。但這樣設(shè)計(jì)也會(huì)帶來一些問題，后面說。

點(diǎn)按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什么和web「手感」不同的原因：實(shí)時(shí)的點(diǎn)按反饋和取消能力。React Native 這套相應(yīng)機(jī)制設(shè)計(jì)得很完善，能像Native code那樣控制整個(gè)點(diǎn)按操作的所有過程。

Debug相當(dāng)方便！修改了js以后，通過內(nèi)建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個(gè)chrome窗口，所有的js都移到了chrome里面運(yùn)行，所以什么斷點(diǎn)單步打調(diào)用棧，都不在話下。

上面的既是特點(diǎn)也是優(yōu)點(diǎn)，下面說說缺點(diǎn)，或者應(yīng)該說：「仍然遺留的問題」，在我看來，這個(gè)方案已經(jīng)超越了Hybird方案。

系統(tǒng)仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個(gè)例子，ScrollView這個(gè)組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現(xiàn)有的版本都沒有暴露，基本上做不了組件聯(lián)動(dòng)效果。另外，這個(gè)版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩余的都是一些抽象程度極強(qiáng)的基本組件。這樣，用戶必須在不同的下寫兩套代碼，而且所有能力仍然強(qiáng)烈依賴 React native 開發(fā)人員暴露的接口。

由于最外層是React，初次學(xué)習(xí)成本高，不像往常的Hybird方案，只要多學(xué)幾個(gè)JS API就可以開始干活了。當(dāng)然，React的確讓后續(xù)開發(fā)變得簡單了一些，這么一套外來的（基于iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那么面目可憎了。

另外，React Native仍然很不完善。文檔還不全，我基本上是看著他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年后才發(fā)布：Blog | React ，屆時(shí)整個(gè)系統(tǒng)設(shè)計(jì)可能還會(huì)有很大的變化。

PS，在使用Tabbar的時(shí)候，我驚喜的發(fā)現(xiàn)他們居然用了iconfont方案，我現(xiàn)在手頭的項(xiàng)目中也有同樣的實(shí)現(xiàn)，不過API怎么設(shè)計(jì)一直很頭疼。結(jié)果，我發(fā)現(xiàn)他是這么寫的：

<TabBarItemIOS

name="blueTab"

icon={_ix_DEPRECATED('favorites')}

.>

在 _ix_DEPRECATED 的定義處，有一句注釋： // TODO(nicklockwood): How can this fit our require system?

以上。

下面是一周前，在React native還沒開源的時(shí)候，通過反解ipa的一些分析過程，有興趣的可以看看。

------------------------簡單粗暴的分割線--------------------

背景和調(diào)研手段

React Native還沒開源，最近和組里兄弟「反編譯」了Facebook Group（這個(gè)應(yīng)用是用React Native實(shí)現(xiàn)的）的ipa代碼，出來幾百個(gè)JS文件，格式化一下，花了幾天時(shí)間讀了一下源碼，對React Native的內(nèi)部核心機(jī)制算是有了一個(gè)基本了解。

React Native的核心實(shí)現(xiàn)：

先簡單說幾點(diǎn)，詳細(xì)的等回頭更新。

1. React Native里面沒有webview，這貨不是Hybrid app，里面執(zhí)行JS是用的

2. JavascriptCore。

3. 2. 再說React Native的核心，iOS Native code提供了十來個(gè)最基本核心的類（RCTDeviceEventEmitter、RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，組成二十來個(gè)基本組件（Popover、Listview等），交由上層的業(yè)務(wù)方來使用（THGroupView）。

4. 3. 就如他們在宣傳時(shí)所說，他們實(shí)現(xiàn)了一套類似css的子集，用來解決樣式問題，相當(dāng)復(fù)雜和強(qiáng)大，靠這個(gè)才能將Native的核心組件組成JS層的基本組件再組成業(yè)務(wù)端的業(yè)務(wù)組件，應(yīng)該是采用facebook/css-layout · GitHub的C語言版本實(shí)現(xiàn)的（在ppt中我們看到了類似flex-direction: column一類的代碼，這個(gè)正是css-layout支持的語法）。

5. 4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴(kuò)展性、靈活性和性能」的問題。

React Native的設(shè)計(jì)考慮：

ReactJS對React Native有著直接的影響（我沒在生產(chǎn)環(huán)境中用過React，只看過代碼用過Angular，如果有誤請指出）

ReactJS里面有這樣的設(shè)計(jì)：

1. ReactJS 的大工廠入口createElement返回的不是某個(gè)實(shí)體DOM對象，而只是一個(gè)數(shù)組

2. 2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個(gè)數(shù)組轉(zhuǎn)換成DOM

3. 3. 底層的渲染核心是可以更換的

另外，F(xiàn)acebook自己有JSX，css-layout等開源項(xiàng)目，基于這些，如果要做一個(gè)用 JS來開發(fā)Native app的東西，很自然就想到了一套最有效率的搞法：

1. 將 ui/browser 里面的代碼替換成一套 Native 的橋接JS（實(shí)際上，iOS版是通過

2. injectGenericComponentClass方法，將核心組件的方法注入到JS里面 ），就直接復(fù)用React的MVVM，自動(dòng)將數(shù)據(jù)映射到Native了

3. 2. Native code里面實(shí)現(xiàn)三組核心API，一組提供核心組件的API（create、update、delete），一組事件方法（ReactJS里面的EventEmitter ），一組對css進(jìn)行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。

這樣，用上了ReactJS本身的所有核心功能和設(shè)計(jì)思路，Native的開發(fā)也足夠簡單。

那，React Native是什么看

其實(shí)這東西從Native開發(fā)來說，相當(dāng)于重新發(fā)明了一個(gè)瀏覽器渲染引擎并且套一個(gè)React的殼，從Web開發(fā)角度來說，就是把原來React的后端換成了Native code來實(shí)現(xiàn)，就跟Flipboard最近搞的React Canvas 一樣： Flipboard · GitHubreact-canvas

React Native的優(yōu)勢和劣勢：：

優(yōu)勢相對Hybird app或者Webapp：

1. 不用Webview，徹底擺脫了Webview讓人不爽的交互和性能問題

2. 2. 有較強(qiáng)的擴(kuò)展性，這是因?yàn)镹ative端提供的是基本控件，JS可以自由組合使用

3. 3. 可以直接使用Native原生的「」動(dòng)畫（在FB Group這個(gè)app里面，面板滑出帶一點(diǎn)果凍彈動(dòng)，面板基于某個(gè)點(diǎn)展開這種動(dòng)畫隨處可見，這種動(dòng)畫用Native code來做小菜一碟，但是用Web來做就難上加難）。

優(yōu)勢相對于Native app：

1. 可以通過更新遠(yuǎn)端JS，直接更新app，不過這快成為各家大型Native app的標(biāo)配了…

劣勢：

1. 擴(kuò)展性仍然遠(yuǎn)遠(yuǎn)不如web，也遠(yuǎn)遠(yuǎn)不如直接寫Native code（這個(gè)不用廢話解釋了吧）

2. 2. 從Native到Web，要做很多概念轉(zhuǎn)換，勢必造成雙方都要妥協(xié)。比如web要用一套CSS的閹割版，Native通過css-layout拿到最終樣式再轉(zhuǎn)換成native原生的表達(dá)方式（比如iOS的Constraint\origin\Center等屬性），再比如動(dòng)畫。另外，若Android和iOS都要做相同的封裝，概念轉(zhuǎn)換就更復(fù)雜了。

更新1：添加了React對React Native的影響。

更新2：基本確定其使用了 css-layout，添加了對React Native的總結(jié)

更新3: React native已經(jīng)開源了： React Native，只有iOS版。我寫了幾個(gè)demo，簡單看了看objc代碼并和開源前的我們的一些結(jié)論（見后文）交叉驗(yàn)證。簡單地從前端工程師和系統(tǒng)整體角度說一下React native的特點(diǎn)和優(yōu)劣吧。

更新4: 補(bǔ)充了幾條優(yōu)勢和與前端開發(fā)的對照