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

wavefish5

coreclr不撑持的平台应该怎么办？仍然使用mono吗?

zxhk0794

我再说一遍，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。
<hr/>至少在 DotNet 11 之前，Mono 还会继续更新的。

tccrock

unity自身做了很多改造，更mono也是需要付出很大成本的
换coreclr 遥遥无期，gc问题是个大问题，大量引擎代码不支持分代gc，用户侧也不支持，不能向后兼容

wmywind

C# benchmark result.xlsx - 蓝奏云


最直接的槽点是他性能真的太差了，我们看到这个跑分下，不同处理器同runtime的跑分比值和CPUZ这种的跑分还是比较接近的，说明性能测得没啥大问题，但是你看看u3d的mono的单核性能，是不是很慢，这不是最离谱的，他的多线程居然比单线程还慢（我用的是.net内置的算法和往上的国密算法，国密算法已经调过结果保证正确，然后用Task或者线程池去跑多线程，单线程跑分由于.net某些内置的并行化，不完全是单线程），此外u3d的mono比普通mono要差很多，也就是mono主线都比u3d mono强很多，而net48还是比mono强很多，而.net6 .net7一步一步飙升的性能，已经把mono .net48都甩了好远了
综合下来说，未来只有.net8是靠谱的，不管是mono还是u3d mono，只是维持勉强能用的程度，不可能有明显的进步了
而大家寄予希望的il2cpp呢？性能也就是u3d mono的两倍而已，甚至并没有因此追上net48，主要还是u3d团队的优化能力太差了，换成il2cpp还是差
平时u3d中还得配合使用burst dots等手段费劲心思的去优化性能，这些并不是通用的性能优化手段，不管这么样，u3d mono这个基建是破破烂烂的，mono也没好到哪里去
u3d mono第二大槽点就是他只实现到st2.1和net4.6，他追不下去了，连nuget里的很多库都不兼容，只能去u3d商店里找组件，比如OpencvSharp，而微软mono也明显只是勉强追赶
后面更可能是.net8  il2cpp nativeaot这几个扛大旗，微软肯定会把.net8推广到别的平台来代替掉mono，所以为了一劳永逸，追上主流，更好的兼容nuget库，就得用.net8

主要进展可以看官方这个贴
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-37
我估摸着这件事情主要是明年，也就是u3d 2024版本的beta版

fkbill

C#最新版的AOT已经可以用了，在那些不支持JIT的平台上应该会逐步可用。

铁道游击队

印象中unity的源码注释写了这样的话：mono的bug一直不修，我们只能这样先规避。
后面貌似unity觉得每升级一个版本都要修mono bug太难受了，就自己起炉灶了