现状
Unity 引擎开发团队宣布，他们已开始将 Unity 引擎运行时从 Mono 迁移到 .NET CoreCLR。
此外，他们还会提供融合 JIT 和 AOT 的解决方案——即集成 IL2CPP 和 Burst，从而达成编译时间效率和代码生成质量之间的最佳平衡。
目前，Unity 迁移到 .NET CoreCLR 运行时所涉及的工作已经开始。团队表示这是一个非常具有挑战性的旅程，为了能够成功完成迁移，他们会逐步解决这个问题，并确保能够以保持现有 Unity 项目稳定性的方式渐进发布更新。
因此，开发团队会分多个阶段完成此次迁移：
- 首先，为桌面平台的独立 player 提供对 .NET CoreCLR 的支持。基于此，开发者可以在 player 设置中选择此运行时以及现有的 Mono 和 IL2CPP 后端。团队认为，此阶段可以帮助他们迁移 Unity 引擎的核心部分（比编辑器部分小得多），并有望解决此迁移所涉及的大部分技术挑战。开发者在这个阶段仍将通过 .NET Standard 2.1 API 访问 .NET 运行时，他们的目标是在 2023 年发布新的运行时。
- 然后在第二阶段，团队会把 Unity 编辑器移植到 .NET CoreCLR，同时取消对 .NET Mono 运行时的支持。第二阶段的挑战是，如何在不使用 AppDomain 的情况下在编辑器中重新加载脚本，并完成向 .NET CoreCLR 的切换。它还将涉及升级 IL2CPP 以支持来自 dotnet/runtime 仓库的基类库。开发者最终可以访问完整的 .NET 7.x 或 8.0 API。Unity 团队计划在 2024 年发布新编辑器。
对外，Unity 正在与 Microsoft 和 JetBrains 等行业合作伙伴合作，加大对开源社区的参与力度，以确保 Unity 创作者能使用最新的 .NET 技术。
过去
过去，Unity 选择 Mono
早在2008年，Unity就宣布和Mono合作，但后续Mono新版本使用SGen GC取代Boehm GC时，Unity不想再次付许可证费用。直到当下（2021年7月），Unity依然依赖 Boehm GC。这是一种没有分代的（扫描慢）、Mark-Sweep的(会有内存碎片问题)、保守(不能精确地识别垃圾)的GC。
对于Boehm GC造成的性能问题，Unity官方有一些折中方案。
- 先尽量分配好所有对象的内存，然后关闭GC，等到合适的时机（如关卡结束），再开启GC；
- 默认开启 incremental 模式分帧处理，注意如果在期间有大量引用关系的改写，分帧处理反而会有大量额外性能损耗（主要来自写屏障）
未来
未来，Unity 选择 CoreCLR
自2016年微软将Mono的许可证由GPL改为MIT以来，Unity也加入了 .NET Foundation，开始将最新的Mono集成到自己的引擎中。但随着微软构筑开源的大一统解决方案 .NET 5，Unity似乎改变了原先的想法。从官方论坛中可以总结出他们的规划：
- 首先集成最新的Mono，因为其支持 .NET Core 的BCL；
- 然后将自家的 IL2CPP 也更新（其依赖Mono的输出结果）；
- Unity 2021.2开始完全支持.NET Standard 2.1，C#8和部分C#9（Span，Range，default interface methods），其中Span的影响非常深远，目前和BurstCompiler的NativeArray还不能无缝转换，最大难点是Span并没有自己的memory但后者有；
- 支持 C#9/10，基于前面的工作，这一步并不难；
- 支持 .NET 6（跳过 .NET 5）。
- 用CoreCLR替代Mono（GC也相应升级为CoreCLR GC），在此之前，GC并不会升级为 Mono的SGen。这项工作会持续比较久，目前还没有ETA。Unity大部分代码是C++，C#只有薄 薄的一层（但是越来越多的代码在切换到 C#）。在切换到CoreCLR后，其访问Managed Object的方式需要彻底改变，因此改动会很大。总体顺序是：先将Player替换为CoreCLR，然后将Editor也替换掉。
存在的两个难题：
所有dll必须重新编译
要修改 UnityEditor 中大量使用 AppDomain进行hot reload的部分（AppDomain在新版.NET中几乎被废弃，出处））；目前的替代类 AssemblyLoadContext 并不能提供之前 AppDomain Reload的所有功能
In general Assembly Load Context is cooperative, and any remaining references (static fields, GC Handles, running threads, etc) will prevent the code from being unloaded.
长远来看，Unity该团队已经意识到自己当年的一些轮子（Coroutine, Customized Boehm GC, IL2CPP, asmdef等）在近几年来.NET运行时、工具链和整套生态的飞速发展面前显得有些陈旧，正在致力于向开发者提供原汁原味的.NET开发体验（出处），同时尽量不颠覆原有的使用习惯（例如出于这些原因，UPM不会和NuGet双向互通）。
另外，Unity团队还有很多高优先级的feature要做，总之，还是希望Unity越来越好吧！
