文章讲述了JIT（Just-in-time）和AOT（AheadOfTime）两种编译方式的原理和应用场景，指出静态编译如C++适用于AOT，而动态编译如JavaScript适合JIT。文章还讨论了Unity中C#的热更新问题，由于苹果对反射机制的限制，C#在iOS上的热更新变得复杂，相比之下，Lua由于其解释型语言的特性更适合热更新。解决方案包括使用ILRuntime项目实现在iOS上的C#代码热更新。
JIT与AOT
一般程序运行有两种方式，静态编译与动态编译。
AOT: Ahead Of Time,预先（静态）编译
静态编译的程序，需要在执行之前全部翻译为机器码，运行前会使得程序安装时间相对较长，但程序运行的时候，性能和启动时间将会得到显著的优化，这种类型称为“AOT”——提前编译。一般是用C/C++ 开发的应用。
JIT : Just-in-time,动态（即时）编译
边解释边运行，可以根据当前硬件情况实时编译生成最优机器指令，也可以根据当前程序的运行情况生成最优的机器指令序列，但有时候会占用运行的资源，同时编译时间也会增加运行的时间，导致进程卡顿。一般是用 JavaScript 和 Python 的应用等。
所有脚本语言都支持 JIT 模式。但需要注意的是 JIT 和 AOT 指的是程序运行方式，和编程语言并非强关联的，有些语言既可以以 JIT 方式运行也可以以 AOT 方式运行，如 Java、Python。
它们可以在第一次执行时编译成中间字节码、然后在之后执行时可以直接执行字节码，中间字节码并非机器码，在程序执行时仍然需要动态将字节码转为机器码，不过通常我们区分是否为 AOT 的标准就是看代码在执行之前是否需要编译，只要需要编译，无论其编译产物是字节码还是机器码，都属于 AOT。
JIT 与热更新
为什么使用 Lua 作为热更新语言，不用 C#
热更新本身对于资源热更新是非常容易的，Unity 自带的 AB 包就可以轻松解决，难的是代码热更新，因为 Unity 中的 C#是编译型语言， Unity 在打包后，会将 C#编译成一种中间代码，再由 Mono 虚拟机编译成汇编代码供各个平台执行，它打包以后就变成了二进制了，会跟着程序同时启动，就无法进行任何修改了。
LUA 是解释型语言，并不需要事先编译成块，而是运行时动态解释执行的。这样 LUA 就和普通的游戏资源如图片，文本没有区别，因此可以在运行时直接从 WEB 服务器上下载到持久化目录并被其它LUA 文件调用。
不用 C#热更的原因
准确的说，C#在安卓上可以实现热更新，但在苹果上却不能。那 C#为什么不做成解释型语言呢？因为 C#的定位是一个追求效率且功能强大的编译型语言。在安卓上可以通过 C#的语言特性-反射机制实现动态代码加载从而实现热更新。
具体做法是：将需要频繁更改的逻辑部分独立出来做成 DLL，在主模块调用这些 DLL，主模块代码是不修改的，只有作为业务（逻辑）模块的 DLL 部分需要修改。游戏运行时通过反射机制加载这些 DLL 就实现了热更新。
但苹果对反射机制有限制，不能实现这样的热更。为什么限制反射机制？安全起见，不能给程序太强的能力，因为反射机制实在太过强大，会给系统带来安全隐患。
解决：C#热更新
lLRuntime 项目为基于 C#的平台(例如 Unity)提供了一个纯以实现， 快速、防便且可靠的 IL 运行时，使得能够在不支持 JIT 的硬件环境(如iOS)能够实现代码的热更新。
编译原理：它把代码分为两个 dll 文件，启动的时候只启动一个，另一个 dll 通过反射启动，在没启动第二个热更的 dll，将第一个 dll 文件替换掉。来达到一个热更的效果。
关于JIT
mono 的 JIT 编译器目录 mini 下的 mini.c 文件
设定 mono 的编译模式为 full-aot（比如打 IOS 安装包的时候），则在运行时试图使用 JIT 编译时，mono 自身的 JIT 编译器就会禁止这种行为进而报告这个异常。JIT 编译的过程根本还没开始，就被自己扼杀了。
学习链接：https://www.cnblogs.com/murongxiaopifu/p/4278947.html
扫一扫
2405
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
