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启动后再解压重新加载。