Unity为什么不更新Mono到最新版本，而是在coreclr没有支持移动平台下迁移到coreclr?

我再说一遍，Unity 就是 DotNet 社区的吸血鬼。从来不知道反哺 DotNet 社区。宣传上就故意和 DotNet/CSharp 做切割。各种隐瞒和矮化 DotNet/CSharp 在 Unity 中的作用，国内社区这一块更加离谱。开源作风也有问题，甚至从 C/C++ 那里抄来的通用算法和辅助函数都要搞成它不太聪明的那套，目的就是不让 DotNet 社区其他人用，困在 Unity 里用。

现在很多后辈同学，真是一点历史都不学。在十几年前 Java 互联网的上升时期，那还是 JSP 和 ASP 横行的年代。没现在这些前端框架，而 ExtJS 是在 Web 上提供桌面体验的一家独大的前端框架，在那些增删改查的项目中不知道有多流行了。而它现在怎么样呢？我为什么提这事？因为 Unity 就是和 ExtJS 一样的，是不厚道的，格局小的不得了的商业组织开发的，一直吸血的，部分开源但缺乏有开源精神的项目！

（给大家提个醒，社区 2016 年就开始讨论迁移到 CoreCLR 的事了。）我早在 2020 年的时候就说过，就算是上天眷命，向 CoreCLR 迁移最快也要两年（2022 年）。我那时是从技术角度评估的，没考虑 Unity 官方的小算盘。现在已经过去三年多了。再来看，Unity 官方在 2020 年到 2022 年这段时间里做了什么呢？Nothing but bluffing. 现在还有同学在想 Unity 官方能在 2024 年推出能用的支持 CoreCLR 的版本，大家别上当呀。

还有很多同学对 IL2CPP 的定位不清楚。不要看到 CPP 就联想到高性能。说穿了 IL2CPP 是个类似 Cython 的东西，逆不了天。而且我有理由相信，Unity 官方一直借着 AOT 需求抵抗一些好的但重要的改良，就是为了它自己的一亩三分地（眼前的商业利益）。

在告诉大家一件事，Unity 最近做的一些 CoreCLR 尝试，在技术上看根本不是优化的，他们为什么非要往这个方向做呢？是包袱太重，技术太拉了，还是有别的考量？我觉得几方面都有。在我看来，很明显他们在走 ExtJS 的老路，遇到困难是在正常不过了。

正确的做法是什么呢？（再给大家提个醒，早在一开始，引擎的 C/C++ 部分也用 GC，并且想通过 C/C++ 和 C# 的部分用同一套 GC 来化简一些问题。）我认为，应该将引擎剩余的 C/C++ 部分尽可能地改写为 C# 并开源。（IL2CPP 最后也该扔掉。）这不是在开玩笑，我觉得这是可行的，而且是唯一的出路。真正融入 DotNet 社区才是正途。这个工作量也并没有大家想得这么高，至少不会比依现在的框架做适配 CoreCLR 的大刀阔斧的改动高多少。注意：现时点引擎的大部分已经是 C# 的。（官方在这一点上一直在试图误导甚至欺骗大家。）

除了 C/C++ 和 IL2CPP 这两方面，C# 的部分要继续改动，特别是涉及反射、异常处理、委托、泛型、异步的一些骚操作都该整改了。SDK、包管理和构建系统都应该和 DotNet 社区对齐。具体就是要基于新的 DotNet SDK，而 Unity SDK 要作为 DotNet SDK 工具和插件。包管理要用 NuGet。构建系统要用 MSBuild（可配合 CMake）。（哪个杠○再说 MSBuild 不是开源或不是跨平台的就直接拉黑。）要开源做真贡献，不要耍小聪明故意整成 Unity-only。总之，只有回到 DotNet 社区中去，才能救 Unity。

至少在 DotNet 11 之前，Mono 还会继续更新的。