客户端热更新框架之UI热更框架设计(上)

什么是热更新，为什么需要热更新？
热更新是目前各大手游等众多App常用的更新方式。简单来说就是在用户通过App Store下载App之后，打开App时遇到的即时更新。对于手游客户端来说，受到苹果审核的约束， 一次审核提交需要10~20天不等的等待时间。而这段时间开发进度依然会推进很多，一旦手游上线，第一个版本在玩家疯狂行为下，出点问题是必然的，所以”在线更新” 就成了家常便饭与必然。如果你要求必须整体重新下载完整下载包体，无法热更， 那么10~20多天后，游戏估计就没啥人了。

热更新要解决的问题？
1: 更新频繁而IOS审核长，IOS无法用DLL反射机制去做代码更新。 如果无热更新机制，则客户端每次都需要玩家重新下载一次完整的安装包，用户体验不好。
2: 解决发布包的容量问题，一切都可以增量下载。

热更新的基本原理是什么？
首先要清楚Unity的打包原理，也就是AssetBundle的打包机制，他会把prefab打包成.asset格式作为传输的数据。通过校验文件的MD5值来判断是否需要更新，如果需要更新则下载差异文件。lua属于解释性文件所以能通过www直接下载到本地，通过C#与lua交互，把逻辑写在lua里，从而实现代码热更新。

为什么需要带热更新的框架？
在中大型商业项目中，基于以上热更新的实际运营需求，国内外各大游戏公司纷纷基于国内已知技术与成熟插件，由技术总监或者主程来牵头研发自己公司的热更新框架。

笔者开发的热更新简单框架介绍：
笔者基于自身技术储备参考部分行业公司框架产品，设计了一套简单热更新客户端框架，现介绍如下，希望以此起到抛砖引玉的作用，结交行业朋友。

热更新框架总体构成：
客户端热更框架，核心主要设计为以下几个模块：
A: 热更新UI框架模块。
B： lua框架（包含热补丁模块）。
lua框架由“纯lua框架”与“C#映射lua”等技术构成。可以实现在lua脚本中，定义unity的生命周期（eg: Start()、Update() 等），方便lua的编写与功能扩展。
业务逻辑方面，固定业务不需要频繁修改的功能，笔者还是坚持用C#完成。 有频繁更新需求的则用基于lua框架来编写。基于本套lua框架，其比纯lua编写效率高很多。
C： 服务器端热更新流程模块。
D： 基础支持插件与框架： xlua插件与AB(AssetBundle)框架。

热更新框架运行过程：
整体热更框架的运行流程如下：
1： 首先热更新流程模块启动。 玩家可以从客户端游戏中看到PC或移动端(手机、Ipad等)与服务器的更新过程。
2： 热更新的UI框架启动。
3： lua框架启动（与第2部分从宏观上可以并行运行）。
3.1> 检查本项目中哪些C#脚本需要进行Bug动态更新。
3.2> 初始化lua框架与C#建立生命周期映射关系，进一步方便程序员在lua中使用unity提供的系统函数(例如：Start()、Update()等) 。
3.3> lua框架启动完毕后，通知框架外部可以开始加载项目lua文件，且运行期解释执行。
4: 场景资源加载。

最后由于篇幅所限，笔者先写到这。下一篇本人会先就 “热更新UI框架” 这个模块，进行详细讲解，欢迎广大小伙伴们留言评论！