（干货）为什么要重制？（二十四篇）？

2024-03-03

还记得上一版本第24章的约定吗？现在就出来兑现吧~

为什么要重拍？

我之前写的专栏都是根据自己的心情写的。一开始，作者什么都不懂，文章发表的顺序也很随意。结果就是大家读完之后，对框架还是没有概念，感觉很混乱。现在，经过两年多的探索，作者对框架体系有了一定的了解，所以希望再次发布这个系列专栏。

为什么不直接在原来的文章中修改呢？

正如上轮第二十四专栏中提到的：虽然之前的内容已经过时，但是这些专栏对作者来说意义重大。他们记录了作者成长的一段经历贴图笔刷，大家的评论都在评论区分享。还有一些有意义的问答支持和鼓励游戏开发框架，所以我不忍心破坏这些珍贵的回忆。

更新了哪些内容？

本次重制版更新内容重点关注以下几点：

在原有内容的基础上添加更多内容。对不流畅、难以理解、含糊不清、不够严谨的表述进行修改和优化。顺序调整：内容将从由易到难、由浅入深、由常用到不常用三个角度进行排版，以提升阅读体验，让其更容易、更完整地掌握。 QFramework的介绍和原理，重点是UI和资源管理模块的介绍和原理。

组织的内容结构如下：

希望这次能给大家展示一个更清晰的框架知识体系。

这就是本专栏翻拍的背景。接下来开始正文。

架构与框架首先了解什么是架构？

建筑是一种惯例、一种规则、一种共识，每个人都知道要遵守。那么这是什么样的协议、什么样的规则、什么样的共识呢？

让我以袋子为例。我经常旅行，背包里装了很多东西。笔记本电脑、电源、2张网卡、鼠标、USB线、一盒大名片、一盒小名片、口香糖、Mini-DisplayPort转VGA接口、U盘、几支笔、小螺丝刀、洗漱用品，干净的衣服游戏开发框架，袜子，香水，老婆给我带来的洗面奶（她觉得我最近很累，脸有点黄），钱包，令牌卡，耳机，纸巾，USB线2d素材，U盘等等。包有很多隔层。我把常用的物品放在外层隔层里，比如笔、纸、一盒小名片等；中间隔层通常装有衣服、袜子、洗漱用品、香水等；背面的大隔层可放置笔记本电脑。类似于笔记本电脑的小格子里有两张网卡、Mini-DisplayPort转VGA接口、一大盒名片、一个记事本。类似于笔记本电脑的大网格，里面有电源、鼠标、口香糖等。

我可以闭着眼睛把东西从包里拿出来，我也可以闭着眼睛把东西放进包里！但不幸的是，一旦我的妻子整理我的包，我就痛苦不堪，发疯了，因为我什么也找不到！如果我那还不到两岁的“小可爱”翻车了那就更不幸了。

这个包就是我放置所有物品的“结构”，每件物品的位置就是我的“协议、规则和共识”。如果我的妻子也知道我的“结构”，我的“协议、规则、共识”，那么无论她怎么搬我的包，我仍然可以轻松地拿或放东西。而且，如果我的同事也知道我的“结构”和我的“协议、规则、共识”，那么我根本不知道他们什么时候碰我的包裹！ ——陶发自然《十年反思：什么是结构？》 ——破坏结构！》

什么是框架？

框架是一个框架——指的是它的限制性，而一个架子——指的是它的支撑性。 ——360百科

概括

本节简单了解框架和架构的概念，得出以下两个结论：

说到这里，大家应该对这两个概念有了感受了。但仍然存在很多问题，比如“如何构建一个结构？”、“框架的约束和支撑是什么以及如何体现？” 等等。这些将在后续专栏中详细解释。这是对架构和框架的第一次介绍。

QFramework简介

两年前，也就是毕业半年后，我刚从cocos2d转到Unity不到两个月。我当时工作的公司有一个游戏开发框架。作者用它在一个项目上工作了两个月。当我用框架做项目的时候，我并没有思考框架是什么。我一开始只是觉得很新鲜，而且越用越舒服，尝到了它的甜头。

后来，笔者接到了一个跑酷游戏项目，于是辞掉了工作，决定全职做这个项目。辞职后，公司框架因保密协议而无法使用。项目只能从头开始开发，结果就是跑酷项目开发过程中各种水土不服。

于是，笔者开始挑选市面上的开源框架。纠结了几天，发现要么上手太难，要么学习成本高，文档不全。有些框架需要很长时间才能理解这些概念。对于我这样的新手，对于应届毕业生来说，市面上的开源框架确实不太友好。

当时笔者决定为自己开发一个适合自己使用习惯的框架，就是现在的QFramework。

为什么叫QFramework？

笔者在做cocos2dx的时候，市面上有一个开源框架叫Quick-Cocos2d-x，可以用简单、强大两个字来形容。

作者一直认为好的工具应该是简单的。

QFramework 的目标是像 Quick-Cocos2d-x 一样“简单而强大”。当时作者纠结了很多名字，比如QuickEngine、QuickUnity等等，Q代表Quick，字母Q给人的感觉很灵活、灵活，所以最终决定是QFramework。

Q框架目标

我记得本系列上一轮第十篇文章中有这样一段话：

作者的意图是构建QFramework，让用户感觉框架中出现的所有概念都必须非常清晰，没有任何模糊的概念，已经达成共识的概念，没有任何陌生的概念，使用门槛尽可能低:)。

这个flag是2016年设立的，从用户反馈来看，已经完成得相当不错了。

QFramework组里有人用三个词形容QFramework：简单、粗犷、精致一点。我认为这个描述非常恰当。

目前主要有三个模块，UIKit、ResKit、ActionKit。目前还有一个模块 EditorKit 正在开发中。

说到这里，你可能对 ActionKit 还有些陌生。它的前身是QChain，负责所有异步逻辑，包括UniRx和Promise，以及一组轻量级行为树。稍后会在一篇非常详细的文章中介绍。

QFramework快速入门：

要引入QFramework，附上三段代码就够了：

1.动作套件

this.Sequence()
	.Delay(1.0f)
	.Event(()=>Log.I("Delayed 1 second"))
	.Until(()=>something is done)
	.Begin();

var sequenceNode = new SequenceNode();
sequenceNode.Append(DelayAction.Allocate(1.0f));
sequenceNode.Append(EventAction.Allocate(()=>Log.I("Delayed 1 second"));
sequenceNode.Append(UntilAction.Allocate(()=>something is true));
this.ExecuteNode(sequenceNode);

2.资源套件

// allocate a loader when initialize a panel or a monobehavour
var loader = ResLoader.Allocate<ResLoader>();
// load someth in a panel or a monobehaviour
loader.LoadSync<GameObject>("Resources/smobj");
loader.LoadSync<Texture2D>("Resources/Bg");
// load by asset bundle's assetName
loader.LoadSync<Texture2D>("HomeBg");
// load by asset bundle name and assetName
loader.LoadSync<Texture2D>("home","HomeBg");
// resycle this panel/monobehaivour's loaded res when destroyed 
loader.Recycle2Cache()
loader = null

3.用户界面套件

// open a panel from assetBundle
UIMgr.OpenPanel<UIMainPanel>();
// load a panel from specified Resources
UIMgr.OpenPanel<UIMainPanel>(prefabName:"Resources/UIMainPanel");
// load a panel from specield assetName
UIMgr.OpenPanel<UIMainPanel>(prefabName:"UIMainPanel1");

这里介绍一下QFramework。

Unity中常用的架构，儿童节礼物

今天是儿童节。作为礼物，我想送给你一段对我影响最大的一段话：

写项目的时候，不要目光短浅，说我会完成项目。我只需要支付费用并上网即可。我们希望我们每次写游戏的时候，都能积累一些东西，把我们写的每一行代码都当作一种可以收藏甚至传承的资产。有了这样的想法，也许我们在写代码的时候，整个思维模式就会完全不一样了。 ——刘刚《Unity项目架构与开发管理》

上面这段话来自于刘刚老师的讲座《Unity项目架构设计与开发管理》的结尾。

Unity项目架构设计与开发管理

笔者在学习Unity不久后有幸看到了刘刚老师的这段视频。笔者当时深受启发。视频中提出的 Manager Of Managers 很好地为 QFramework 指明了方向。视频简单易懂，里面很多内容值得反复咀嚼。我花了很长时间才消化掉里面的内容。直到今天，再次观看这个视频，我仍然收获颇多。希望大家看完后有所收获、有所启发。

视频中最精彩的部分是从一个没有架构的项目逐渐演变到MVVM和StrangeIOC架构。

关于Unity的架构，常用的有几种方法，简单总结如下：

1.清空GO：

在Hierarchy上创建一个空的GameObject，然后附加所有与GameObject无关的逻辑控制脚本。使用 GameObject.Find() 访问对象数据。

缺点：逻辑代码分散各处，不适合大型项目。

2.简单的游戏管理器：

所有与 GameObject 无关的逻辑都放在单例中。

缺点：单个文件太大。

3.经理中的经理：

分别管理不同的功能。如下：

4. 在视图和模型之间添加媒体层。

MVCS：奇怪的IOC插件。