前几天，我发了一篇文章，介绍了自己开源的 Unity 框架 MyFramework。

文章发出去以后，没想到关注的人比我预想的多一些。

公众号和知乎都有不少阅读，也有一些人去 GitHub 点了 Star，还有一部分人加入了交流群。

这几天被问得比较多的问题是：

这个框架和 ET 有什么区别？

和 QFramework 有什么区别？

是不是重复造轮子？

为什么已经有这么多 Unity 框架了，还要自己写一套？

这些问题很正常。

因为在 Unity 开发圈里，ET 和 QFramework 都是大家比较熟悉的框架。

如果一个新的开源框架出现，很多人第一反应一定是：

它和已有框架相比，到底有什么不同？

这篇文章就专门聊一下这个问题。

但我不想把它写成“谁比谁强”的对比。

因为不同框架面对的问题不一样，设计目标不一样，适合的人群也不一样。

更准确地说：

ET、QFramework 和 MyFramework，并不是同一类框架。

它们解决的是不同方向的问题。

---

一、先说结论

如果用一句话概括：

ET 更偏大型在线游戏的双端全栈架构。

QFramework 更偏轻量、渐进式、快速开发和架构学习。

MyFramework 更偏长期 Unity 商业项目工程化，以及客户端和服务器配套工具链。

这三者的差异，不是简单的“功能多少”或者“代码量大小”。

而是它们从一开始关注的问题就不一样。

ET 更关注：

• 客户端和服务器一体化

• C# 服务端

• 分布式架构

• Actor / Fiber

• 多进程服务器

• 网络通信

• 热重载

• 大型在线游戏整体架构

QFramework 更关注：

• 简单易上手

• 低接入成本

• MVC / IOC / CQRS 等架构思想

• UIKit / ResKit / AudioKit 等常用工具

• 快速搭建 Unity 项目结构

• 适合学习和中小项目快速开发

MyFramework 更关注：

• Unity 客户端工程化

• HybridCLR 热更新分层

• UI 代码自动生成

• 配置表工具链

• 协议代码生成

• 客户端与 C++ 服务器配套

• 资源管理

• 对象池

• 工程检查

• 低 GC 和强生命周期控制

所以我不会说 MyFramework 是 ET 或 QFramework 的替代品。

更准确的说法是：

如果你要研究大型在线游戏双端架构，ET 很有价值。

如果你想快速学习 Unity 项目架构和常用工具，QFramework 很合适。

如果你更关注长期 Unity 商业项目中的 UI、配置、协议、热更新、资源和服务器配套流程，MyFramework 会更贴近这个方向。

---

二、为什么不能简单说谁更强

很多框架对比文章容易写成：

A 比 B 强。

B 比 C 简单。

C 比 A 更适合商业项目。

但这种说法其实没有太大意义。

因为框架不是孤立的代码集合，而是一个开发方式的选择。

不同框架背后代表的是不同问题。

比如 ET。

如果你要做的是大型在线游戏，尤其是涉及服务器架构、分布式、Actor、双端 C#、多进程服务端这些内容，那么 ET 的方向是很明确的。

它不是只帮你封装几个 Unity 工具，而是试图解决客户端和服务器整体架构的问题。

再比如 QFramework。

QFramework 的核心优势之一就是简单、轻量、渐进式。

它可以让开发者用比较低的成本接入一套架构思想。

对于很多中小项目、独立游戏、教学项目，或者想学习 Unity 架构组织方式的人来说，这种轻量方案非常友好。

而 MyFramework 不是朝这两个方向做的。

它不是为了做一套最轻量的架构，也不是为了做一套完整的 C# 分布式服务器体系。

我当初写它的原因很简单：

我在长期 Unity 项目里，遇到了太多重复、容易出错、后期难维护的问题。

所以我需要一套更可控的工程体系，把这些问题统一管起来。

---

三、MyFramework 最初解决的不是“架构好不好看”

很多框架一开始会讨论：

• 应不应该 MVC

• 应不应该 ECS

• 应不应该 IOC

• 应不应该事件驱动

• 应不应该数据驱动

• 应不应该模块化

这些问题当然重要。

但我在真实项目里更常遇到的问题其实是：

UI 节点越来越多，手写绑定越来越痛苦。

配置表字段改了，客户端和服务器容易不一致。

协议字段顺序写错，调试起来很浪费时间。

资源引用乱了，打包后才发现资源缺失。

热更新代码和非热更代码边界不清，后面维护很麻烦。

对象频繁创建销毁，GC 和生命周期都不好控制。

项目跑久了，很多隐藏问题不是靠人记住规范能解决的。

所以 MyFramework 的思路不是先设计一个很漂亮的架构图，再往里面填功能。

它更像是从实际项目中一点点长出来的。

遇到 UI 绑定重复，就做 UI 代码生成。

遇到配置表容易出错，就做配置表检查和代码生成。

遇到客户端和服务器协议不一致，就做协议生成。

遇到资源规范难靠人维护，就做资源检查。

遇到运行时对象创建太多，就做对象池和生命周期管理。

遇到热更新边界混乱，就明确拆出 Frame_Base、Frame_Game、Game、Frame_HotFix、HotFix。

所以 MyFramework 的核心不是某一个单独模块。

它真正想解决的是：

长期 Unity 项目怎么把工程复杂度管住。

---

四、和 ET 的区别

ET 是一个非常成熟的 Unity 客户端与服务器全栈框架。

它最强的地方在于双端一体化，尤其是服务端架构。

如果一个项目希望客户端和服务器都使用 C#，并且希望深入研究 Actor、Fiber、多进程、分布式游戏服务器等内容，那么 ET 是一个很有代表性的选择。

它更像是在回答这个问题：

一个大型在线游戏的客户端和服务器整体架构，应该怎么组织？

而 MyFramework 更像是在回答另一个问题：

一个长期 Unity 商业项目中，客户端工程化和工具链应该怎么组织？

这两个问题有交集，但重点不同。

1. ET 更重视双端全栈

ET 的重点不是只在 Unity 客户端。

它的服务端体系是核心能力之一。

很多人研究 ET，并不是只为了学 Unity UI 怎么写，而是为了理解整套在线游戏架构。

包括：

• 服务端进程如何组织

• 消息如何分发

• Actor 如何通信

• 服务器状态如何管理

• 客户端和服务端如何共享代码

• 热重载如何提高开发效率

这些是 ET 很重要的方向。

2. MyFramework 更重视 Unity 客户端工程化

MyFramework 当然也有配套服务器框架。

但 MyFramework 本身更重视 Unity 客户端开发中那些每天都会遇到的问题。

比如：

• UI 怎么自动生成代码

• 资源怎么统一管理

• 配置表怎么检查

• 网络协议怎么生成

• 热更新代码怎么分层

• 对象池怎么管理

• 工程资源怎么扫描

• 多语言怎么处理

• 红点、特效、Tween、输入怎么统一

这些问题不一定像分布式服务器那样“高大上”。

但在长期商业项目中，它们每天都会出现。

处理不好，后期维护成本会非常高。

3. MyFramework 不想和 ET 拼服务器架构

这点要说清楚。

MyFramework 不是想证明自己比 ET 的服务器架构更强。

ET 在服务端架构、双端体系、社区沉淀上有很深的积累。

MyFramework 的优势不是这个方向。

MyFramework 更想强调的是：

我有一套 Unity 客户端框架，同时有配套 C++ 服务器框架。

协议、配置、消息结构可以形成客户端和服务器的工具链闭环。

也就是说，它更偏“客户端工程化 + 配套服务器流程”。

而不是“我要做一个 ET 的替代品”。

---

五、和 QFramework 的区别

QFramework 和 MyFramework 的差异更明显。

QFramework 的核心优势是：

轻量。

简单。

渐进式。

容易学习和接入。

它的核心架构可以浓缩到很小的代码规模里，这本身就是它的设计目标之一。

对于很多 Unity 开发者来说，QFramework 的价值在于：

• 快速理解 Unity 项目架构

• 学习 MVC / IOC / CQRS 等思想

• 使用 UIKit 快速管理界面

• 使用 ResKit 管理资源

• 使用 AudioKit 管理声音

• 用比较低的成本改善项目结构

这类框架非常适合学习和快速开发。

它解决的问题是：

如何让 Unity 项目更快进入一个相对清晰的架构状态。

而 MyFramework 的方向不一样。

MyFramework 不是为了“尽可能轻”。

它甚至可以说有点重。

因为它不是只提供一个架构核心，而是把很多工程流程都放进来了：

• UI 生成工具

• 配置表工具链

• 协议生成

• 热更新分层

• 资源检查

• 代码检查

• 对象池

• 自定义 UI 封装

• 网络消息系统

• 配套服务器框架

• 大量基础工具类和单元测试

所以如果一个人想找一个“复制进项目就能马上理解”的轻量框架，MyFramework 不是最合适的。

但如果一个人已经做过长期项目，遇到过 UI、配置、协议、资源、热更新、服务器协作这些问题，那么 MyFramework 的设计取向会更容易理解。

1. QFramework 更像架构入门和快速开发工具箱

QFramework 的优势在于降低门槛。

它让很多开发者第一次接触到比较系统的 Unity 架构组织方式。

这点很有价值。

因为很多 Unity 项目最大的问题不是框架不够强，而是一开始完全没有架构意识。

QFramework 在这个阶段很适合。

2. MyFramework 更像长期项目工程工具链

MyFramework 更关注的是：

当项目持续几年后，哪些问题会反复出现？

哪些东西靠人手写一定容易出错？

哪些检查应该由工具自动完成？

哪些代码应该通过生成减少重复？

哪些模块应该被框架统一管理？

所以 MyFramework 的很多设计不是为了让初学者第一眼觉得简单，而是为了让长期项目后期还能维护下去。

---

六、为什么我要自己写一套

很多人会问：

既然已经有 ET 和 QFramework，为什么还要自己写？

我的答案是：

因为我遇到的问题和它们的核心方向不完全一样。

我并不是为了证明自己能写框架。

也不是为了单纯重复造轮子。

而是在长期项目中，我需要一套更符合自己开发习惯和项目需求的工具链。

我希望它满足几个目标。

1. 生命周期必须明确

我不太喜欢隐藏太多流程。

一个系统什么时候创建，什么时候初始化，什么时候更新，什么时候销毁，我希望是明确的。

这也是 MyFramework 整体代码风格偏传统游戏引擎开发方式的原因。

2. UI 不能靠人一直手写绑定

Unity UI 项目做大以后，节点绑定是非常重复而且容易出错的。

我希望 UI Prefab 中需要访问的节点，能够直接生成对应成员变量和绑定代码。

程序只需要写业务逻辑，不要每天重复写查找节点和缓存组件。

3. 配置和协议不能靠口头约定

客户端和服务器之间，最怕的就是结构不一致。

字段顺序不一致，类型不一致，消息 ID 不一致，都会产生很隐蔽的问题。

所以配置表和协议都应该尽量通过工具生成，而不是靠人工同步。

4. 热更新边界必须清楚

Unity 商业项目中，热更新非常常见。

但热更新不是简单接一个 HybridCLR 就结束了。

更重要的是：

哪些代码放热更？

哪些代码不能热更？

框架层和业务层怎么拆？

编辑器代码和运行时代码怎么区分？

所以 MyFramework 里明确拆出了多个层级，而不是把所有代码混在一起。

5. 工程检查不能只靠人工规范

很多项目都有规范文档。

但只靠文档是不够的。

因为项目一忙，规范一定会被忘。

所以我更倾向于把能检查的东西尽量工具化。

比如：

• 资源引用检查

• UI 节点检查

• 代码规范检查

• 热更引用检查

• 图集检查

• 多语言检查

• 缺失脚本检查

这些东西越早发现，成本越低。

---

七、MyFramework 适合什么人

MyFramework 不是一个适合所有人的框架。

它比较适合下面几类人。

1. 做过中大型 Unity 项目的人

如果你已经做过一两个长期项目，应该会理解很多问题不是 Demo 阶段能看出来的。

例如：

• UI 越来越难维护

• 配置越来越多

• 协议越来越多

• 资源越来越乱

• 热更新边界越来越模糊

• 代码规范越来越难靠人维护

这些问题积累到后期，都会变成项目成本。

MyFramework 主要就是为这类问题服务的。

2. 想研究 Unity 客户端工程化的人

如果你关心的不只是“功能怎么做出来”，而是：

• 项目结构怎么设计

• 工具链怎么配合

• 代码生成怎么减少重复

• 工程检查怎么落地

• 资源、UI、协议、配置怎么统一管理

那 MyFramework 会有一定参考价值。

3. 想同时研究客户端和服务器配套流程的人

MyFramework 还有一个配套的 C++ 服务器框架。

两者可以围绕协议、配置、网络消息形成一套流程。

如果你对 Unity 客户端和自研服务器配套感兴趣，这也是它和很多纯客户端框架不同的地方。

4. 喜欢强控制风格的人

MyFramework 的代码风格不是轻量、魔法、自动化隐藏一切的方向。

它更偏显式、强控制、强生命周期。

如果你喜欢这种传统游戏引擎式开发方式，可能会比较适应。

如果你更喜欢极简、低侵入、快速接入，那 QFramework 可能会更舒服。

---

八、MyFramework 不适合什么人

同样也要说清楚。

MyFramework 并不适合所有开发者。

1. 不适合只想快速做一个小 Demo 的人

如果你只是想快速做一个小游戏，或者几天内完成一个原型，MyFramework 可能显得太重。

这种情况下，使用 Unity 原生功能或者轻量工具就够了。

2. 不适合完全不想理解框架的人

MyFramework 有自己的代码风格、目录结构、生命周期和工具链。

如果只是希望导入后什么都不用理解，直接拖几个组件就完成开发，那它不是这个方向。

3. 不适合想要完整分布式服务器方案的人

如果你的目标是深入研究 C# 分布式服务器、Actor、Fiber、多进程服务端架构，那么 ET 可能更适合作为主要研究对象。

MyFramework 的服务器配套更偏向于和 Unity 客户端形成协议、配置和业务流程闭环。

它不是为了取代 ET 的服务端架构方向。

---

九、我怎么理解“重复造轮子”

写框架很容易被说重复造轮子。

这个说法不能说错。

因为从功能点上看，很多东西确实已经有人做过。

UI 框架有人做过。

资源管理有人做过。

对象池有人做过。

配置表有人做过。

协议生成有人做过。

服务器框架也有人做过。

但问题在于：

你的项目到底需要什么样的轮子？

如果已有轮子完全符合你的开发方式，那当然没必要重新写。

但如果你需要的是一整套符合自己项目流程的工具链，那么自己写一套也不是没有意义。

对我来说，MyFramework 的价值不在于某一个单独模块有多稀有。

而在于这些模块能否形成一套统一的开发流程。

例如：

• UI Prefab 可以生成代码

• 配置表可以检查并生成代码

• 协议可以生成客户端和服务器代码

• 服务器可以配套客户端联调

• 热更新代码有明确分层

• 资源和代码能被工具检查

• 项目结构长期保持可维护

这些东西组合在一起，才是这个框架真正想表达的价值。

---

十、如果你已经在用 ET 或 QFramework，还需要看 MyFramework 吗

这取决于你的目的。

如果你已经在用 ET，并且你的项目方向就是双端 C#、服务端架构、分布式在线游戏，那么继续深入 ET 是合理的。

MyFramework 不一定适合作为替代品。

但你仍然可以参考它的一些客户端工程化思路，比如：

• UI 代码生成

• 配置表检查

• 工程资源检查

• 热更新分层

• 客户端工具链组织方式

如果你已经在用 QFramework，并且项目规模不大，或者你主要追求快速开发和轻量架构，那也没有必要因为看到 MyFramework 就马上迁移。

但如果你后面遇到这些问题：

• UI 节点越来越多

• 配置和协议越来越难维护

• 热更新代码边界不清

• 客户端和服务器结构不同步

• 工程资源检查缺失

• 项目长期维护成本上升

那 MyFramework 也许可以提供一些参考。

框架不是信仰，不需要站队。

真正重要的是：

它能不能解决你的项目问题。

---

十一、我希望 MyFramework 成为什么

我不希望 MyFramework 被理解成：

又一个 Unity 小工具集合。

也不希望它被理解成：

某个成熟框架的替代品。

我更希望它成为一个可以参考的 Unity 工程化案例。

一个开发者看到它以后，可以了解：

• 一个长期 Unity 项目可以怎么拆分热更新层

• UI 自动生成可以怎么落地

• 配置表工具链可以怎么做

• 协议生成如何配合客户端和服务器

• 资源检查和代码检查能解决什么问题

• 对象池和生命周期管理如何组织

• 客户端框架如何与服务器框架配套

如果有人直接拿去用，那当然很好。

如果有人只是参考其中一部分设计，把它改造成自己的项目工具链，我也觉得有价值。

开源这个项目，不是为了告诉别人“你必须这样写”。

而是想给正在做 Unity 项目的人提供一个真实工程的参考。

---

结语

ET、QFramework 和 MyFramework，代表的是三种不同的方向。

ET 更偏大型在线游戏双端全栈架构。

QFramework 更偏轻量、渐进式、快速开发和架构学习。

MyFramework 更偏长期 Unity 商业项目工程化，以及客户端和服务器配套工具链。

它们不是简单的强弱关系。

选择哪个框架，取决于你要解决什么问题。

如果你正在学习 Unity 架构，想快速建立项目结构，QFramework 很值得看。

如果你正在研究大型在线游戏双端架构，ET 很值得研究。

如果你关注的是 Unity 商业项目中的 UI、配置、协议、热更新、资源检查、低 GC、强生命周期和服务器配套流程，那么 MyFramework 也许可以给你一些参考。

项目地址：

GitHub - ZHOURUIH/MyFramework: Unity 商用级别开发框架,经过了多年经验沉淀.一个在unity上使用的网络游戏客户端开发框架,为unity所有使用方式提供完善的封装和管理,只需要专注于游戏逻辑的编写 · GitHub

配套服务器框架：

GitHub - ZHOURUIH/MyServerFramework · GitHub