热更新&加载器技术（二）：常见的平台和更新方式

这篇主要讲一下热更新的原理，和各个平台使用库的方法。

综述

热更新是相对于冷更新的一种技术，冷更新差不多就是重装的意思，用户主动从网络、存储介质（光驱、u盘等）来获取安装包，进行安装的过程。而热更新，是程序自主从安装渠道（一般是网络）进行更新升级的过程。
热更新一般是对客户端进行升级更新，服务端不涉及。B/S架构的应用一般就是个浏览器内核+H5/CSS/JS，主要代码都部署在服务端，可以说本身就是热更新的架构，非常方便。移动端B/S架构除了浏览器内核外，还有小程序（有些也叫快应用等）也属于这种。
说点题外话，我个人感觉做点小业务，B/S架构非常快速方便，但不适合做大业务、游戏方面等对性能要求高的产品，所以这时候可以选择原生。Qt是一个跨平台架构，已经非常接近原生的效果和性能了，况且也可以混合编程，这也是我为何选择Qt的原因。不过它在3D、安卓、ios上并不是非常成熟，我们拭目以待。

桌面平台下的更新方式

我个人喜欢下载和收藏软件，所以对软件的更新方式还是比较熟悉的，在桌面平台（主要是win、linux、mac）下大概就是两种方式：

1、使用时更新提示

估计最常见的就是这种了，一般出现在刚打开软件时，或正在使用时出现提示，或你手动点击更新检测后出现提示，如果需要升级，会出现几种情况：
第一种：最老式的，提供一个url地址，你自己去下载覆盖安装。
第二种：软件后台下载安装包，下载完毕后提示关闭原软件，手动/自动安装，更新完毕后打开新软件。软件安装包也有可能是所有更新文件的一个压缩包，效果一样，只需要移动即可。
这种方式使用的最多，sandbox、360chrome、hbuilder、firefox等都是这种更新方式。
第三种：差量更新，软件会后台自动下载后提示关闭原软件，更新完毕后打开新软件。
这种虽然和上面的第二种方式差不多，能省一些升级的时间和流量，但实现就比较难了，因为你得做两个配置文件，一个在本地，给所有的本地文件都标注一个版本号，甚至是URL地址，一个在服务器上，内容也是如此，升级程序才可以去对比所有文件和版本号来判断是否下载，所以出于开发效率和升级文件制作成本考虑，一般人不会选择这种，如果说软件组成的文件数目不多，且比较大时（比如把所有资源打包为一个文件），这时用差量更新比较适合。

2、使用前自动更新

使用这种方式的更新好像游戏软件方面比较多一些，而且是自动进行的，也是我喜欢的一种方式，但要注意一点，如果你服务器软件更新后，客户端必须更新时，要加入一个强退的机制，让玩家重新进入更新，否则版本不一致时通信会遇到障碍。
和上面的第二种、第三种方式一样，也有全部更新和差量更新之分。

移动平台的更新方式

移动平台主要就是android和ios，且苹果明确规定app禁止使用热更新，所以不进行讨论（但原理差不多），我对移动平台开发不是很熟，而且移动应用本身在一个沙箱内运行，不像桌面环境那样开放，但经过我的观察，也有一些主动更新的方式。
1、最常见的，提示后，后台下载整个app包，然后重新安装。
2、跳转到应用商店（或手动打开应用商店），点击更新后会自动更新（不用手动点击安装了），而且手机适配的应用商店有个好处，应该是应用商店有专门的人负责进行制作apk差量更新包，所以有些app更新界面就会提示原大小和差量更新大小，有时差的还挺大。这技术网上搜搜也有，但不在本篇讨论范围内。
3、有些app（游戏比较多），会把一些资源文件（或代码）下载到外部存储卡里进行调用，这个也是自动进行的，和PC端差不多。

我个人的方案

我花了点时间做了个升级/加载器框架，适配到了各个平台，于软件运行前进行更新检测和差量更新，然后去调用可执行程序或动态链接库，win平台下还挺好用，但安卓/qt环境下遇到了非常多的坑，下节再细说。