游戏开发——热更新学习

为什么会有热更新？

因为正常来说游戏版本的更迭需要对游戏进行重新编译打包，比如说cs、cpp这类语言，更改了代码之后必须要进行编译才能运行，例如一个安卓app，一个apk对应一个app，这个app是无法自己更改自己的，只能用新的apk文件来安装一个新的版本

如果我在1.0版本上修改了几个bug，增加了几kb的内容，传统的方法是，我重新编译一次，打包成一个1.1版本的apk文件，扔给应用商店审核，那么这就出问题了，

1. 如果我一个完整的安装包有10G，但是我就修改了几kb的内容，用户每次更新就需要下载10G的内容，而这其中有很多重复下载的文件
2. 应用商店是需要审核的，甚至在ios商店的审核时间会很长，如果我有一个恶性bug必须马上修复，那么对于在线游戏来说，在修复的这段时间就只能停服了

因此热更新就出现了，我们可以将程序拆解成两个部分，基础部分和业务部分，基础部分是底层的、不会经常变动的部分；业务部分是基于基础部分之上的，变动频繁的部分

通常，这个基础部分是无法热更新的，如果需要修改这部分，就得重新打包发给应用商店审核，而业务部分则是可以被热更新的，用户使用的是客户端，我们就使用服务端发更新补丁给客户端，客户端下载之后就可以直接进行替换，不需要下载多余的部分

是否可以热更新实际上还涉及到编译型语言和解释型语言的区别

编译型语言和解释型语言

编译型语言要求必须提前将所有源代码一次性转换成机器语言交给系统执行，也就是生成一个可执行程序，那么显而易见的是，编译型语言生成的一个可执行程序是无法跨平台运行的，必须根据不同的平台单独生成不同的可执行程序

解释型语言则可以一边执行一边转换，通过解释器逐行将语言解释成机器语言交给系统执行，那么结合编译型语言的特性，解释型语言会针对不同的平台开发不同的解释器（一个可执行程序），同一段代码通过解释器让不同的平台执行同样的操作

那为什么我们不全部使用解释型语言呢？因为解释型语言多了解释器这个中间层，编译型语言编译完之后，系统直接照做就可以了，但是解释型语言却需要通过解释器转译，所以解释型语言的效率天生低于编译型语言。

资源热更新

在Unity中使用 AssetBundle(简称AB包) 来进行资源的热更新，AB包实际上就是Unity提供的一种用于存储资源的资源压缩包