說到版本更新，肯定離不開版本號，各家的版本號格式不同，意義也不一致，比較流行的版本號由3到4個數(shù)字組成，其中用.隔開，比如1.23.53、2.343.12.34，基于react-native開發(fā)產(chǎn)品，我個人覺得比較合理的版本號應該由4個數(shù)字組成，從左到右，第一位數(shù)字表示大版本號，當有重大更新時，該位數(shù)字加一，第二位數(shù)字是react-native的版本號，第三位數(shù)字表示發(fā)布的次數(shù)，發(fā)布正式版時，該位數(shù)字為偶數(shù)，發(fā)布測試版時，該位數(shù)字為奇數(shù)，在研發(fā)時，內(nèi)部測試版和對外發(fā)布的正式版一定是有所區(qū)別的，那么我們通過判斷該位的奇偶性就能很方便地區(qū)分對待了，最后一位數(shù)字表示了版本管理工具的版本號，比如我們目前使用svn來管理項目版本，每次提交時svn都有一個自增的版本號，將這個版本號記錄在產(chǎn)品的版本號中，可以方便我們通過svn的log查詢到對應的修改內(nèi)容。

了解了版本號中各個數(shù)字的意義之后，那么我們接下來說說如何實現(xiàn)js代碼的熱更新。
熱更新的大致流程如下：

1.啟動的時候使用原生語言判斷本地是否存在曾經(jīng)熱更新下來的js代碼，如果存在，那么加載該js代碼，否則加載安裝包asset中的js代碼。這一步很好理解，發(fā)布產(chǎn)品的時候肯定有一份js代碼是打包在asset中的，這是默認加載的js代碼，假如我們已經(jīng)成功通過熱更新下載好了更新的js代碼保存在本地，那么app啟動的時候就應該直接加載保存在本地的js代碼而不是asset中的舊代碼了，否則每次啟動都加載舊代碼，那么熱更新也就失去意義了。
2.js代碼加載完成后就向服務器索要一份版本信息配置文件，其中記錄了js代碼壓縮包的下載地址和版本號，也就是之前所說的第四位版本號，將該版本號與本地記錄的js版本號進行比較，如果不一致，說明有新的js代碼需要更新，如果一直，說明本地的js代碼是最新的了，就直接進入主界面了。
3.根據(jù)版本信息配置文件中的下載地址下載js代碼壓縮包，為什么需要壓縮？因為js代碼太大了，目前我的js代碼有1.2M左右，壓縮一下就只有260K，可以加快用戶的下載速度和節(jié)省用戶的流量消耗，壓縮包下載完成后開始解壓，并將版本信息配置文件保存在本地。
4.js代碼準備好了，那么接下來就是加載js代碼了，如何加載？還記得開發(fā)時的“reload JS”按鈕嗎？查看react-native源碼便可找到加載js代碼的方法。
5.加載js完畢，又回到向服務器索要版本信息配置文件的步驟，不出意外的話，這次服務器端的版本號和本地的版本號是一致的，那么按照流程，就進入到了主界面，至此，整個熱更新的流程也就結束了。

這就結束了嗎？當然不是。試想，用戶手機上的app和我們開發(fā)測試用的app如果共用一份服務器上的版本信息配置文件，那用戶不就可以更新到不穩(wěn)定的功能了嗎？如何解決？很簡單，使用版本號中第三位數(shù)字進行判斷當前app是用戶版還是測試版，再重申一次，版本號為偶數(shù)的便是用戶使用的版本，版本號為奇數(shù)的便是開發(fā)測試使用的版本。在服務器上我們放置兩個版本信息配置文件，分別提供給用戶版和開發(fā)測試版使用，在js代碼中，我們可以通過調(diào)用原生代碼獲取到版本號，判斷奇偶性，然后從服務器端獲取不同的版本信息配置文件，如此即可。

目前熱更新只能實現(xiàn)js代碼的更新，局限性比較大，當原生代碼更新了或者圖片資源更新了，還是需要重新打包，提供用戶下載安裝。

下面放上一個熱更新實例圖，新安裝好的版本，主界面Toolbar右上角是沒有“更多”按鈕的，版本號的最后一位為1，重啟啟動后開始熱更新，更新成功后，主界面Toolbar右上角出現(xiàn)“更多”按鈕，版本號最后一位變成436。