Unity工程无代码化

  1. 云栖社区>
  2. 博客>
  3. 正文

Unity工程无代码化

推荐码发放 2019-08-11 22:59:14 浏览153
展开阅读全文

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: 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编译代码的宏,来自于几个地方:

  1. Build setting defines
  2. asmdef内的定义
  3. 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安装目录都不一样,所以需要通用化。有两个方法:

  1. 将dll拷贝到工程同级目录,将ref hintpath改成相对路径(不过,在unity升级后,此目录也需要升级,不适合unity需要频繁升级的项目)
  2. 添加环境变量UNITY_PATH,修改csproj,示例如下

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

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

  1. 所有人都需要提交csproj,而csproj默认是将新加的代码添加至末尾,所以在多人同时新加文件时,很容易产生冲突,而且不能自动resolve,需要手动合并。
  2. 若引入了第三方的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的编译环节有所了解。切换过来后,感觉是一种新的体验,有兴趣的可以试试。
原文地址https://www.cnblogs.com/kumbayaco/p/11334885.html

网友评论

作者关闭了评论
推荐码发放
+ 关注