如何做到 Unity 项目结构清晰
背景先上图，看完图，也许你就会明白我为什么会写这篇文章，我昨天第一次打开 git 看到这个代码结构，着实有点蒙B，怎么说呢，目录结构有点混乱，你也许不能想象这是一个已经上线的项目...
某已上线 Unity 项目代码结构目录
简单案例
本人强迫症十级，有种莫名的冲动，但是这样的目录结构随着项目慢慢变大，参与人数增加，维护难度会呈指数级增长，先来看一个之前做过的棋牌（项目逻辑简单，所以项目结构也相对简单）类游戏项目结构，如下图：
之前棋牌项目目录结构
其实这个棋牌项目前前后后直到上线也就用了两个月，前后端各一个人开发，比较仓促，所以代码结构也相对不是那么规范，往大里说，其实 Unity 的项目结构决定着你架构设计，因为他直接决定着你后期代码维护以及多人协作开发的复杂度，要不后期你将会发现，自己会浪费大量的时间处理混乱的项目而不是添加新功能。
应该是什么样子
项目结构设定在 Unity 里对于开发者（使用者，无论是美术、策划还是程序猿）完全自由（也就是你想怎么搞就怎么搞），正因如此，项目结构在 Unity 里经常变得非常混乱，如上面我们看到的情况，而且会愈演愈烈，下面是我经常采用的资源结构
我之前经常用的项目目录结构
Editor
有人说为什么你会把 Editor 单独独立出来，而不是放在需要支持 Inspector 的脚本对应目录上，当然也可以这样，这个只是我的个人习惯，强迫症所致，我看项目中有一堆 Editor 的目录不舒服；
Editor/AssetBundle 编辑器扩展ab包自动化打包管理，版本管理，等编辑器相关代码; Editor/Common 一些编辑器扩展的公用代码; Editor/ExcelBuild 表格处理工具代码; Editor/PackageBuild: 打包时候的工具代码 …Gizmos
这个目录一般用于需要做场景特殊绘制标记使用，一般做场景编辑时能够给美术同学和策划同学更直观的展示，主要放置绘图相关的资源，当然这个绘制效果不会在 Game 视图中显示，如果想要显示，需要勾选 Game 视图中的Gizmos 选项，注：此目录的资源不会被打进最终的包内；
Gizmos
Plugins
这个目录主要是存放一些第三方 SDK 的库文件，比如 WebSocket 库，微信开放平台的登录 SDK，Unity 已经为我们处理的很好了，只需要按照目录规则放置就可以了，例如：安卓的库就放置在 Plugins/Android 下，Unity 自身的 Package 不要放在这个目录下。
Artwork
存放美术资源的目录（涵盖动画、模型、材质、Shader、UI、原图等等），最好通过 svn 外链或者 git submodel 的方式引入，同样在上面的目录少了一个策划的目录，其实一般就是一个 csv 目录，一般也是通过 svn 外链或者 git submodel 的方式引入，这里就不做过多介绍了；
External
这个目录主要是放置一些外部的插件 Package，例如腾讯的行为树插件，注：外部的 Package 很多代码结构都比较混乱，特别是美术 Package，无论是程序还是美术 Package，请注意都要自己理解透，在按照自己的项目结构整理进对应的目录，如果是代码，不建议整合进自己的项目，如下：
MNet
Resources
这个目录是放置一些必要资源（随包体且需要动态加载），也就是说在这个文件夹里的所有文件，不管有没有使用，都会统统自动打进包内，不过 Unity 会执行资源压缩，访问这个目录的资源需要通过 Resources.Load 接口进行加载，注：它是一个只读的文件夹，程序运行时只能读不能写，在实际的项目中一般只会放必要的少量资源在这个目录中，大部分资源会放在别的目录下，打成 AssetBundle 文件放在 StreamingAssets 目录中。
StreamingAssets
流式资源目录，必须在 Assets 根目录下，这个文件夹里的所有文件，不管有没有使用，都会统统自动打进包内，与 Resources 不同的是，该目录下的文件打包时不会被压缩，会原封不动打进包内。它是一个只读的文件夹，程序运行时只能读不能写，它在各个平台下的路径是不同的，我们可以使用 Application.streamingAssetsPath 访问该路径，实际项目中一般会把资源打成 AssetBundle 放在该目录中，如果想了解 AssetBundle 下载，后面我有时间当读写一篇来做讲解。
Scenes
这里简单介绍下吧！场景目录，肯定是存放场景文件的目录，和场景耦合的一些 Lighting 灯光烘焙数据、Navigation 导航数据等建议打包成 Prefabs 动态加载，这里一般会分成几个目录（根据项目来定），例如：PVE 关卡类项目，可以有 Levels，LevelEditor 目录等，最好有明确的目录标识。
建议
[*]如非必要，尽量不要在根目录创建目录，就算创建也最好有清晰的命名，下面这个就是一个典型不太好的案例，绿色的文件夹还是有必要的建议放置在 Assets 根目录下，这些平台脚本建议收拢到根目录的一个 Build 目录下会更好，通过 svn 外链或者 git submodel 的方式引用；
错误示范
[*]尽量不要将任何资源放置在根目录中，尽可能放置在 Artwork 目录对应的目录，特别是有些 Package 资源包（资源商店下载的）一般都很随意，建议理解后，按照材质、纹理、Shader 以及模型的目录对应放置，且命名最好有严格的规范，建议程序同学写一个脚本检测；
[*]尽量应用 AB 资源方式管理资源，尽量减少 Resources 的使用；
为什么不使用 Resources 机制来加载与卸载资源呢？Resources 机制不方便资源更新，不方便打空包, Resources下的所有资源以及相关依赖都会被打包进去。Resources 也不方便资源更新, 所以干脆使用纯AssetsBundle 来做资源的加载与卸载，方便打空包，同时也方便资源更新。如果不打空包，只要把打包出来的AB 包放到 StreammingAssets 目录下，这个目录下的所有的资源都会打包进去，到时候到这里来读取 AB 包就可以了。
[*]Scripts 作为代码的主体维护的文件夹，其实对它的分类非常的重要，我给大家看一个早些年，还是 Unity 5.X 版本时候的一个项目，其实是按照 ECS 来的，现在看起来还是有很多问题，但是也相对比较清晰，看目录结构就知道是干什么。
ECS
[*]Unity 提供非常方便的场景编辑器，我们连拖带拽，随便挂脚本（生命周期没有保障，查问题难），很容易就能在场景里面搭建出游戏所需的场景（我经常夸张的说，我儿子 8 岁，他 Unity Playground 很快就能搭建一个场景出来，确实很简单一点不夸张），但是这种方式我们在实际的项目中是坚决不允许的；
首先不方便多人同时编辑场景后的代码提交与合并, 如果有冲突很麻烦也很难解决，其次也不方便打空包,节点都在场景，打包时,节点依赖的资源都会被打包进去，建议建立严格的命名和加载规则，美术按照规则输出，策划配置配置表，程序输出支持规则的包，美术输出资源，策划配置打包 AB 资源，美术和策划就能在真实环境看到效果；总结
由于晚上去游泳，导致只能加班来整理这部分内容，时间也不早了，一不小心又到了晚上 11 点了，周报还没有写呢，就到这里吧！最后附上今晚上的游泳成绩，还差 9s 达成今年的目标，加油！！！
很好的干货，同时请教下，unity项目怎么备份？现在遇到一个问题，unity项目太大了，得有差不多10G左右，如果完整拷贝太占空间了。有没有比较好的备份机制？ 如果都是有效资源话（Library 目录建议删除），10G 确实有点大了，估计你们构建做平台切换花费的时间也要很长吧！如果是备份其实我建议美术资源采用 svn 外方式或者 git submodule 方式，特别是 raw 资源（原画、音频、UI 未做图集处理前的资源等等）； 上SVN啊[思考]
页:
[1]