.NET和Unity的未来，让用户编写高性能代码，并带来长期的稳定性与兼容性

用微信扫码二维码

分享至好友和朋友圈

.NET 生态正在多方面上积极动态地演变，Unity 希望尽快将这些改进带给广大用户。Unity 内部的 .NET 技术小组正致力于不断改进 .NET 集成，更新最新的 C# 特性与 .NET Standard 2.1。但根据大家的反馈，Unity 最近又在全面改善开发者体验上投入了更多力量。

.NET和Unity的演变

Unity 与 .NET 的故事要从 17 年前说起，当时的 CTO 决定开始采用 Mono .NET 运行时和 C#。Unity 之所以偏爱 C#，不仅是因为它很简单，还因为 JIT（just-in-time）编译器可以将 C# 代码转译成效率较高的原生代码。而为了做到性能平衡、可控，Unity 引擎剩下的大部分都采用了 C++ 开发。

多年来，Unity 一直依靠着 Mono .NET 运行时和 C# 语言（2.0）的一个特定分支来运行。在这期间，引擎对其他平台的支持也在不断扩增。我们还开发了自己的编译器和运行时：IL2CPP，让你能够针对 iOS 及部分主机平台进行开发。

与此同时，整个微软 .NET 生态系统也在不断发展，并推出了新的许可和对非 Windows 平台的支持。我们借着这股东风在 2018 年升级到了 Unity .NET Mono Runtime，并引入了更现代的 C# 版本（7.0以上）。同年，我们还发布了 Burst 编译器的首个版本，开创了为 C# 分支快速生成原生代码的先河。在取得这一突破后，Unity 提出了一个新设想：将 C# 拓展到引擎剩余几个关键部分、不再用 C++ 进行开发，并为 DOTS 运行时的开发做铺垫。

Unity 2020 LTS 和 Unity 2021 LTS 使用了新版 C# 语言和 .NET API（如Span）。同时，我们也看到 .NET 生态的性能有了极大的改善，其引入的 csproj SDK 风格和蓬勃发展的 NuGet 生态正在让开发环境变得更加友好。

我们将要做的事

经过长时间的发展，Unity 已经包含了一个巨大的 C++ 代码库，它继承了 Mono .NET Runtime 的职能来直接与 .NET 对象互动。这些代码对 .NET (Core) Runtime 来说不再合规或高效。

此外，Unity 编辑器还绑定着一条复杂的自定义编译管线，它不依靠 MSBuild 运行，因此也不能轻易从引擎特性中获益。

在过去几年里，我们也一直在积极与广大用户交流，以发掘出真正能促使用户成功的改进。我们听到大家非常想使用最新的 C# 语言、.NET 运行时技术和 NuGet 的第三方 C# 代码。在谈到 Unity 平台的使用时，大家都说希望借助高质量的 C# 测试、调试和剖析工具，标准 .NET API 和 Unity API 的优秀整合，来最大限度地挖掘出硬件的性能。作为一名 Unity C# 程序员，一定希望 Unity 工具能够与工具箱中的其他工具无缝衔接，能实现快速迭代，从而实现一流的运行时性能。

要达到这个目标，我们得花几年时间。

我们的做法

这项计划的第一步是在 Unity 内部集结所有热衷于 C# 和 .NET 的员工，建立一支 C#/.NET 技术小组来开展工作。

我们的工作将建立在 .NET 生态系统之上，而非开发定制解决方案。为了让用户能享受新版 .NET SDK/Runtime 和 MSBuild 所带来的性能与生产力提高，我们将从 Mono .NET Runtime 转移到 CoreCLR，即现代的 .NET (Core) Runtime。

这项行动也会带来当前 .NET 领域以外的创新，让 C# 脚本能更快地完成 .NET 迭代。我们将致力于结合 IL2CPP 和 Burst 这两个 JIT 和 AOT (ahead-of-time) 解决方案，在编译效率和 CodeGen（代码生成）质量之间的达到最佳平衡。

在外部，我们将与微软、JetBrains 等业内伙伴合作，保证 Unity 创作者能用上最新的 .NET 技术。我们也在进一步深入参与开源社区。这项工作将分成几个步骤进行。再来看看我们未来的计划。

2022年的工作内容

今年，我们的团队计划在以下几个方面开展工作。

C#开发流程

迭代时间仍然是我们首要的工作重点，我们清楚每一名用户都想尽可能地利用起自己的时间。以下是我们改进工作的几个例子。

我们正在改进编译管线的 IL Post Processing 所耗费的时间，它负责在 C# 被编译后修改编译好的 .NET 程序集。现在 IL Post Processing 将在编译阶段后持续运行，来降低约几百毫秒的耗时。

随着 Burst 编译器的使用愈加频繁，我们将采用一种可传递哈希算法来改进代码改动检测的精细度。如此一来，我们就能够找出那些需要快速编译的可爆发（Burstable）代码。我们正在将 Burst 编译器移出进程，使其能在单独的 .NET 6.0 可执行程序中运行，更快地完成代码编译。

我们还将改进引擎每次调用 TypeCache、在后台建立镜像数据（reflection data）的过程，借此改进域的重新加载。

我们还将添加测试和验证流程来更好地跟踪软件包和项目模板的迭代时间倒退。

至于转移到 MSBuild，我们第一步须将编译管线与 Unity 编辑器分割开来，并将其转移到一个单独的进程中。这个过程涉及多年以来遗留下来的成千上万行 C++ 和 C# 代码，我们要实现这一目标就必须解开这些代码——同时还要保持向下兼容。这项工作并不会在用户的角度带来多大变化，但它将铺好通往 MSBuild 的道路并简化引擎的维护。

我们还将改进 Burst 的 C# IDE 调试体验，推出一种新的调试模式，当用户在 Burst 代码路径上设置断点时，自动将调试器切换到托管调试。这意味着你不必再手动删去调试路径上的 [BurstCompile] 属性。

现代化.NET运行时

转移至 .NET CoreCLR 运行时的工作已经开始，这是一个非常具有挑战性的旅程。为了使整个过程能够顺利完成，我们将分步骤解决各个问题，并在保证现有 Unity 项目稳定的前提下碎片化发布更新。

因此，整个迁移过程将分多个阶段完成：

首先，我们将为桌面平台上的独立运行版提供 .NET CoreCLR 的支持。该运行时将和现有的 Mono 与 IL2CPP 后端一起在运行版设置中列出。第一阶段我们将完成 Unity 引擎核心部分（比编辑器部分小得多）的迁移，并尽量解决迁移过程所涉及的绝大部分技术挑战。我们的目标是在 2023 年期间发布这个新运行时，目前你仍需用 .NET Standard 2.1 API 访问 .NET 运行时。

然后，我们会把 Unity 编辑器移植到 .NET CoreCLR，同时移除对 .NET Mono 运行时的支持。第二阶段我们将挑战不使用 AppDomains 在编辑器内重新加载脚本，并完成向 .NET CoreCLR 转移。这一阶段也将涉及到升级 IL2CPP、支持 dotnet/runtime 仓库的基础类库。你将能使用完整的 .NET 7.x 或 8.0 API。我们希望能在 2024 年里发布这个新的编辑器。

现代化Unity运行时

Unity 2021 LTS 新支持的 .NET Standard 2.1 使我们能够从多个方面着手现代化 Unity 运行时。我们目前正在推进两项改进工作。

改进 async/await 编程模型。基础性的 async/await 编程方法主要用于编写必须异步完成、不阻塞引擎主循环的游戏代码。

2011 年，在 async/await 成为 .NET 的主流之前，Unity 引入了基于迭代器的异步运算协程（coroutines），但这种方法并不兼容 async/await，并且效率也更低。同时，.NET Standard 2.1 一直在改进 C# 和 .NET 对 async/await 的支持，推出了 ValueTask 来更高效地完成 async/await 的运算，并允许用户自行用 AsyncMethodBuilder 编写的类任务系统。

在有了这些改进之后，我们将努力结合 async/await 与 Unity 中现有的异步操作（如等待下一帧或等待 UnityWebRequest 的完成）。第一步，我们将引入取消令牌（cancellation token），改进 MonoBehavior 被销毁时或退出运行模式时被挂起异步任务的取消操作。我们也一直在与 UniTask 作者等社区贡献者密切合作，保证他们能够用上这些新功能。

利用 Span 减少内存分配和拷贝。Unity 本身是一个带有 C# 编程外壳的 C++ 引擎，两种语言之间存在着大量的数据交换。这就造成引擎经常性地来回复制数据、分配托管对象，造成工作效率低下。

C# 7.2 引入的 Span 可以有效改善这个问题，且 .NET Standard 2.1 默认可使用 Span 值类型。近年来，你可能听说过或读到过许多归功于 Span 的 .NET 运行时重大性能改进。我们同样希望在 Unity 中利用起它，并有效地减少分配，从而减少 Garbage Collection 卡顿、提高大量 API 的整体性能。

Unity 官方微信

第一时间了解Unity引擎动向，学习最新开发技巧

每一个“在看”，都是我们前进的动力

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.