前言

React Native 是 Facebook 2015年開源的 Javascript 框架雏掠，旨在使用 Javascript 高效開發(fā)手機端 App斩祭。配合著多個顯而易見的優(yōu)勢和 Facebook 強大的宣傳機器，它立刻成為國內(nèi)外大小公司的明星開發(fā)框架乡话。開源社區(qū)的參與激情摧玫、各方博客的宣傳追捧，從其 Github 上 56000+ 星和 13000+ Fork 就可見一斑绑青。

對于 React Native诬像，iOS 開發(fā)者社區(qū)也是褒貶不一。有人認為 React Native 更快更好闸婴，蘋果原生那套要完颅停，不趕快學(xué)習(xí)就晚了；也有人認為 React Native 不過是 Facebook 的又一個玩具掠拳，以它現(xiàn)在的稚嫩還難以對原生的 Swift/Objective-C 造成足夠威脅。

在這里我還是要推薦下我自己建的iOS開發(fā)學(xué)習(xí)群：680565220纸肉，群里都是學(xué)ios開發(fā)的溺欧，如果你正在學(xué)習(xí)ios 喊熟，小編歡迎你加入，今天分享的這個案例已經(jīng)上傳到群文件姐刁，大家都是軟件開發(fā)黨芥牌，不定期分享干貨（只有iOS軟件開發(fā)相關(guān)的），包括我自己整理的一份2018最新的iOS進階資料和高級開發(fā)教程

筆者希望就這幾年親身開發(fā) React Native 和原生 iOS 的經(jīng)驗聂使，以及在硅谷的所見所聞壁拉，對這個問題提出一點自己的看法。對于一門新技術(shù)柏靶，我個人認為弃理，評判其是否值得采用有以下兩個標(biāo)準(zhǔn)：

該技術(shù)本身是否具備足夠的優(yōu)點

該技術(shù)是否符合目前的開發(fā)需求

下面就將從技術(shù)和開發(fā)需求兩個角度出發(fā)，談一談 React Native屎蜓。

React Native 的技術(shù)特點

React Native 的優(yōu)點很明顯痘昌。官網(wǎng)的醒目位置有簡單介紹，開發(fā)者們也在各種場合做了相關(guān)說明炬转，總結(jié)如下：

跨平臺開發(fā)辆苔。同一段 Javascript 代碼可以被用于 iOS 和 Android 兩個平臺。相比于以前 iOS 和 Android App 各維護一套邏輯大同小異的代碼扼劈，React Native 的開發(fā)驻啤、測試和維護成本要低很多。

快速編譯荐吵。比起 Xcode 中漫長的編譯骑冗，React Native 采用了熱加載（Hot Reload）的即時編譯機制，使得 App UI 的開發(fā)體驗大幅改善捍靠，幾乎到了和網(wǎng)頁開發(fā)一樣隨改隨變的效果沐旨。

快速發(fā)布。通過 JSBundle榨婆，React Native 可以即時更新 App磁携。相比原來冗長的審核和上傳過程，發(fā)布和測試新功能的效率大幅提高良风。

渲染和布局更加高效谊迄。React Native 可以直接套用網(wǎng)頁開發(fā)的 CSS 和 flex 機制，擺脫了 autolayout 和 frame 布局中繁瑣的數(shù)學(xué)計算烟央，更加直接簡便统诺。

簡單易學(xué)。相比于 iOS 和 Android 的一整套復(fù)雜的知識體系疑俭，React Native 從本質(zhì)上來講就是狀態(tài)機粮呢，對于開發(fā)者來講理解不難，且實際操作可謂入門容易、上手輕松啄寡。如果是前端開發(fā)者豪硅，那么對于 Javascript 本來就有相應(yīng)了解，用 React Native 開發(fā)手機應(yīng)用更是水到渠成挺物。

React Native 的跨平臺特性是最大賣點

當(dāng)然懒浮，看上去很完美的 React Native 在技術(shù)上也有諸多風(fēng)險，比如：

第三方依賴识藤。React Native 嚴(yán)重依賴于 Facebook 的維護砚著。蘋果在 iOS 上每次技術(shù)的更新、政策的改變都會讓原來使用了 React Native 代碼庫受到影響痴昧，等待 Facebook 和社區(qū)的修復(fù)會妨礙 App 的更新和用戶體驗稽穆。前段時間，百度和開發(fā)者們棄用

React Native 而迫使的 Facebook 修改開發(fā)者權(quán)限（License）事件剪个，證明了開發(fā)依賴于第三方的風(fēng)險確實存在秧骑。

邏輯上的額外開銷。直到今天扣囊， React Native 依然只是0.49版本乎折，僅僅支持簡單的 UI 制作，其不成熟的 API 連復(fù)雜的動畫都難以實現(xiàn)侵歇，更別提 iOS 的底層優(yōu)化和兼容操作骂澄。同時因為操作系統(tǒng)和設(shè)備的不同，React Native 得分別進行針對性處理惕虑，這對代碼庫的維護又是一個挑戰(zhàn)坟冲。

聯(lián)調(diào)的困難。對于原生的 iOS 和 Android App 引入 React Native溃蔫，會增加整個代碼庫的復(fù)雜度健提，在深入底層原生代碼進行 debug 時也是困難重重，可以說是在開發(fā)和維護上的成本都有所增加伟叛。

另外私痹，有很多人覺得 React Native 的性能不如原生的 Objective-C/Swift 好。筆者自己嘗試過统刮，覺得差別不大紊遵。與硅谷很多開發(fā)者的交流中得知，React Native 的性能與原生相比只有毫秒只差侥蒙，根本不會對用戶體驗造成影響暗膜。對此感興趣的朋友可以閱讀此文Comparing the Performance between Native iOS (Swift) and React-Native，文中在 CPU鞭衩、GPU学搜、內(nèi)存3個維度上進行了多個 API 的比較娃善，React Native 與原生的 Swift 相比真是不遑多讓。

React Native 在 UI 上的表現(xiàn)確實驚艷

App 所面對的開發(fā)需求

作為 iOS 開發(fā)者恒水，脫離了應(yīng)用談技術(shù)会放，好比鏡中花、水中月——空談而已钉凌。實際 App 開發(fā)中，有以下幾種情況捂人。我們來一一分析適不適合引入 React Native御雕。

第一種情況，從零開始開發(fā)一款簡單的 App滥搭。它很有可能是獨立開發(fā)者的小試牛刀酸纲，或是初創(chuàng)公司的第一代產(chǎn)品。我個人認為這種情況下是非常適合用 React Native 的瑟匆。此時闽坡，App 的UI 和業(yè)務(wù)邏輯都比較簡單，React Native 可以滿足絕大多數(shù)情況愁溜。而且疾嗅，開發(fā)者時間有限，沒時間系統(tǒng)學(xué)習(xí)兩大平臺的知識體系冕象；初創(chuàng)公司的成本有限代承，需要在 iOS 和 Android 兩個平臺上發(fā)布產(chǎn)品，以便用最短時間渐扮、最小成本迅速積累第一波用戶论悴，拿到投資。React Native 的技術(shù)特點非常符合這些要求墓律。

符合這種的產(chǎn)品就如 Facebook 的 F8 App膀估，這是一款專為其年度開發(fā)者大會打造的 App。因為它只有日歷耻讽、地圖察纯、推送等簡單功能，React Native 再適合不過——1個工程師花了2周就完成了全部的開發(fā)齐饮，現(xiàn)已開源在 Github 上捐寥。

第二種情況，從零開始開發(fā)一款比較復(fù)雜的 App祖驱。這有可能是一個公司新的產(chǎn)品線握恳，也有可能是一個成熟 App 的重構(gòu)。在這種情況下捺僻，質(zhì)量乡洼、口碑崇裁、以及日后的維護就是首要考慮因素，原生的 Swift/Objective-C 在面對實際問題時解決方案更加成熟多樣束昵，React Native 發(fā)揮不了其技術(shù)優(yōu)勢拔稳，故而原生開發(fā)是更為穩(wěn)妥的選擇。

舉個例子锹雏，Uber 在去年推出了他們新的 App巴比。內(nèi)部也嘗試了 React Native，但因為無法滿足 App 對于復(fù)雜動畫的需求礁遵、與底層系統(tǒng)的兼容不夠轻绞、性能上的優(yōu)化不足等多個原因，最終決定放棄使用佣耐。

Facebook F8 App政勃，React Native 經(jīng)典案例

第三種情況，在原有的 App 中引入新的功能兼砖。這種情況比較復(fù)雜奸远，它又分為以下幾種情況：

原來的 App 代碼庫是 100% 的 Objective-C/Swift。這種情況下我個人不推薦引入 React Native讽挟。因為技術(shù)團隊已經(jīng)穩(wěn)定在 iOS 和 Android 兩個技術(shù)棧上了懒叛，引入第三個技術(shù)棧，技術(shù)上增加復(fù)雜度和維護成本戏挡，人員上要組建一個新的 React Native 團隊芍瑞，開支和組織架構(gòu)上都有負面影響。除非有足夠的預(yù)算褐墅，或是后期有大幅采用 React Native 的計劃拆檬，否則不推薦引入 React Native。

驗證新功能該不該引入妥凳。驗證過程中公司有時間成本竟贯，高層希望的是短期內(nèi)就能做出決策。React Native 正是這種情況的銀色子彈逝钥。據(jù)我所知 Tesla 的 App 就采用了這種機制屑那。

新功能確定引入，不是核心功能艘款，并不復(fù)雜持际。這種情況下當(dāng)然可以嘗試 React Native。如果是網(wǎng)頁端類型的 App 或是功能哗咆，比如淘寶蜘欲、攜程、京東之類晌柬，他們本身就有大量的網(wǎng)頁端開發(fā)經(jīng)驗姥份，不如直接讓負責(zé)的前端工程師來處理相關(guān)的移動端業(yè)務(wù)郭脂。即使不成功也不會影響主要業(yè)務(wù)，同時可以為公司的技術(shù)積累提供寶貴經(jīng)驗澈歉。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了類似的循序漸進得采用 React Native 的策略展鸡。

新功能確定引入，是重要功能埃难，有嚴(yán)格的發(fā)布要求和日期莹弊。這個同上文說的第二種情況相同，保險和穩(wěn)妥起見不推薦采用 React Native涡尘。

總結(jié)

單純從技術(shù)角度來講箱硕，React Native 絕對是移動端不可多得的優(yōu)秀框架。它狀態(tài)機的思路可以被借鑒用來寫原生的 View Controller悟衩，其 UI 布局上的機制也對我們平日在性能上的優(yōu)化提供了靈感。

目前硅谷對于 React Native 也普遍持保守態(tài)度栓拜，采用 React Native

的科技巨頭也只有 Facebook座泳，Amazon，Uber幕与，Airbnb 四家挑势，而且都是局部小功能、小App采用啦鸣。好消息是潮饱，F(xiàn)acebook 對于 React Native 的投入不遺余力，圈內(nèi)開發(fā)者也是對此頗為積極诫给。更多細節(jié)可以閱讀官方的開發(fā)日程表：React Native Scheduling

筆者認為香拉，只有在快速開發(fā)、節(jié)約成本的考慮之下中狂，React Native 才能發(fā)揮出巨大的優(yōu)勢凫碌。對于 iOS 開發(fā)者，React Native 只可作為適當(dāng)補充胃榕，我們還是應(yīng)該多多鉆研 Swift / Objective-C 以及 App 開發(fā)的思路盛险，它們才是進階成長的關(guān)鍵所在。