标签：公测 运行 传统 静态 加载 工作流 了解 感受 修复
热更新的内容可以是美术资源，可以是代码，但相对来说，美术资源的更新不会受到约束，代码实际上是重灾区，本文介绍的主要是代码热更新。
热更新对于开发者来说是一件麻烦事，特别对于看重效率，便捷性和结构的程序员来说，热更新就是运营人员的不懂技术的表现。
然而，对于上线才是刚刚开始的网络游戏，特别是手游来说，热更新是极为重要的基础功能。
为什么要热更新
客户端
1、适应上线需求
对于手游客户端来说，受到苹果审核的约束， 一次审核提交需要10~20天不等的等待时间。而这段时间，开发进度依然会推进很多。
一旦手游上线，第一个版本在玩家疯狂行为下，出点问题是必然的，所以”上线更”就成了家常便饭。如果你要说，必须大包，无法热更。那么10~20多天后，游戏估计就没啥人了。 更别说渠道，发行投入巨大资金进行推广之下让玩家迎来的一堆bug的版本以及所谓程序员的傲慢和清高。
2、热调试，热开发，热发布
除了线上问题之外，由于Unity3D为了适应64位应用需求，将C#编译出的IL代码利用il2cpp第三方库编译成为c++。效率提升了倒是好，但工程编译和发布时间变得相当感人，没个1~2个小时完全搞不定。即便加装ssd，为了修改一个bug，也不知道要等多少根烟的时间...
只要核心功能不变化的情况下，完全可以让热更新成为开发期间的好工具，lua代码修改后，马上可以在手机上看效果，没有编译，发布的时间损耗，其实反而提升了开发效率。
服务器
对于服务器来说，常见游戏类型的玩家一般在半夜的在线人数会急速下降。但是对于比较热门的MMO，以沟通为基础的游戏，半夜也会有很多人在线，因此传统的停服更新对于玩家的热情秒杀很大的。想想看《守望先锋》公测停15天各位是什么感受？所以为了玩家体验，同时保证服务器稳定的前提下，修复一些轻微bug，用热更新再合适不过了。所以老服务器程序员，千万不能以服务器稳定为借口而忽略了玩家体验。技术是用来解决问题的，不是用来装X的。
怎么热更新
以下是Unity3D的几种热更新方式：
基于C#, 使用动态加载Assembly反射更新代码
这种方式在安卓上完全可行，对现有架构无需大的修改，一样使用C#和Unity3D的方式进行开发。但在iOS上受到限制，因此对于全平台首发的游戏，或者双平台都要上的游戏，已经慢慢的不使用这种方法进行热更新了。
基于Lua，将Lua代码视为资源，动态加载并运行
云风团队早期研究出的UniLua是基于C#编写的Lua虚拟机来运行， 而且只支持字节码解释，因此无法做动态功能，效率奇低。后期，ulua的出现，彻底将Lua作为比较正统的更新方式存在。ulua基于Tolua库进行封装，添加了一些便捷封装，代码打包和基本的框架。
ToLua本身是一个基于C版Lua上扩充的库，以静态链接库方式与Unity3D代码链接。因此，可以说ToLua是跑在C层上，速度不亚于C++和Lua的组合。基于Lua的代码更新方式，无论跨任何平台都可以以同一套代码和工作流进行，因此避免很多麻烦，成为现在主流的开发方式。
游戏逻辑全都用Lua写么？
做过网页和手机App的童鞋都发现，js，一个bug超多，设计奇怪的语言居然成为主流界面开发语言，为啥？
动态特性适合制作ui。
另外一个反例就是：使用C++开发界面，例如Qt, MFC之类，虽然设计严谨，但是最终挡不住各种奇葩的修改需求。
因此，界面非常推荐使用动态语言来开发，游戏界就是用Lua。而游戏核心，根据各自游戏类型来定，总的一点，效率瓶颈点，Update之类的，尽量使用C#或者C++来实现。
写在最后
当前中国大环境下的玩家和各种氪金理由与纯的不能再纯的游戏人的基本愿望是冲突的。然而国外游戏的各种设计和机制，暴雪战网更新不及时，版本不对没提示，这些基本错误在中国的网游都不会出现的。
技术上无法赶英超美的我们，在体验上已经输出了我们的价值观，老外们都在学。对于程序员来说，只是多贴近玩家，多了解外面的世界而已。
标签：公测 运行 传统 静态 加载 工作流 了解 感受 修复
原文地址：http://www.cnblogs.com/AaronBlogs/p/6953520.html
