React native 拆包

拆包是React-Native項目不得不面臨的一個重要技術(shù)門檻害淤。


圖片來自網(wǎng)絡(luò)

為什么要拆包腋舌?

bundle文件過大: 一個Helloworld的App送矩,如果使用0.53RN 官方命令react-native bundle打包出來的JSBundle文件大小大約為530KB澄暮,RN依賴模塊本身占了99.9%搅荞。

頁面加載慢: 如果使用熱更新,從網(wǎng)絡(luò)獲取整個包的下載時間很長幽污,每次進入RN頁面都需要執(zhí)行RN基礎(chǔ)模塊的定義嚷辅。

如果只是一個單獨的新APP,純RN的距误,或者只有一兩個業(yè)務(wù)使用簸搞,這點大小算不了什么扁位。
但是對于很多業(yè)務(wù)的公司項目,如果每個業(yè)務(wù)的JSBundle都需要這么大的一個RN框架趁俊,那將是沒必要的域仇。

Facebook官方有沒有解決方案呢?
Facebook的打包工具是metro, metro自帶unbundle命令寺擂,不過暇务,打包結(jié)果不符合預(yù)期;
Android端是將每一個模塊輸出到單個文件并以模塊ID命名怔软;IOS端是將模塊以流形式打到一個文件中垦细;

方案

調(diào)研的方案可以分三類:

1.手動拆分&合并后再加載

使用RN打包工具打包,手動將文件分開分成基礎(chǔ)包A.js, 業(yè)務(wù)包B.js;然后在APP加載該頁面的時候?qū),B兩個文件合并再執(zhí)行挡逼;
優(yōu)點:成本低括改,不需要改打包工具;
缺點:性能沒有提升挚瘟,不能優(yōu)化執(zhí)行時間叹谁,反而會增加翘紊;

2.動態(tài)更新

可以從編譯產(chǎn)物看到require(moduleID)敲茄;這個方案的思路是:編寫一個空的React容器組件,利用DeviceEventEmitter監(jiān)聽一個Native事件讨勤,在需要加載頁面時订框,Native下載將模塊保存下來析苫,以對應(yīng)模塊ID命名,然后通過DeviceEventEmitter對應(yīng)模塊的id發(fā)給React來調(diào)用require(msg.id),比如:

export default class App extends Component {
  constructor(){
    super();
    this.state = {
        dynamicModule : null
    }
  }
  componentDidMount(){
    DeviceEventEmitter.addListener('LoadBundle',(events) =>{ 
      let moduleId = parseInt(events.moduleID, 10))
      let dynamicModule = require(moduleId);
      self.setState({ dynamicModule:dynamicModule });
    });  
  }
  render() {
    const { dynamicModule } = this.state;
    if (dynamicModule) {
      return React.createElement(dynamicModule, this.props);
    } else {
      return (
        <View><Text>空空的容器</Text></View>
      );
    }
  }
}

但是在編譯前使用require(moduleID)會報錯穿扳,因為編譯前根本就未生成模塊Id衩侥,所以需要改動打包工具。
優(yōu)點:性能好矛物,能優(yōu)化執(zhí)行時間, 加載時只是執(zhí)行了React容器組件的render()方法茫死;
缺點:成本很大,需要修改Naive的RN源碼來重寫require方法履羞,android在unbundle調(diào)用的是assets目錄下峦萎,不能通過網(wǎng)絡(luò)動態(tài)獲取,而且需要改打包工具忆首。

3.動態(tài)執(zhí)行

將bundle分為兩部分爱榔,在內(nèi)存中先執(zhí)行基礎(chǔ)模塊的定義,然后再需要打開頁面時糙及,執(zhí)行該頁面的業(yè)務(wù)模塊文件详幽;
優(yōu)點:性能好,能優(yōu)化執(zhí)行時間;
缺點:成本大, 需要改Native加載方式唇聘,打包工具也許修改版姑。

Rabbit-bundler是按照此方案實現(xiàn)的打包工具。
具體請參考:Rabbit-bundler介紹

本文參考

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末雳灾,一起剝皮案震驚了整個濱河市漠酿,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌谎亩,老刑警劉巖,帶你破解...
    沈念sama閱讀 212,185評論 6 493
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件宇姚,死亡現(xiàn)場離奇詭異匈庭,居然都是意外死亡,警方通過查閱死者的電腦和手機浑劳,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,445評論 3 385
  • 文/潘曉璐 我一進店門阱持,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人魔熏,你說我怎么就攤上這事衷咽。” “怎么了蒜绽?”我有些...
    開封第一講書人閱讀 157,684評論 0 348
  • 文/不壞的土叔 我叫張陵镶骗,是天一觀的道長。 經(jīng)常有香客問我躲雅,道長鼎姊,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,564評論 1 284
  • 正文 為了忘掉前任相赁,我火速辦了婚禮相寇,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘钮科。我一直安慰自己唤衫,他們只是感情好,可當我...
    茶點故事閱讀 65,681評論 6 386
  • 文/花漫 我一把揭開白布绵脯。 她就那樣靜靜地躺著佳励,像睡著了一般。 火紅的嫁衣襯著肌膚如雪桨嫁。 梳的紋絲不亂的頭發(fā)上植兰,一...
    開封第一講書人閱讀 49,874評論 1 290
  • 那天,我揣著相機與錄音璃吧,去河邊找鬼楣导。 笑死,一個胖子當著我的面吹牛畜挨,可吹牛的內(nèi)容都是我干的筒繁。 我是一名探鬼主播噩凹,決...
    沈念sama閱讀 39,025評論 3 408
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼毡咏!你這毒婦竟也來了驮宴?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,761評論 0 268
  • 序言:老撾萬榮一對情侶失蹤呕缭,失蹤者是張志新(化名)和其女友劉穎堵泽,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體恢总,經(jīng)...
    沈念sama閱讀 44,217評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡迎罗,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,545評論 2 327
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了片仿。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片纹安。...
    茶點故事閱讀 38,694評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖砂豌,靈堂內(nèi)的尸體忽然破棺而出厢岂,到底是詐尸還是另有隱情,我是刑警寧澤阳距,帶...
    沈念sama閱讀 34,351評論 4 332
  • 正文 年R本政府宣布塔粒,位于F島的核電站,受9級特大地震影響娄涩,放射性物質(zhì)發(fā)生泄漏窗怒。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,988評論 3 315
  • 文/蒙蒙 一蓄拣、第九天 我趴在偏房一處隱蔽的房頂上張望扬虚。 院中可真熱鬧,春花似錦球恤、人聲如沸辜昵。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,778評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽堪置。三九已至,卻和暖如春张惹,著一層夾襖步出監(jiān)牢的瞬間舀锨,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,007評論 1 266
  • 我被黑心中介騙來泰國打工宛逗, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留坎匿,地道東北人。 一個月前我還...
    沈念sama閱讀 46,427評論 2 360
  • 正文 我出身青樓,卻偏偏與公主長得像替蔬,于是被迫代替她去往敵國和親告私。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 43,580評論 2 349

推薦閱讀更多精彩內(nèi)容