在上一篇文档中提到了unity的c#代码运行的方式以及可以通过拆分代码模块，将可能需要更新扩展的逻辑放到一个独立的.dll中，通过更新这个.dll文件来实现热更新。
但是这种朴素的想法在ios平台会受到限制。
这篇文档就来着重讲一下ios到底是怎么限制这种更新方式的，以及ILRuntime是如何绕过限制来实现通过.dll做代码热更新的。
前面提到c#编译出来的.dll文件不是“老古董”的windows下的动态链接库，而是中间语言（CIL）的程序集（assemblly）。对unity来说这些CIL是通过mono虚拟机来运行的，而mono又是如何运转的呢？
我们知道程序运行通常有三种方式：
-
静态编译（C/C++)
-
动态解释（原生的lua）
-
动态编译（可以简单理解为对某些热点代码进行编译，进而优化解释执行的过程）
在mono虚拟机中使用了一种叫Jit（Just In Time）的动态编译技术来优化它的虚拟机的执行。还有一种对Jit的理解是：一个程序在它运行的时候创建并且运行了全新的代码，而并非那些最初作为这个程序的一部分保存在硬盘上的固有的代码, 就叫Jit
它有几个要点：
-
程序需要运行
-
生成的代码是新的代码，并非作为原始程序的一部分被存在磁盘上的那些代码
-
不光生成代码，还要运行
我们再来看一下ios平台到底限制了什么。关于ios热更的限制，又很多中说法，比如：
-
ios禁止动态加载dll
-
ios平台禁止JIT编译
-
ios禁止了内存的可执行权限
根据一些大佬的实践考证，ios并非把JIT禁止了,而是封了内存的可执行权限。但是对于Jit来说，要动态生成代码并且执行，则需要在运行是动态分配内存来存放生成的代码，并通过这块内存来执行对于的代码逻辑。内存没有可执行权限，相当于变相的封锁了JIT这种编译方式。
于是Mono在ios上需要Full AOT模式编译和运行。即预先对程序集中的所有IL代码进行AOT编译生成一个本地代码映像，然后在运行时直接加载这个映像而不再使用JIT引擎：
-
收集要被编译的方法
-
使用JIT进行编译
-
发射（Emitting）经JIT编译过的代码和其他信息
-
直接生成文件或者调用本地汇编器或连接器进行处理之后生成文件
所以单纯的用mono是无法动态加载.dll来实现热更新的。
我们再看下ILRuntime是怎么做的
ILRuntime自己实现了一套运行时，借助Mono.Cecil库来读取DLL的PE信息，以及当中类型的所有信息，最终得到方法的IL汇编码，然后通过内置的IL解译执行虚拟机来执行DLL中的代码。
demo中的关键部分代码如下
//创建ILRuntime运行时环境
AppDomain appdomain = **new** ILRuntime.Runtime.Enviorment.AppDomain();
//加载dll信息
appdomain.LoadAssembly(fs, p, **new** ILRuntime.Mono.Cecil.Pdb.PdbReaderProvider());
//调用dll中的方法
appdomain.Invoke("HotFix_Project.InstanceClass", "StaticFunTest", null, null);
并且ILRuntime实现了一套反射机制，可以让热更的dll和unity的主工程可以互相调用。
总结一下ILRuntime和基于lua的热更新，其实本质都是相通的：基于自我实现的虚拟机（lua的虚拟机或者IL虚拟机，均基于栈实现），来构建一个自我运行环境，在里面解析执行对于的指令（lua虚拟机的指令/IL语句），来实现对热更新的代码。而代码文件对工程来说来说，其实都只是资源文件。
相关参考文章
ILRuntime官方文档
http://ourpalm.github.io/ILRuntime/public/v1/guide/index.html
谁偷了我的热更新？Moon,Jit,IOS
https://www.cnblogs.com/murongxiaopifu/p/4278947.html
对C#热更新方案ILRuntime的探究
https://www.cnblogs.com/zblade/p/9041400.html
使用ILRuntime，你可能需要了解这些
https://blog.csdn.net/qiaokelz/article/details/109504276
网友评论