1. 划分程序集的意义
在大型项目中，合理的规划和拆分代码模块，设置合理的引用关系，可以解除基础框架-游戏模块-三方插件的耦合。
如上图中游戏模块作为需要经常改动的模块，它引用了基础框架模块和三方插件。而后者没有对其的引用。
如果按上图划分程序集并设置引用关系：代码的依赖关系会因为程序集依赖被强制限制。如果某个不规范的程序员擅自在基础框架中添加了涉及到游戏模块的代码，那么Ta会发现代码报错，编辑器无法在基础框架程序集中查到对游戏模块程序集的代码的引用。
如果基础框架和游戏模块同在同一个程序集中：代码的依赖关系必须要靠个人的代码能力管理。作为管理者必须要严格规范下属并经常review代码，不然不规范的下属几天就可能把基础框架和游戏模块揉合成一团小猫玩过的毛线团，很难理顺！
2. 程序集与热更新
在热更新需求下的程序集划分与普通的项目差别很小，基本通用，主要在于我们如何划分AOT程序集和JIT程序集，而且还有对于unity默认的Assembly-CSharp程序集的定义。
例如上面的图片中的例子，我们可以有2种划分方案：
AOT程序集包括基础框架模块和三方插件，热更程序集包括游戏模块的1~N个程序集。这种方案下适用于基础框架稳固完善的项目，因为基础框架不会有大的变动所以不需要频繁更新整包；
AOT程序集仅包括三方插件(甚至三方插件也可以不包括)，剩余所有的程序集作为热更。这种方案下基本所有内容都可以热更，适用于新项目的快速迭代。
但是划分方案2中，有个问题：
- 下载/加载ab资源等操作，是在需要热更的基础框架中；
- 加载热更资源和加载dll等初始化操作，是在AOT程序集中，且会用到下载/加载ab资源代码；
所以在上面的几条前提下，我们发现这种划分方案下：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 热更中默认程序集是否热更？
以下两种方案都可以，但是各有利弊：
- 我们可以将其定义为AOT程序集，不引用任何热更程序集，那么下载热更资源，加载dll等操作均在这里实现。
- 我们也可以将其定义为热更程序集，那么下载热更资源，加载dll等操作均在划分的其他AOT程序集中实现。
把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：是否自动被依赖；勾选后会被默认的Assembly-CSharp程序集自动依赖。所以如果我们想在Assembly-CSharp中隔离对当前程序集的依赖，取消勾选。
- No Engine References:不依赖于引擎提供的代码模块。适用于可以在unity或其他平台的项目中通用的程序集。
- Override References：可以手动指定所依赖的预编译的程序集，因为unity项目中的预编译程序集可以被其他默认依赖，勾选后当前程序集可以选择(不)依赖某个预编译的程序集。
- Root Namespace: 当前程序集的默认命名空间，填写后我们使用unity添加新代码文件，会自动添加命名空间。我测试只有在unity中创建才生效。
