React-Native端跨平臺開發(fā)技術(shù)分析

一蜻牢、跨平臺開發(fā)技術(shù)介紹

入門路線
2015年Facebook 推出了React Native讓跨平臺開發(fā)技術(shù)火了一把，去年阿里開源了weex也朝著越來越熱的趨勢發(fā)展。為了節(jié)省開發(fā)成本，我們也得默默的跟上他們的步伐。
接下來我們會暢談各類跨平臺開發(fā)技術(shù)的優(yōu)劣背零，告訴大家為什么要選擇RN進(jìn)行開發(fā)。

市場上主流APP分類：

Native App（原生）
即傳統(tǒng)的原生APP開發(fā)模式,Android基于Java語言,底層調(diào)用Google的 API;iOS基于OC或者Swift語言,底層調(diào)用App官方提供的API无埃。體驗最好徙瓶。
- 優(yōu)點
  - 直接依托于操作系統(tǒng),交互性最強(qiáng),性能最好
  - 相比于其它模式的交互,原生APP體驗是最優(yōu)的
  - 功能最為強(qiáng)大,特別是在與系統(tǒng)交互中,幾乎所有功能都能實現(xiàn)
  - 得益于原生是直接依托于系統(tǒng)的,所以可以直接調(diào)用官方提供的api,功能最為全面(比如本地資源操作,通知,動畫等)
- 缺點
  - 開發(fā)成本高,無法跨平臺,不同平臺Android和iOS上都要各自獨立開發(fā)
  - Android上基于Java開發(fā),iOS上基于OC或Swift開發(fā),相互之間獨立,必須要有各自的開發(fā)人員
  - 門檻較高,原生人員有一定的入門門檻,相比廣大的前端人員而言,較少
  - 原生的一個很大特點就是獨立,所以不太容易入門,不像web前端一樣那么廣泛,而且Android,iOS都需要獨立學(xué)習(xí)
Web App
即移動端的網(wǎng)站,將頁面部署在服務(wù)器上,然后用戶使用各大瀏覽器訪問,不是獨立APP,無法安裝和發(fā)布
Web網(wǎng)站一般分兩種,MPA(Multi-page Application)和SPA(Single-page Application)。而Web App一般泛指后面的SPA形式開發(fā)出的網(wǎng)站(因為可以模仿一些APP的特性)
優(yōu)點
- 開發(fā)成本低,可以跨平臺,調(diào)試方便,web app一般只需要一個前端人員開發(fā)出一套代碼,然后即可應(yīng)用于各大主流瀏覽器(特殊情況可以代碼進(jìn)行下兼容),沒有新的學(xué)習(xí)成本,而且可以直接在瀏覽器中調(diào)試
- 維護(hù)成本低,如果代碼合理,只需要一名前端就可以維護(hù)多個web app
- 更新最為快速,由于web app資源是直接部署在服務(wù)器端的,所以只需要替換服務(wù)器端的文件,用戶訪問是就已經(jīng)更新了(當(dāng)然需要解決一些緩存問題)
- 無需安裝App,不會占用手機(jī)內(nèi)存,通過瀏覽器即可訪問,無需安裝,用戶就會比較愿意去用
缺點
- 性能低,用戶體驗差嫉称，由于是直接通過的瀏覽器訪問,所以無法使用原生的API,操作體驗不好
- 依賴于網(wǎng)絡(luò),頁面訪問速度慢,耗費流量侦镇，Web App每次訪問都需要去服務(wù)端加載資源訪問,所以必須依賴于網(wǎng)絡(luò),而且網(wǎng)速慢時訪問速度很不理想,特別是在移動端,如果網(wǎng)站優(yōu)化不好會無故消耗大量流量
- 功能受限,大量功能無法實現(xiàn)，只能使用Html5的一些特殊api,無法調(diào)用原生API,所以很多功能存在無法實現(xiàn)情況
- 臨時性入口,用戶留存率低织阅，這既是它的優(yōu)點,也是缺點,優(yōu)點是無需安裝,確定是用完后有時候很難再找到,或者說很難專門為某個web app留存一個入口,導(dǎo)致用戶很難再次使用
Hybrid App
即混合開發(fā),由Native通過JSBridge等方法提供統(tǒng)一的API,然后用Html5+JS來寫實際的邏輯,調(diào)用API,這種模式下,由于Android,iOS的API一般有一致性,而且最終的頁面也是在webview中顯示,所有有跨平臺效果
優(yōu)點
- 開發(fā)成本較低,可以跨平臺,調(diào)試方便壳繁。Hybrid模式下,由原生提供統(tǒng)一的API給JS調(diào)用,實際的主要邏輯有Html和JS來完成，而由于最終是放在webview中顯示的,所以只需要寫一套代碼即可,達(dá)到跨平臺效果,另外也可以直接在瀏覽器中調(diào)試,很為方便，最重要的是只需要一個前端人員稍微學(xué)習(xí)下JS api的調(diào)用即可,無需兩個獨立的原生人員闹炉，一般Hybrid中的跨平臺最少可以跨三個平臺:Android App,iOS App,普通webkit瀏覽器
- 學(xué)習(xí)成本較低蒿赢，這種開發(fā)模式下,只需要前端人員關(guān)注一些原生提供的API,具體的實現(xiàn)無需關(guān)心,沒有新的學(xué)習(xí)內(nèi)容,只需要前端人員即可開發(fā)。
- 功能更加完善,性能和體驗要比起web app好太多渣触，因為可以調(diào)用原生api,所以很多功能只要原生提供出就可以實現(xiàn),另外性能也比較接近原生了
- 部分性能要求的頁面可用原生實現(xiàn)羡棵，這應(yīng)該是Hybrid模式的最多一個好處了,因為這種模式是原生混合web,所以我們完全可以將交互強(qiáng),性能要求高的頁面用原生寫,然后一些其它頁面用JS寫,嵌入webview中,達(dá)到最佳體驗
缺點
- 相比原生,性能仍然有較大損耗，這種模式受限于webview的性能桎梏,相比原生而言有不少損耗,體驗無法和原生相比
- 不適用于交互性較強(qiáng)的app昵观，這種模式的主要應(yīng)用是:一些新聞閱讀類,信息展示類的app;但是不適用于一些交互較強(qiáng)或者性能要求較高的app(比如動畫較多就不適合)
React Native App
Facebook發(fā)起的開源的一套新的APP開發(fā)方案,使用JS+部分原生語法來實現(xiàn)功能晾腔。初次學(xué)習(xí)成本較高,但是在入門后,經(jīng)過良好的封裝也能夠?qū)崿F(xiàn)大部分的跨平臺舌稀。而且體驗很好啊犬。
- 優(yōu)點
  - 雖然說開發(fā)成本大于Hybrid模式,但是小于原生模式,大部分代碼可復(fù)用，相比于原生模式,這種模式是統(tǒng)一用JS寫代碼,所以往往只需要一名成員投入學(xué)習(xí),即可完成跨平臺app的開發(fā),而且后續(xù)代碼封裝的好,很多功能可復(fù)用
  - 性能體驗高于Hybrid,不遜色與原生壁查，這種模式和Hybrid不一樣,Hybrid中的view層實際上還是dom,但是這種模式的view層是虛擬dom,所以性能要高于Hybrid,距離原生差距不大
    這種模式可以認(rèn)為是用JS寫原生,即頁面用JS寫,然后原生通過Bridge技術(shù)分析JS,將JS內(nèi)容單獨渲染成原生Android和iOS,所以也就是為什么性能不遜色原生
  - 開發(fā)人員單一技術(shù)棧,一次學(xué)習(xí),跨平臺開發(fā)觉至，這種模式是統(tǒng)一由JS編寫,有著獨特的語法,所以只需要學(xué)習(xí)一次,即可同時開發(fā)Android和iOS
  - 社區(qū)繁榮,遇到問題容易解決，這應(yīng)該是React Native的很大一個優(yōu)勢,不像Hybrid模式和原生模式一樣各自為營,這種模式是Facebook統(tǒng)一發(fā)起的,所以有一個統(tǒng)一的社區(qū),里面有大量資源和活躍的人員,對開發(fā)者很友好
- 缺點
  - 雖然可以部分跨平臺,但并不是Hybrid中的一次編寫,兩次運行那種,而是不同平臺代碼有所區(qū)別
  - 這種模式實際上還是JS來寫原生,所以Android和iOS中的原生代碼會有所區(qū)別,如果需要跨平臺,對開發(fā)人員有一定要求
    當(dāng)然了,如果發(fā)展了有一定時間,組件庫夠豐富了,那么其實影響也就不大了,甚至?xí)菻ybrid更快
  - 開發(fā)人員學(xué)習(xí)有一定成本睡腿，雖然社區(qū)已經(jīng)比較成熟了,但是一個新的普通前端學(xué)習(xí)起來還是有一定學(xué)習(xí)成本的,無法像Hybrid模式一樣平滑
Weex app
Weex最底層的原理是和React-Native相同的语御，就是將JS代碼渲染成原生組件，只不過在業(yè)務(wù)代碼層面席怪，Weex和React-Native有差別
- 優(yōu)點
  - 一套代碼跨平臺应闯，只要遵循特定的語法規(guī)則，完全可以達(dá)到一套代碼多個平臺運行
  - 核心就是在web環(huán)境下挂捻，將源碼編譯成web中顯示的Html dom對象等碉纺，在原生環(huán)境下編譯成原生組件。而React-Native中刻撒，它是JS寫原生代碼骨田，不同平臺代碼是不一樣的，雖然有大部分可以復(fù)用声怔，但并不是完全一套代碼多個平臺态贤。
  - 語法接近H5，基本用法和H5一致醋火，特別是后來改成了支持VUE.JS后悠汽，使用起來更是很方便。
- 缺點
  - 社區(qū)相比React-Native不足芥驳，是一個比較大的缺點介粘，目前相比React-Native是新生，坑更多一點

跨平臺開發(fā)的四個流派：

Web 流：也被稱為 Hybrid 技術(shù)晚树，它基于 Web 相關(guān)技術(shù)來實現(xiàn)界面及功能
Web 流最常被吐槽的就是性能慢（這里指內(nèi)嵌 HTML 的性能姻采，不考慮網(wǎng)絡(luò)加載時間），以下是主要原因
- 早期瀏覽器實現(xiàn)比較差，沒有進(jìn)行優(yōu)化
- CSS 過于復(fù)雜慨亲，計算起來更耗時
- DOM 提供的接口太有限婚瓜，使得難以進(jìn)行優(yōu)化

除了性能問題， Web 流更嚴(yán)重的問題是功能缺失刑棵，比如 iOS 8 就新增 4000+ API巴刻，而 Web 標(biāo)準(zhǔn)需要漫長的編寫和評審過程，增加 4000 API 這輩子是等不到了蛉签。

代碼轉(zhuǎn)換流：將某個語言轉(zhuǎn)成 Objective-C胡陪、Java 或 C#，然后使用不同平臺下的官方工具來開發(fā)
- 為了保證APP體驗碍舍，寫原生代碼是必須的柠座，但不同平臺下的官方語言不一樣，這會導(dǎo)致同樣的邏輯要寫兩次以上片橡，于是就有人想到了通過代碼轉(zhuǎn)換的方式來減少工作量妈经，比如將 Java 轉(zhuǎn)成 Objective-C。
  這種方式雖然聽起來不是很靠譜捧书，但它卻是成本和風(fēng)險都最小的吹泡，因為代碼轉(zhuǎn)換后就可以用官方提供的各種工具了，和普通開發(fā)區(qū)別不大经瓷，因此不用擔(dān)心遇到各種詭異的問題爆哑，不過需要注意生成的代碼是否可讀，不可讀的方案就別考慮了舆吮。
- 雖然代碼轉(zhuǎn)換這種方式風(fēng)險小揭朝，但我覺得對于很多小 APP 來說共享不了多少代碼，因為這類應(yīng)用大多數(shù)圍繞 UI 來開發(fā)的歪泳，大部分代碼都和 UI 耦合萝勤，所以公共部分不多。
  在目前的所有具體方案中呐伞，只有 j2objc 可以嘗試敌卓，其它都不成熟。
編譯流：將某個語言編譯為二進(jìn)制文件伶氢，生成動態(tài)庫或打包成 apk/ipa/xap 文件
編譯流比前面的代碼轉(zhuǎn)換更進(jìn)一步趟径，它直接將某個語言編譯為普通平臺下的二進(jìn)制文件，這種做法有明顯的優(yōu)缺點：
- 優(yōu)點
  - 可以重用一些實現(xiàn)很復(fù)雜的代碼癣防，比如之前用 C++ 實現(xiàn)的游戲引擎蜗巧，重寫一遍成本太高
  - 編譯后的代碼反編譯困難
  - 或許性能會好些（具體要看實現(xiàn)）
- 缺點
  - 如果這個工具本身有 Bug 或性能問題，定位和修改成本會很高
  - 編譯后體積不小蕾盯，尤其是如果要支持 ARMv8 和 x86 的話
虛擬機(jī)流：通過將某個語言的虛擬機(jī)移植到不同平臺上來運行
除了編譯為不同平臺下的二進(jìn)制文件幕屹，還有另一種常見做法是通過虛擬機(jī)來支持跨平臺運行，比如 JavaScript 和 Lua 都是天生的內(nèi)嵌語言，所以在這個流派中很多方案都使用了這兩個語言望拖。
- 不過虛擬機(jī)流會遇到兩個問題：一個是性能損耗渺尘，另一個是虛擬機(jī)本身也會占不小的體積。
- React Native 的思路簡單來說就是在不同平臺下使用平臺自帶的 UI 組件说敏。同時 React Native 和 Web 扯不上太多關(guān)系鸥跟，我們熟知的 Web 是指 W3C 定義的那些規(guī)范，比如 HTML盔沫、CSS医咨、DOM，而 React Native 主要是借鑒了 CSS 中的 Flexbox 寫法架诞，還有 navigator拟淮、XMLHttpRequest 等幾個簡單的 API，更別說完全沒有 Web 的開放性侈贷，所以 React Native 和 HTML 5 完全不是一回事惩歉。
- React Native 比傳統(tǒng) Objective-C 和 UIView 的學(xué)習(xí)成本低多了等脂，熟悉 JavaScript 的開發(fā)者應(yīng)該半天內(nèi)就能寫個使用標(biāo)準(zhǔn) UI 的界面俏蛮，而且用 XML+CSS 畫界面也遠(yuǎn)比 UIView 中用 Frame 進(jìn)行手工布局更易讀
- 它目前已經(jīng)有組件倉庫了，而且在 github 上都有 500 多倉庫了上遥，其中有 sqlite搏屑、Camera 等原生組件，隨著這些第三方組件的完善粉楚，基于 React Native 開發(fā)越來越不需要寫原生代碼了辣恋。

二、RN開發(fā)環(huán)境搭建

React Native (簡稱RN)是Facebook于2015年4月開源的跨平臺移動應(yīng)用開發(fā)框架模软，是Facebook早先開源的UI框架 React 在原生移動應(yīng)用平臺的衍生產(chǎn)物伟骨，目前支持iOS和安卓兩大平臺。RN使用Javascript語言燃异，類似于HTML的JSX携狭，以及CSS來開發(fā)移動應(yīng)用，因此熟悉Web前端開發(fā)的技術(shù)人員只需很少的學(xué)習(xí)就可以進(jìn)入移動應(yīng)用開發(fā)領(lǐng)域

RN通信機(jī)制
開發(fā)工具
- WebStorm ( webstorm激活碼)
- Xcode（只有mac系統(tǒng)才能開發(fā)iOS應(yīng)用）
- Genymotion安卓模擬器
- Android Studio
開發(fā)論壇
環(huán)境搭建
React Native 環(huán)境搭建官方提供了詳細(xì)的搭建教程
環(huán)境搭建注意
- React Native 更新操作
  - 更新項目版本 npm(Node Package Manager)
    $npm update -g react-native
  - 查詢網(wǎng)上RN最新的版本
    $npm info react-native
  - 升級或者降級RN 版本
    $npm install --save react-native@0.XX.X
- 工欲善其事回俐，必先利其器
  ReactNative 代碼智能提醒： ReactNative-LiveTemplate逛腿。
  將ReactNative.xml復(fù)制到~/Library/Preferences/WebStorm/templates然后重啟。 (沒有templates手動創(chuàng)建仅颇，WebStorm名字可能不一樣)
- iOS允許http請求設(shè)置（不然第一次運行會報錯）
- iOS RN 0.45以上版本所需的第三方編譯庫
  OR（https://sourceforge.net/projects/boost/files/boost/1.63.0/）

三单默、創(chuàng)建我們第一個RN項目

React Native項目創(chuàng)建

react-native init YochiProject
cd YochiProject
react-native run-ios(運行iOS應(yīng)用)
react-native run-android(運行安卓應(yīng)用)

對應(yīng)的目錄下分別為Android和iOS工程

打開WebStorm，導(dǎo)入我們的項目即可開始開發(fā)了

運行成功后的效果點擊模擬器command+R刷新