RN的啟動機制是將JS代碼打包成為一資源文件，App啟動時加載這個bundle從而啟動RN項目。基于這一點，可以利用對這個bundle文件的下載合成從而實現熱更新。
這樣做的優點有：
1.JS方面的代碼可以跳過發布版本來進行更新，如果應用結構足夠好，理論上界面相關的改變都可以通過熱更新實現。
2.部分bug可以實時修復。
3.沒有熱修復原生部分代碼，不會被蘋果審核拒掉。（關于蘋果為什么會拒部分熱更新庫請自行了解）
缺點是：
1.原生部分改動及bug還需要依賴于發布版本。
下面是干貨：
首先，因為會存在不得不發布appstore版本的情況，所以我們可以利用這一點來減少版本管理的難度。每次發布appstore版本進行原生更新時，我們稱之為大版本更新，此時工程內保留的jsbundle為當前最新版本。當需要熱更新時，我們稱之為小版本更新，通過增量包與大版本更新時留在本地的jsbundle合成為最新版本。
然后，我們需要明確版本管理機制。因為客戶端的當前版本是未知的，我們需要知道客戶端應該下載哪一個版本的包來更新到最新版本。這里有兩種做法：
1.根據客戶端的版本請求服務端，服務端通過比對當前客戶端版本及最新版本生成增量包來讓客戶端下載，客戶端利用本地版本和下載的增量包合成最新版本。
2.客戶端保留兩個bundle文件，一個bundle是當前加載使用的版本，一個bundle是用于合成最新版的最低版本。服務端保留基于最低版本生成的增量包，客戶端只需要請求最新版本的增量包即可與最低版本合成最新版。
這兩種做法的優缺點也很明顯，我們舉例說明。假設我們當前大版本下有10個小版本。
第一種做法服務端會生成 10基于9的增量包，10基于8的增量包，10-7，10-6....10-1,9-8，9-7...2-1個增量包。
而第二種做法會生成10-1，9-1，8-1...2-1個增量包。
雖然當發布了最新版本之后，之前不需要的可以刪除（即第一種做法服務端保留的版本只會是10-9到10-1共9個版本），但是就消耗的資源來說第一種要比第二種多出生成時的消耗及刪除時的消耗。
而第二種做法客戶端是基于最低版本來更新的，所以第二種客戶端包會大一點，服務端保留的增量包體積會大一點。
明確了版本管理的原則后，根據業務需要我們就可以完成這個生成patch包及下載合成最新版本的流程了。
在進行熱更新有一點需要額外注意的地方，增量包合成之后時候，可能會出現bug導致直接閃退，此時需要增加一項版本回滾的功能保證客戶端的正常使用。思路是利用JS正常啟動時通知原生部分，來確認是否正常啟動，未正常啟動的時候進行回滾即可。
PS：涉及到圖片等資源的熱更新，可以利用更改引入路徑來解決，這里不再詳述。（曾經面試時傻得說的太過詳細，后來發現人家是來我這里套方案的- -累覺不愛）
如果能幫助到你，麻煩點個贊哦！
下面與正文無關，純粹一點個人感想，不感興趣可跳過。。。
在iOS這一行干了三年之后，發現技術處于一個不上不下的地方。一方面，接觸過的東西非常多，可以說常見App能用到的東西都使用過，但是問題也是接觸了太多東西，對技術不夠深入，很多東西都停留在使用階段，知其然不知其所以然。甚至很多都是模糊的，不夠明確的。另一方面，近段時間找工作的經歷也讓我認清自身技術上沒有特別亮眼的長處。
重新開始更新博客即有利于知識結構的重建，也有利于對知識進行一個總結回顧。希望能堅持下來，找準不足，發展特長。也愿所有與我一樣處于瓶頸期的道友們同樣能找到自身發展的道路并能堅持走下去。
PS：如果有公司缺iOS的，對我感興趣的幫忙內推一下哦，萬分感謝！聯系方式微信 woaicccrrrfff
