📄️ 支持的Unity版本和平台
HybridCLR已经稳定支持了2019.4.x、2020.3.x、2021.3.x、2022.3.x 系列LTS版本及2023.2.x、6000.x.y等测试版本，并且支持所有il2cpp支持的平台。
📄️ 安装
安装兼容的Unity版本
📄️ 配置
安装完com.code-philosophy.hybridclr包后，需要正确设置相关参数。配置相关详细文档可见 hybridclr_unity包介绍。
📄️ 配置程序集
一般来说，必须将热更新代码独立为assembly，才能方便地进行热更新。
📄️ 加载和运行
加载更新assembly
📄️ 打包工作流
由于热更新本身的要求以及Unity资源管理的一些限制，对打包工作流需要一些特殊处理，主要分为几部分：
📄️ 发布WebGL平台
由于WebGL平台有较多特殊性，故特地单独文档介绍如何发布WebGL平台。本文档在 hybridclrtrial项目（github gitee ）上演示发布过程。
📄️ 代码裁剪
Unity使用了代码裁剪技术来帮助减少il2cpp backend的包体大小。如果未做防裁剪处理，由于AOT主工程里的代码一般不多，大量的C#类型和函数被
📄️ MonoBehaviour支持
HybridCLR完全支持热更新MonoBehaviour和ScriptableObject工作流，即可以在代码里在GameObject上Add热更新脚本或者在资源上直接挂载
📄️ PInvoke支持
在v8.0.0版本之前在热更新代码中定义了extern函数，并且试图调用它时，会抛出ExecutionEngineException:method body is null的错误。
📄️ MonoPInvokeCallback支持
当与lua之类的第三方语言交互时，需要从这些第三方语言调用C#函数。必须解决两个问题：
📄️ AOT泛型
CLR中有两类泛型特性：泛型类型和泛型函数。泛型是c#中使用极其广泛的特性，即使一个没有明显包含泛型的用法，也可能隐含了泛型相关的定义或者操作。
📄️ 桥接函数
HybridCLR的interpreter与AOT之间需要双向函数调用。比如interpreter调用AOT函数，或者AOT通过interface接口或者delegate回调interpreter。
📄️ DOTS支持
DOTS的TypeManager初始化时机过早，而且不支持动态注册Component和System等类型。为了让热更新模块能在DOTS系统中正常
📄️ 代码混淆
如果没有对热更新代码进行混淆，经过ILSpy之类的反编译工具，可以轻易还原近乎源码的C#代码，这对商业游戏项目和独游开发的知识产权和代码安全产生严重威胁。
📄️ 内存与GC
HybridCLR运行时消耗内存主要分为几部分：
📄️ 执行性能
虽然HybridCLR也是解释执行，但无论从理论原理还是真机测试数据表明，HybridCLR相比当前流行的lua、ILRuntime之类的热更新方案，性能有极大的提升(数倍甚至数十倍)。
📄️ 对App包体影响
接入hybridclr后对包体影响主要由以下几部分构成：
📄️ 对App内存影响
接入hybridclr后对App运行时内存的影响主要由以下几部分构成：
📄️ 不支持的特性
不在限制事项中的特性HybridCLR都支持，请不要再问HybridCLR是否支持某个功能。
📄️ hybridclr Package手册
com.code-philosophy.hybridclr是一个Unity package，它提供了HybridCLR所需的Editor工作流工具脚本及Runtime脚本。借助
📄️ 最佳实践
Assembly.Load之后不要保存 assemblyBytes
📄️ 从netstandard迁移到.Net Framework
Unity在打包过程中，会把对netstandard.dll的引用全部转换最终的mscorlib.dll之类的引用，导致原始代码
📄️ HybridCLR+lua/js/python
有一些项目已经上线，它们的大多数代码已经用lua实现了；或者一些新项目已经用lua开发到一半，他们无法完全切换为全C#开发，但希望
📄️ 代码结构及版本
完整的HybridCLR代码由三个仓库构成：
📄️ HybridCLR源码结构及调试
HybridCLR模块介绍
📄️ il2cpp bug记录
逆变协变泛型接口调用错误