GIC在UI上支援直接以XML來寫，而業務邏輯支援使用JavaScript來寫，因此具備了應用熱更新的能力。
本篇將會重點介紹如何使用GIC來實現應用的熱更新。
如果你不想看下面內容，也可以直接使用腳手架來建立一個具有HotUpdate功能的工程模板。你可以按照腳手架的提示直接執行這個模板來檢視hotUpdate的功能，如下圖
如何建立請移步到這個地址。
HotUpdate流程
這裡介紹的是一種全量更新的方法，也就是說每次更新都會將整個project整體打包更新。也許你可能會擔心整體更新的話包體積太大，這裡其實你大可以放心，我們公司現在三個APP都採用這樣的方式，打包以後其實也就幾十KB~幾百KB，包括圖片在內。如果包實在太大，那我相信這時候整個APP已經很複雜龐大了，這時候你可能需要使用另外一種方式來實現了，比如把不同的模組獨立打包。
HotUpdate的實現是需要服務端和客戶端一起配合實現的，服務端提供更新介面以及包下載伺服器，客戶端則根據服務端返回的更新資料，從伺服器下載新包。下面分別介紹兩端的實現流程。
服務端
更新介面需要兩個引數。
- appVersion:用來表示客戶端版本號
- pakageVersion:客戶端當前使用的包的版本號
根據這個兩個引數，服務端需要一張資料表來儲存各個版本的資訊。表設計如下
| packageVersion | needAppVersion | packageUrl | md5 | updateDate |
|---|---|---|---|---|
| 包版本號 | 能夠執行該包需要的最低app版本號 | 包的下載地址 | 包的md5校檢碼 | 更新日期 |
更新邏輯如下：
- 使用appVersion 跟 needAppVersion 比較，獲取needAppVersion <
= appVersion 的所有記錄，並且按照packageVersion 從高到底排序。- 使用pakageVersion 跟第一步篩選出的第一條資料的
packageVersion比較，如果是小於的，那麼返回第一步的第一條資料，如果是>
=的，那麼就說明沒有可以更新的包。
客戶端
app啟動的時候，從服務端請求更新介面，如果服務端返回了更新資料，那麼說明有新的包可以更新。
這時候客戶端根據拿到的packageUrl地址下載新的包，並且校驗md5值，然後將新包解壓到本地資料夾中，最後使用GICRouter的loadAPPFromPath:方法重新載入包使得更新生效。
當然，你也可以將下載好的新包等下一次app啟動後再解壓重新載入。