Unity工程无代码化

  • 2019 年 10 月 3 日
  • 筆記

目的

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: PluginsScripts下的代码 (一般还有个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的编译环节有所了解。切换过来后,感觉是一种新的体验,有兴趣的可以试试。