ILRuntime的使用建议

影响热更执行效率的因素

1.热更DLL的编译模式，用Debug的模式编译会比Release编译慢数倍。
2.编辑器内执行比打包出来执行慢10倍左右。
3.使用Development Build打包会慢数倍。
4.IL2CPP编译的C++编译选项Release以外选项也会导致运行慢很多倍。
5.没有正确使用CLR绑定会让执行速度慢数十倍。
6.没有注册值类型绑定的情况下大量使用值类型会导致GC Alloc大量增加。
7.使用foreach由于会频繁创建值类型导致性能开销较大。
8.主工程调用热更工程开销>热更调用主工程。
9.解译<<<<<<原生，合理规划。

如何定位热更性能问题

1.Profiler!!
2.ILRuntime已加入Profiler支持。
3.由于懒加载，方法在第一次执行时会有额外开销，可通过预热解决。
4.编辑器中每次调用20字节的额外GC Alloc，定义DISABLE_ILRUNTIME_DEBUG宏可避免，但将失去断点调试+行号报告。

如何排查热更中的GC Alloc异常

1.Profiler!!
2.确定在非热更环境，相同做法的开销。
3.在正常情况下，热更与非热更会产生GC Alloc的情况应该一致。
4.CLR绑定是否正确以及注册成功。
5.对应的值类型绑定是否已注册。
6.编辑器下需禁用调试支持才能准确获取GC Alloc量。
7.调用热更工程应尽量使用appdomain.BeginInvoke。

如何达到最佳的性能

1.做好规划，想好哪些部分热更哪些不热更。
2.“所有代码均可热更”是一刀切懒政，且不可实现的伪命题。
3.消耗较大的独立算法，应作为工具方法写在主工程拱热更使用。
4.抓大放小，重点关注Update逻辑，频繁调用的逻辑。
5.使用ILRutime2.0新加入的寄存器模式优化计算密集的性能热点。
6.每次出包都要使用CLR自动分析绑定，确保所有已用到的方法均已绑定。
7.在非Development Build真机包上验证最终性能。
8.如需一段时间尽可能保持流畅性，可提前预热逻辑，做好缓存。

如何使用ILRuntime的寄存器模式

1.ILRuntime2.0以上加入。
2.大幅提升数值运算性能，优化频繁调用小方法的开销。
3.通过AppDomain构造函数指定运行模式。
-1.None（关机寄存器模式）
-2.JITOnDemand（按需编译）
-3.JITImmediately（立即编译）
4.可通过[ILRuntimeJIT(ILRuntimeJITFlags.JITImmediately)]对方法或一个类型下的所有方法进行模式重载。

寄存器模式的补充说明

1.绝大多数情况可直接使用JITOnDemand模式。
2.如方法内无数值计算，也没频繁调用热更内小方法，而以调用主工程方法为主，寄存器模式无法对其进行优化，甚至有可能比常规模式慢。
3.对方法或类型重载进行模式时可选项比初始化AppDomain是多
-1.NoJIT(指定该方法或该类型永不使用寄存器模式)
-2.ForceInline(指定该方法无论大小，在调用时都应被内联)

内存占用方面的优化

1.编辑器和真机Mono内存占用相差数倍，在真机上看
2.ILRuntime基础类型长度均为12字节，配置表全量读入内存会大量占用内存。
3.可使用Sqlite存储配置随用随取，仅缓存用到的数据。
4.尽量利用IL2CPP的剪裁功能缩小可执行文件尺寸。