前言
React Native 是 Facebook 2015年開源的 JAVAscript 框架，旨在使用 JavaScript 高效開發(fā)手機(jī)端 App。配合著多個(gè)顯而易見(jiàn)的優(yōu)勢(shì)和 Facebook 強(qiáng)大的宣傳機(jī)器，它立刻成為國(guó)內(nèi)外大小公司的明星開發(fā)框架。開源社區(qū)的參與激情、各方博客的宣傳追捧，從其 Github 上 56000+ 星和 13000+ Fork 就可見(jiàn)一斑。
對(duì)于 React Native，IOS 開發(fā)者社區(qū)也是褒貶不一。有人認(rèn)為 React Native 更快更好，蘋果原生那套要完，不趕快學(xué)習(xí)就晚了；也有人認(rèn)為 React Native 不過(guò)是 Facebook 的又一個(gè)玩具，以它現(xiàn)在的稚嫩還難以對(duì)原生的 Swift/Objective-C 造成足夠威脅。
筆者希望就這幾年親身開發(fā) React Native 和原生 iOS 的經(jīng)驗(yàn)，以及在硅谷的所見(jiàn)所聞，對(duì)這個(gè)問(wèn)題提出一點(diǎn)自己的看法。對(duì)于一門新技術(shù)，我個(gè)人認(rèn)為，評(píng)判其是否值得采用有以下兩個(gè)標(biāo)準(zhǔn)：
- 該技術(shù)本身是否具備足夠的優(yōu)點(diǎn)
- 該技術(shù)是否符合目前的開發(fā)需求
下面就將從技術(shù)和開發(fā)需求兩個(gè)角度出發(fā)，談一談 React Native。
React Native 的技術(shù)特點(diǎn)
React Native 的優(yōu)點(diǎn)很明顯。官網(wǎng)的醒目位置有簡(jiǎn)單介紹，開發(fā)者們也在各種場(chǎng)合做了相關(guān)說(shuō)明，總結(jié)如下：
- 跨平臺(tái)開發(fā)。同一段 Javascript 代碼可以被用于 iOS 和 Android 兩個(gè)平臺(tái)。相比于以前 iOS 和 Android App 各維護(hù)一套邏輯大同小異的代碼，React Native 的開發(fā)、測(cè)試和維護(hù)成本要低很多。
- 快速編譯。比起 Xcode 中漫長(zhǎng)的編譯，React Native 采用了熱加載（Hot Reload）的即時(shí)編譯機(jī)制，使得 App UI 的開發(fā)體驗(yàn)大幅改善，幾乎到了和網(wǎng)頁(yè)開發(fā)一樣隨改隨變的效果。
- 快速發(fā)布。通過(guò) JSBundle，React Native 可以即時(shí)更新 App。相比原來(lái)冗長(zhǎng)的審核和上傳過(guò)程，發(fā)布和測(cè)試新功能的效率大幅提高。
- 渲染和布局更加高效。React Native 可以直接套用網(wǎng)頁(yè)開發(fā)的 css 和 flex 機(jī)制，擺脫了 autolayout 和 frame 布局中繁瑣的數(shù)學(xué)計(jì)算，更加直接簡(jiǎn)便。
- 簡(jiǎn)單易學(xué)。相比于 iOS 和 Android 的一整套復(fù)雜的知識(shí)體系，React Native 從本質(zhì)上來(lái)講就是狀態(tài)機(jī)，對(duì)于開發(fā)者來(lái)講理解不難，且實(shí)際操作可謂入門容易、上手輕松。如果是前端開發(fā)者，那么對(duì)于 Javascript 本來(lái)就有相應(yīng)了解，用 React Native 開發(fā)手機(jī)應(yīng)用更是水到渠成。
當(dāng)然，看上去很完美的 React Native 在技術(shù)上也有諸多風(fēng)險(xiǎn)，比如：
- 第三方依賴。React Native 嚴(yán)重依賴于 Facebook 的維護(hù)。蘋果在 iOS 上每次技術(shù)的更新、政策的改變都會(huì)讓原來(lái)使用了 React Native 代碼庫(kù)受到影響，等待 Facebook 和社區(qū)的修復(fù)會(huì)妨礙 App 的更新和用戶體驗(yàn)。前段時(shí)間，百度和開發(fā)者們棄用React Native 而迫使的 Facebook 修改開發(fā)者權(quán)限（License）事件，證明了開發(fā)依賴于第三方的風(fēng)險(xiǎn)確實(shí)存在。
- 邏輯上的額外開銷。直到今天， React Native 依然只是0.49版本，僅僅支持簡(jiǎn)單的 UI 制作，其不成熟的 API 連復(fù)雜的動(dòng)畫都難以實(shí)現(xiàn)，更別提 iOS 的底層優(yōu)化和兼容操作。同時(shí)因?yàn)椴僮飨到y(tǒng)和設(shè)備的不同，React Native 得分別進(jìn)行針對(duì)性處理，這對(duì)代碼庫(kù)的維護(hù)又是一個(gè)挑戰(zhàn)。
- 聯(lián)調(diào)的困難。對(duì)于原生的 iOS 和 Android App 引入 React Native，會(huì)增加整個(gè)代碼庫(kù)的復(fù)雜度，在深入底層原生代碼進(jìn)行 debug 時(shí)也是困難重重，可以說(shuō)是在開發(fā)和維護(hù)上的成本都有所增加。
另外，有很多人覺(jué)得 React Native 的性能不如原生的 Objective-C/Swift 好。筆者自己嘗試過(guò)，覺(jué)得差別不大。與硅谷很多開發(fā)者的交流中得知，React Native 的性能與原生相比只有毫秒只差，根本不會(huì)對(duì)用戶體驗(yàn)造成影響。對(duì)此感興趣的朋友可以閱讀此文Comparing the Performance between Native iOS (Swift) and React-Native，文中在 CPU、GPU、內(nèi)存3個(gè)維度上進(jìn)行了多個(gè) API 的比較，React Native 與原生的 Swift 相比真是不遑多讓。
App 所面對(duì)的開發(fā)需求
作為 iOS 開發(fā)者，脫離了應(yīng)用談技術(shù)，好比鏡中花、水中月——空談而已。實(shí)際 App 開發(fā)中，有以下幾種情況。我們來(lái)一一分析適不適合引入 React Native。
第一種情況，從零開始開發(fā)一款簡(jiǎn)單的 App。它很有可能是獨(dú)立開發(fā)者的小試牛刀，或是初創(chuàng)公司的第一代產(chǎn)品。我個(gè)人認(rèn)為這種情況下是非常適合用 React Native 的。此時(shí)，App 的UI 和業(yè)務(wù)邏輯都比較簡(jiǎn)單，React Native 可以滿足絕大多數(shù)情況。而且，開發(fā)者時(shí)間有限，沒(méi)時(shí)間系統(tǒng)學(xué)習(xí)兩大平臺(tái)的知識(shí)體系；初創(chuàng)公司的成本有限，需要在 iOS 和 Android 兩個(gè)平臺(tái)上發(fā)布產(chǎn)品，以便用最短時(shí)間、最小成本迅速積累第一波用戶，拿到投資。React Native 的技術(shù)特點(diǎn)非常符合這些要求。
符合這種的產(chǎn)品就如 Facebook 的 F8 App，這是一款專為其年度開發(fā)者大會(huì)打造的 App。因?yàn)樗挥腥諝v、地圖、推送等簡(jiǎn)單功能，React Native 再適合不過(guò)——1個(gè)工程師花了2周就完成了全部的開發(fā)，現(xiàn)已開源在 Github 上。
第二種情況，從零開始開發(fā)一款比較復(fù)雜的 App。這有可能是一個(gè)公司新的產(chǎn)品線，也有可能是一個(gè)成熟 App 的重構(gòu)。在這種情況下，質(zhì)量、口碑、以及日后的維護(hù)就是首要考慮因素，原生的 Swift/Objective-C 在面對(duì)實(shí)際問(wèn)題時(shí)解決方案更加成熟多樣，React Native 發(fā)揮不了其技術(shù)優(yōu)勢(shì)，故而原生開發(fā)是更為穩(wěn)妥的選擇。
舉個(gè)例子，Uber 在去年推出了他們新的 App。內(nèi)部也嘗試了 React Native，但因?yàn)闊o(wú)法滿足 App 對(duì)于復(fù)雜動(dòng)畫的需求、與底層系統(tǒng)的兼容不夠、性能上的優(yōu)化不足等多個(gè)原因，最終決定放棄使用。
第三種情況，在原有的 App 中引入新的功能。這種情況比較復(fù)雜，它又分為以下幾種情況：
- 原來(lái)的 App 代碼庫(kù)是 100% 的 Objective-C/Swift。這種情況下我個(gè)人不推薦引入 React Native。因?yàn)榧夹g(shù)團(tuán)隊(duì)已經(jīng)穩(wěn)定在 iOS 和 Android 兩個(gè)技術(shù)棧上了，引入第三個(gè)技術(shù)棧，技術(shù)上增加復(fù)雜度和維護(hù)成本，人員上要組建一個(gè)新的 React Native 團(tuán)隊(duì)，開支和組織架構(gòu)上都有負(fù)面影響。除非有足夠的預(yù)算，或是后期有大幅采用 React Native 的計(jì)劃，否則不推薦引入 React Native。
- 驗(yàn)證新功能該不該引入。驗(yàn)證過(guò)程中公司有時(shí)間成本，高層希望的是短期內(nèi)就能做出決策。React Native 正是這種情況的銀色子彈。據(jù)我所知 Tesla 的 App 就采用了這種機(jī)制。
- 新功能確定引入，不是核心功能，并不復(fù)雜。這種情況下當(dāng)然可以嘗試 React Native。如果是網(wǎng)頁(yè)端類型的 App 或是功能，比如淘寶、攜程、京東之類，他們本身就有大量的網(wǎng)頁(yè)端開發(fā)經(jīng)驗(yàn)，不如直接讓負(fù)責(zé)的前端工程師來(lái)處理相關(guān)的移動(dòng)端業(yè)務(wù)。即使不成功也不會(huì)影響主要業(yè)務(wù)，同時(shí)可以為公司的技術(shù)積累提供寶貴經(jīng)驗(yàn)。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了類似的循序漸進(jìn)得采用 React Native 的策略。
- 新功能確定引入，是重要功能，有嚴(yán)格的發(fā)布要求和日期。這個(gè)同上文說(shuō)的第二種情況相同，保險(xiǎn)和穩(wěn)妥起見(jiàn)不推薦采用 React Native。
總結(jié)
單純從技術(shù)角度來(lái)講，React Native 絕對(duì)是移動(dòng)端不可多得的優(yōu)秀框架。它狀態(tài)機(jī)的思路可以被借鑒用來(lái)寫原生的 View Controller，其 UI 布局上的機(jī)制也對(duì)我們平日在性能上的優(yōu)化提供了靈感。
目前硅谷對(duì)于 React Native 也普遍持保守態(tài)度，采用 React Native 的科技巨頭也只有 Facebook，Amazon，Uber，Airbnb 四家，而且都是局部小功能、小App采用。好消息是，F(xiàn)acebook 對(duì)于 React Native 的投入不遺余力，圈內(nèi)開發(fā)者也是對(duì)此頗為積極。更多細(xì)節(jié)可以閱讀官方的開發(fā)日程表：React Native Scheduling
筆者認(rèn)為，只有在快速開發(fā)、節(jié)約成本的考慮之下，React Native 才能發(fā)揮出巨大的優(yōu)勢(shì)。對(duì)于 iOS 開發(fā)者，React Native 只可作為適當(dāng)補(bǔ)充，我們還是應(yīng)該多多鉆研 Swift / Objective-C 以及 App 開發(fā)的思路，它們才是進(jìn)階成長(zhǎng)的關(guān)鍵所在。
