React Native學(xué)習(xí)<一> 認(rèn)識(shí)Recat Native

博客原文:http://www.reibang.com/p/b88944250b25

前言

React Native 誕生于 2015 年腥沽，名副其實(shí)的富二代尘盼，主要使命是為父出征收奔，與 Apple 和 Google 抗衡势决，為開(kāi)發(fā)者帶去一套跨平臺(tái)、動(dòng)態(tài)更新的 Javascript 框架，口號(hào)是：Learn once, write anywhere：Build mobile apps with React。在試圖推翻 Android 和 iOS 壓制的同時(shí)碑幅，還提攜了一把自家兄弟：React。

從誕生之日 React Native 就充滿(mǎn)了期待和爭(zhēng)議塞绿。期待是無(wú)數(shù)開(kāi)發(fā)者希望不用忍受頻繁發(fā)版的噩夢(mèng)沟涨，也不用同時(shí)為兩個(gè)平臺(tái)開(kāi)發(fā)業(yè)務(wù)邏輯幾無(wú)差別的兩個(gè) App；爭(zhēng)議是 React Native 真的能以一己之力救大眾于水火嗎异吻？React Native 在跨平臺(tái)時(shí)還能保持良好的用戶(hù)體驗(yàn)嗎裹赴？

當(dāng)然我們知道，這種問(wèn)題向來(lái)都是仁者見(jiàn)仁，智者見(jiàn)智棋返。比起一味的疑惑延都、爭(zhēng)論，還不如來(lái)好好看看這貨究竟是個(gè)啥懊昨？甚至自己動(dòng)手來(lái)玩一把窄潭。

本文主要針對(duì)兩類(lèi)讀者：

• 想要入門(mén) RN 的人，在閱讀官方文檔前先對(duì) RN 形成一個(gè)整體的印象

• 對(duì) RN 心存好奇酵颁，在猶豫是否要入坑的開(kāi)發(fā)者，可以通過(guò)本文對(duì) RN 更客觀(guān)全面的認(rèn)識(shí)

目錄

• React Native 好在哪

1.跨平臺(tái)＋動(dòng)態(tài)更新
2.代碼復(fù)用
3.RN vs Weex
4.RN vs Hybrid
5.RN 劣勢(shì)

• React Native 運(yùn)行機(jī)制

• RN 開(kāi)發(fā)環(huán)境搭建

• 引入 React Native

1.Build from Scratch
2.集成到已有項(xiàng)目

• Javascript月帝、React 及 ES6躏惋、JSX 語(yǔ)法

• UI 層

• 網(wǎng)絡(luò)請(qǐng)求層

• Debugging 調(diào)試

1.In-App 報(bào)錯(cuò)
2.Console.log
3.大殺器：Chrome 逐行調(diào)試

• 從 JS 調(diào)用 Native 方法或顯示自定義 Native View

1.Native Modules：JS 里直接調(diào)用 Native(Java/Swift) 方法
2.Native UI Component：JS 里直接調(diào)用自定義的 Native View

• React Native 適合你嗎？

• 為什么要寫(xiě)這篇文章

一嚷辅、React Native 好在哪

下面我們來(lái)看下 Hybrid 及 React Native 等開(kāi)發(fā)模式包含了哪些常規(guī)移動(dòng)開(kāi)發(fā)所不具備的優(yōu)勢(shì)簿姨。

1. 跨平臺(tái)＋動(dòng)態(tài)更新

傳統(tǒng)的客戶(hù)端開(kāi)發(fā)模式是怎樣的呢？

Android 與 iOS Team 分別編寫(xiě)客戶(hù)端代碼簸搞，打包扁位，分發(fā)到 Play Store 和 Apple Store，通過(guò)更新 JSON 數(shù)據(jù)來(lái)更新頁(yè)面趁俊。

不過(guò)域仇，當(dāng)客戶(hù)端發(fā)生嚴(yán)重問(wèn)題而服務(wù)器上無(wú)法 quick fix 時(shí)，就不得不重新發(fā)版寺擂。

對(duì)國(guó)外 Android 市場(chǎng)而言還好暇务，因?yàn)槟芡ㄟ^(guò) Play Store 快速更新；國(guó)內(nèi) Android 市場(chǎng)則由于分發(fā)渠道太雜怔软，很難及時(shí)把新版本立即推送給所有用戶(hù)垦细，當(dāng)然這也是為何熱修復(fù)技術(shù)在國(guó)內(nèi)盛行而國(guó)外冷清的原因；而 Apple Store 則需要一定的審核時(shí)間挡逼，而且最近又在抓 iOS 熱修復(fù)框架如 JsPatch括改、Rollout 等。

相比而言家坎，Hybrid 和 RN/Weex 模式除了能下發(fā) Json 數(shù)據(jù)來(lái)刷新界面內(nèi)容嘱能，更能直接下發(fā)業(yè)務(wù)邏輯代碼，直接實(shí)現(xiàn)整體 App 的更新乘盖。而且焰檩，它們不用在乎 Android 和 iOS 兩個(gè)平臺(tái)，因?yàn)橐环?JS 代碼寫(xiě)好后订框，把 JS Bundle 放在服務(wù)器上析苫，所有的客戶(hù)端立即更新。

2. 代碼復(fù)用

一般而言，同一款產(chǎn)品的 Android 和 iOS 兩端除 UI 有些許不同外衩侥，多數(shù)業(yè)務(wù)邏輯幾乎完全一致国旷，這便造成了人力的浪費(fèi)。

而最近 Instagram 的官博 React Native at Instagram 一文中已經(jīng)提到茫死，利用 RN (React Native 縮寫(xiě)跪但，下同) 開(kāi)發(fā)的 feature 可以實(shí)現(xiàn) 85% - 99% 的代碼復(fù)用率。這意味著我們可以用更少的人力成本來(lái)達(dá)到相同的效果峦萎。

3. RN vs Weex

實(shí)現(xiàn)上面的效果有兩種開(kāi)發(fā)框架：混合開(kāi)發(fā)框架 Cordova 和基于 Javascript 的 React-Native屡久、Weex 框架。

下面我從自己的實(shí)踐經(jīng)驗(yàn)出發(fā)做些比較爱榔，也歡迎讀者提出自己看法被环。

最開(kāi)始覺(jué)得 RN 的學(xué)習(xí)成本比較大，所以首先考慮了 Weex 框架详幽，據(jù)說(shuō)是阿里巴巴良心出品筛欢。不過(guò)在嘗試后不得不選擇了放棄，原因有這幾點(diǎn)：

• Bug 較多唇聘。我們最先測(cè)試了最基本的 ListView版姑，在 iOS 運(yùn)行良好，而同樣的 Demo 代碼到了 Android 這邊的下拉刷新就出現(xiàn)了問(wèn)題迟郎，這使得我們開(kāi)始警惕剥险；

• 社區(qū)、文檔弱谎亩，GitHub Issue 基本是中文炒嘲。當(dāng)然我毫無(wú)歧視中文之意。我認(rèn)為匈庭，一套項(xiàng)目開(kāi)源是真正意義是希望借助開(kāi)源社區(qū)的力量夫凸，一起來(lái)完善改進(jìn)，因此要優(yōu)先推崇英文阱持，使項(xiàng)目國(guó)際化夭拌，得到全世界開(kāi)發(fā)者的共同支持，這樣才是可持續(xù)的模式衷咽。而 Weex 的 Issue 里放眼望去基本 90% 都是中文鸽扁，無(wú)論提問(wèn)者還是項(xiàng)目維護(hù)者。這一點(diǎn)直接把國(guó)外優(yōu)秀的開(kāi)發(fā)者拒之門(mén)外镶骗，也很難讓我看到多么長(zhǎng)遠(yuǎn)的未來(lái)桶现。
  下面是摘取的 RN 里的一則中文 issue：

• Contributor 差別。因?yàn)樯厦嬉稽c(diǎn)鼎姊，Weex 的 Contributor 只有 91 個(gè)人骡和，而 React-Native 的 Contributor 有 1214 人相赁。Contributor 是用來(lái)干嘛的？除了支持新功能慰于，還有就是修復(fù) bug 啊钮科。Weex/RN 都是希望一統(tǒng) Android + iOS 的，這么偉大的目標(biāo)婆赠，這么艱巨的工程绵脯，不是幾個(gè)人可以輕輕松松搞定的。

• 公司背景（來(lái)自YY）休里。大家都知道 RN 來(lái)自 Facebook蛆挫，Weex 來(lái)自阿里巴巴。如果想一窺它們的未來(lái)妙黍，需要先想一下這種技術(shù)對(duì)他們各自的意義璃吧。大家都清楚，F(xiàn)acebook废境、Google、Apple 是當(dāng)今當(dāng)之無(wú)愧的巨頭筒繁，在移動(dòng)互聯(lián)網(wǎng)這波浪潮里噩凹，Google 掌握了 Android 法器，Apple 控制了 iOS 神器毡咏，F(xiàn)acebook 呢驮宴？并沒(méi)有這些系統(tǒng)級(jí)入口。當(dāng)然 Windows 的經(jīng)歷也讓 Facebook 并不那么傾向去開(kāi)發(fā)一個(gè)新的移動(dòng)操作系統(tǒng)來(lái)競(jìng)爭(zhēng)呕缭。那怎么辦堵泽？React Native 應(yīng)運(yùn)而生，打出的口號(hào)就是： Learn once, write anywhere恢总。什么意思迎罗，沒(méi)錯(cuò)，就是明確告訴你學(xué)一次就可以同時(shí)開(kāi)發(fā)兩個(gè)平臺(tái)了片仿。這一點(diǎn)可一直都是移動(dòng)端開(kāi)發(fā)人員和創(chuàng)業(yè)公司的理想纹安。有人說(shuō)了，Apple 這么強(qiáng)勢(shì)砂豌，RN 要是太囂張厢岂，分分鐘把你禁掉。這時(shí)我們就要來(lái)看看 RN 的 Showcase 了阳距，哪些 App 應(yīng)用了 RN 呢塔粒？Facebook, Instagram, Airbnb, Walmart, QQ, 京東等，這回 Apple 要禁 RN 就要稍微掂量下這些大廠(chǎng)的意見(jiàn)吧筐摘。

當(dāng)然卒茬，我是很希望國(guó)內(nèi)也能推出優(yōu)質(zhì)的開(kāi)源項(xiàng)目來(lái)和國(guó)外大廠(chǎng)抗衡的船老，不過(guò)真正優(yōu)質(zhì)的大型開(kāi)源項(xiàng)目往往除了開(kāi)發(fā)者的個(gè)人能力，和公司的戰(zhàn)略和制度關(guān)系也很大扬虚。

4. RN vs Hybrid

這里的 Hybrid 開(kāi)發(fā)主要針對(duì) Cordova 框架努隙，其實(shí)在放棄 Weex 之后我們還是沒(méi)考慮 RN，而是轉(zhuǎn)過(guò)去了解 Cordova辜昵，不過(guò)做了大致了解后也放棄了荸镊。主要硬傷有兩點(diǎn)：

• 性能短板。大家知道 Hybrid 是基于 WebView 的堪置，在 Android 上的性能缺陷非常明顯躬存；而 RN 是利用 JSCore 轉(zhuǎn)化成 Native 運(yùn)行的，性能相對(duì)而言好不少舀锨；

• 用戶(hù)體驗(yàn)岭洲。了解移動(dòng)產(chǎn)品的人都知道用戶(hù)體驗(yàn)的重要性，RN 的體驗(yàn)和原生的幾乎沒(méi)有差別坎匿，而 Webview 的實(shí)現(xiàn)是網(wǎng)頁(yè)開(kāi)發(fā)思路盾剩，體驗(yàn)會(huì)相差很大。

性能和用戶(hù)體驗(yàn)是移動(dòng) App 的命根子替蔬。

因此告私，綜合考慮下來(lái)，我們還是決定相信 Facebook 并采用 RN承桥。

5. RN 劣勢(shì)

上面我提到了 RN 的一些優(yōu)勢(shì)驻粟，不過(guò)作為開(kāi)發(fā)者更加需要明確其劣勢(shì)，我總結(jié)了下大概有以下幾點(diǎn)劣勢(shì)：

• 學(xué)習(xí)成本凶异。Weex 的寫(xiě)法就是類(lèi)似常規(guī)的 Html/JS蜀撑，對(duì)于前端人員來(lái)說(shuō)很容易上手，就算了非前端人員來(lái)說(shuō)也花不了多久剩彬。而 RN 是在 React.js 上進(jìn)行改進(jìn)形成的一套語(yǔ)法酷麦，和常規(guī)前端差別較大，因此需要好幾天的學(xué)習(xí)適應(yīng)襟衰。當(dāng)然我覺(jué)得優(yōu)秀的程序員的基本素質(zhì)之一就是能快速學(xué)習(xí)贴铜、練習(xí)并熟練一種新語(yǔ)言的。我個(gè)人的話(huà)大概花了兩三天的時(shí)間已經(jīng)能完成一套涵蓋網(wǎng)絡(luò)瀑晒、JS與Native通信的頁(yè)面了绍坝，對(duì)于 React.js 語(yǔ)法也上手很快。

• 安裝包 Size苔悦。對(duì)于 iOS 而言影響不算很大轩褐，對(duì)于 Android 來(lái)說(shuō)，我嘗試后發(fā)現(xiàn)引入 RN 會(huì)給 apk 帶來(lái) 6MB 左右的增幅玖详，不過(guò)利用 split apk
  的技術(shù)就能縮小到到 1MB 左右的增幅把介。

• 首次加載耗時(shí)勤讽。大家知道 RN 需要從服務(wù)器下載 JS bundle，然后在本地轉(zhuǎn)化成 Native code 運(yùn)行的拗踢，所以在第一次打開(kāi) App 時(shí)需要花費(fèi)一些時(shí)間進(jìn)行下載和刷新脚牍。當(dāng)然我們可以在發(fā)布 client 時(shí)內(nèi)置一個(gè)寫(xiě)好的 js 文件在本地作緩存用。

二巢墅、React Native 運(yùn)行機(jī)制

對(duì)于一個(gè)用 RN 搭建的移動(dòng) App诸狭，在啟動(dòng)后會(huì)從服務(wù)器下載最新的 JS Bundle 文件，然后由本地 JavascriptCore 引擎對(duì) JS 文件進(jìn)行解析君纫，并利用 Bridge 映射到對(duì)應(yīng)的 Native 方法和 UI 控件驯遇。得到的效果是：

1.同樣的 RN 代碼，下發(fā)到 Android 和 iOS 不同平臺(tái)中蓄髓，會(huì)自動(dòng)調(diào)用對(duì)應(yīng) Native 的 UI 控件叉庐，保證了各平臺(tái)用戶(hù)體驗(yàn)的連貫性；

2.開(kāi)發(fā)者就算是移動(dòng)端小白会喝，只要有 Web 基礎(chǔ)陡叠，通過(guò)編寫(xiě)一套 RN 端代碼就可以同時(shí)完成 Android 與 iOS App 的開(kāi)發(fā)；

3.由于可以利用 JS bundle 同時(shí)下發(fā)數(shù)據(jù)和業(yè)務(wù)邏輯肢执，這意味著你可以像 Web 開(kāi)發(fā)一樣匾竿，實(shí)時(shí)迭代更新你的移動(dòng)端 App，無(wú)需在了解各自平臺(tái)的熱修復(fù)技術(shù)蔚万；

4.Native Modules，這是 RN 強(qiáng)大的一個(gè)擴(kuò)展性临庇，允許你通過(guò)簡(jiǎn)單的代碼就能實(shí)現(xiàn)在 JS 里直接調(diào)用你自己的 Native 方法反璃；

5.Native Components，如果你自己實(shí)現(xiàn)了一些復(fù)雜的 Native UI 組件假夺，而這些組件尚未被 RN 支持淮蜈，你可以利用 Native Components 快速把原生組件引入到 RN 中并可以直接在 JS 里更新這些組件的狀態(tài)。

三已卷、RN 開(kāi)發(fā)環(huán)境搭建

首先 IDE 方面梧田，RN 推薦了一些工具：

• Nuclide 是 Facebook 內(nèi)部用來(lái)開(kāi)發(fā) RN 的工具，Debug 功能強(qiáng)大侧蘸。只不過(guò)這是一款Atom 的插件裁眯，意味著你必須先安裝 Atom，再來(lái)安裝這款開(kāi)發(fā)插件讳癌；

• Deco 是專(zhuān)為開(kāi)發(fā) RN 誕生的工具穿稳，可以快速搜索開(kāi)源的第三方 RN 組件并直接插入到代碼中，用 MacOS 的同學(xué)可以嘗試下晌坤。我本人最開(kāi)始也是試用這個(gè)逢艘，上手簡(jiǎn)單旦袋、小巧簡(jiǎn)潔。不足的是功能有點(diǎn)簡(jiǎn)單它改，無(wú)論是 Debug 功能還是代碼檢查之類(lèi)的都不具備心软；

• Sublime 可以通過(guò)第三方包來(lái)達(dá)到不錯(cuò)的開(kāi)發(fā)效率，各方面還算可圈可點(diǎn)习寸；

• Visual Studio 這款也是蠻強(qiáng)大的 IDE垮卓，之前有用過(guò)的小伙伴可以試一下。

本人的話(huà)目前采用的是 Sublime爬泥，因?yàn)閭€(gè)人常用 Sublime柬讨，而且第三方插件很豐富，輕量方便袍啡。下面簡(jiǎn)單說(shuō)下配置踩官，感興趣的小伙伴可以看下。

1.Babel 用來(lái)高亮 React JSX 語(yǔ)法境输，支持 ES6蔗牡，而 React-Native 就是搭建在 React.js 基礎(chǔ)上的；

2.React-Native-Snippets 可以快速生成 RN 的一些模版代碼嗅剖；

3.ESLint 超級(jí)強(qiáng)大的 Lint 工具辩越，支持 ES6、JSX 語(yǔ)法檢查信粮，而且還有 React 和 RN 的插件黔攒，比純粹的 JSXHint/JSLint 都強(qiáng)大；

當(dāng)然强缘，用 Atom 的小伙伴自然要首先考慮 Nuclide督惰。

四、引入 React Native

引入 RN 有兩種方法：從零構(gòu)建旅掂；集成到已有項(xiàng)目赏胚。

1. Build from Scratch

先說(shuō)第一種，從零開(kāi)始構(gòu)建商虐，比較簡(jiǎn)單觉阅，遵循官方文檔 Getting Started 基于你自己的操作系統(tǒng)和平臺(tái)一步步安裝相關(guān)的依賴(lài)，然后利用如下命令：

react-native init AwesomeProject

你就創(chuàng)建好一個(gè) RN 工程項(xiàng)目了秘车，結(jié)構(gòu)如下：

RN 目錄結(jié)構(gòu)

里面有四個(gè)文件夾：

• android / ios：各自存放了一個(gè)相關(guān)平臺(tái)的工程 project典勇，可以直接下拉 JS Bundle 并運(yùn)行，對(duì)于移動(dòng)端小白而言可以不用管里面的具體實(shí)現(xiàn)叮趴；

• node_modules：里面是自動(dòng)生成的 node 依賴(lài)之類(lèi)的文件痴柔，通過(guò)讀取 package.json 里的配置來(lái)生成；

• js：這個(gè)文件夾最為重要疫向，我們的開(kāi)發(fā)都在這個(gè)文件夾里咳蔚，把寫(xiě)好的 js 文件打包下發(fā)給 client 就會(huì)自動(dòng)生效

2. 集成到已有項(xiàng)目

有很多公司是希望在現(xiàn)有 App 的基礎(chǔ)上集成 RN 來(lái)開(kāi)發(fā)一些特定的 Feature豪嚎，這種情況就不能參考上面的方法了。在 RN 的官方文檔里有一節(jié) Integration with Existing Apps , 只需要按照一步步做即可谈火。

以 Android 為例侈询，大概要做以下幾步：

1.添加 gradle 依賴(lài)：compile "com.facebook.react:react-native:+" // From node_modules.；

2.創(chuàng)建空的 Activity 糯耍，指定 JS bundle 和入口 Component 名字即會(huì)自動(dòng)在這個(gè) Activity 里去加載 JS bundle 文件扔字；

3.在 Activity 里監(jiān)聽(tīng) onBackPressed 事件，用來(lái)與 JS 端協(xié)作處理返回鍵點(diǎn)擊事件温技。

4.啟動(dòng) server革为，運(yùn)行 App 即可。

總之需要說(shuō)明的是舵鳞，即使是移動(dòng)端小白震檩，也可以遵循文檔里的指示完成這一步。接下來(lái)的大部分時(shí)間只要關(guān)心 JS 端開(kāi)發(fā)就行了蜓堕。

五抛虏、Javascript、React 及 ES6套才、JSX 語(yǔ)法

我們知道 RN 采用了 React 和 ES6 的語(yǔ)法迂猴，所以我們必須先對(duì)這些語(yǔ)法有一定了解才能去讀 RN 的代碼。

關(guān)于 Javascript背伴，我推薦 W3School 里的 JS語(yǔ)法 和 MDN 里的 JS手冊(cè)沸毁，大家只要對(duì)一些基礎(chǔ)語(yǔ)法做些了解就可以。

關(guān)于 React傻寂，我推薦 阮一峰 寫(xiě)的 React 入門(mén)實(shí)例教程以清，基本上把文章讀一遍，再自己動(dòng)手寫(xiě)一遍崎逃，就能理會(huì)到 React 的大致用法了。

關(guān)于 ES6眉孩、ES7个绍、JSX等，感興趣的可以看一下 RN 文檔中 Javascript Environment 里提到的支持的方法浪汪，需要時(shí)再來(lái)查詢(xún)也可以巴柿。也可以看 Babel 出的 Learn ES2015 手冊(cè)。

這里有一個(gè)很不錯(cuò)的 GitHub 項(xiàng)目死遭，幫助你通過(guò)交互性的例子來(lái)快速上手語(yǔ)法知識(shí)：React Native Express广恢。

六、UI 層

簡(jiǎn)單熟悉了 React 語(yǔ)法后呀潭，基本能正常閱讀 RN 的示例代碼了钉迷。

正式開(kāi)發(fā) App 的第一步當(dāng)然就是寫(xiě) UI 界面了至非，由于 RN 已經(jīng)封裝好了一套 JS 的 UI 組件，這些組件會(huì)自動(dòng)在 Android/iOS 端調(diào)用對(duì)應(yīng)的原生 UI 組件糠聪，因此我們只需要熟悉這些 UI 組件的用法及屬性荒椭、回調(diào)方法即可。

我們可以在文檔的 Components 看到不少組件舰蟆，比如View, Text, Button, Image, Switch, 還有我們用的最多的 ScrollView 和 ListView趣惠。

在讀文檔時(shí)，我們可以先通過(guò)一邊寫(xiě)代碼一邊讀文檔的方式進(jìn)行身害，RN 非常貼心味悄，直接在 Web 里嵌入了模擬器，我們只要修改編輯框里的代碼塌鸯，立即就能在右邊的模擬器看到效果侍瑟。這極大的降低了我們的學(xué)習(xí)成本。

Text Component

另外界赔，在學(xué)習(xí)一個(gè)組件時(shí)丢习，我們要區(qū)分哪個(gè)屬性是某個(gè)平臺(tái)特有的。比如下面兩個(gè) Text 的屬性：textBreakStrategy 只會(huì)在 Android 上生效淮悼，而 adjustsFontSizeToFit 只可以用在 iOS 上咐低。

Platform Specific Properties

然后，如果你希望在 Android 和 iOS 里顯示不同的內(nèi)容怎么辦呢袜腥？RN 里有一節(jié)是Platform Specific Code见擦，可以有如下幾種形式來(lái)進(jìn)行區(qū)分：

if (Platform.OS === 'ios') {
  // stuff for ios
} else {
  // stuff for android
}

除此之外，UI 組件的用法學(xué)習(xí)就很類(lèi)似常規(guī)的 Html 標(biāo)簽了羹令，只要知道其使用方式即可鲤屡，甚至需要用的時(shí)候再來(lái)查文檔也行。

七福侈、網(wǎng)絡(luò)請(qǐng)求層

學(xué)完上面的我們已經(jīng)能夠?qū)懗?UI 界面了酒来，而且這套界面已經(jīng)能夠在不同平臺(tái)上轉(zhuǎn)化成各自平臺(tái)的 Native UI 了。然后肪凛，我們就需要去網(wǎng)絡(luò)層請(qǐng)求真實(shí)數(shù)據(jù)了堰汉。

RN 里提供了 Fetch API 來(lái)進(jìn)行實(shí)現(xiàn)。舉個(gè)例子伟墙，你想要通過(guò) GET 方法去請(qǐng)求數(shù)據(jù)并轉(zhuǎn)化成 JSON翘鸭，可以通過(guò)如下代碼實(shí)現(xiàn)：

fetch('https://facebook.github.io/react-native/movies.json')
      .then((response) => response.json())
      .then((responseJson) => {
        return responseJson.movies;
      })
      .catch((error) => {
        console.error(error);
      });

熟悉 Reactive 編程的伙伴應(yīng)該對(duì)這樣的語(yǔ)法不陌生，比如 Android 上的 RxJava戳葵； iOS 上的 RxSwift就乓；Web 上的 RxJS。上面 function 的功能就是：請(qǐng)求網(wǎng)址 https://facebook.github.io/react-native/movies.json，把返回的 Response 轉(zhuǎn)化成 JSON object生蚁，取出 JSON object 里的 movies 字段噩翠。同時(shí)，如果發(fā)生 error 會(huì)被 catch 住守伸。

當(dāng)然绎秒，上面是最基本的 GET 請(qǐng)求，F(xiàn)etch API 還支持自定義 Headers尼摹，更換 Method见芹，添加 Body 等。

fetch('https://mywebsite.com/endpoint/', {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    firstParam: 'yourValue',
    secondParam: 'yourOtherValue',
  })
})

上面構(gòu)建了一個(gè)基本的 POST 請(qǐng)求蠢涝，添加了自己的 Headers:Accept和Content-Type玄呛，添加了 Body。

因此看下來(lái)和二，RN 里的網(wǎng)絡(luò)請(qǐng)求不僅具備了 Reactive 編程的簡(jiǎn)潔徘铝，也能自定義常規(guī)的 Http 請(qǐng)求，寫(xiě)法簡(jiǎn)單惯吕。

除了 Fetch API 之外惕它，RN 還內(nèi)置了 XMLHttpRequest API(俗稱(chēng) AJAX)，而且支持TCP 全雙工通信方式 WebSocket废登。

八淹魄、Debugging 調(diào)試

調(diào)試是很多程序員非常關(guān)注的一個(gè)環(huán)節(jié)，因?yàn)?RN 是用 JS 寫(xiě)完后到 Native 解釋成 Native 方法來(lái)執(zhí)行的堡距，因此如果能快速調(diào)試 JS 代碼是非常重要的一環(huán)甲锡。

最開(kāi)始 RN 的調(diào)試功能比較弱，不過(guò)現(xiàn)在的 Debugging 功能在我看來(lái)還是很不錯(cuò)的羽戒。一般來(lái)講可以有以下幾個(gè)調(diào)試方式：

1. In-App 報(bào)錯(cuò)

RN 里默認(rèn)集成了 In-App 的錯(cuò)誤提示方式缤沦，即在 App 運(yùn)行過(guò)程中會(huì)彈出全屏的報(bào)錯(cuò)信息呈現(xiàn)給你，而你也可以通過(guò)閱讀具體的錯(cuò)誤信息快速找到錯(cuò)誤原因易稠。通過(guò)點(diǎn)擊這個(gè)錯(cuò)誤信息里的某一行缸废，會(huì)立即自動(dòng)打開(kāi)對(duì)應(yīng)的代碼。

In-App Error

2. Console.log

在開(kāi)發(fā) Client 時(shí)驶社，我們一般都會(huì)用 Log.log() 來(lái)打印一些運(yùn)行時(shí)變量的值企量，然后實(shí)時(shí)查看打印出來(lái)的 log 來(lái)調(diào)試，在 RN 也一樣衬吆，你只要在 JS 里寫(xiě)一句 console.log('this is log data')，就會(huì)自動(dòng)在 Client 的常規(guī) log 里能看到绳泉，比如 Android 的 adb logcat 里就會(huì)自動(dòng)打印出'this is log data'一行逊抡。

3. 大殺器：Chrome 逐行調(diào)試

這個(gè)殺器的最牛逼之處就是可以像 Client 一樣，逐行調(diào)試代碼！

我們來(lái)看下面一張圖冒嫡。從左往右拇勃。先是文件目錄，我們選中了 index.js 文件夾孝凌，然后第二個(gè) Tab方咆，是 index.js 的內(nèi)容。這里關(guān)鍵的是我可以直接選中某一行代碼設(shè)斷點(diǎn)蟀架。當(dāng) Client 運(yùn)行到這一行時(shí)瓣赂，就會(huì)在第三個(gè) Tab 里打印出運(yùn)行時(shí)環(huán)境及變量。我們可以看到 props 里就有我們傳進(jìn)去的變量值片拍。

Chrome Debug

有了以上幾種調(diào)試方式煌集，我們幾乎可以和常規(guī)的 Native 開(kāi)發(fā)一樣來(lái)調(diào)試 RN 代碼了，不得不說(shuō) RN Team 確實(shí)牛 x 鞍剖　苫纤！

九、從 JS 調(diào)用 Native 方法或顯示自定義 Native View

這又是另一個(gè)牛 x 之處啊纲缓。

很多人覺(jué)得 RN 限制太多卷拘，只能支持有限的 View 組件和有限的方法，難以發(fā)揮 Client 的最大性能祝高。簡(jiǎn)單點(diǎn)說(shuō)栗弟，在 Client 可以繪制復(fù)雜的 View，可以調(diào)用高性能 C++ 等底層代碼褂策，但 RN 卻做不到横腿。

于是，RN 里提出了 Native Modules 和 Native UI Component 兩種技術(shù)斤寂。

Native Modules：JS 里直接調(diào)用 Native(Java/Swift) 方法

所謂 Native Modules耿焊，就是自己在 Client 寫(xiě)好了某些方法，由于某些原因這些方法不太方便或者無(wú)法搬到 RN 里面遍搞，那么罗侯，我們可以在 Client 把這些方法暴露出來(lái)給 RN，然后在 JS 里可以像 import 普通的 module 一樣把這些 Native Modules 引入進(jìn)去溪猿，直接調(diào)用钩杰。

具體的實(shí)現(xiàn)方法可以參考文檔 iOS Native Modules 和 Android Native Modules。

Native UI Component：JS 里直接調(diào)用自定義的 Native View

很多時(shí)候我們?cè)趯?xiě) Client 時(shí)诊县，為了實(shí)現(xiàn) Designer 天馬行空的設(shè)計(jì)讲弄，常常需要自定義 View，即自己繪制某些系統(tǒng)并不提供的特定 UI依痊”艹可想而知，這些 View 肯定不會(huì)出現(xiàn)在 RN 的 UI Component 里。

那么瓶摆，我們就需要首先在 Native 層自己寫(xiě)好一個(gè)自定義 View凉逛，然后利用Native UI Component 技術(shù)把這個(gè) View 及其中某些 public 方法暴露給 RN，那么 RN 就能直接 import 進(jìn)來(lái)并顯示了群井。

具體的實(shí)現(xiàn)方法可以參考文檔 iOS Native UI Component 和 Android Native UI Component状飞。

如果讀過(guò)文檔不是很理解的小伙伴可以留言，我再 post 一些 demo 代碼上來(lái)

十书斜、React Native 適合你嗎诬辈？

這里借鑒下前段時(shí)間舊金山的 React Native 會(huì)議上的一些優(yōu)劣總結(jié)給讀者以參考。當(dāng)然不一定對(duì)菩佑，僅供參考自晰。

RN 的優(yōu)點(diǎn)：

• 跨平臺(tái)
• 原生的用戶(hù)體驗(yàn)
• 開(kāi)發(fā)者體驗(yàn)好
• 動(dòng)態(tài)更新代碼邏輯
• 社區(qū)強(qiáng)大
• 有個(gè)好爹

RN 的缺點(diǎn)：

• 不夠成熟
• 不夠穩(wěn)定
• 生態(tài)系統(tǒng)在搭建中
• 優(yōu)質(zhì)的 App 需要時(shí)間打磨
• 偶爾需要寫(xiě) Native 代碼(也就是 JS + Swift + Java)

適合下面這些人/公司：

• 你對(duì) JS/React 有一定了解
• Web 開(kāi)發(fā)人員比 Mobile 開(kāi)發(fā)人員多
• 有意愿投資精力給 RN
• App 設(shè)計(jì)不是特別區(qū)分 Android 和 iOS
• 希望熱更新

下面這些人要稍微考慮下：

• 完全不了解 JS/React
• 已經(jīng)有現(xiàn)成的 Android/iOS team
• App 設(shè)計(jì)嚴(yán)格遵守 Android、iOS各自設(shè)計(jì)規(guī)范
• 不想要投入時(shí)間／金錢(qián)給 RN

十一稍坯、為什么要寫(xiě)這篇文章

幾個(gè)月前我對(duì) React Native 也非常不看好酬荞，當(dāng)然現(xiàn)在也沒(méi)有說(shuō)非常看好瞧哟』烨桑或者說(shuō)，寫(xiě)這篇文章毫無(wú)為 React Native 布道之意勤揩。

接觸 React Native 主要是因?yàn)闃I(yè)務(wù)需要咧党，PM 希望能夠隨時(shí)改動(dòng)某塊變化較大的模塊，常規(guī)的開(kāi)發(fā)提交流程往往需要較長(zhǎng)的時(shí)間陨亡，而熱修復(fù)技術(shù)本身并未得到 Google 和 Apple 的官方認(rèn)可傍衡，也就是隨時(shí)可能因破壞生態(tài)安全之名被取締。

因此才考慮去了解 Hybrid 開(kāi)發(fā)和 JS Native 開(kāi)發(fā)模式负蠕，在了解過(guò)程中蛙埂，又由于性能差、用戶(hù)體驗(yàn)不好而放棄 Hybrid遮糖，由于社區(qū)不完善绣的、Bug 較多等原因放棄 Weex，最終才選擇了 React Native欲账，開(kāi)始學(xué)習(xí) React屡江、JSX等語(yǔ)法。

目前使用下來(lái)對(duì) React Native 的一些個(gè)人感受：

1. 學(xué)習(xí)門(mén)檻并沒(méi)有開(kāi)始想象那么高赛不。大概只花了兩三天時(shí)間就熟悉了 Javascript惩嘉、React 框架、JSX語(yǔ)法踢故，然后就開(kāi)始著手業(yè)務(wù)開(kāi)發(fā)文黎。

2. 對(duì) Android App 的影響奏路。React Native 會(huì)給 Android 端帶來(lái) 6MB 左右的 size 增幅，不過(guò)在采用了 split apk 后就只有 1MB 左右增幅臊诊。

3. Debug 功能比較完善，至少不用擔(dān)心發(fā)生問(wèn)題后不知從哪下手斜脂。

4. 性能還行抓艳。最初擔(dān)心的是 React Native 性能不好，但自己上手后帚戳，并沒(méi)有明顯感覺(jué)到很明顯的 React Native 對(duì) App 性能的負(fù)面影響玷或，無(wú)論是 iOS 還是 Android，當(dāng)然片任，這一點(diǎn)還在繼續(xù)考察中偏友。

5. 動(dòng)態(tài)部署真的很不錯(cuò)。以前每次寫(xiě)好代碼都要花不少時(shí)間來(lái)編譯運(yùn)行对供，而現(xiàn)在只要寫(xiě)一份代碼位他，就可以同時(shí)在 Android 和 iOS 實(shí)時(shí)更新了，這無(wú)疑節(jié)省了生命产场。

6. 有待完善鹅髓。當(dāng)然，React Native 中確實(shí)還存在著不少問(wèn)題京景，生態(tài)系統(tǒng)也還不夠完善窿冯。不過(guò)我相信，這只是時(shí)間問(wèn)題确徙。

不過(guò)我想說(shuō)的是醒串，React Native 所代表的跨平臺(tái)、動(dòng)態(tài)更新技術(shù)已經(jīng)引起了全世界開(kāi)發(fā)者關(guān)注鄙皇，而且這種技術(shù)勢(shì)必會(huì)是未來(lái)的需求和潮流芜赌。React Native 不一定會(huì)成功，但至少目前 React Native 已經(jīng)是這一領(lǐng)域的領(lǐng)跑者育苟。

而寫(xiě)這篇文章的目的较鼓，就是希望告訴更多開(kāi)發(fā)者，React Native 并不完美违柏，但值得一試博烂。

謝謝。