01-认知篇-总览-HybridCLR是什么

HybridCLR是什么

前言

在 Unity 游戏开发领域，热更新一直是一个无法回避的核心话题。对于一款上线后的移动游戏而言，能够在不重新发布 App Store 审核的情况下修复 Bug、更新内容、调整玩法逻辑，直接关系到产品的生命周期和运营效率。

长期以来，Unity 生态中的热更新方案主要依赖 Lua 脚本（如 xLua、ToLua、SLua）或纯 C# 解释器（如 ILRuntime）。这些方案虽然解决了"能不能热更新"的问题，但在性能、兼容性、开发体验和生态融合等方面存在诸多妥协。开发者需要在"热更新"和"原生体验"之间做出艰难抉择。

HybridCLR 的出现，从根本上改变了这一局面。

本文作为整个系列的总纲，将从宏观层面介绍 HybridCLR 是什么、它的核心特性、工作原理、支持平台、版本演进、适用场景以及它在 Unity 热更新技术图谱中的位置，为读者构建一个完整而清晰的认知框架。

一、HybridCLR 的定义

1.1 官方定义

HybridCLR 是一个特性完整、零成本、高性能、低内存的 Unity 全平台原生 C# 热更新解决方案。它扩充了 IL2CPP 运行时代码，使其由纯 AOT（Ahead-of-Time）运行时改造为 "AOT + Interpreter" 混合运行时，从而原生支持动态加载程序集（Assembly），从底层彻底支持了热更新。

这段话包含了几个关键信息：

特性完整：近乎完整实现了 ECMA-335 规范，只有极少量不支持的特性。这意味着你可以用 C# 的所有主流语法特性书写热更新代码，包括泛型、反射、多线程、async/await 等。
零成本：开发者不需要学习新的编程语言或框架，不需要额外的代码生成步骤，不需要修改原有的开发习惯。接入 HybridCLR 后，热更新代码与 AOT 代码的编写方式完全一致。
高性能：HybridCLR 实现了一个极其高效的寄存器解释器，性能远超 ILRuntime、xLua 等传统方案。
低内存：热更新脚本中定义的类与普通 C# 类占用一样的内存空间，不存在传统方案中的桥接对象、代理对象等额外内存开销。
原生支持：HybridCLR 修改的是 IL2CPP 运行时本身，而非在 IL2CPP 之上叠一层额外解释器。这意味着热更新代码与 AOT 代码在运行时的交互是原生的、无缝的。

1.2 核心价值主张

HybridCLR 的核心价值可以用一句话概括：用写原生 C# 代码的方式写热更新代码，获得与原生几乎一致的性能。

具体来说：

维度	传统方案	HybridCLR
编程语言	Lua / 受限 C#	完整 C#
学习成本	需学新语言 / 框架	零学习成本
性能	解释执行，数倍至数十倍差距	接近原生 AOT
内存	桥接对象、代理对象额外开销	与原生一致
泛型	不支持或受限	完整支持
多线程	不支持	完整支持
DOTS/ECS	不支持	完整支持
MonoBehaviour	无法直接挂载	完整支持

1.3 工作原理

在深入了解特性之前，有必要先理解 HybridCLR 的核心工作原理。

HybridCLR 的核心思想来自 Mono 的混合执行模式（Mixed Mode Execution）技术。它将 IL2CPP 这个纯 AOT 运行时改造为 "AOT + Interpreter" 混合运行时。具体来说，HybridCLR 做了以下几件关键的事情：

实现了一个高效的元数据（DLL）解析库：当热更新 DLL 被加载时，这个解析库负责读取和解析 DLL 中的元数据信息，包括类型定义、方法定义、字段定义、属性定义、自定义特性等。这些元数据信息被注册到 IL2CPP 的运行时元数据系统中，使得热更新代码中定义的类型对运行时"可见"。
改造了元数据管理模块：IL2CPP 的原始元数据管理模块只支持在编译时静态注册的元数据。HybridCLR 改造了它，使其支持运行时的动态元数据注册。
实现了一个 IL 指令集到自定义寄存器指令集的编译器：当热更新代码中的方法第一次被调用时，这个编译器将 IL 字节码编译为 HybridCLR 自定义的寄存器指令集。这种自定义指令集比原始的栈式 IL 指令集更高效，因为寄存器指令可以减少内存访问次数。
实现了一个高效的寄存器解释器：这个解释器执行由编译器生成的寄存器指令。它是 HybridCLR 性能的核心------官方数据显示，这个解释器的性能远优于 ILRuntime 等纯 C# 实现的解释器。
提供了大量的 intrinsic 函数：对于一些常见的性能敏感操作（如数组访问、字符串操作、数学运算等），HybridCLR 提供了 intrinsic 函数，直接调用底层硬件指令，进一步提升了解释性能。

1.4 与 IL2CPP 的关系

理解 HybridCLR，首先需要理解 IL2CPP。

IL2CPP 是 Unity 提供的一个 AOT 编译后端，它将 C# 编译生成的 IL（Intermediate Language）中间代码转换为 C++ 代码，然后通过原生编译器（如 clang、MSVC）编译为机器码。IL2CPP 的主要优势包括：

性能优异：最终生成的是原生机器码，没有运行时编译开销。
平台兼容性好：通过 C++ 中间层，可以支持几乎所有平台。
安全性高：没有 JIT 编译，符合苹果 iOS 平台的审核要求。

但 IL2CPP 也有一个根本性的局限：它是纯 AOT 的，不支持运行时加载和执行新的 C# 代码 。这意味着你无法在 IL2CPP 模式下像在 Editor 或 Mono 模式下那样，通过 Assembly.Load 动态加载一个 DLL 并执行其中的代码。

HybridCLR 的解决方案是：不绕过 IL2CPP，而是增强 IL2CPP。它在 IL2CPP 运行时中注入了 Interpreter（解释器）模块，使得 IL2CPP 在保持原有 AOT 能力的同时，新增了动态加载和执行 IL 代码的能力。

这种设计带来了一个重要的优势：AOT 代码仍然以原生方式运行，性能无损；只有热更新代码走解释器路径。而且，通过 DHE（Differential Hybrid Execution）技术，未被修改的函数在热更新后仍然以 AOT 方式运行，只在首次变更或新增的函数走解释器路径，进一步缩小了性能损耗的范围。

下图展示了 HybridCLR 中代码执行的完整链路：

复制代码

热更新代码 (C#) → IL 字节码 → HybridCLR 编译器 → 自定义寄存器指令 → 寄存器解释器 → 执行
                                                    ↑
AOT 代码 (C#) → IL 字节码 → IL2CPP 编译器 → C++ 代码 → 原生编译器 → 机器码 → 直接执行

可以看到，AOT 代码和热更新代码在进入运行时之前的编译链路是完全不同的。AOT 代码走 IL2CPP 的全编译链路，最终以机器码执行；热更新代码走 HybridCLR 的编译器 + 解释器链路，以寄存器指令的方式解释执行。两者的互调是通过 HybridCLR 提供的桥接机制完成的，开发者无需关心底层细节。

二、核心特性详解

2.1 近乎完整的 ECMA-335 规范支持

ECMA-335 是 CLI（Common Language Infrastructure）的国际标准，定义了 .NET 运行时的核心规范。HybridCLR 对这套规范的支持程度，直接决定了热更新代码能在多大程度上使用 C# 语言的特性。

HybridCLR 几乎完整实现了 ECMA-335 规范，支持的特性包括：

特性类别	具体支持	是否支持
类型系统	类、结构体、枚举、接口、委托	✅ 完整支持
继承	单继承、多接口实现	✅ 完整支持
泛型	泛型类、泛型方法、泛型接口、泛型约束	✅ 完整支持
反射	Type.GetType、MethodInfo.Invoke、Attribute	✅ 完整支持
多线程	Thread、Task、async/await、volatile、ThreadStatic	✅ 完整支持
异常处理	try/catch/finally/throw/filter	✅ 完整支持
委托与事件	Delegate、Event、Lambda、闭包	✅ 完整支持
不安全代码	unsafe、指针操作	✅ 完整支持
P/Invoke	DllImport、MonoPInvokeCallback	✅ 完整支持

不支持的特性极少，主要包括：

System.Reflection.Emit（运行时生成 IL 代码）
Marshal.GetFunctionPointerForDelegate 的部分场景

2.2 完整的 .NET 运行时支持

HybridCLR 不仅仅是一个"解释器"，它实际上提供了一个完整的 .NET 运行时环境。这意味着热更新代码可以：

使用 System.Linq：支持 LINQ 查询和 Lambda 表达式
使用 System.Threading.Tasks：支持 async/await 异步编程模型
使用 System.Collections.Generic：支持 List、Dictionary 等泛型集合
使用 System.Reflection：支持 Type.GetType、MethodInfo.Invoke、Attribute 操作等
使用 System.IO：支持文件读写操作
使用 System.Text.RegularExpressions：支持正则表达式

这在其他方案中是无法实现的。例如，ILRuntime 虽然也支持 C#，但在泛型、多线程等特性的支持上存在较多限制；xLua 使用 Lua 语言，其运行时与 .NET 运行时完全隔离，无法使用任何 .NET 标准库。

2.3 性能表现

HybridCLR 的官方性能测试报告显示，它在多个关键指标上大幅领先于其他热更新方案：

指标	HybridCLR	ILRuntime	xLua	说明
方法调用（解释器模式）	基准	3-5 倍慢	4-8 倍慢	空方法调用的开销对比
数组访问	基准	2-3 倍慢	-	连续数组元素的读写
数值计算	基准	3-4 倍慢	5-8 倍慢	浮点数运算循环
对象创建	基准	2-3 倍慢	3-5 倍慢	new 对象的性能
内存占用	基准	1.5-2 倍高	2-3 倍高	同等逻辑的内存消耗

性能优势的核心来自于 HybridCLR 的寄存器解释器设计。与传统的栈式解释器不同，寄存器解释器减少了大量的内存压栈/弹栈操作，指令密度更高，执行路径更短。此外，HybridCLR 的编译器在编译 IL 到寄存器指令的过程中，还会进行一些简单的优化，如常量折叠、死代码消除等。

2.4 DHE 差分混合执行

DHE（Differential Hybrid Execution）是 HybridCLR 商业版（旗舰版）的核心技术。它解决了传统热更新方案中的一个根本性矛盾：

热更新意味着代码需要被重新加载和执行。如果所有热更新代码都走解释器，性能必然下降。但如果只热更新很少的一部分代码（比如只有 1% 的代码变更），为什么 100% 的热更新代码都要承受性能损失？

DHE 的思路是：只解释执行发生了变更的函数，未变更的函数仍然以 AOT 方式运行。

具体实现如下：

差异检测：在打包时，DHE 编译器对比新版本和旧版本的 DLL，识别出哪些函数发生了变更（内容修改、新增、删除）。
增量编译：只对变更的函数生成解释器代码，未变更的函数保持 AOT 代码不变。
混合执行：运行时加载差分包，变更的函数走解释器路径，未变更的函数走 AOT 路径。

这种设计带来了显著的性能优势：在实际项目中，一次热更新通常只涉及 1%-5% 的代码变更，这意味着 95%-99% 的热更新代码仍然以原生 AOT 性能运行。

DHE 的工作流程可以概括为以下步骤：

步骤一：基准构建

在项目首次构建时，DHE 编译器会生成一个"基准快照"，记录每个函数的 IL 代码哈希值和对应的 AOT 编译结果。

步骤二：差异检测

当热更新 DLL 被构建时，DHE 编译器将新的 DLL 与基准快照进行逐函数对比。对于每个函数，计算其 IL 代码的哈希值，与基准快照中的哈希值进行比对。

步骤三：增量包生成

根据差异检测的结果，DHE 编译器只将有变更的函数编译为寄存器指令，打包到差分包中。未变更的函数不会出现在差分包中。

步骤四：运行时合并

在运行时，DHE 运行时加载差分包，将变更函数的寄存器指令注册到运行时中。当这些函数被调用时，走解释器路径；其余函数仍然通过 IL2CPP 的 AOT 路径执行。

DHE 的使用注意事项：

DHE 是商业版功能，需要购买授权
DHE 要求构建基准快照，增加了构建流程的复杂度
DHE 的最佳效果依赖于较小的变更比例（建议每次更新变更不超过 10% 的代码）

2.3 热重载（Hot Reload）

HybridCLR 支持 100% 卸载程序集的热重载能力。这意味着：

可以完全卸载旧的程序集，加载新的程序集
旧的类型定义被完全清除，新的类型定义生效
支持重复加载/卸载循环，不会产生内存泄漏

这在以下场景中尤为有用：

开发调试阶段：修改代码后无需重启游戏，节省大量迭代时间
线上运营阶段：支持多次热更新，每次热更新都是对旧程序集的完全替换
A/B 测试：可以快速切换不同版本的代码逻辑

2.4 零学习成本

这是 HybridCLR 最受开发者欢迎的特性之一。对比传统方案：

xLua：需要学习 Lua 语言、xLua 框架 API、Lua 与 C# 的桥接规则、热更新代码的编写限制。
ILRuntime：需要了解 ILRuntime 的运行机制、适配 C# 代码的限制、处理跨域继承等问题。
HybridCLR：不需要学习任何新东西。热更新代码就是用 C# 写的普通的 Unity 脚本。MonoBehaviour 可以直接挂载在 prefab 上，ScriptableObject 可以直接创建，泛型和反射可以直接使用。

这种"零学习成本"的特性，降低了一个团队接入热更新的门槛。对于项目管理者而言，这意味着更短的接入时间、更低的学习曲线、更小的质量风险。

2.5 完整的 Unity 工作流兼容

许多热更新方案在 Unity 编辑器中的工作流与发布后的工作流存在差异，导致开发阶段和发布阶段需要两套不同的测试流程。HybridCLR 在这方面做到了高度一致：

MonoBehaviour 支持：热更新脚本可以像普通脚本一样挂载在场景物体或 prefab 上，运行时可以正确实例化
ScriptableObject 支持：热更新中定义的 ScriptableObject 可以正常创建和序列化
DOTS/ECS 支持：HybridCLR 与 Unity DOTS 技术栈完全兼容
Profiler 支持：HybridCLR 提供了 Profiler 支持，可以在 Unity Profiler 中分析热更新代码的性能

三、技术架构概览

为了便于后续篇章的深入阅读，这里从宏观层面介绍 HybridCLR 的技术架构。

3.1 三层架构

HybridCLR 的整体架构可以分为三个层次：

复制代码

┌─────────────────────────────────────────────────────┐
│               Unity 包集成层                         │
│  com.code-philosophy.hybridclr                      │
│  编辑器工具、运行时初始化、打包配置                    │
├─────────────────────────────────────────────────────┤
│               il2cpp_plus 适配层                     │
│  Unity 版本适配、IL2CPP 内部 API 适配                │
├─────────────────────────────────────────────────────┤
│               hybridclr 核心运行时                    │
│  元数据模块 │ 编译器模块 │ 解释器模块 │ DHE 模块      │
└─────────────────────────────────────────────────────┘

3.2 三大仓库

HybridCLR 的核心代码分布在三个 GitHub 仓库中：

hybridclr：核心运行时，使用 C++ 编写，包含元数据解析、IL 编译器、寄存器解释器、DHE 等核心模块。这是 HybridCLR 的心脏。
il2cpp_plus：对 Unity 官方 IL2CPP 的 fork 和适配，使 IL2CPP 能够与 hybridclr 核心协同工作。不同 Unity 版本对应不同的分支。
com.code-philosophy.hybridclr：Unity Package 包，提供编辑器工具、运行时初始化脚本、构建配置 UI 等，是开发者与 HybridCLR 交互的主要界面。

3.3 核心的四个模块

hybridclr 的核心运行时由四个模块组成：

模块	功能	对应源码目录
元数据模块	解析和存储程序集的元数据信息	`hybridclr/metadata/`
编译器模块	将 IL 字节码编译为自定义寄存器指令	`hybridclr/compiler/`
解释器模块	执行自定义寄存器指令	`hybridclr/interpreter/`
DHE 模块	差分编译与混合执行	`hybridclr/codec/`

四、支持的版本与平台

4.1 Unity 版本支持

HybridCLR 支持以下 Unity 版本：

Unity 版本	支持状态	备注
2019.4.x LTS	✅ 支持	完整支持
2020.3.x LTS	✅ 支持	完整支持
2021.3.x LTS	✅ 支持	完整支持
2022.3.x LTS	✅ 支持	推荐版本
2023.2.x	✅ 支持	最新特性
6000.x.y	✅ 支持	最新 LTS

4.2 平台支持

HybridCLR 支持所有 IL2CPP 支持的目标平台：

平台	支持状态	备注
iOS	✅ 完整支持	完全通过苹果审核
Android (armv7/arm64)	✅ 完整支持	主流 Android 设备
Windows (x86/x64)	✅ 完整支持	PC 平台
macOS (Intel/Silicon)	✅ 完整支持	包含通用二进制
WebGL	✅ 完整支持	需要通过特定测试
PlayStation/Xbox/Switch	✅ 支持	主机平台
visionOS	✅ 支持	Apple Vision Pro
鸿蒙	✅ 支持	华为生态

五、版本演进历史

HybridCLR 的发展历史虽然只有短短几年，但演进速度令人瞩目。以下为关键里程碑：

时间	事件
2021.11	创建 HybridCLR QQ 主群
2022.01	发布 Preview 1 版本，支持对象定义、继承、虚函数调用
2022.03	正式开源，GitHub 公开代码
2022.05	首次在 Android 和 iOS 平台完整运行大型 RPG 卡牌项目
2022.07	更名为 HybridCLR（原名 huatuo），GitHub 星标突破 2000
2022.09	实现完整的 workflow 工具，一键打包
2022.11	进入 LTS 版本，稳定维护阶段
2023.02	DHE 最终版本完成
2023.05	发布 v3.0.0，正式支持 2022.3.0
2024.01	发布 v5.0.0，再次支持 2019
2024.06	发布 v6.0.0，正式支持 Unity 2023 和 6000

截至本文撰写时（2025 年 5 月），HybridCLR 的最新版本为 v8.8.0，GitHub 星标超过 6000，已被数千个商业游戏项目接入使用，其中数百款已在 iOS 和 Android 双端上线。

从版本演进的历史可以看出，HybridCLR 的发展呈现出几个明显的阶段：

技术验证期（2021.11 - 2022.03）：从项目启动到开源，主要完成核心功能的可行性验证，包括 IL 指令集解析、基础类型系统支持、异常处理等。
功能完善期（2022.03 - 2022.11）：开源后快速迭代，陆续完成了 Android/iOS/WebGL 的平台支持，实现了完整的 workflow 工具集，进入了 LTS 稳定阶段。
商业成熟期（2022.11 - 2023.05）：DHE 功能完成、企业版发布、多 Unity 版本全面支持，标志着产品进入商业化阶段。
生态扩展期（2023.05 - 至今）：持续跟进 Unity 最新版本，扩展平台支持（visionOS、鸿蒙等），社区生态快速壮大。

六、开发者的工作流变化

接入 HybridCLR 后，Unity 项目的开发工作流会发生一些重要的变化。理解这些变化，有助于团队更好地规划开发流程。

6.1 传统的 Unity 热更新工作流（以 xLua 为例）

复制代码

编写 Lua 热更新代码 → 打包 Lua 文件 → 上传资源服务器 → 客户端下载并执行
    │
    ├── 需要维护 Lua 与 C# 的桥接代码（Generate 代码）
    ├── Lua 代码无法获得 C# 编译时检查
    ├── Lua 调试工具链不完善
    └── Lua 代码与 C# 代码的交互需要编写额外的接口定义

6.2 HybridCLR 的工作流

复制代码

编写 C# 热更新代码（与 AOT 代码完全一致） → 编译为 DLL → 打包 → 客户端下载并加载
    │
    ├── 所有代码都是 C#，获得完整的编译时类型检查
    ├── 热更新代码可以使用 Visual Studio / Rider 等 IDE 的全部调试能力
    ├── 热更新代码与 AOT 代码共享同一套类型系统，无需桥接层
    └── 热更新脚本可以直接挂载到游戏对象和 prefab 上

6.3 工程结构变化

引入 HybridCLR 后，项目的工程结构通常需要做以下调整：

划分 AOT 程序集和热更新程序集：将游戏逻辑代码划分为两个部分------随包发布的 AOT 代码和可以热更新的代码。HybridCLR 推荐的做法是将热更新代码放在独立的 Assembly Definition 中。
配置 AOT 泛型引用：由于 IL2CPP 编译时不能预知热更新代码会使用哪些泛型实例化，需要在 AOT 侧预先声明可能用到的泛型实例。HybridCLR 提供了自动分析工具来生成这些配置。
调整打包流程：热更新 DLL 需要从 Unity 构建流程中提取出来，单独打包和上传。HybridCLR 提供了一键打包工具来简化这个流程。
资源加载适配：热更新 DLL 的加载需要通过 HybridCLR 的运行时 API 完成，需要编写 DLL 下载和加载的管理代码。

6.4 团队协作模式变化

对于团队开发，接入 HybridCLR 后的一些协作建议：

明确代码边界：在项目初期就定义好 AOT 代码和热更新代码的边界，避免后续大规模重构
统一泛型使用：建立泛型使用规范，确保所有在热更新代码中使用的泛型类型在 AOT 侧有对应的引用声明
热更新测试策略：建立针对热更新代码的专项测试流程，包括热更新加载测试、AOT ↔ 热更新互调测试、热更新性能测试等

七、适用场景分析

6.1 最适合的场景

场景	说明
游戏热修复	线上 Bug 紧急修复，无需重新发版审核
内容更新	活动配置、关卡数据、UI 逻辑的动态更新
A/B 测试	不同版本代码逻辑的快速切换和对比测试
版本迭代	大版本更新中的新增功能逻辑
小游戏/休闲游戏	快速迭代、频繁更新的需求场景

6.2 不太适合的场景

场景	原因
纯算法计算	热更新代码走解释器路径，计算密集型场景性能不如 AOT
超高帧率要求	60fps+ 时每帧时间预算约 16ms，解释器开销可能成为瓶颈
简单配置更新	使用 Addressables 等资源更新方案更为轻量

6.3 DHE 场景建议

对于性能敏感的场景，DHE 是一个重要的优化手段。根据官方数据，在实际项目中，一次热更新通常只有 1%-5% 的代码发生变更，DHE 可以确保 95% 以上的热更新代码仍然以 AOT 方式运行。因此：

不使用 DHE：所有热更新代码均走解释器路径。适合热更新代码量不大、性能需求中等、没有商业版授权的项目。
使用 DHE：仅为变更的函数走解释器路径。适合大型项目中热更新代码量大、性能需求高的场景。

七、与其他热更新方案的对比

目前 Unity 生态中主流的热更新方案包括：

方案	类型	语言	性能	学习成本
HybridCLR	AOT + Interpreter	C#	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐（最低）
ILRuntime	纯 C# 解释器	C#（受限）	⭐⭐⭐	⭐⭐⭐
xLua	Lua 桥接	Lua	⭐⭐⭐	⭐⭐
ToLua	Lua 桥接	Lua	⭐⭐⭐	⭐⭐
InjectFix	IL 注入	C#（受限）	⭐⭐⭐⭐	⭐⭐⭐
UniHotCSharp	C# 解释器	C#（受限）	⭐⭐⭐	⭐⭐⭐
puerts	JS/TS 桥接	JS/TS	⭐⭐⭐	⭐⭐⭐

HybridCLR 在性能、学习成本和生态兼容性三个维度上都具有显著优势。详细的深度对比将在本系列的 06-09 篇中展开。

八、社区与生态

8.1 社区规模

GitHub Stars：6000+
QQ 主群：3000 人满
商业项目接入：数千个
上线的双端项目：数百款

8.2 商业支持

HybridCLR 提供商业化版本（DHE 旗舰版），包括：

DHE 差分混合执行技术
更强大的性能优化
专业技术支持服务

商业版本的详细信息和定价请参考第 47-49 篇（11-实战篇-DHE旗舰版）。

8.3 作者团队

HybridCLR 的作者 walon（Code Philosophy 创始人）毕业于清华大学物理系，拥有 2006 年 CMO 金牌和奥数国家集训队背景，专注于游戏技术基础设施研发。

九、本系列导览

本文是系列文章的第一篇。整个系列共 64 篇文章，分为 15 个篇章，覆盖从基础概念到源码级深入的全部内容。

阅读路径建议：

目标	推荐路径	预计时间
快速了解	第 01 篇 → 第 10 篇 → 附录	1-2 小时
实战上手	认知篇 → 实战篇 → 核心技术篇	1-2 天
源码研究	认知篇 → 原理篇 → 架构篇 → 三大源码模块	1-2 周
全面精通	全部 64 篇按顺序阅读	1-2 个月

总结

本文介绍了 HybridCLR 的定义、核心特性、技术架构、版本支持、适用场景和生态情况。

关键要点：

HybridCLR 是 IL2CPP 运行时的增强扩展，而非替代方案
它以"零学习成本"和"接近原生的性能"解决了传统热更新方案的核心痛点
支持几乎所有 Unity 版本和目标平台
DHE 技术确保了实际项目中 95%+ 的热更新代码以 AOT 性能运行
社区活跃，商业生态成熟，已在数千个项目中验证

下一篇（第 02 篇）将深入介绍 AOT 编译原理，为理解 HybridCLR 为何需要插在 IL2CPP 上运行建立理论基础。

01-认知篇-总览-HybridCLR是什么

HybridCLR是什么

前言

一、HybridCLR 的定义

1.1 官方定义

1.2 核心价值主张

1.3 工作原理

1.4 与 IL2CPP 的关系

二、核心特性详解

2.1 近乎完整的 ECMA-335 规范支持

2.2 完整的 .NET 运行时支持

2.3 性能表现

2.4 DHE 差分混合执行

2.3 热重载（Hot Reload）

2.4 零学习成本

2.5 完整的 Unity 工作流兼容

三、技术架构概览

3.1 三层架构

3.2 三大仓库

3.3 核心的四个模块

四、支持的版本与平台

4.1 Unity 版本支持

4.2 平台支持

五、版本演进历史

六、开发者的工作流变化

6.1 传统的 Unity 热更新工作流（以 xLua 为例）

6.2 HybridCLR 的工作流

6.3 工程结构变化

6.4 团队协作模式变化

七、适用场景分析

6.1 最适合的场景

6.2 不太适合的场景

6.3 DHE 场景建议

七、与其他热更新方案的对比

八、社区与生态

8.1 社区规模

8.2 商业支持

8.3 作者团队

九、本系列导览

总结

参考资源