在Unity项目的开发过程中，我们经常需要使用各种第三方库，而这些库常常在构建时会导致无法正常编译。为了避免这种问题，Unity引入了asmdef，来解决依赖管理问题。本文将从多个方面来深入阐述asmdef的使用。
一、asmdef的概念
asmdef是指“Assembly Definition”，可翻译为“程序集定义文件”。它是Unity 2017.3版本引入的一项新功能，用于解决项目开发中出现的依赖问题。
通过asmdef文件可以定义程序集（Assembly），从而对代码的依赖进行管理。可以将一组相关的类与资源打包到一个asmdef文件中，这样可以避免在运行时出现代码找不到引用的情况。同时，asmdef也可以帮助我们更好地组织项目代码，使得整个项目的结构更加清晰。
二、asmdef的使用
1. 创建asmdef文件
创建asmdef文件非常简单。在Unity项目的Assets文件夹下，右键选择“Create->Assembly Definition”即可创建一个asmdef文件。
Assets/
MyAssembly/
MyAssembly.asmdef
2. asmdef文件的内容
asmdef文件的内容非常简单，只包含几个必要的字段：name，references，includePlatforms和excludePlatforms。
其中，name字段是Program Assembly的名字，必须与程序集名字相同。references字段表示引用的程序集，即在此Program Assembly中需要引用的其他程序集文件。includePlatforms和excludePlatforms字段是指定Build时需要包含或者排除的平台。
{
"name": "MyAssembly",
"references": [],
"includePlatforms": [],
"excludePlatforms": []
}
3. 添加脚本到asmdef文件中
在asmdef文件中添加脚本非常简单，只需要将脚本文件夹拖到asmdef引用面板即可。我们可以将所有相关脚本都拖到同一个asmdef文件夹中来简化管理。
从Unity 2021.2版本开始，我们还可以直接在项目视图中进行asmdef文件的操作。通过右键选择“Add>>Scripts”可以将整个脚本文件夹添加到asmdef中，非常方便。
4. 编译asmdef文件
在Unity中，如果没有特定地设置每一个脚本的编译方式，Unity会默认将所有脚本打成一个Assembly，这意味着当有脚本需要更改时，会将整个程序集重新编译一次。如果引用了大量的第三方库，在重新编译整个程序集时，会消耗大量的时间。
使用asmdef文件可以避免这个问题，因为asmdef文件是可以单独编译的。asmdef文件中规定了Assembly的命名空间和程序集名，我们可以在编译时选择只编译某个Assembly，而不需要重新编译整个程序集。
使用asmdef文件不仅可以节省时间，也可以帮助我们更好地管理依赖关系和组织代码结构。
三、asmdef在项目中的应用
1. 模块化开发
使用asmdef文件可以帮助我们实现模块化开发，将不同功能的代码放置在不同的程序集中管理。这样，代码组织得更加清晰明了，也方便团队合作。
// Module 1:
namespace MyGame.Module1
{
public class MyClass1 { }
}
// Module 2:
namespace MyGame.Module2
{
public class MyClass2 { }
}
// MyGame.asmdef references MyGame.Module1.asmdef and MyGame.Module2.asmdef
2. 多版本管理
使用asmdef文件可以帮助我们实现版本控制。例如，当我们需要为不同的平台打包不同的Assembly时，我们可以使用不同的asmdef文件。我们还可以使用条件编译指令来控制在不同的平台上编译不同版本的代码。
3. 第三方库管理
当我们的项目需要使用第三方库时，我们可以将其打包成一个单独的程序集。在引用第三方库时，我们只需要参照其官方文档添加相应的asmdef文件，就可以避免其对其他代码的影响。
结论
通过本文的介绍，我们可以看到asmdef可以帮助我们更好地进行依赖管理和代码组织。使用asmdef可以实现模块化开发、版本管理和第三方库管理等功能，同时还可以避免整个程序集的重新编译，从而提高构建效率。因此，在Unity项目开发中，我们应该积极地使用asmdef文件。
注意：ADF所在的文件夹名称，以及ADF的文件名，跟程序集的名称没有关系。程序集的名称只跟ADF文件中的Name属性有关。创建时对ADF命名的话，属性中的Name也会相应修改。
实战环节
下面我们使用一个实际案例看看这个功能如何使用
例如在2017.3之前的版本中的的脚本目录结构是这样的
在2017.3之前的版本中，这些脚本最后会全部被编译到一个Assembly-CSharp.dll中
再来看下如果我们创建了程序集定义文件(Assembly Definition File)后会怎样
创建ADF文件
我们按照目录结构分别创建一个ADF，并且在Scripts文件夹下创建一个Main的ADF
我们随便打开一个脚本，可以看到VS将这几个分别识别为了几个C#工程
刚刚创建的ADF还差一些没有设置，就是依赖关系，比如Network要依赖SDK中的内容，如果不设置，就会像下图一样报错
同时VS中也会报错
下面我们来修复这个问题，选中Network ADF文件，然后在References中添加SDK的引用，别忘了点击下面的Apply
现在不报错了，再打开VS，也不报错了，可以看到Network这个C#工程中加了一条SDK的引用
常见问题：多层级的ADF
如果一个文件夹及子文件夹中，有多个ADF，每个脚本被添加到离这个脚本最短路径的ADF中去。
比如上面实战环节的Utils中并没有创建ADF，那么ADF就会被添加到父目录的Main中
如果你搞不清楚一个脚本究竟被包含在了哪个ADF中，只需要选中这个脚本，在Inspector面板中就会清楚的看到
最佳实践
强烈建议你对项目中的所有脚本使用ADF，或完全不使用。否则，没有使用ADF的脚本会在每次ADF重新编译时也被重新编译。这会减少你在项目中ADF所带来的好处。
还有就是一定要对目录结构好好进行划分
感觉这个功能设计是好的，但是实际项目中由于脚本文件的划分，和自己定义公共插件库的划分不是非常明确，导致脚本直接会经常出现引用，如果引用过多，就导致ADF失去了他的优势，反而感觉比较麻烦，容易出现问题。个人感觉如果项目编译真的很慢，而且项目脚本功能有明确的划分，实在ADF还是不错的选择。
链接：https://www.jianshu.com/p/53161ce351e7
————————————————
版权声明：本文为CSDN博主「Peter_Gao_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_42672770/article/details/131193440