在自己上手實(shí)現(xiàn)拆包工具之前，我們也調(diào)研了其他家關(guān)于這方面的解決方案。

因?yàn)檫@種操作并沒有官方的解決方案，又和各家的工程結(jié)構(gòu)相關(guān)聯(lián)，所以網(wǎng)上大家提供的解決方案基本都是描述了實(shí)現(xiàn)思路而沒有可以直接使用的工具, 而且一般時(shí)間也比較久遠(yuǎn)。

分析了多個案例之后，解決方案基本匯一下兩種。

方案一

RN分包之Bundle改造
此篇詳細(xì)解釋了 bundle 文件結(jié)構(gòu)以及如何改造打包工具并且已開源(bundle 文件結(jié)構(gòu)圖片來源地)。

整體的實(shí)現(xiàn)思路是一致的，但是嘗試過之后沒有采用，主要原因是：

1. 我們的工程采用 TypeScript 開發(fā)。在 rn 的工程會有一個 rn.config.js 的配置文件。 這個方案沒有去讀取這個配置文件，導(dǎo)致 ts/tsx 的代碼不支持編譯。
2. 這個方案是基于 metro 0.20 版本修改的。我們的工程創(chuàng)建時(shí)默認(rèn)使用的是 metro 0.30.+, 這個 metro 工程結(jié)構(gòu)已經(jīng)發(fā)生了很大的變化。
3. 它里面采用固定 moduleId 的方案是使用 modulePath 的 md5 值。這有一個問題是整個 metro 和 client 涉及到 moduleId 的部分都是采用 number 類型讀取，更改了 moduleId 類型會涉及到很多很多地方的兼容問題。

方案二

react-native-split

這個方案的解決思路非常有意思, 不涉及到任何對 Metro 的修改。
它的主要原理是：

1. 調(diào)用官方 bundle 構(gòu)建打包生成 jsbundle
2. 調(diào)用 babylon 分析 jsbundle 重新生成語法樹
3. 深度遍歷語法樹，根據(jù)配置文件判斷屬于 common 的部分寫入到 common.bundle; 屬于業(yè)務(wù)的部分寫入到 biz.bundle

這個方案的接入成本很低，也很好維護(hù)。但是因?yàn)闆]有把 moduleId 固化下來，如果新增一個 module 可能導(dǎo)致很多 module 對應(yīng)的 id 發(fā)生變化，那么所有的線上模塊都需要重新部署，運(yùn)維成本會很高。

結(jié)論

以上兩個方案是找到有代碼可以研究的方案，但是都并不適用于我們現(xiàn)有的工程環(huán)境。但是從這個兩個方案可以反映出我們的思路是正確的。