Unity 游戏框架搭建：目录结构设计

我们在最近几篇的文章里，学习了刘钢老师的《Unity 项目架构设计与开发管理》的部分内容。到这篇为止，学习的这些内容已经够我们消化一段时间了。

那么我们今天开始进行正式的整理。

我们先回顾一下当前的目录,如下: 我们收集了十四个示例。

在正式整理之前，我们进行一次备份。我们目前已经导出的版本如下:

• QFramework_v0.0.0: 第一次整理前备份
• QFramework_v0.0.1: 第一次整理后备份
• QFramework_201YMMDD_H: 第十四个示例完成后的备份 那么我们的这次备份文件的版本应该是_v0.0.2 版本。那么其实不用再进行导出了，而是，直接把 QFramework_201YMMDD_H 这个文件名改成 QFramework_v0.0.2: 即可。

当然如果童鞋在第十四个示例完成之后忘记导出了，那就以现有的版本再进行一次导出就可以了，导出之后记得改名字。

OK，导出的步骤就算完成了。

我们开始准备整理，还记得我们的约定和规则嘛？列出如下： 约定和规则:

• 每个示例在 QFramework 目录下创建一个文件夹，文件夹的格式是: 数字.示例的功能
• 每个示例写一个脚本，脚本中包含可复用的静态方法和 MenuItem 方法。
• 每写一个示例进行一次导出，导出的文件名后边加上日期和时间，这个功能已经在导出功能里内置了。
• 每次有 API 变更的时候做一次备份，备份的名字采用 QFramework_vX.Y.Z 格式。
• 每次进行整理的时候要确保是在功能有效的情况下进行删除和变更。
• 确保菜单名和文件夹名一致。
• 要给类/代码文件取合适的命名。
• 在删除弃用代码的步骤:

1. 消除弃用警告。
2. 搜索弃用方法的引用，并逐个升级为最新的方法。
3. 全局搜索方法名，并根据情况逐个升级为新的方法。

如果按照这个规则，把每个 Manager Of Managers 里的 Manager 都实现一遍，那么我们的示例就会从 14 个变成 20 多个。这样在 QFramework 的一级目录下文件会非常多。而在未来我们会收集越来越多的工具，框架的东西也会越来越多，那么如果每个工具和功能都写一个示例，那么当展开 QFramework 的目录的时候可想而知是有多壮观了。我们在这次，不得不解决掉这个问题。

目录结构设计

我们要重新组织目录。从我们自身出发思考，我们是框架是用来干什么的？

1. 知识库
2. 工具库/类库
3. 框架

第一个知识库，其实就是我们的示例本身，我们在未来，通过查看一下示例，就能知道一些知识点或者 API 如何用？从这个使用目的去思考，知识库部分，其实就是 Example。所以，可以把我们的知识库相关的部分提取成 Example。

第二个工具库/类库，全部都是可复用的代码库，当然有的功能是适用于 Editor 环境下的，有的功能是适用于 Runtime 环境下的。不过这个到时候细分一下就好了。那么它是属于框架的一部分，所以所在的文件夹是 QFramework/Framework/Util 和 QFramework/Framework/Editor。

第三个框架，框架部分就是我们目前的核心部分，目前只有一个 QMonoBehaviourSimplify，而之后呢，需要加入很多 ManagerOfManagers 的 Manager，这部分内容的目录结构，暂时还没有想法，所以就全部扔到 QFramework/Framework 下方就好了。所以到此，我们的目录结构如下:

• QFramework
• Examples
• Framework
• Editor
• Util

Examples 里在未来还是充当知识库的作用。 而 Framework 里到时候放的就是货真价实的框架。这就算是这次目录的结构的设计了。它能满足我们的学习需求，也能满足框架文件的合理存放需求。但是还不够，肯定之后会有很多问题的，不过没关系，遇到了问题再说，大不了就再整理一次，而且现在的版本才 0.0.3 版本，用的人也是自己，用不着去发布给别人用。所以我们不着急一开始就设计一个非常严格且合理的文件结构。

目录结构就设计到这，我们有了一个还不错的结论。

菜单栏的设计

关于菜单栏的设计，目前可以先不考虑，可以是等到目录全部分好了之后再去设计。

转载请注明地址：凉鞋的笔记： liangxiegame.com 订阅全套专栏或参加小班： liangxiegame.com