Unity工程无代码化

目的

Unity默认是将代码放入工程，这样容易带来一些问题。
1. 代码和资源混合，职能之间容易互相误改。
2. 当代码量膨胀到一定程度后，代码的编译时间长到无法忍受。新版的unity支持通过asmdef来将代码分成多个dll工程，有所缓解。

所以，我们可以将代码全部挪到Unity工程之外，将代码编译成dll，然后把dll以managed plugin的方式放入unity工程。

 

实现

那么，我们怎么组织代码工程呢。先看下unity的vs tool自动生成的工程格式。

 

 

Assembly-Csharp: Scripts下的代码

Assembly-Csharp-Editor: Editor下的代码

Assembly-Csharp-firstpass: Plugins\Scripts下的代码 （一般还有个Csharp-firstpass-editor的工程，此工程下为Plugins/Editor的代码）

Unity.2D.Spritexx：这个是笔者导入的Sprite2D的package，由于此package为unity内置，实际存放目录在Unity安装目录的 Data/Resources/PackageManager/Builtin下。非内置的在Library/PackagesCache目录下。

 

查看工程settings

首先需要打开查看权限，visual studio-option-tools for unity-general，将Access to project properties改成True。

 

 

  

 

具体的compilation symbols很长，这里就不贴出来了。

此时，我们直接将此工程拷贝到项目外面，然后批量修改csproj里的文件路径，右键build，将dll放入原工程，触发unity编译后，会出现很多重复定义的报错，没关系，这是因为dll和工程内的代码重复了。

直接删吗？不急，先备份下工程。

删除代码，报错消失。点play，所有功能消失，一大堆script missing的warning。

原有脚本的meta都被删除了，难怪。没办法，用文本全局替换下guid。

原始脚本的meta 类似这样

 

 

而dll内的脚本meta 类似这样

 

 

其中fileID为dll的guid，而guid为dll内class的id（class名字不变的情况下，此ID不会变）

批量替换后，点play，一切恢复正常。（此批量替换过程，理论上完全可以自动化）

至此，工作是否已经完成？

没有。

 

这时候打包，会提示dll reference了 UnityEditor.dll，怎么办呢？ 查看project 的编译宏，果然有各种UNITY_EDITOR的宏。

看来需要在打包的时候，单独重新编译dll。

好在visual studio支持命令行打包dll，即msbuild。本地编译runtime的dll，命令行如下

Msbuild xx.csproj /t:Rebuild /p:DefineConstants=a;b;c;…

此处的defienConstants即为编译宏，覆盖了csproj里定义的define。依次将csharp和csharp-plugin编译。（Editor dll暂时忽略）

 

再次打包，成功。

 

但是此时 点击编辑器的play，你会发现有些功能发生异常（取决于代码），有些定义找不到了。原因是Editor的dll和Play的dll不兼容了（编译宏不一样）。所以为了编辑器运行正常，又得编译一遍play的dll。

 

此过程到此，感觉流程已经走通了。然而在发布到项目组正式开发流程之前，还有一些问题需要解决。

 

问题

• 代码调试问题

vs调试 managed dll时，需要mdb文件。所以我们在编译dll时，需要手动生成mdb。可以从google上下载一个pdb2mdb，在post build时，自动生成mdb，并将mdb和dll拷贝到unity工程。（隔壁项目组说将pdb和dll放入工程，unity会自动生成mdb，但尝试了n次均失败，遂放弃unity自带的mdb功能）。

 

• 编译宏问题

unity编译代码的宏，来自于几个地方：

a. Build setting defines

b. asmdef内的定义

c. unity内部的define（根据buildplayer传入的platform和buildoption来决定）

如果仅靠visual tools生成的工程里的define，显然不太实际。vs tools本身不负责编译dll，工程里的define仅仅为了方便代码编辑和代码自动补全。这部分可以查看 vs tools的源码（已经做成package了），vs tools是根据unity编译出的dll，去自动更新vs工程。而无代码化后的流程 其实是反过来了。

不过，通过查看 visual studio code editor源码，找到unity一个内部的接口

 

通过此接口，可以获取各个target和option的编译宏

 

• 引用依赖问题

Vs tools是将所有可能依赖的dll全部加到reference列表中，多的reference倒是无所谓，最终编译都只会包含真正需要引用的dll。但是ref dll的路径 需要处理下，默认为全路径，但每个人机器上unity安装目录都不一样，所以需要通用化。有两个方法：

a. 将dll拷贝到工程同级目录，将ref hintpath改成相对路径（不过，在unity升级后，此目录也需要升级，不适合unity需要频繁升级的项目）

b. 添加环境变量UNITY_PATH，修改csproj，示例如下

 

csproj的Condition可以很好的解决不同环境下的一致性问题

 

• Include scripts问题

由于涉及到多人协作，我们的csproj没有采取正则include，而是显式的include了每个代码文件，这样产生了两个问题

a. 所有人都需要提交csproj，而csproj默认是将新加的代码添加至末尾，所以在多人同时新加文件时，很容易产生冲突，而且不能自动resolve，需要手动合并。

b. 若引入了第三方的package，升级变得繁琐，要逐个检查是否需要include

 

为了解决这个问题，综合各个方面，决定使用终极方案，即根据代码文件/asmdef以及自定义的一些规范，自动生成csproj，这个过程跟vs tools类似。实现后，开发不再需要提交csproj文件，并且会自动检测代码文件的新增或删除，并自动修改，这样你的visual studio会自动提示reload（是不是跟原始的工作流程很像了？）。这个自动生成的过程，可以参考visual studio editor package代码，此处就不再做详细展开。

 

• Burst compile问题

Unity2019提供了burst功能，这个burst过程是在打包阶段发生的，它会自动扫描unity自动生成的dll（即Csharpt-xxx系列）内的代码，然后进行burst。但是此时我们的代码都在plugins下的dll里，所以扫描不到。此时需要修改burst package相关的代码，具体如何修改就不贴了，很简单。

 

总结

踩了不少坑，也对unity的编译环节有所了解。切换过来后，感觉是一种新的体验，有兴趣的可以试试。