开发平台：Unity 2020
编程平台：Visual Studio 2020
参考文档：Unity 组织项目文档
 

前言

---

  应用型开发是 Unity 开发者固有的技能特性。其基于现有 Unity API + 三方SDK 等条件基础上，创新设计可创造价值与回报的行为。然而，每一次应用开发设计并非是全新方向的探索开发，在该方向上，仍然存在相当数量的功能、框架、工具在以往的历史工程项目中可见。例如 UGUI Framework、Src、Designer Module、Font 或是其他资产内容，以提高复用性。
 

如何设计资产目录结构

---

  在 Unity 的众多案例资产目录中，关注到其目录结构的设计合理性与可移植性。基于原文档总结与建议，个人归纳如下：

• 区别 自建框架 、公司框架、第三方工具包
  自建框架：由自己根据项目开发需求，建立的框架内容，关联内容基于该框架运行。
  公司框架：由前辈建立的开发框架体，尚不确认该框架结构设计是否规范、可移植性问题。必要时，即使关联项多也必须存放至该文件目录下，即无论以后如何变化，均不可向其添加任何脚本。
  第三方工具包：由第三方工作室、团队或个人开发者发布的资产内容。其本质上不属于公司或个人开发者创建的资产。可改动性上不存在。同时因为其第三方包体特性，这类包体内的工具存在较强的可移植性。
• 规范 框架、功能 的应用方式
  框架：仅保留核心运行内容，任何基于该框架上的开发脚本应独立于该框架下进行。例如 UGUI Framework 下建立 UI Page 等实现应用内容，此应用产生的脚本、预制体应单独存放于另外的资产文件夹。例如 Unity 官方文件夹结构中 提供 Level/Prefabs 的路径文件夹。
  功能：自由应用性 与 固定应用型。自由应用型 是基于固定应用型提供的逻辑，这种逻辑在相当长的时间内得到一次更新。例如 Unity 针对实际用户可能的需求，提供了 TransformUtility、EditorUtility、RectTransformUtility 等助理方法。同理我们可建立 GameObjectUtils 管理场景内物体状态信息，组件信息，亦或是 ProjectUtils 管理 Asset资产库 的文件夹结构。
• 开发中注重 框架性
  重复性的功能开发是开发者最忌讳与无意义的事情，在开发过程中，应注意与尝试做成可移植工具包等内容，用以移植。

 

关于我的框架设计

---

• Art 艺术资产：由主持开发者承认的资源资产。
  一个项目的开发涉及 UI美术/特效美术/地编/模型/音效/程序 等多名成员协同。当然，并非必须限定为以上类型的成员，多名程序开发也是经常遇见的事情。参与成员的数量越多 + 参与者职责种类繁多 的情况下，容易造成资产紊乱的情况。所以 Art 资产文件一般由1-3名成员协作整理各成员使用的自用资产类型，以更好的应为开发环境。一般情况下，由团队成员参与的资产存放至 Experimental 实验性资产。
• Framework 开发框架：由主持的程序开发者所管理的框架资产。
  是 程序开发者 在历史开发过程中，总结的程序架构与工具组。例如 一套成熟的 UGUI 加载方案，AssetBundle 热更新方案，TCP 通讯协议，亦或是多平台的适配工具等。值得注意的是 本资产文件目录，仅存放80%以上由开发者自建框架的内容。若完全依赖于第三方总结的框架内容，应建议存放至 Third Party 目录下。
• Resources 动态资产：需要动态加载的资产对象（程序）
  尽管 Resources 在如今看来没有 AssetBundle 加载模式那么性能表现优越。但加载设定配置上，依旧保持着不可撼动的地位。例如 SO数据的存储与动态加载，在 Unity 2020 推出的 TMP 文本设置等配置文件再合适不过。当然，为管理项目中的设定，使用 SO数据 建立设置文件，以 UI 形式访问设置信息，加以修改。当然，不会使用 AB 加载模式下，选择 Resources 加载模式也是可以的（中小型项目即可，大型项目请务必考虑 AB 加载）。
• Level 级别资产：场景管理
  由主持开发者管理项目在用场景。特别的注意！若非必要情况，除主持外的所有人员均不可直接在该场景内进行。若需要从该场景下修改内容，应当在 主持负责人 + 场景负责人 的协助下进行。或复制该场景修改，待主持开发者统一替换（局限性：无法应对多人同时修改场景，尤其是多人同时修改统一场景内对象上显得捉襟见肘）
• Docs 文档资产：交付与管理文档。
  由相关资产负责人根据资产类型提供交接与说明的文档。其中一部分包括 备份/记忆 相关开发过程。以帮助新一批开发者/一段时间未参与的开发者快速入手项目内容。具体入手效率视撰写者表达能力与阅读者理解能力而定，为保证文档质量，一般有要求的文本格式与1-3位开发者共同出笔汇总撰写。
• Experimental 实验性资产
  在未被项目主持者采纳审阅的情况下，批准团队成员使用的文件夹。该文件夹内容根据人员类别命名，任何资产/场景/数据均存放至该目录下供团队使用，经由项目主持人确认后，规范资产至 Art 资产目录下。同时，实验性资产 被允许用于非正式项目时的功能 框架等内容测试。直到测试结束。值得注意的是 该文件目录下的所有资产仅作为临时存放点，在终极打包中，该文件应不参与正式项目打包流程，且严格意义其内资产与正式项目使用资产无任何关联性！
• Third Party：第三方资产
  对于中小型公司而言，并未所有的功能均是公司原创资产。例如 DoTween 程序动画，Uniform 气象插件，Motion Rig 程序化骨骼，或者是来源于 Github Gitee 等开源的工具框架等内容。因为其本身不属于 开发者原创内容，其版本管理与内容维护在一定程度上限制了开发的应用。（即使强大到能应对多种需求，但总有难以企及的地方），当然满足开发就足够了。有些时候，该文件目录还会存放 Unity 官方包工具的内容，例如 AR Foudatyion，XR 等内容。
• SRC：程序资产
  主要由 程序开发人员 管理的资产。包括但不局限于 Scripts，Shaders，Graph View 等内容。需注意！非程序人员不可变动此文件夹。在内部文件资产结构上应遵循程序职责进行划分。
• StreamingAssets 外部本地资产
  外部资产一般存放整块项目的配置内容，当然严格意义上，此目录的数据不能影响整体项目的运行情况。有些时候，客户在未准备服务端的时候，可考虑暂时使用该目录作为临时数据存储。若未有服务器规划的设计，应当严格设计该目录结构。

 

关于实际开发

  该框架适用于个人和小型团队的开发与管理。当然从长远角度上看，框架的设计上并不是显得完善。例如 Plugin 依赖的第三方扩展程序存放至 StreamingAsset 或许会更加 。设置在未来开发中遇到更多类型资产需要合理的分配，标记与使用。但有一套框架去管理项目，总比从一堆杂乱中寻找目标好上很多。

2022/9/15 记录

---

  告 2022/09/15 那天，Plugins、StreamingAssets 属于 unity 比较特殊的文件夹对象。由于 Unity 自身设计上的问题，并非所有程序都能被囊括其中。于是，导入外部程序库是事实所需。Plugins 针对三方DLL的特殊收纳文件夹。凡 Assets 目录下的所有 Plugins 目录文件夹将在打包时统一归纳至 “项目名_Data/…/Plugin” 目录下。 太沙雕了，要不是我闲的没事多看一眼。真TM沙雕。
2023/03/20 记录