网站建设市场行情分析,wordpress跳转插件,天津高端视频制作公司,app开发怎么赚钱目的 Unity默认是将代码放入工程#xff0c;这样容易带来一些问题。1. 代码和资源混合#xff0c;职能之间容易互相误改。2. 当代码量膨胀到一定程度后#xff0c;代码的编译时间长到无法忍受。新版的unity支持通过asmdef来将代码分成多个dll工程#xff0c;有所缓解。所以… 目的 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的idclass名字不变的情况下此ID不会变 批量替换后点play一切恢复正常。此批量替换过程理论上完全可以自动化 至此工作是否已经完成 没有。 这时候打包会提示dll reference了 UnityEditor.dll怎么办呢 查看project 的编译宏果然有各种UNITY_EDITOR的宏。 看来需要在打包的时候单独重新编译dll。 好在visual studio支持命令行打包dll即msbuild。本地编译runtime的dll命令行如下 Msbuild xx.csproj /t:Rebuild /p:DefineConstantsa;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的编译环节有所了解。切换过来后感觉是一种新的体验有兴趣的可以试试。 转载于:https://www.cnblogs.com/kumbayaco/p/11334885.html
