前言

在面试中，我们经常会被问到Unity的底层是如何处理C#,本节给通过一下3个点来给大家详细的分析这个问题:

C#的发展历史

C#没有出来之前，当时Java凭借Java虚拟机+Java字节码解释执行,让Java代码移植编写可以跨平台运行。同时Java等有了垃圾回收机制等，大大的降低了开发的难度。微软为了应对Java, 推出了.net平台。.net平台包含了几个点:

a: 设计创造一些编程开发语言，比如: C#, J#等。

b: .net开发工具,将.net 这些编程语言编译成.net字节码，我们叫做 CLR或IL,这样C#编写的代码可以被J#调用的到，因为底层都是基于.net字节码。

c: 开发一个.net 虚拟机能解释执行CLR字节码,同时把.net虚拟机移植到多个平台(windows, win mobile等windows系的操作系统)。这样用C#/J#开发的程序能跨平台到.net支持的操作系统上，同时C#， J#底层一样，能相互的调用。

d: 为了让.net能支持更多的平台，微软把.net CLR的标准开放出来了。

e: 出了一个开源的项目Mono, 以.net为标准，开发出了支持主流的PC与移动操作系统的.net 虚拟机。这样使得.net代码有机会能运行到非win家族系列的操作系统上。

Unity为什么用C#

讲完.net的发展历史的几个阶段以后，我们来看下为什么Unity会使用选C#来做开发语言。Unity 出来的时候，也需要解决 游戏 for mac, 游戏for linux, 游戏for windows, 游戏 for xbox等平台，后来手游发展起来以后又要解决 游戏 for Android, 游戏for IOS等。所以Unity引擎必须要构建在能跨平台发布的这个基础上。所以早期的Unity选择了Mono,作为跨平台基础，所以Unity是基于mono发展起来的项目。而mono 基于.net技术构建，所以在mono上开发，可以支持多种开发语言，c#, J#等所以早期Unity能支持C#, Boo, Js等编程语言，都是基于mono .net技术。所以Mono帮助Unity解决了跨平台问题，开发语言与开发工具的问题。

看上去一切很美好，但是基于mono构建的技术方案也有致命的问题，后期的Unity发现问题越来越多，主要的问题如下:

a: 程序执行效率，在移动端解释执行CLR代码,终归效率不如直接的native代码;

b: Mono虚拟机移植,当一个新的游戏开发平台出来以后，又要重新移植mono虚拟机，这里产生的bug先不说,能不能支持出来还不一定;

c: mono版权问题，当Unity使用mono的时候，需要mono的授权;

d: mono 虚拟机要移植到 web平台几乎不可能,而现在web平台也非常的流行,比如微信抖音小游戏等;

e: IOS不允许运行.net 虚拟机;

Unity il2cpp 救世主

为了解决mono .net的问题，Unity 开发团队推出了一个新的技术，就是il2cpp,顾名思义就是讲CLR/IL代码通过il2cpp,把它转成c/c++代码，然后再基于平台的native开发工具再进行编译，最终编译出native的二进制代码。

同时C#这些高级编程语言会有一些高级特性，比如垃圾回收等，这样就需要在底层做一些支撑，比如基于C/C++实现垃圾回收, C#的线程库等。这些功能都实现到il2cpp runtime库(il2cpp vm)上，运行的时候来提供这些基础服务的支撑。

这样做发布IOS没有任何问题，native code性能也好,同时如果有新的平台出现的时候，只要把C/C++移植到对应的平台就可以了，移植的时候非常的方便。

总结一下unity基于il2cpp 来构建处理C#的基本原理与步骤:

(1) 开发者还是基于.net的C#来进行开发;

(2) 还是使用.net的工具将C#的代码编译成CLR or IL

(3) 使用il2cpp工具,将CLR/IL字节码转成静态的C++代码;

(4) 使用native的开发工具(xcode, Android NDK等)，来将C++代码编译成目标的native机器码;

这样Unity开发到目标OS平台的安装包就打包发布出来了。假设有新的平台出现后，只要将游戏引擎的native代码+平台工程工具移植好就可以了，获得更好性能的同时获得了更好的跨平台移植性。最后上一个图来展示一下整个的架构,如下:

本节就分享到这里了，关注我，学习更多的Unity开发的知识。