iOS混合開發庫(GICXMLLayout)8、熱更新

GIC在UI上支持直接以XML來寫，而業務邏輯支持使用JavaScript來寫，所以具有了應用熱更新的能力。

本篇將會重點介紹如何使用GIC來實現應用的熱更新。

若是你不想看下面內容，也能夠直接使用腳手架來建立一個具備HotUpdate功能的工程模板。你能夠按照腳手架的提示直接運行這個模板來查看hotUpdate的功能，以下圖

如何建立請移步到 這個地址。

HotUpdate流程

這裏介紹的是一種全量更新的方法，也就是說每次更新都會將整個project總體打包更新。也許你可能會擔憂總體更新的話包體積太大，這裏其實你大能夠放心，咱們公司如今三個APP都採用這樣的方式，打包之後其實也就幾十KB~幾百KB，包括圖片在內。若是包實在太大，那我相信這時候整個APP已經很複雜龐大了，這時候你可能須要使用另一種方式來實現了，好比把不一樣的模塊獨立打包。

HotUpdate的實現是須要服務端和客戶端一塊兒配合實現的，服務端提供更新接口以及包下載服務器，客戶端則根據服務端返回的更新數據，從服務器下載新包。下面分別介紹兩端的實現流程。

服務端

更新接口須要兩個參數。

1. appVersion:用來表示客戶端版本號
2. pakageVersion:客戶端當前使用的包的版本號

根據這個兩個參數，服務端須要一張數據表來保存各個版本的信息。表設計以下

packageVersion	needAppVersion	packageUrl	md5	updateDate
包版本號	可以運行該包須要的最低app版本號	包的下載地址	包的md5校檢碼	更新日期

更新邏輯以下：

1. 使用appVersion 跟 needAppVersion 比較，獲取needAppVersion <= appVersion 的全部記錄，而且按照packageVersion 從高到底排序。
2. 使用pakageVersion 跟第一步篩選出的第一條數據的packageVersion比較，若是是小於的，那麼返回第一步的第一條數據，若是是>=的，那麼就說明沒有能夠更新的包。

客戶端

app啓動的時候，從服務端請求更新接口，若是服務端返回了更新數據，那麼說明有新的包能夠更新。

這時候客戶端根據拿到的packageUrl地址下載新的包，而且校驗md5值，而後將新包解壓到本地文件夾中，最後使用GICRouter的loadAPPFromPath:方法從新加載包使得更新生效。

固然，你也能夠將下載好的新包等下一次app啓動後再解壓從新加載。