客户端热更新框架之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框架" 这个模块，进行详细讲解，有感兴趣小伙伴们，给我留言，谢谢！