另类Unity热更新大法代码注入式补丁热更新.docxVIP

另类Unity热更新大法：代码注入式补丁热更新眼看Unity引擎热火朝天，无数程序猿加入到了Unity开发的大本营。 一些老项目，当时ulua/slua还不如今天那样的成熟，因此他们选择了全c＃开发；也有一些出于性能考虑，全c#开发；也有一些没有太丰富运营经验的开发团队，没有想太多，用全c#爽爽地开发。用C#开发爽爽的日子一天一天的过去了，直到突然有一天，策划老大说：“我们得做个热更新模块！”；突然有一天，老板说：“别人游戏用Lua热更 新，为什么我们不行？”；突然有一天，运营说：“线上游戏出了个bug，重新编译出包审核得几天啊！”——嗯，这时候，受伤的总是程序猿。有没有亡羊补牢，临危受命的折衷方法？可以不用把C#改成Lua，可以不用区分平台（AndroidDLL重载IOS却不行），可以对任何代码做修复的方法？有的，并且用很笨的一句代码来概括：class Fucker {void Fucking() {if (PatchScript.HasPatchScript(Fucker.Fucking)) {// do patch fuck PatchScript.CallPatchScript(Fucker.Fucking);return; }// do origin fuck Log.Info(I am a original fuck); }}往所有的函数注入代码，当存在补丁脚本时执行补丁脚本，不存在时执行原代码。因此，本文的热更新等同于打补丁。什么是热更新？吐槽一点，虽然我们这个方法确实将热更新做成模块了，但这绝对是迫不得已的。 热更新绝对不是一个功能模块能实现，它是一个底层架构所决定的。要说一个项目不好，无法实现热更新，这归根到底是架构没想好、策划没坚持、程序没执着、运营懒得管等等各种各样复杂原因所导致的。我心目中理想热更新是怎样？要热！：对任意部位的代码进行修改；运行时，自动下载更新代码，尔后无需重启；运行时，立即重载代码，并继续运行；兼顾开发环境与生产环境的简便性；热更新在Web开发领域非常普遍，毕竟HTTP是无状态的；而游戏这种高实时性的开发相比，要想做好热更新就确实需要架构层的更多考虑了。怎么做好热更新，我们还是回到主题，接下来介绍方法，可以达到什么目的：对任意部位的方法体代码进行修改；运行时，立即重载代码，并继续运行语言无关：同样的思路可以应用在Java、C#、Go、C++等等使用起来不太方便亡羊补牢专用代码注入补丁热更新大法流程上面说了很多废话。接下直奔主题，要怎样做到：class Fucker {void Fucking() {if (PatchScript.HasPatchScript(Fucker.Fucking)) {// do patch fuck PatchScript.CallPatchScript(Fucker.Fucking);return; }// do origin fuck Log.Info(I am a original fuck); }}我们要针对Fucker类的Fucking方法进行更新，则新建Lua脚本Fucker.Fucking.lua-- 文件名Fucker.Fucking.luafunction Func()print(I am a patch fuck!)endreturn Func一个补丁脚本就此完成，当程序运行到Fucking函数时，实际上它执行的是Lua脚本，变相的实现了热更新的功能——改变代码的执行行为。STEP 1：执行环境本文针对Unity游戏开发，那么原语言，当然是C#了；而打补丁的语言，当时Lua了；在这里我们使用SLua插件，它的高质量代码和强大的反射功能，非常适合代码注入补丁热更新。classPatchScript{public bool HasPatchScript(string path){return File.Exists(Script/ + path + .lua); }public void CallScript(string path){string scriptCode = File.ReadAllString(path);var luaFunc = this.luaState.doScript(scriptCode) as LuaFunction; luaFunc.call(); }}STEP 2：代码注入嗯，执行环境，非常的简单，不就是简单的if判断吗？ 估计最令人迷惑的部分就是，如何往所有的C#函数体前部分插入代码了。我们要做的，遍历所有的c#文件，取得class类名，然后再分析函数名，定位函数在代码