React native出來也快一周了，我寫了幾個demo，簡單看了看objc代碼并和開源前的我們的一些結(jié)論（見后文）交叉驗證。簡單地從前端工程師和系統(tǒng)整體角度說一下React native的特點(diǎn)和優(yōu)劣吧。

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

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

• JSX vs HTML
• CSS-layout vs css
• ECMAScript 6 vs ECMAScript 5
• React native View vs DOM

1. 無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個界面就全變了。
2. 多數(shù)布局代碼都是JSX，所有Native組件都是標(biāo)簽化的XML，這對于前端程序員來說，降低了不少學(xué)習(xí)成本，也大大減少了代碼量，不信你可以看看JSX編譯后的代碼。
3. 復(fù)用React系統(tǒng)，也減少了一定學(xué)習(xí)和開發(fā)成本，更重要的是利用了React里面的分層和diff機(jī)制。js層傳給Native層的是一個diff后的json，然后由Native將這個數(shù)據(jù)映射成真正的布局視圖。
4. css-layout也是點(diǎn)睛之筆，前端可以繼續(xù)用熟悉的類css方式來編寫布局，通過這個工具轉(zhuǎn)換成constrain布局。
5. 系統(tǒng)只有js-objc的單向調(diào)用，就是把原生UI組件的方法通過javascritcore或者webview（低版本iOS）映射到j(luò)s中來，整個調(diào)用過程是異步的，這樣的設(shè)計令React native可以讓js運(yùn)行在桌面chrome中，通過websocket連接Native code和桌面chrome，極大地方便了調(diào)試。對其中的機(jī)制Bang的一篇文章寫得很詳細(xì)，我就不拾人牙慧了：http://blog./tech/2698/ 。但這樣設(shè)計也會帶來一些問題，后面說。
6. 點(diǎn)按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什么和web「手感」不同的原因：實(shí)時的點(diǎn)按反饋和取消能力。http://facebook./react-native/docs/gesture-responder-system.html#content 這套相應(yīng)機(jī)制設(shè)計得很完善，能像Native code那樣控制整個點(diǎn)按操作的所有過程。
7. Debug相當(dāng)方便！修改了js以后，通過內(nèi)建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個chrome窗口，所有的js都移到了chrome里面運(yùn)行，所以什么斷點(diǎn)單步打調(diào)用棧，都不在話下。

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

1. 系統(tǒng)仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個例子，ScrollView這個組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現(xiàn)有的版本都沒有暴露，基本上做不了組件聯(lián)動效果。另外，這個版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩余的都是一些抽象程度極強(qiáng)的基本組件。這樣，用戶必須在不同的平臺下寫兩套代碼，而且所有能力仍然強(qiáng)烈依賴 React native 開發(fā)人員暴露的接口。
2. 由于最外層是React，初次學(xué)習(xí)成本高，不像往常的Hybird方案，只要多學(xué)幾個JS API就可以開始干活了。當(dāng)然，React的確讓后續(xù)開發(fā)變得簡單了一些，這么一套外來的（基于iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那么面目可憎了。

另外，React Native仍然很不完善。文檔還不全，我基本上是看著他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年后才發(fā)布： http://facebook./react/blog/#when-is-react-native-android-coming ，屆時整個系統(tǒng)設(shè)計可能還會有很大的變化。

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

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

HOW?

以上。

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

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

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

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

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

1. React Native里面沒有webview，這貨**不是Hybrid app**。
2. 再說React Native的核心，iOS Native code提供了十來個最核心的類（RCTDeviceEventEmitter、RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，組成二十來個基本組件（Popover、Listview等），交由上層的業(yè)務(wù)方來使用（THGroupView）。
3. 就如他們在宣傳時所說，他們實(shí)現(xiàn)了一套類似css的子集，用來解決樣式問題，相當(dāng)復(fù)雜和強(qiáng)大，靠這個才能將Native的核心組件組成JS層的基本組件再組成業(yè)務(wù)端的業(yè)務(wù)組件，個人猜測是采用CSSLayout的C語言版本實(shí)現(xiàn)的。
4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴(kuò)展性、靈活性和性能」的問題。

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

ReactJS對React Native有著直接的影響（我沒真正在生產(chǎn)環(huán)境中用過React，只用過Angular，下面的觀點(diǎn)可能有偏差）

ReactJS是這么設(shè)計的： 1. ReactJS 通過createElement返回的不是某個實(shí)體DOM對象，而只是一個數(shù)組
2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個數(shù)組轉(zhuǎn)換成DOM

另外，F(xiàn)acebook自己有JSX，CSSLayout等開源項目（自己去github上找介紹吧）

有了React再考慮React Native，很自然就想到了一套最有效率的搞法：
1. 將 ui/browser 里面的代碼替換成一套 Native 的橋接JS（實(shí)際上，iOS版是通過
injectGenericComponentClass方法，將核心組件的方法注入到JS里面 ），不就用上React的MVVM，自動將數(shù)據(jù)映射到Native了么
2. Native code里面實(shí)現(xiàn)三組核心API，一組提供核心組件的API（create、update、delete），一組事件方法（ReactJS里面的EventEmitter ），一組對Style進(jìn)行解析（貌似是用的CSSLayout的C語言版本）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）

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

React Native的優(yōu)勢和劣勢：（非最終結(jié)論，可能會更新）：

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

1. 不用Webview，徹底擺脫了Webview讓人不爽的交互和性能問題
2. 有較強(qiáng)的擴(kuò)展性，這是因為Native端提供的是基本控件，JS可以自由組合使用
3. 可以直接使用Native原生的「牛逼」動畫（在FB Group這個app里面，面板滑出帶一點(diǎn)果凍彈動，面板基于某個點(diǎn)展開這種動畫隨處可見，這種動畫用Native code來做小菜一碟，但是用Web來做就難上加難）。

相對于Native app：

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

劣勢：

1. 擴(kuò)展性仍然遠(yuǎn)遠(yuǎn)不如web，也遠(yuǎn)遠(yuǎn)不如直接寫Native code（這個不用廢話解釋了吧）
2. 從Native到Web，要做很多概念轉(zhuǎn)換，勢必造成雙方都要妥協(xié)。最終web要用一套CSS的閹割版，Native要費(fèi)勁地把這個閹割版轉(zhuǎn)換成native原生的表達(dá)方式（比如iOS的Constraint\origin\Center等屬性），兩邊都會不爽。