——从 Native 机器码、Mono/IL2CPP 到编辑器与运行时内存
1. Unity 编辑器的本质
1.1 Unity.exe 是什么
-
Unity 编辑器（Unity.exe / Unity.app）是一个 Native 程序
-
也就是说：
- 已经由 C/C++ 编译为目标平台的机器码
- 操作系统直接加载并执行
-
CPU 只执行机器码
-
Unity 编辑器不是：
- C++ 源码
- C# 源码
- IL
而是 机器码 + 数据段
结论：当你双击 Unity.exe，本质上是在执行一段已经编译好的 Native 机器码。
2. Unity 的双层技术架构
Unity 从一开始就采用了Native + Managed 的混合架构。
2.1 Native 层（C++）
职责：
- 引擎核心
- 渲染（Graphics / GPU 提交）
- 物理（PhysX）
- SceneView / Inspector / Gizmo
- 资源管理
- 编辑器 UI
特点：
- 编译期生成机器码
- 直接被 CPU 执行
- 性能高、控制底层
2.2 Managed 层（C#）
职责：
- 游戏逻辑（MonoBehaviour）
- 编辑器扩展（EditorWindow / CustomInspector）
- 工具脚本
- 用户逻辑层
执行方式：
- C# → IL
- IL → Mono VM / IL2CPP Runtime 解释或 AOT
CPU 并不直接执行 IL
CPU 执行的是 Mono VM / IL2CPP 的 Native 机器码
3. Mono、IL、IL2CPP 的真实关系
3.1 C# 是如何变成可执行逻辑的
流程（编辑器内）：
.cs（文本）↓
C# 编译器↓
IL（DLL）↓
Mono VM（Native）↓
CPU 执行 Mono VM 的机器码
-
IL 是 数据
-
Mono VM 是 Native 程序
-
Mono VM 负责：
- 类型系统
- 对象内存布局
- 字段访问
- 方法调用
3.2 为什么 Unity 需要 IL2CPP
IL2CPP 并不是为了“跨平台 IL”，而是为了解决：
- iOS 等平台 禁止 JIT
- Mono JIT 性能和平台限制
- 安全性与反编译难度
IL2CPP 流程：
IL↓
IL2CPP（转为 C++）↓
平台 C++ 编译器↓
Native 机器码
IL2CPP VM 本身是 C++ 写的 Native Runtime
4. 编辑器态 vs 运行态（关键分界）
4.1 这是两个“状态”，不是两套引擎
| 维度 | 编辑器态（Edit Mode） | 运行态（Play Mode） |
|---|---|---|
| 是否运行逻辑 | ❌ | ✅ |
| 是否 Update | ❌ | ✅ |
| 是否可保存 | ✅ | ❌ |
| 数据是否权威 | ✅ | ❌ |
| 所在进程 | Unity.exe | Unity.exe |
Play Mode 并不会启动新进程
4.2 编辑器态内存
- 反序列化后的
.unity / .prefab / .asset - Hierarchy 中的 GameObject
- Inspector 中的字段值
- 是 权威数据源
- 可以序列化回硬盘
4.3 运行态内存
- 编辑器态场景的 完整克隆
- 仅存在于 Play Mode 生命周期
- 所有修改都是 临时的
- 退出 Play Mode 时整体丢弃
5. Inspector 修改数据的本质
5.1 Inspector 修改了什么
- ❌ 不是修改脚本
- ❌ 不是修改机器码
- ✅ 修改的是：
内存中组件实例的字段二进制数据
例如：
Transform.positionMonoBehaviour.publicField
5.2 为什么 Inspector 的值会覆盖脚本默认值
-
脚本中的字段初始化值：
- 只在 组件第一次创建时生效
-
Inspector：
- 直接写内存
- 保存时序列化
结论（非常重要）：
Unity 使用的是 Hierarchy / 内存中的字段值，而不是脚本源码中的默认值。
6. Unity 的对象文件体系
6.1 Unity 的“对象文件”类型
| 文件 | 作用 |
|---|---|
.unity |
场景序列化 |
.prefab |
GameObject 模板 |
.asset |
ScriptableObject / 资源 |
.mat |
材质 |
.anim |
动画 |
.controller |
Animator Controller |
.meta |
GUID / 依赖信息 |
它们的共同点：
- 是 序列化数据
- 不是对象
- 不是机器码
- 不能直接运行
7. 实例化（Instantiate）的真正含义
7.1 Instantiate ≠ 读文件
Instantiate 的本质是：
内存级对象克隆
过程：
-
已有一个内存对象（Prefab 或原对象）
-
Unity：
- 复制其可序列化字段数据
- 复用类型信息（Mono VM 类型表）
- 分配新的内存
-
得到独立实例
(Clone)
7.2 为什么不是简单读二进制
因为：
- 每个实例必须有独立字段内存
- 类型系统必须绑定 Mono VM
- 需要参与 Update / Physics / Render
- 资源文件只是“快照”，不是“活对象”
8. Play Mode 为什么不保存修改
8.1 根因总结（一句话）
Play Mode 修改的是运行时克隆内存，而不是编辑器权威数据源。
8.2 Play Mode 内部机制
编辑器态内存（权威）↓ 克隆
运行态内存（临时）
-
所有运行时修改：
- 发生在临时内存
- 没有序列化权限
-
退出 Play Mode：
- 临时内存整体销毁
- 编辑器态回滚
9. Native / Managed 与 Edit / Play 的正确关系
9.1 四象限模型（非常重要）
执行方式┌─────────────────┐│ Native | Managed │
┌───────────┼─────────────────┤
│ 编辑器态 │ Editor C++ | Editor C# │
│ (Edit) │ SceneView | Inspector │
├───────────┼─────────────────┤
│ 运行态 │ Runtime C++| Game C# │
│ (Play) │ Renderer | MonoBehav │
└───────────┴─────────────────┘
Edit / Play 是状态维度
Native / Managed 是实现维度
它们是 正交的，不是上下层关系。