unity项目中的程序集划分--设计思想和具体操作

RhinoFreak · 发表于 2022-12-2 15:01

1. 划分程序集的意义

在大型项目中，合理的规划和拆分代码模块，设置合理的引用关系，可以解除基础框架-游戏模块-三方插件的耦合。

图2. 普通的项目的程序集划分

如上图中游戏模块作为需要经常改动的模块，它引用了基础框架模块和三方插件。而后者没有对其的引用。

如果按上图划分程序集并设置引用关系：代码的依赖关系会因为程序集依赖被强制限制。如果某个不规范的程序员擅自在基础框架中添加了涉及到游戏模块的代码，那么Ta会发现代码报错，编辑器无法在基础框架程序集中查到对游戏模块程序集的代码的引用。

如果基础框架和游戏模块同在同一个程序集中：代码的依赖关系必须要靠个人的代码能力管理。作为管理者必须要严格规范下属并经常review代码，不然不规范的下属几天就可能把基础框架和游戏模块揉合成一团小猫玩过的毛线团，很难理顺！
2. 程序集与热更新

在热更新需求下的程序集划分与普通的项目差别很小，基本通用，主要在于我们如何划分AOT程序集和JIT程序集，而且还有对于unity默认的Assembly-CSharp程序集的定义。

例如上面的图片中的例子，我们可以有2种划分方案：

但是划分方案2中，有个问题：

所以在上面的几条前提下，我们发现这种划分方案下：AOT程序集中有很多对热更程序集中代码的调用。
我们可以通过Assembly加载，通过反射调用到热更的代码，但是这样必然很繁琐。还有另外一种方法，为了避免AOT引用热更代码，我们也可以在AOT中实现另外一套资源下载/加载逻辑。当然这2种方法都很麻烦，最好还是基础框架的代码（至少下载/加载ab资源的代码）设置为AOT程序集。
3 Assembly-CSharp程序集

在上述2种方案中，我们都要考虑一个特殊的程序集：unity默认的Assembly-CSharp程序集。
如果自己添加的代码，如果没有专门划分程序集，那么就会被设置为默认的Assembly-CSharp或Assembly-CSharp-Editor程序集。
3.1 默认程序集的特殊之处

不确定性和混沌性：自定义的程序集必定包含在某个专属的文件夹下或dll中，但是默认程序集的代码遍布整个项目目录，藏于各个犄角旮旯之中，不便管理和统计。
拥有最大访问权力：自定义的程序集需要设置对外部程序集的引用后，才可以在内部使用相关的接口代码。但是默认程序集可以访问项目内所有的程序集(在勾选Auto Referenced的时候)，它相当于是处于程序集引用关系的金字塔顶部。
3.2 热更中默认程序集是否热更？

以下两种方案都可以，但是各有利弊：

把Assembly-CSharp程序集当作热更程序集有个不好的地方，那便是我们随意加入的测试代码(没有放在有程序集定义的文件夹下)，某些导入的三方插件等等，只要未定义过程序集，那么默认就会加入到Assembly-CSharp程序集。所以会经常误把某些代码打入热更dll。为避免程序花费时间和精力去检查这些内容，不建议用这种方案。
4. unity中如何划分程序集

在一个普通的C#项目中，我们可以在vs中右键程序集(项目)条目然后打开属性，查看该程序集的相关设定。但是unity生成的项目中，我们是无法使用这个操作的。

因为程序集的生成和划分是由我们在unity中处理，然后unity自动生成。其中unity中用来划分程序集的文件就是Assembly Definition。
当我们在目录中右键创建Assembly Definition 文件后，该目录内的所有代码文件将被划分为当前定义的程序集。

我们通过Assembly Definition文件，可以处理以下事情：

Define Constraints

Assembly Definition Refercences

Platforms

除了上面这些常用的功能，还有General选项下这些很有用的选项：

Allow ‘unsafe’ Code

Auto Referenced

No Engine References

Override References

Root Namespace

		自动登录	找回密码
密码			立即注册

unity项目中的程序集划分--设计思想和具体操作

本帖子中包含更多资源