[Unity3D]Unity3D游戏开发之Lua与游戏的不解之缘终结篇：UniLua热更新完全解读

版权声明：本文采用国际知识共享“署名-非商业使用-禁止演绎”协议4.0进行授权许可。转载请注明作者姓名和文章出处。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

喜欢我的博客请记住我的名字：秦元培，我的博客地址是blog.csdn.net/qinyuanpei。

转载请注明出处，本文作者：秦元培， 本文出处：http://blog.csdn.net/qinyuanpei/article/details/40213439

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

大家好，我是秦元培，欢迎大家关注我的博客，我的博客地址是blog.csdn.net/qinyuanpei。在之前的三篇系列文章《Unity3D游戏开发之Lua与游戏的不解之缘》中，博主带领大家一起领略了Lua在游戏开发中强大而迷人的作用，通过UniLua这个开源项目我们将Lua引入了Unity3D的世界，并且在此基础上我们写出了Lua'与Unity3D交互的第一个示例程序。今天呢，我们来说说Unity3D配合AssetBundle和;Lua实现热更新。

首先，我们来了解一下什么是热更新吧！所谓热更新是指在不停机的状态下对系统进行更改，例如我们的Windows可以在不重启的状态下完成补丁的更新、Web服务器在 不重启的前提下完成对数据和文件的替换等都是热更新的经典实例。那么对于Unity3D而言，什么是热更新呢？如果我们最终发布的Unity3D游戏是一个Web游戏，那么每次游戏加载的过程中实现对资源代码的更新就是热更新。如果我们最终发布的Unity3D游戏是一个客户端游戏，那么我们在重重启客户端以后实现对资源代码的更新就是热更新。为什么这么说呢？因为Web游戏需要保证玩家能够及时快速地进入游戏，因此在游戏加载完之前，我们必须完成对游戏资源和代码的更新。可是对于客户端游戏而言，玩家可以在等待本次更新结束后再进入游戏，而且大部分的客户端程序在更新完后都会要求玩家重启客户端，所以对于客户端游戏而言，热更新并非是严格意义上的热更新。那么，我们为什么要进行热更新呢？答案是为了缩短用户获取新版本客户端的流程、改进用户体验。这其实就是博主在前文中提到的传统单机游戏依靠光盘载体进行发售所面临的问题，玩家为了获取最新版本的游戏，需要下载全新的客户端并将它安装到计算机或者手机设备上。在互联网产品开发中有一种称为快速迭代的理念，试想如果我们每次对客户端进行局部的调整，就需要玩家去下载新版本的客户端，试问这样的用户体验真得能让用户满意吗？所以现在为了方便用户、留住用户、进而从留住的用户身上赚到钱，我们总能在游戏产品中找到热更新的影子。我们知道在Unity3D中可以通过AssetBundle来实现对游戏中资源的更新，在http://blog.csdn.net/janeky/article/details/17666409这篇文章中作者janeky已经给出了较为完美地解决方案，因为博主使用的Unity3D免费版无法使用AssetBundle的功能，而博主本人不愿意使用破解版，因为这是一个程序员的良心，所以本文更多的是从代码更新的这个角度来讲Unity3D的热更新，对于资源的热更新大家建议大家还是去看janeky的这篇文章吧。好了，下面正式开始Unity3D代码级的热更新之旅！

在Unity官方的API中官方给出了一种基于反射的思路，即将C#脚本存储为文本文件，然后将其转化为byte字节，再通过反射技术取得该类型及其方法。理论上这样当然没有问题，可是我们知道由于IOS是一个封闭的系统，设计者出于安全的考虑不允许在该平台下使用反射技术。那么问题来了，反射并不是一个完美地解决方案。关于反射技术实现Unity3D的热更新，大家可以参考这篇文章：http://blog.csdn.net/janeky/article/details/25923151。好了，下面我们来说说博主是如何通过Lua实现Unity3D的热更新的吧。我们知道在Lua提供的C#接口中有一个DoString()的方法，该方法可以直接利用Lua虚拟机执行字符串中的脚本。所以，我们可以通过在本地读取Lua脚本来执行脚本中的命令，如果我们脚本中的命令可以直接对Unity3D进行操作，那么我们就可以通过Lua脚本来更新游戏中的代码逻辑。那么，我们怎么能让Lua脚本操作Unity3D呢？在前一篇文章中，我们介绍了一种Require的方法，该方法可以将C#库引入到Lua脚本中并通过Lua来执行C#库中的方法。顺着这样的思路，博主便有了下面的设想：

在这个设想中，我们首先需要将Unity API封装成一个C#类库，在这个类库中我们将会涉及动态加载场景和动态创建场景，因为我们更新游戏的逻辑的时候将会用到这些方法。这些方法通过封装后我们便可以在Lua脚本通过Require方式来引用，进而我们就可以通过Lua脚本来动态地进行设计。我们设计一个固定的位置来存储Lua脚本更新文件，这样我们只需要对比本地版本和服务器版本是否相同就可以知道我们是否需要更新。这里我们通过WWW来从远程服务器上下载最新的Lua脚本更新文件，下载下来的Lua脚本处于项目外部，我们无法使用Resource.Load()这样的方法来加载，可是我们可以通过WWW来加载一个本地文件，这样我们就实现了Lua脚本文件的更新。当然，我们可以使用AssetBundle来更新Lua脚本文件，可是博主的免费版不支持AssetBundle，所以博主想出了这样一个曲线救国的方法。当Lua脚本文件更新后，我们就可以在游戏主逻辑里通过DoString()方法来执行脚本文件中的代码。在游戏主逻辑里主要的任务是比较当前版本号和服务器版本号来判断是否需要更新，如果需要更新就下载Lua脚本更新文件然后执行脚本中的代码，这样我们就实现了客户端程序的更新。好了，下面我们继续以前一篇文章中的项目为例来将博主的这个设想变成现实。

首先，我们在CSharpLib.cs这个类中增加下面两个方法并完成方法的注册：

好了，这样我们就完成了一个简单的C#类库，下面我们来在主逻辑代码中增加一个更新脚本的方法UpdateScripts():

这里的代码逻辑很简单，就是读取脚本更新本地文件然后执行脚本，其中mUpdateFilePath是脚本更新文件路径：

这里博主设想的是在本地存储一个版本号，每次更新前先获取服务器端的版本号，如果两个版本号不同则需要从服务器上下载更新脚本文件进行更新。不过博主这里没有想到什么好方法来获取版本号，所以这里就只写了更新。那么，我们来看看更新脚本文件都做了哪些事情吧！

首先我们通过Require引入了CSharpLib.cs 这个类库，接下来，我们将场景中名称为Cube的物体的位置设为(2,1,0)、 利用本地的两个Prefab资源创建了一个Cube和一个Sphere。那么，我们的设想能不能实现呢？我们一起来看最终效果吧！

执行Lua脚本更新前：

执行Lua脚本更新后：

如我们所愿，Lua脚本成功地对场景实现了一次更新。可能有的朋友会问，这里用的是本地资源，如果我想用服务器上的资源怎么办呢？答案是博主最不愿意提及的AssetBundle，即利用AssetBundle加载远程资源，然后用Lua实现更新，这些逻辑可以添加到CSharpLib这个类库中。大家可以设想一下，如果有一天我们能够将Unity的所有方法都封装起来，那么我们就可以直接用Lua来创建场景了，如果要更新客户端，只要更换Lua文件就可以了，怎么样是不是很简单呢？可是Unity不开源啊，这些想法终究只是想法啦。好了，今天的内容就是这样了，欢迎大家关注我的博客，谢谢大家！