RN的啟動機(jī)制是將JS代碼打包成為一資源文件笛洛，App啟動時加載這個bundle從而啟動RN項目巡蘸」硌ⅲ基于這一點，可以利用對這個bundle文件的下載合成從而實現(xiàn)熱更新翘悉。
這樣做的優(yōu)點有：
1.JS方面的代碼可以跳過發(fā)布版本來進(jìn)行更新茫打，如果應(yīng)用結(jié)構(gòu)足夠好，理論上界面相關(guān)的改變都可以通過熱更新實現(xiàn)妖混。
2.部分bug可以實時修復(fù)老赤。
3.沒有熱修復(fù)原生部分代碼，不會被蘋果審核拒掉制市。（關(guān)于蘋果為什么會拒部分熱更新庫請自行了解）
缺點是：
1.原生部分改動及bug還需要依賴于發(fā)布版本抬旺。
下面是干貨：
首先，因為會存在不得不發(fā)布appstore版本的情況祥楣，所以我們可以利用這一點來減少版本管理的難度开财。每次發(fā)布appstore版本進(jìn)行原生更新時，我們稱之為大版本更新误褪，此時工程內(nèi)保留的jsbundle為當(dāng)前最新版本责鳍。當(dāng)需要熱更新時，我們稱之為小版本更新兽间，通過增量包與大版本更新時留在本地的jsbundle合成為最新版本历葛。
然后，我們需要明確版本管理機(jī)制嘀略。因為客戶端的當(dāng)前版本是未知的恤溶，我們需要知道客戶端應(yīng)該下載哪一個版本的包來更新到最新版本。這里有兩種做法：
1.根據(jù)客戶端的版本請求服務(wù)端屎鳍，服務(wù)端通過比對當(dāng)前客戶端版本及最新版本生成增量包來讓客戶端下載宏娄，客戶端利用本地版本和下載的增量包合成最新版本。
2.客戶端保留兩個bundle文件逮壁，一個bundle是當(dāng)前加載使用的版本孵坚，一個bundle是用于合成最新版的最低版本。服務(wù)端保留基于最低版本生成的增量包窥淆，客戶端只需要請求最新版本的增量包即可與最低版本合成最新版卖宠。
這兩種做法的優(yōu)缺點也很明顯，我們舉例說明忧饭。假設(shè)我們當(dāng)前大版本下有10個小版本扛伍。
第一種做法服務(wù)端會生成 10基于9的增量包，10基于8的增量包词裤，10-7刺洒，10-6....10-1,9-8鳖宾，9-7...2-1個增量包。
而第二種做法會生成10-1逆航，9-1鼎文，8-1...2-1個增量包。
雖然當(dāng)發(fā)布了最新版本之后因俐，之前不需要的可以刪除（即第一種做法服務(wù)端保留的版本只會是10-9到10-1共9個版本）拇惋，但是就消耗的資源來說第一種要比第二種多出生成時的消耗及刪除時的消耗。
而第二種做法客戶端是基于最低版本來更新的抹剩，所以第二種客戶端包會大一點撑帖，服務(wù)端保留的增量包體積會大一點。
明確了版本管理的原則后澳眷，根據(jù)業(yè)務(wù)需要我們就可以完成這個生成patch包及下載合成最新版本的流程了胡嘿。
在進(jìn)行熱更新有一點需要額外注意的地方，增量包合成之后時候境蔼，可能會出現(xiàn)bug導(dǎo)致直接閃退灶平，此時需要增加一項版本回滾的功能保證客戶端的正常使用。思路是利用JS正常啟動時通知原生部分箍土，來確認(rèn)是否正常啟動逢享，未正常啟動的時候進(jìn)行回滾即可。
PS：涉及到圖片等資源的熱更新吴藻，可以利用更改引入路徑來解決瞒爬，這里不再詳述。（曾經(jīng)面試時傻得說的太過詳細(xì)沟堡，后來發(fā)現(xiàn)人家是來我這里套方案的- -累覺不愛）
如果能幫助到你侧但，麻煩點個贊哦！
下面與正文無關(guān)航罗，純粹一點個人感想禀横，不感興趣可跳過。粥血。柏锄。
在iOS這一行干了三年之后，發(fā)現(xiàn)技術(shù)處于一個不上不下的地方复亏。一方面趾娃，接觸過的東西非常多，可以說常見App能用到的東西都使用過缔御，但是問題也是接觸了太多東西抬闷，對技術(shù)不夠深入，很多東西都停留在使用階段耕突，知其然不知其所以然笤成。甚至很多都是模糊的评架，不夠明確的。另一方面炕泳，近段時間找工作的經(jīng)歷也讓我認(rèn)清自身技術(shù)上沒有特別亮眼的長處古程。
重新開始更新博客即有利于知識結(jié)構(gòu)的重建，也有利于對知識進(jìn)行一個總結(jié)回顧喊崖。希望能堅持下來，找準(zhǔn)不足雇逞，發(fā)展特長荤懂。也愿所有與我一樣處于瓶頸期的道友們同樣能找到自身發(fā)展的道路并能堅持走下去。
PS：如果有公司缺iOS的塘砸，對我感興趣的幫忙內(nèi)推一下哦节仿，萬分感謝！聯(lián)系方式微信 woaicccrrrfff
