关于Unity程序集这件事？

qq_39858654

已于 2023-04-12 11:01:45 修改

阅读量999

点赞数 3

分类专栏： Unity C# 文章标签： c# 开发语言

于 2023-01-08 22:00:35 首次发布

本文链接：https://blog.csdn.net/qq_39858654/article/details/128604085

版权

Unity 同时被 2 个专栏收录

13 篇文章 4 订阅

订阅专栏

9 篇文章 0 订阅

订阅专栏

这个始于一个很简单的问题：SteamVR2.0里面添加自己写的脚本调用不起来，搞很久终于搞明白了，这里用一个很简单的事例来解释。

先新建一个工程，在Project下新创建了一个文件夹Scripts1，文件夹下创建了一个名为ABC的脚本文件。

然后，我又在Assets目录下，又新建了一个名ABC的脚本文件，结果看下图：

很明显示报错了，现在不着急，我们在Scripts1文件下再创建一个名为Assembly Definition的文件。

文件创建好后，报错消失了，这是为什么呢？

没错，这个就是程序集的！！！

现在，让我们用Visual Studio打开代码看一下。

看出问题了吗？

对的，我们新建了一个程序集(NewAssembly)，让两个ABC脚本处于了不同的程序集，一个是Unity默认的程序集，另一个是我们新建的，就像Windows同一个文件夹下不能有同名文件，同一个程序集下也不能有同名的脚本。

下面我们开始正式讲一下程序集：

Unity程序集没有想的那么难，我们可以将C#想像成小说文件，而程序集的作用就是给它们分类，将不同题材的小说文件分到一堆去，修仙的一堆、科幻的一堆、灵异的又是一堆，这个分类又有什么用呢？

效率问题，先看一下当我们创建了一个Assembly Definition(程序集)文件时，工程文件发生了什么变化：

在项目的根目录下多出了一个NewAssembly.csproj文件，还有就是Unity项目默认创建就有的Assembly-CSharp.csproj文件，这些.csproj文件表示有一个这样的文件就会有一个程序集，是不是跟上图Visual Studio的程序集一样，这些.csproj文件还会生成对应的dll文件，每次修改C#代码返回Unity后,C#代码文件所对应的程序集，就会重新编译一次，重新生成新的dll文件。

当该文件夹中没有下图的Assembly Definition及Assembly Definition Renference文件时，在默认情况下，Unity几乎将所有游戏脚本都编译到了预定义程序集Assembly-CSharp.dll中。

这就解释最开始的例子问题了，当有两个ABC脚本却没报错，因为我们在Scripts1中创建了一个新的程序集NewAssembly，将两个名称相同的ABC脚本文件分配到了不同的程序集中。

在Unity中建多个程序集可以提高效率，就像一个机器的零部件，它就是一个整体，但零部件某个部分在使用过程中经常坏，且机器的零部件价格较贵，为了节约成本，于是设计人员就把经常坏的部分单独拆分开来，让一整个机器的零部件拆分成两个零部件，当经常坏部分坏了，就可以只换坏的部分了。

同理，当我们在Unity中没有创建任何程序集时，大部分C#脚本几乎都归于程序集Assembly-CSharp，该程序集中的任意一个C#脚本发生改变时，计算机就要重新编译整个程序集，生成新的DLL文件，脚本少还好，但如果一个Unity项目中有几千个脚本文件，当你修改完成代码返回Unity时，就会出现Unity加载速度慢或直接卡死的情况，这就是程序集的分块更新，可用于提高Unity的编译效率，这个对于大项目才有明显的作用，小项目加不加没太大区别。

程序集的分块更新仅限于提高编译效率，不！

其实你每天都可能用到它。