金昱東

摘要：隨著移動互聯(lián)網(wǎng)的飛速發(fā)展，移動設備與平臺也在不斷更新迭代，多種平臺與操作系統(tǒng)共存。對用戶而言，多了一種選擇，而對于開發(fā)者而言，則大大增加了開發(fā)成本。為了實現(xiàn)相同的功能，為每個平臺單獨開發(fā)應用無疑是一種非常耗費人力資源的解決方案；而基于Web的跨平臺開發(fā)方案并不能保證在不同平臺提供統(tǒng)一流暢的用戶體驗。因此降低開發(fā)成本、保證應用體驗是移動平臺開發(fā)一直追求和關注的兩個核心點。本文論述了React Native相比其他跨平臺解決方案的優(yōu)勢與不同，并在React Native基礎上提供了一種代碼壓縮與動態(tài)加載的解決方案，大幅減少動態(tài)加載業(yè)務代碼的大小與傳輸時間，將其在實際開發(fā)中的實用性進一步提高。

關鍵詞：軟件工程；移動互聯(lián)網(wǎng)；跨平臺；ReactNative；動態(tài)加載

中圖分類號：TP311

文獻標識碼：A

DOI：10.3969/j.issn.1003-6970.2016.02.020

引言

移動端的操作系統(tǒng)目前呈現(xiàn)兩極分化，Android與iOS是目前最普及的兩個移動操作系統(tǒng)。然而在為它們開發(fā)同一個應用程序時，通常都需要兩套開發(fā)人員來維護兩個不同的代碼倉庫。除了React Native外比較流行的解決辦法是使用Htm15等Web技術來實現(xiàn)“一套代碼，多處運行”。然而由于設備與操作系統(tǒng)的差異性，基于Web的界面與交互在兩個平臺上的體驗并不一致且相差甚遠。因此它只解決了開發(fā)成本的問題，并沒有解決保證應用體驗的問題。然而React Native則很好的同時解決了這兩個問題。

另外值得一提的是在Android與iOS平臺都可以實現(xiàn)代碼的動態(tài)加載，與Web同樣靈活。即在程序運行的過程中更新業(yè)務代碼，可以用來實現(xiàn)bug修復或應用升級等功能。

Android依托于Java的Classloader，而iOS依托于Objective-的動態(tài)性。React Native主要使用JS作為開發(fā)語言，也非常好的支持了動態(tài)加載機制，但缺點是打包后的JS代碼過多，不利于在質量較低的移動網(wǎng)絡下進行傳輸。因此本論文提出了一種基于ReactNative的代碼壓縮方法，可以大幅精簡JS代碼量，使其在移動網(wǎng)絡下的穩(wěn)健性更高、實用性更強。

1 React Native的概念

React Native是Facebook在2015年發(fā)布的一套基于JavaScript的開源框架。React Native結合了Web應用和Native應用的優(yōu)勢，可以使用JavaScript來開發(fā)iOS和Android原生應用。在JavaScript中用React抽象操作系統(tǒng)原生的UI組件，代替DOM元素來渲染界面。因此它同時解決了以下的兩個問題：

1.1 減少開發(fā)成本

無論是Android還是iOS平臺，React Native都使用JavaScript作為主要的開發(fā)語言，同時它也使用了React來簡化和加速開發(fā)流程。由于Android與iOS中的系統(tǒng)UI組件大部分都相似（如文字、圖片、列表等），基礎功能（如本地存儲、動畫、通知）也基本類似，因此React Native將這些組件統(tǒng)一抽象為一個Module，開發(fā)者不用再關心到底當前編寫的Module運行在哪個平臺上，只需要關注本身的業(yè)務邏輯即可。

而對于Android與iOS所各自特有的概念，ReactNative進行單獨定義，如Android中的Toolbar、iOS中的TabBar等等。這樣開發(fā)者就可以針對不同平臺的特性，在現(xiàn)有代碼基礎上稍作修改以適配不同的移動操作系統(tǒng)。Android軟件的設計與其他系統(tǒng)中軟件設計基本類似，可能在測試方法、測試用例的編寫上有所不同，但是畢竟開發(fā)流程并不同意。

Facebook在提出React Native的時候提出“Learnonce，write anywhere”，即不同的平臺代碼不會完全相同，但是會很相似。即也可以保證一套開發(fā)人員即可完成多平臺業(yè)務場景的開發(fā)與實現(xiàn)，相較于傳統(tǒng)的開發(fā)方式有很大改觀。

1.2 提供一致的用戶體驗

一般來講，在各自平臺使用原生的API開發(fā)的應用是運行效率最高的，即用戶體驗最好的。而基于Web形式的應用既需要加載時間，又需要有較強的處理器進行DOM渲染，因此在不同平臺、不同設備上的體驗非常不一致。雖然說JQuery等開源方案經過優(yōu)化可以達到比較好的效果，但是離原生應用差距還是較大。

舉例來說PhoneGap屬于較為成熟的基于Web的跨平臺解決方案，它在iOS上的流暢度和加載時間要遠遠好于Android，或Android中只能處理一些簡單的靜態(tài)邏輯。如果僅僅使用PhoneGap為iOS開發(fā)，就失去了跨平臺解決方案的意義。

React Native雖然使用JavaScript作為開發(fā)語言，但是它并不將界面UI渲染到Web上，而是使用JavaScript解釋器，將JS代碼解釋為原生的組件再渲染到界面上。因此，從用戶體驗上來講，React Native的渲染效率應該與原生應用是一致的。它與Web類的開發(fā)框架的不同之處在下一章進行詳細講解。

2 React Native運行原理

由于Android版本的React Native剛處于測試階段，因此這里選取iOS作為分析對象，對不同平臺來說，它們的實現(xiàn)原理基本類似。

2.1 JS與原生模塊相互調用

在iOS中，React Native使用白帶的JavaScriptCore作為JS的解析引擎，但并沒有用到JavaScriptCore提供的一些可以讓JS與OC互調的特性，而是自己實現(xiàn)了一套機制，這套機制可以通用于所有JS引擎上，這么做應該也是考慮到了項目的靈活性與iOS安全機制的問題。

實際上普通的JS與原生代碼的調用非常簡掣，無論是Android還是iOS，原生代碼可以向JS傳遞消息，如iOS中webview提供的stringByEvaluatingjavaScriptFromString方法可以直接執(zhí)行一段JS腳本，并且可以獲取它的返回值。這個返回值其實就相當于JS向原生代碼傳遞消息。React Native就是以此為基礎，通過模塊配置表和響應流程實現(xiàn)了原生代碼與JS代碼的無縫銜接調用。

2.2 模塊配置表

在React Native初始化的時候，為了使JS知道可調用的原生模塊Module方法與命名，需要將一份Module的配置表傳遞給JS，配置表里包含了所有的模塊和模塊中的方法信息。

React Native框架中提供了一個叫做RCTBridgeModule的接口。在React Native初始化的時候，可以通過runtime接口objc_getClassList獲取所有的類，然后逐個判斷是否實現(xiàn)了RCTBridgeModule接口，就可以找到所有的模塊類了。一個模塊中有很多方法，一些可以暴露給JS調用，另一些則不需要。需要暴露的方法使用RCT_EXPORT_METHOD宏定義包裹，其實是將方法名在編譯時重新定義為有固定前綴的方法，方便查找并記錄。

因此在原生代碼中定義好了接口與函數(shù)，ReactNative就會根據(jù)運行時環(huán)境獲取所有的模塊與其方法生成模塊配置表。這個配置表在原生代碼與JS代碼之間都維持一份相同的配置，便于原生代碼與JS代碼相互調用。

2.3 事件傳遞響應流程

React Native的主要核心是自己實現(xiàn)了一套JS與原生代碼相互調用的機制，這也是與其他基于Web的跨平臺方案不同的地方。使用JS寫好業(yè)務代碼后，由React Native進行解釋，偏向效率的邏輯執(zhí)行、UI渲染都會在原生階段進行處理，因此React Native的執(zhí)行效率要比其他的跨平臺方案高很多。

JS與原生代碼的調用流程比較負責，如下所示：

1、JS端調用原生模塊中的某個方法

2、將調用分解為模塊名、方法名、參數(shù)，傳遞給MessageQueue進行處理，生成callbackld

3、將模塊名、方法名、參數(shù)對應模塊配置表，轉換成模塊id、方法id、參數(shù)id

4、原生模塊根據(jù)各個id確定被調用的方法與參數(shù)

5、執(zhí)行原生代碼邏輯，將執(zhí)行結果進行回調

6、JS端根據(jù)callbackld接收執(zhí)行結果

其中需要特別注意的是，JS并不會主動傳遞數(shù)據(jù)給OC。在調用OC方法時，會把模塊id、方法id放入到一個隊列中。等原生代碼過來調用JS的任意方法時，將這個隊列返回再執(zhí)行這個隊列中需要執(zhí)行的方法。所以React Native是一種基于事件響應機制的框架，在沒有操作時不會進行無效的循環(huán)執(zhí)行。

3 代碼壓縮與動態(tài)加載

3.1 動態(tài)加載的概念

在移動平臺安裝或更新軟件時，通常使用apk或ipa文件進行安裝，也就是所稱的安裝包。這個安裝包中包含了應用全部功能的實現(xiàn)。然而通常情況下，用戶只有下載完整的安裝包才能使用最新版的軟件系統(tǒng)。動態(tài)加載的概念則是只下載更新部分的特定代碼（文件形式），覆蓋到原來的代碼空間，這個概念與我們在Windows平臺上所說的補丁概念類似。

在移動平臺的背景下，由于用戶的網(wǎng)絡環(huán)境可能更差、存儲空間更小，因此動態(tài)加載就非常適用于移動平臺軟件的更新與需求實現(xiàn)。另外一方面，由于移動互聯(lián)網(wǎng)發(fā)展迅速、軟件迭代頻繁，動態(tài)加載可以在不下載完整安裝包的情況下，讓用戶沒有感知的完成應用的更新，更有利于修復線上bug與需求的快速實現(xiàn)。

React Native就完全支持動態(tài)加載的這個特性，當開發(fā)人員編寫好新的功能模塊時，將業(yè)務代碼與所需要的資源（Assets）打包下發(fā)到軟件中，軟件再動態(tài)加載業(yè)務代碼，實現(xiàn)動態(tài)加載。主要流程如下圖所示：

需要注意的是，在下載更新包之后，需要對代碼的版本、安全性進行驗證，防止打錯版本或第三方對軟件進行篡改劫持。

3.2 簡化JS代碼結構

在React Native當中，可以對JS業(yè)務代碼進行打包處理，即JS代碼既可以在線訪問也可以離線訪問。使用如下命令可以將JS業(yè)務代碼進行打包：

react-native Bundle-minify

這樣就可以將JS業(yè)務代碼打包成一個bunlde文件，在app運行時指定這個文件的本地地址（或在線地址）就可以對其進行訪問并解釋執(zhí)行。但是有一個非常明顯的缺陷是，使用React Native提供的bunlde命令打包出的JS文件代碼量非常的大，至少有5萬行以上。React Native應用加載的流程如下圖所示：從圖中可以看到，第三步與第四步中是較為耗時的兩個過程。沒有經過處理的bunlde文件體積通常在300KB以上，如果使用2G網(wǎng)絡傳輸則需要至少十秒以上，這對于用戶體驗有非常大的影響。另外，過多的代碼量對移動的設備的性能也會造成影響，5萬行代碼的執(zhí)行時間通常也在200到300毫秒之間，雖然說時間并不多，但是用戶可以明顯感受到加載界面時的卡頓現(xiàn)象。

因此在本研究當中針對這兩個非常耗時的環(huán)節(jié)進行優(yōu)化，提出了一種分離基礎JS與業(yè)務JS的方法，可以大大縮小代碼的下載與加載時間。如下圖所示：

如上圖所示，原有的Bundle文件中，同時夾雜了基礎JS代碼與業(yè)務JS代碼?；AJS代碼指的是業(yè)務代碼運行時所依賴的基礎環(huán)境。我們?yōu)椴煌K打包出的的Bundle文件中都會包含基礎JS代碼，因此如果軟件中同時有多個Bundle文件時，會造成空間的浪費。經過驗證基礎JS代碼大概在5萬行左右，而業(yè)務JS根據(jù)業(yè)務復雜程度而定，一般不超過IOKB，這樣就非常有利于業(yè)務JS在網(wǎng)絡中進行傳遞與動態(tài)加載。

3.3 動態(tài)加載與實驗驗證

在分離了JS代碼之后，就可以針對具體的業(yè)務場景進行優(yōu)化。由于基礎JS文件較大，不適合在網(wǎng)絡中進行傳輸，因此可以將其緩存在本地。而每次啟動應用進行更新時，只需要下載體積非常小的業(yè)務JS。流程如下圖所示：

應用啟動后，加載本地的基礎JS代碼，且在不同的業(yè)務場景切換時不再次加載。即基礎JS在各個業(yè)務場景間進行共享。其次從網(wǎng)絡中下載業(yè)務JS代碼，由于單個業(yè)務場景邏輯本身實現(xiàn)并不需要非常大的代碼量，因此一般業(yè)務JS打包并壓縮之后可以保持在SKB左右，使用2G網(wǎng)絡進行下載時僅僅需要1秒就可以完成。同時由于不再需要加載基礎JS，渲染業(yè)務場景的時間也會更少，經過實驗驗證僅需10到50毫秒即可渲染完畢。相較于之前的200毫秒有較大的提升。如下表所示：

4 結論

React Native不同于其他的跨平臺開發(fā)框架，它同時解決了開發(fā)成本和運行效率的兩個關鍵問題。在此基礎之上本論文優(yōu)化了其工程代碼結構，將基礎JS與業(yè)務JS相互隔離，兩部分可獨立更新與迭代替換。其次在使用React Native進行動態(tài)加載時，僅需加載業(yè)務JS即可，大幅減少了在移動網(wǎng)絡中傳輸?shù)臄?shù)據(jù)大小，加快了界面的載入速度，同時也明顯提升了應用的用戶體驗。