博客主页:https://xiaoy.blog.csdn.net
本文由 呆呆敲代码的小Y 原创,首发于 CSDN
学习专栏推荐:Unity系统学习专栏
游戏制作专栏推荐:游戏制作
Unity实战100例专栏推荐:Unity 实战100例 教程
欢迎点赞 收藏 ⭐留言 如有错误敬请指正!
未来很长,值得我们全力奔赴更美好的生活✨
------------------❤️分割线❤️-------------------------
热更新
方面系列知识,就从这一篇开始吧!热更新的基本概念原理及主流热更新方案介绍
开始学习吧!热更新 是一种App软件开发者常用的更新方式。简单来说,就是在用户通过下载安装APP之后,打开App时遇到的即时更新。
游戏热更新 是指在不需要重新编译打包游戏的情况下,在线更新游戏中的一些非核心代码和资源,比如活动运营和打补丁。
(1)游戏上线后,在运营过过程中,如果需要更换UI显示,或者修改游戏的逻辑行为。传统的更新模式下,需要重新打包游戏,让玩家重新下载包体,造成用户体验不佳的情况。
(2)热更新允许在不重新下载游戏客户端的情况下,更新游戏内容。
热更新分为 资源热更新 和 代码热更新 两种,代码热更新实际上也是把代码当成资源的一种热更新,但通常所说的热更新一般是指代码热更新。
一个游戏中有个很最重要的部分就是要想方设法的留住用户,如果每次游戏内容发生变化时(这在网游中经常会发生),都需要用户去重新下载一个安装包(客户端),这无疑是对游戏用户的留存产生了一个极大的威胁。
热更新作用:能够缩短用户取得新版客户端的流程,改善用户体验。
没有热更新情况:
pc用户:下载客户端->等待下载->安装客户端->等待安装->启动->等待加载->玩
手机用户:商城下载APP->等待下载->等待安装->启动->等待加载->玩
有了热更新情况:
pc用户:启动->等待热更新->等待加载->玩
有独立loader的pc用户:启动loader->等待热更新->启动游戏->等待加载->玩
手机用户:启动->等待热更新->等待加载->玩
通过对比就可以看出,有没有热更新对于用户体验的影响还是挺大的,主要就是省去用户自行更新客户端的步骤。
尤其手游是快节奏的应用,功能和资源更新频繁,特别是重度手游安装包常常接近1个G,如果不热更新,哪怕改动一行代码也要重新打个包上传到网上让玩家下载。
对于IOS版本的手游包IPA,要上传到苹果商店进行审核,周期漫长,这对于BUG修复类操作是个灾难。
所以说就需要热更新技术的出现来解决这个问题。
游戏中一些UI界面和某些模型等等的显示都是通过去加载相应的素材来实现的,当我们只把对应的素材资源进行替换就可以界面和模型发生变化,这个时候我们可以让客户端通过资源对比后从而进行相关资源的下载就可以实现热更新了。
比如在一个游戏中的某些资源我们是放在服务器中的,当我们需要更换游戏中的某些资源时(如UI界面,某个英雄数值需要调整)。
我们只需要把这些新的资源与旧的资源进行替换,而不需要重新下载整个安装包就可以完成一个游戏版本的更迭,就相当于实现了一次热更新。
既然游戏需要热更新,那么我们既然使用了 Unity引擎
,为什么不能直接使用 C#
脚本去进行游戏热更新,反而大多都是使用Lua语言去实现热更新呢?
这就不得不提一下C#语言的特性了,热更新本身对于资源热更新是非常容易的,Unity自带的AB包就可以轻松解决,难的是代码热更新,因为Unity中的C#是编译型语言,Unity在打包后,会将C#编译成一种中间代码,再由Mono虚拟机编译成汇编代码供各个平台执行,它打包以后就变成了二进制了,会跟着程序同时启动,就无法进行任何修改了。
所以直接使用C#进行热更新显然是不可行的,但是也不是说一点办法也没有。在安卓上可以通过C#的语言特性-反射机制实现动态代码加载从而实现热更新。
C#的编译流程:写好的代码->编译成.dll扩展程序(UnityEditor完成)->运行于Unity
C#热更具体做法:将需要频繁更改的逻辑部分独立出来做成DLL,在主模块调用这些DLL,主模块代码是不修改的,只有作为业务(逻辑)模块的DLL部分需要修改。游戏运行时通过反射机制加载这些DLL就实现了热更新。
但苹果对反射机制有限制,不能实现这样的热更。为了安全起见,不能给程序太强的能力,因为反射机制实在太过强大,会给系统带来安全隐患。
其中 ILRuntime
就是使用C#进行的热更新(后边主流热更新方案中会讲到,这里先提一下)。
而 LUA
则是解释型语言,并不需要事先编译成块,而是运行时动态解释执行的。这样LUA就和普通的游戏资源如图片,文本没有区别,因此可以在运行时直接从WEB服务器上下载到持久化目录并被其它LUA文件调用。
Lua热更新解决方案是通过一个Lua热更新插件(如ulua、slua、tolua、xlua等)来提供一个Lua的运行环境以及和C#进行交互。
lua热更原理:逻辑代码转化为脚本,脚本转化为文本资源,以更新资源的形式更新程序。
热更的基本流程可以分成2部分:
第一步、导出热更新所需资源
第二步、游戏运行后的热更新流程
更新注意:
要有下载失败重试几次机制;
要进行超时检测;
要记录更新日志,例如哪几个资源时整个更新流程失败。
下面举例了目前市面上比较主流的几种热更新方案,后面会针对这几种热更新方案都做一个比较详细的介绍,看一看各自的优缺点。
Lua热更
原理:逻辑代码转化为脚本,脚本转化为文本资源,以更新资源的形式更新程序
Lua系解决方案: 内置一个Lua虚拟机,做好UnityEngine与C#框架的Lua导出。典型的框架有xLua, uLua,大体都差不多。
Lua热更新解决方案是通过一个Lua热更新插件(如ulua、slua、tolua、xlua等)来提供一个Lua的运行环境以及和C#进行交互。xLua是腾讯开源的热更新插件,有大厂背书和专职人员维护,插件的稳定性和可持续性较强。
由于Lua不需要编译,因此Lua代码可以直接在Lua虚拟机里运行,Python和JavaScript等脚本语言也是同理。而xLua热更新插件就是为Unity、.Net、Mono等C#环境提供一个Lua虚拟机,使这些环境里也可以运行Lua代码,从而为它们增加Lua脚本编程的能力。
借助xLua,这些Lua代码就可以方便的和C#相互调用。这样平时开发时使用C#,等需要热更新时再使用Lua,等下次版本更新时再把之前的Lua代码转换成C#代码,从而保证游戏正常运营。
ILRuntime
项目是掌趣科技开源的热更新项目,它为基于C#的平台(例如Unity)提供了一个纯C#、快速、方便和可靠的IL运行时,使得能够在不支持JIT的硬件环境(如iOS)能够实现代码热更新。
ILRuntime项目的原理实际上就是先用VS把需要热更新的C#代码封装成DLL(动态链接库)文件,然后通过Mono.Cecil库读取DLL信息并得到对应的IL中间代码(IL是.NET平台上的C#、F#等高级语言编译后产生的中间代码,IL的具体形式为.NET平台编译后得到的.dll动态链接库文件或.exe可执行文件),最后再用内置的IL解译执行虚拟机来执行DLL文件中的IL代码。
由于ILRuntime项目是使用C#来完成热更新,因此很多时候会用到反射来实现某些功能。而反射是.NET平台在运行时获取类型(包括类、接口、结构体、委托和枚举等类型)信息的重要机制,即从对象外部获取内部的信息,包括字段、属性、方法、构造函数和特性等。我们可以使用反射动态获取类型的信息,并利用这些信息动态创建对应类型的对象。
ILRuntime中的反射有两种:
git地址:https://github.com/Tencent/puerts
puerts
解决方案: 内置一个JavaScript/TypeScript解释器,解释执行TypeScript代码。
官方地址:https://focus-creative-games.github.io/hybridclr/about/#%E6%96%87%E6%A1%A3
HybridCLR(代号wolong)
是一个特性完整、零成本、高性能、低内存的近乎完美的Unity全平台原生c#热更方案。
HybridCLR扩充了il2cpp的代码,使它由纯AOT (opens new window) runtime变成‘AOT+Interpreter’ 混合runtime,进而原生支持动态加载assembly,使得基于il2cpp backend打包的游戏不仅能在Android平台,也能在IOS、Consoles等限制了JIT的平台上高效地以AOT+interpreter混合模式执行。从底层彻底支持了热更新。
HybridCLR开创性地实现了 Differential Hybrid Execution(DHE) 差分混合执行技术。即可以对AOT dll任意增删改,会智能地让变化或者新增的类和函数以interpreter模式运行,但未改动的类和函数以AOT方式运行,让热更新的游戏逻辑的运行性能基本达到原生AOT的水平。
个人觉得HyBridCLR最大的优点就是对Unity开发者们非常友好,在使用前搭建好各种配置之后,热更新方面的操作就不需要我们下功夫了,按照之前的开发正常进行就好,只要更换对应的dll文件就可以自动实现热更新功能,恐怖如斯~
后续会详细介绍下HybridCLR,并按照文档做一些案例用于学习使用HybridCLR进行热更新。