作为一个软件工程师，模块（module）应该是再熟悉不过的概念了。我们用它来划分代码，小的项目可能几个模块，大的项目则有可能有几十个甚至上百个模块。有很多语言原生就支持模块这个概念，但遗憾的是C++语言并不属于这类语言。为了弥补这个不足，虚幻引擎特别为C++创造了一套清晰的模块规范，使得引擎能更好的服务于大型的游戏项目。
通常来说，在虚幻引擎里的一个模块表现为在工程源代码目录中的一个独立子目录加上一个用C#写的构建脚本。模块常见的目录结构如下所示：
- Private
- Public
- *.Build.cs
顾名思义，Private目录用来存放的是本模块私有的代码，即你不想被其他模块引用的类或者函数等。通常来说源文件（cpp）都放在Private目录，有时候头文件也可以放在里面。而Public目录存放的是对外公开的代码，即本模块开放给其他模块引用的代码，所以一般只放头文件。最后*.Build.cs文件用来告诉UBT（Unreal Build Tool）如何配置本模块的编译和构建环境，具体该怎么设置C#代码里的变量，这里就不详细介绍了。当其他模块依赖了本模块，Public目录下的头文件都会被加入到头文件的包含路径里，这样其他的模块就可以引用我们定义的类或者函数了。
打开引擎生产的Visual Studio工程，我们会发现工程好几个构建选项，分两大类：一种带编辑器（Editor），一种不带。也就是说带编辑器的，运行起来后会先看到引擎的编辑器，而不带的自然就是游戏了，所以前者可以称之为编辑器模式，后者称之为游戏模式。在编辑器模式下，模块编译链接后表现为一个DLL文件（动态链接库文件）。而在游戏模式下，所有模块都被编译到一个可执行文件里。这一点不同会造成一个很有趣的现象，我们在后面会讨论。
这里我们从虚幻引擎Launcher界面下载一个免费的游戏用例工程，名字叫ShooterGame。这个工程里有两个模块，一个叫ShooterGame，一个叫ShooterGameLoadingScreen。我们随便查看一个ShooterGame模块里的一个头文件，如下所示：
AShooterHUD类
我们把Visual Studio工程按编辑器模式编译之后，可以在工程的Binaries目录下，找到一个如下图所示的DLL文件，这就是ShooterGame模块对应的动态库。用DLL Exoport Viewer查看该动态链接库，我们能很容易找到上面图示代码对应的接口，如下图所示：
ShooterGame模块DLL
从这两个截图的对比，我们发现类的声明前面带UCLASS的（继承自UObject/AActor的类）都在DLL中自动被导出。那么你自定义的类或者函数也想导出为其他模块所用的话该怎么办？答案是加上一个宏，宏的格式是这样的：YOURMODULENAME_API 。比如我要在模块ShooterGameLoadingScreen里导出我定义的类MyPrvateClass，那么代码就像下面这样：
class SHOOTERGAMELOADINGSCREEN_API MyPrivateClass
{
public:
MyPrivateClass();
~MyPrivateClass();
};
假如你忘记加了SHOOTERGAMELOADINGSCREEN_API，而又在其他模块里引用了这个类，那么链接的时候会报找不到对应符号的错误。那么SHOOTERGAMELOADINGSCREEN_API 这个神奇的宏到底会定义成什么样才能有这样的功能。我们借助于工具搜索一下工程目录下的文件内容，会发现如下的内容：
查找SHOOTERGAMELOADINGSCREEN_API结果
由此可见，在编辑器模式下，宏SHOOTERGAMELOADINGSCREEN_API会根据所在文件的不同被定义成DLLEXPORT或者DLLIMPORT，从而实现符号的导入导出。所以在编辑器模式下没有这个宏，链接的时候就会报错。而在游戏模式下这个宏的定义为空，这是因为在游戏模式下，所有的模块都是编译到同一个可执行文件里的。说到这里，你会不会想到那么在游戏模式下我们即使不给这个类加上这个宏在其他的模块里一样可以引用？事实上还真是这样。
当在编辑器模式下，每个模块都构建成一个DLL，所以像SHOOTERGAMELOADINGSCREEN_API这样的宏起到标注哪些类是DLLEXPORT或者DLLIMPORT，从而达到其他的DLL可以调用的目的。但在非编辑器模式下，所有的模块都编译到了一个可执行文件里了，不存在一个模块对应一个DLL的情况，所以这个宏就失去意义了。也就是说这个时候即使没有这个宏，你在Public目录下定义的这些类或函数都是可以被其他模块引用的。当然在我们日常项目里还是要按照这个规范来，需要暴露给其他的模块引用，还是加上这个宏（因为在平时开发中我们最常用的还是编辑器模式）。
总之，模块是一个很好的概念。模块划分好了，可以有效的减少不必要的耦合，提高代码的重用性，让程序员的生活过得轻松点，非常感谢Epic在引擎层面对模块提供了支持。
网友评论