摘要：React 起源于 Facebook 的內(nèi)部項目，因為該公司對市場上所有 JavaScript MVC 框架，都不滿意，就決定自己寫一套，用來架設(shè) Instagram 的網(wǎng)站。做出來以后，發(fā)現(xiàn)這套東西很好用，就在2013年5月開源了。這個項目本身也越滾越大，從最早的UI引擎變成了一整套前后端通吃的 Web App 解決方案。衍生的 React Native 項目，目標(biāo)

React 起源于 Facebook 的內(nèi)部項目，因為該公司對市場上所有 JavaScript MVC 框架，都不滿意，就決定自己寫一套，用來架設(shè) Instagram 的網(wǎng)站。做出來以后，發(fā)現(xiàn)這套東西很好用，就在2013年5月開源了。

這個項目本身也越滾越大，從最早的UI引擎變成了一整套前后端通吃的 Web App 解決方案。衍生的 React Native 項目，目標(biāo)更是宏偉，希望用寫 Web App 的方式去寫 Native App。

React Native 一經(jīng)推出，就獲得眾多開發(fā)者的關(guān)注。React Native 使得 JavaScript 能夠開發(fā)真正的 APP, 它不僅有著與原生應(yīng)用相媲美的體驗，同時擁有著 Web 應(yīng)用的優(yōu)勢和開發(fā)效率。React Native 鮮明的特點就是組件化，一個應(yīng)用都是多個組件構(gòu)成；同時為了更高的效率，React Native 采用了內(nèi)存 Dom tree Diff 計算，優(yōu)化了 view 的渲染效率和體驗。使用 JavaScript 開發(fā)跨終端的應(yīng)用是未來的趨勢。

那么，現(xiàn)在使用 React Native 開發(fā)能給開發(fā)者帶去哪些便利，又會遇到哪些坑呢，又該在什么場景選擇 React Native 呢？這篇文章整理了一些我們高手問答欄目中的相關(guān)問答內(nèi)容以解決大家的疑惑。歡迎各位一起討論、交流、學(xué)習(xí)。

一、React Native 相關(guān)特性——首先來了解一下 React Native 的一些特性

React-Native是在React的基礎(chǔ)上設(shè)計的（也許描述得不對），對于前端來說，純業(yè)務(wù)組建（不涉及UI，僅僅是邏輯）能否在iOS，Android，Web上共享？從官方的視頻看到，React Native提倡的是 Learn once, Write anywhere，這不是是預(yù)示著多個平臺還得每個寫一遍，不知道共享度能有多少？

你說的很對，React-Native是React基礎(chǔ)上設(shè)計的，這是當(dāng)時Facebook兩個團隊做的事情，ReactJS先出來的。如果是語法層面，不設(shè)計UI，是可以共享的。

React-Native請問是基于什么設(shè)計模式開發(fā)的？

設(shè)計模式硬套倒也想不出，基本3個層面：（1）語言層面：JS & JSX，這個對前端人員比較熟悉。（2）核心層面：使用Javascript內(nèi)核引擎 ＋ OC原生組件 （3）使用組件開發(fā)APP，就像搭積木一樣。

Dom tree Diff 是什么？ 具體是怎么運算的呢？ 尤其是提高效率上。

舉個栗子：以前我們需要給一個評論點贊，需要更新該評論下的贊，贊的用戶昵稱信息，我們暫且叫做視圖重渲染吧，比如使用jquery, $('#container').empty().....render()。那么react做了一件什么事呢？react構(gòu)建的是虛擬的dom，通過內(nèi)部屬性的改變通知虛擬dom進行內(nèi)存計算（與舊屬性的虛擬dom進行一次比較，即diff），將計算后的結(jié)果直接更新在界面上，不要我們手動管理視圖。內(nèi)存換效率。具體的可以看下這篇文章https://facebook.github.io/react/docs/glossary.html 

既然原生上面有一層虛擬DOM，那按道理應(yīng)該可以做到根據(jù)一套JS在不同的環(huán)境下渲染不同的原生代碼，實現(xiàn)1次編寫處處運行。而且Native是需要編譯的吧，那它應(yīng)該做不到H5那種的實時更新。還有一點，這層虛擬DOM能做到一套View同時渲染W(wǎng)eb和Native兩套界面嗎?

是這樣的，因為iOS和Android有各自不同風(fēng)格的控件，有的區(qū)別很大，所以React-Native提供了Platform可以判斷當(dāng)前系統(tǒng)是Android還是iOS，然后渲染什么樣的UI，這些可以寫在一套js代碼里，熱更新不需要編譯，React-Native有一個bundle命令，打包出來的bundle文件是可以直接被加載的，不需要編譯。 如果想一套View渲染W(wǎng)eb和App的話，UI部分的代碼是不一樣的，這個可以看React的文檔和React-Native的文檔，render渲染的JSX部分代碼不一樣。

既然Web的view和Native的view無法公用，那在Web上弄一層shadow-dom有什么意義?僅僅為了實現(xiàn)diff算法嗎?React確實我沒深入了解過，寫NG比較多,感覺寫React很繁瑣

虛擬DOM主要是解決Web的一個性能瓶頸問題，類似cordova之類的跨平臺解決方案性能瓶頸就在DOM上，虛擬DOM就是當(dāng)DOM有更改的時候在進行DOM渲染，可以有效地減少DOM渲染次數(shù)，解決這個性能問題。NG更適合單頁的web app或者說H5在native部分。

問下兩個問題 1).React Native當(dāng)初宣傳的時候說的是 一次學(xué)習(xí)，處處編寫。為什么React Native不是那種傳統(tǒng)的一次編寫，處處運行。 2)Native和Web端的React有聯(lián)系嗎？

React-native是從React發(fā)展而來的，最大的優(yōu)勢就是既有Web的熱更新優(yōu)勢，又有接近Native的性能，核心思想是虛擬DOM，所以針對不同的平臺編寫不同的JS，實際上底層調(diào)用的還是原生控件，所以是一次學(xué)習(xí)處處編寫而不是一次編寫處處運行。 Native和Web端的react是有聯(lián)系的。

React Native 組件的屬性和方法夠多夠靈活嗎？

目前React-Native的第三方庫還不是很豐富，需要oc的支持和暴露，當(dāng)然這只是目前。組件的方法不是很多，但是很好的處理了一個UI組件的渲染生命周期，足以控制組件；組件可以自定義和擴展，所以屬性是可以靈活使用。具體的可以關(guān)注3個比較重要的屬性：props、state、ref

二、入門相關(guān)——接下來，看一看 React Native 的相關(guān)學(xué)習(xí)資料

React Native學(xué)習(xí)成本如何，如何快速使用？

學(xué)習(xí)成本不算太高，我之前從來沒做過Web開發(fā)，沒接觸過JS，也能入個手寫一寫，參考這篇小博文，入手會比較快：http://richard-cao.github.io/

入門學(xué)習(xí)也可以參考： https://github.com/xujinyang/react-native-android-guidehttps://github.com/jondot/awesome-react-native https://github.com/ele828/react-native-guide 

相關(guān)入門資料推薦

干貨：https://github.com/xujinyang/react-native-android-guide

https://github.com/LeoMobileDeveloper/ReactNativeMaterials

Redux的資料： https://github.com/xgrommx/awesome-redux

這個需要什么基礎(chǔ)？還有就是以后的發(fā)展您是怎么看的？會代替原生還是和原生相輔相成？

（1）基礎(chǔ)：前端基礎(chǔ)，例如：JS、JSX、Flexbox以及熟悉iOS的組件即可。

（2）前景：現(xiàn)在最大的優(yōu)勢就是熱更新；對于需要及時更新的部分，可以采用React-Native

（3）目前：相輔相成；未來的話，我希望更多是大部分替代原生。

用React Native 開發(fā)APP需要掌握其他哪些技能，除了React Native部分

會一些JS是最好的，掌握一些ES6語法之類的。

三、適用場景相關(guān)——技術(shù)總是脫離不了使用場景的

RN目前在項目實踐中已知的坑有哪些？假如新開發(fā)一個項目，完全使用RN是否可行？另外想了解一下您在項目中使用的程度和場景，謝謝！　

不太建議完全使用RN，因為Facebook也在不斷填坑，每個月都有新版本，一個長期項目經(jīng)不起頻繁換依賴庫的版本；我們公司也只是作為業(yè)余研究性質(zhì)，不過RN的熱更新思路真心不錯，可以隨時更換功能模塊。需要注意的是，熱更新和在線更新是不一樣的，分別對應(yīng)的是 hot-reloading 和 reload，調(diào)試時是通過 hot 選項控制；鑒于 hot-reloading 需要和服務(wù)器實時保持一個socket長連接和既有的不確定性，我不相信會有公司會采用 hot-reloading 的方案，應(yīng)用于生產(chǎn)環(huán)境。如果真的應(yīng)用hot-reloading了，那就分享下心得唄。

目前使用React-Native有那些局限，React-Native更適合開發(fā)那些應(yīng)用？

React-Native還是有些坑需要踩的，現(xiàn)在Github上也能看到Recat-Native源碼庫都有不少開發(fā)者在提bug，更新的也很快。目前React-Native做一些內(nèi)部APP還是可以的；目前對動畫的支持不是很高，這個可以在一些APP中做一些優(yōu)雅降級；更適合開發(fā)那些動畫效果要求不是忒高、組件功能要求相對較少（如果團隊中有OC的開發(fā)者可以忽略）的APP。很多坑，我們團隊現(xiàn)在都在踩。

請問React-Native的目前推廣和應(yīng)用局限性有哪些？

React-Native技術(shù)的推廣可以從公司內(nèi)存APP試水；邊踩坑邊開發(fā)，React-Native的局限性除了平臺因素，就是對開發(fā)者要求較高。當(dāng)然開發(fā)效率來說，應(yīng)該是很快的。如果團隊中有Object-C成員，相對而言，上手就會輕松很多。

現(xiàn)在互聯(lián)網(wǎng)公司開發(fā)一個新的移動APP，是不是建議使用React-Native

不一定，React-Native是可以減少一些開發(fā)成本，但是目前React-Native Android還有很多不完善的地方，目前比較適合做偏UI方面相對簡單的一些需求和功能 。

四、React Native 與其他開發(fā)工具、方式對比

想知道，這個與 Phonegap 的比較，包括開發(fā)效率，學(xué)習(xí)曲線，用戶體驗，工具的完善程度等。

Phonegap 和 React-Native 還是不同。React-Native 內(nèi)部在 iOS7 版本以上采用的是JS Core Engine 解析的，在版本上是降級使用 WebView。React-Native 針對前端開發(fā)者上手難度應(yīng)該不是很大，主要熟悉Flexbox布局、JSX語法、React-Native API。

這個同跨平臺開源的.NET + C#開發(fā)通吃平臺的APP相比，差距在哪里呢？

你說的應(yīng)該是指Xamarin吧，這個我有嘗鮮過，收費的商業(yè)解決方案，我感覺是主要依賴官方提供的控件和庫，React-Native相對學(xué)習(xí)成本沒那么高，畢竟現(xiàn)在做C#的相對小眾，React-Native沒提供的原生控件你可以通過它提供的擴展來自行擴展，開源而且社區(qū)相當(dāng)活躍，我認為前景很廣闊，個人認為要比Xamarin好，性能方面沒對比過，因為我沒買Xamarin的方案。

能從學(xué)習(xí)周期、開發(fā)難度、運行速度方面分析下，AngularJS和React Native的差異嗎？

對我個人來說，我是一個Android開發(fā)者，之前沒接觸過Web和JS，Angular我也有看過，Angular學(xué)習(xí)成本我認為比React高，做APP方面的就是ionic，React是個純UI的東西，React-Native也是，然后提供了和原生APP的擴展模塊，開發(fā)周期我感覺對于我來說肯定是React比較快，運行速度方面React-Native是要勝于ionic的。

React-Native開發(fā)出來的APP和原生的APP的性能有區(qū)別嗎，React Native做出來的安卓APP是不是沒有原生的流暢?。?/p>

React-Native開發(fā)效率高于Native；React-Native效率和體驗高于Hybird；React-Native整體性能跟Native差距不大。Facebook給出的性能測試是接近原生的性能，如果不是很復(fù)雜的APP，看不出什么差別，但是如果相對復(fù)雜的動畫UI之類的，那肯定還是原生更勝一籌。不過如果只是開發(fā)一個功能性APP的話基本沒啥大差別了，畢竟現(xiàn)在的Android手機性能也很好。

用這個你覺得在與我們這幫原生Android App工程師的競爭中，你們最大的技術(shù)優(yōu)勢是什么，對比原生，你們的劣勢有在何處?

最大的技術(shù)優(yōu)勢：iOS和Android可以一定程度上的代碼公用，減少開發(fā)成本和開發(fā)周期，可以隨時線上熱更新。 和原生相比的劣勢：目前React-Native Android不適合做相對復(fù)雜的動畫效果和UI，體驗上會有一些問題，而且熱更新只是針對純React的模塊，和原生交互的會有原生代碼，熱更新就不好用了。目前我感覺最好的方式還是原生+React的混合開發(fā)，根據(jù)需求做技術(shù)選型。

我們目前在用國內(nèi)的APICloud來做移動端的開發(fā)！我感覺React-Native這個東西相應(yīng)該沒有APICloud方便吧！還有React-Native和Phonegap應(yīng)該差不多的吧？

React-Native和Phonegap差很多，React-Native性能接近Native的性能是因為React核心是虛擬DOM，通過diff算法來進行有效的DOM更新，從而突破Web的DOM性能瓶頸。Phonegap，也就是現(xiàn)在的開源方案cordova，它做出來是Hybrid，RN做出來是Native，性能是最大差別，不過如果你的是資訊類應(yīng)用，不計較性能，團隊又多Web開發(fā)人員也不妨考慮cordova。還有你說的APICloud，實際上是給原生APP套了個WebView殼，尤其在Android上會有性能問題。

我感覺最好的方式還是原生開發(fā)，雖然需要的精力多了些但最終是值的，你說呢？

這個就看產(chǎn)品和需求怎么定了，技術(shù)選型往往都是跟著產(chǎn)品和需求跑，畢竟技術(shù)是服務(wù)用戶的嘛，我覺得互惠互利吧。

另外Swift開源后，將來有可能第三方機構(gòu)開發(fā)出Siwft可以同時構(gòu)建iOS APP的平臺，所以我感覺還是學(xué)好Java和Swift比較好一些，混合開發(fā)也許以后會好一點，但目前很長一段時間和原生開發(fā)還是要差不少吧。

你要說的是Swift同時構(gòu)建Android APP吧？不排除這種可能，不過目前混合開發(fā)還是比較主流的，畢竟BAT和其他一線二線互聯(lián)網(wǎng)公司都在用，Web和原生結(jié)合可以解決很多產(chǎn)品需求上的問題。

相比其他移動開發(fā)，它的優(yōu)勢是什么？

RN的優(yōu)勢在于性能與靈活性的平衡，比Hybrid好的性能，熱更新有比Native好的靈活性?？焖僮龀鰳I(yè)務(wù)邏輯和UI 基本一致 、性能介于原生和混合的APP。

五、入坑之后，就要不斷的填坑——看看各位使用React Native 時遇到的問題

React-Native 和 React 的代碼可以復(fù)用嗎？

目前我們團隊也在做這件事，想要完全的復(fù)用還是很難的。需要做就是將一個方向打通，比如React轉(zhuǎn)Native。那么就會遇到如需要將div、img等封裝成React-Native的View、Image組件；同時css樣式的改變和css-layout的打通也是比較耗時的工作。后期，我會在大會上分享我們團隊正在做的這件事。

還有就是動畫這塊，因為原生的有很多框架，甚至可以用opengl，那React-Native有望做到嗎？你說的執(zhí)行的是打包完成的JS文件。那提交到Appstore以后，怎么來熱跟新？覆蓋掉以前的JS文件嗎？蘋果現(xiàn)在支持應(yīng)用可以這樣了嗎？ 

你把JS Bundle文件改成線上拉即可。因為React-native本身就存在OC的代碼，審核是可以通過的。React-Native提供了transform；當(dāng)然比如頁面的切換的動畫也是支持的；同時有些效果可以在Webview中使用Canvas。

請教一下，在開發(fā)模式下能否將轉(zhuǎn)換的JS直接打包到APK中而不用Reload，另外可以說說你對訪問外網(wǎng)JS的想法嗎？

直接將JS打包不用reload是可以的，但是開發(fā)模式下這么做會比較麻煩。訪問外網(wǎng)JS我感覺可能會有一些安全性方面問題，其他的還好

我在學(xué)習(xí)React-Native，現(xiàn)在要用post或者get請求和服務(wù)器進行交互，怎么做？有沒有一些demo？

查看官方文檔：https://facebook.github.io/react-native/docs/network.html#content，講的很清楚了，用法比較簡單

最近在學(xué)習(xí)React Native，開發(fā)過程中難免會涉及到與原生頁面進行調(diào)用和傳值。請問如何實現(xiàn)。是否有開源demo參考？

https://facebook.github.io/react-native/docs/native-modules-android.html#content 請參考這個，還是不難的，我做的這個小模塊就用到了

看了OC-JS的通訊原理，發(fā)現(xiàn)是他們之間的通訊是單向的，只能OC調(diào)用JS。那事件是如何轉(zhuǎn)化的呢？比如：在JS中使用window.setTimeout()設(shè)置定時觸發(fā)事件，那這個事件是轉(zhuǎn)化成OC的定時觸發(fā)事件，然后等待OC來執(zhí)行嗎？

React-Native中內(nèi)置了JS引擎；低版本系統(tǒng)降級的是采用Webview。

是啊。但是既然是調(diào)用原生控件，那這個控件就是在OC層繪制出來的，能綁定的事件是不是應(yīng)該也只有OC的事件？像一點點擊事件之類的，是在OC層觸發(fā)，還是在JS層觸發(fā)呢？ 在iOS7以上版本，先不考慮使用WebView的情況。

嗯嗯，iOS7以上可以嘗試React-Native

對于RN我一直很擔(dān)心就是國內(nèi)的一些第三方服務(wù)的支持情況？如果都需要iOS和Android對于它們官方的SDK進行封裝的話工作量就太大了？你們是否使用了相關(guān)的服務(wù)：比如支付、登錄等。

對于微信、QQ、支付寶等都已經(jīng)有開源封裝，隨著RN的推進，以后會有更多第三方服務(wù)的封裝，我們用過微信和支付寶的，推薦一下：https://github.com/reactnativecn/react-native-wx https://github.com/huangzuizui/rn-alipay

我在華為6P上構(gòu)建各種紅屏，開avd各種正常，這是什么原因？

紅屏是因為bundle問題吧，如果是debug狀態(tài)，你要監(jiān)聽電腦本地的node server8081端口，來reload js代碼；如果是release的話，要先用react-native bundle命令打出bundle，然后一起打包成apk 

Android機上使用React Native占用內(nèi)存情況如何？有出現(xiàn)內(nèi)存溢出的可能么？你用的是模擬器，還是真實Android系統(tǒng)？Android 5.0？

我在我的測試機上沒出現(xiàn)過內(nèi)存溢出哈，不過我做的功能也不難，其實內(nèi)存溢出這個事情原生代碼寫的不好也會出的吧。都是真機，有5.0的，也有4.x的，4.1以上

前段時間接觸過React-Native，當(dāng)時發(fā)現(xiàn)Android好多Widgets都沒有哎，是我使用的方式不對嗎？

還有React-Native目前只能加速APP build 的速度嗎？我看源碼只有dev的時候才會加載網(wǎng)絡(luò)端的bundle，這樣感覺意義不大啊，我嘗試修改其源碼使release版也可以加載在線bundle，不過后來沒時間就放棄了。

Android常用的控件基本都有了，其他的如果自己有需要也可以自己實現(xiàn)，這個在 React-Native 的官方文檔有提到 Native 模塊和 UI 模塊與 React 的結(jié)合部分。 React-Native在Release下也可以加載在線的bundle，可以參考博客：http://richard-cao.github.io/。react和加速app build的速度沒必然聯(lián)系。

最終發(fā)布的安裝文件不會有被反編譯或者被查看到JavaScript代碼的風(fēng)險吧？（畢竟是用Javascript開發(fā)的）。另外，你們踩坑之路，遇到難題后一般去哪里查文檔的？ 有沒有優(yōu)秀的RN文檔資源或者圖書推薦？ 

不用擔(dān)心，F(xiàn)acebook打包出來的js代碼是經(jīng)過混淆的，反混淆出來也難以看出業(yè)務(wù)邏輯。

一些學(xué)習(xí)資料：https://github.com/jondot/awesome-react-native https://github.com/ele828/react-native-guide

原生Android開發(fā)獲取本地APP圖標(biāo)都是Drawable類型的，如何把本地APP的圖標(biāo)顯示在RN的Image上？

http://reactnative.cn/docs/0.31/images.html#content 使用混合App的圖片資源，如果你在編寫一個混合App （通過Xcode的asset類目或者Android的drawable文件夾打包）

React-Native ListView上1000條數(shù)據(jù)如何？卡不卡？很多非原生前端（包括很多原生前端）并不曉得React-Native的性能如何，更可能是壓根不知曉其性能消耗情況。React-Native真的如其吹噓的具備原生的體驗嗎?

你說的是這個issue吧？https://github.com/facebook/react-native/issues/499 新的版本已經(jīng)修復(fù)了；附帶一個三方的解決方案 https://github.com/sghiassy/react-native-sglistview

這個也算fixed？react-native-sglistview也算是解決方案？看看他的issues https://github.com/sghiassy/react-native-sglistview/issues 還有多少坑。 

謝謝你的熱心說明，我對ListView的性能研究得不夠深入，總結(jié)來說RN還真不適合做大量數(shù)據(jù)列表

最近在調(diào)研RN，主要面臨兩個問題，1是可復(fù)用的ListView，2是好用的tabbar，還請推薦下，有沒現(xiàn)成的組件，如沒有，自己寫可不可行？不知iOS方面有沒有兼容的計劃？

ListView解決方案，https://my.oschina.net/droidwolf/blog/750479

iOS方面，http://blog.wix.engineering/2016/06/30/recycling-rows-for-high-performance-react-native-list-views/ 

請問RN在項目版本管理中，如何分配目錄方便團隊共同使用？包括新加入成員。

RN還是比較好做版本管理的，項目規(guī)模2到4個人，其中一個主程，按功能模塊分工，遇到?jīng)_突由主程協(xié)調(diào)其他開發(fā)協(xié)調(diào)解決，不過沖突基本很小，沒有二進制文件的沖突也比較好解決。

之前想學(xué)習(xí)RN Android開發(fā)，Windows下搭建開發(fā)環(huán)境各種坑，最終放棄。不知道現(xiàn)在RN Android針對Windows環(huán)境有沒有改進？

不好意思，我也沒試過Windows下的體驗，估計進展不大吧，因為Facebook是技術(shù)主導(dǎo)型公司，比較少用Windows吧

國內(nèi)搭建環(huán)境都極不順利，有什么好的方法嗎？

npm掛一個淘寶鏡像的代理，可能會快一些，不過最好還是有科學(xué)上網(wǎng)環(huán)境， 淘寶npm鏡像：https://npm.taobao.org/ 

六、也有不少開發(fā)者對增量更新這方面比較關(guān)心——有關(guān)增量更新的問題

React-Native實現(xiàn)的應(yīng)用能否實現(xiàn)增量更新？如果能，蘋果商店會限制此類應(yīng)用嗎？

可以實現(xiàn)增量更新；大家都知道天貓已經(jīng)上了一個活動頁，至少目前來看，Apple是不會限制的。相信大公司應(yīng)該有大公司的胸懷。

React Native 應(yīng)該是支持熱跟新吧，就是通過服務(wù)端來控制界面，這樣就不要老提交蘋果審核了，但是我不確定支持嗎？還有就是他和原生開發(fā)有什么區(qū)別？原生能做的它都可以嗎？

遠程的熱更新是ok的，因為執(zhí)行的是Jsbundle，Jsbundle是打包完成的js文件；原生做的它都可以么？－－至少可以通過各種途徑去實現(xiàn)，React-Native iOS版本目前也是公測中。