v1.0.39 修改部分扩展函数的名字,修正新工程导入框架后的运行时AtlasManager报错
一个偏传统游戏引擎开发思路的 Unity 游戏框架与工具链。
MyFramework 不是单纯封装 Unity API 的运行时框架，而是一套围绕实际商业项目开发流程整理出来的工程体系，重点关注：
框架从 0 开始设计并持续迭代多年，目前已经应用于：
支持平台：
✅ Windows ✅ Android ✅ iOS ✅ WebGL
MyFramework 已支持通过 Unity Package Manager 以 Git 插件形式安装。
推荐使用发布分支安装，用户不需要手动指定具体版本号。
GitHub：
https://github.com/ZHOURUIH/MyFramework.git?path=/Packages/com.zhourui.myframework
Gitee：
https://gitee.com/inothingtodo/MyFramework.git?path=/Packages/com.zhourui.myframework
安装方式：
Window Package Manager + Install package from git URL...
然后输入上面的 Git URL。
GitHub 访问不稳定时，可以使用 Gitee 地址。
安装插件后，新建工程中还没有默认启动场景、业务入口脚本和运行时配置文件，需要执行初始化菜单。
普通初始化：
MyFramework/初始化/初始化框架
带 HybridCLR + Obfuz 的初始化：
MyFramework/初始化/初始化框架+HybridCLR+Obfuz
初始化会自动处理：
复制 ProjectTemplate~ 中的默认项目文件 生成 Assets/Resources/Scene/start.unity 生成 Assets/Resources/Settings/FrameSettings.asset 生成 ProjectSettings/MyFrameworkSettings.asset 将 GameEntry 脚本挂接到 start.unity 的 GameEntry 节点 将 start.unity 添加到 Build Settings
如果选择 HybridCLR + Obfuz 初始化，还会自动处理：
安装 HybridCLR 安装 Obfuz 添加 USE_HYBRID_CLR / USE_OBFUZ 宏 设置生成代码输出目录到 Assets/Scripts/AutoGenerated
框架和默认启动场景仍然会使用部分旧输入接口，例如 UnityEngine.Input 和 StandaloneInputModule。
UnityEngine.Input
StandaloneInputModule
如果工程启用了 Input System Package，并且运行时报：
You are trying to read Input using the UnityEngine.Input class...
需要在 Unity 中手动设置：
Project Settings Player Other Settings Active Input Handling = Both
修改后通常需要重启 Unity 编辑器才能完全生效。
MyFramework 最主要的特点不是某一个单独模块，而是一套比较完整的项目开发工作流。
通过在 UI Prefab 上配置需要访问的节点，自动生成 UI 脚本代码与注册逻辑，减少大量重复的查找节点和绑定代码。
UI Prefab ↓ UGUIGenerator ↓ 生成 UI 成员变量 ↓ 生成节点查找代码 ↓ 业务逻辑代码
支持：
使用 CSV 作为配置表格式，并配套自研表格编辑器。
配置表工具链支持：
配置表编辑阶段即可发现大量错误，减少运行时问题。
CSV 配置表 ↓ 表格编辑器 ↓ 字段检查 / 引用检查 / 路径检查 ↓ 生成客户端表格代码 ↓ 生成服务器表格代码
根据协议配置自动生成客户端与服务器消息代码。
协议配置 ↓ 协议生成工具 ↓ 生成客户端消息代码 ↓ 生成服务器消息代码 ↓ 自动注册消息
MyFramework 有配套服务器框架：
https://github.com/ZHOURUIH/MyServerFramework
客户端与服务器可以共享协议生成、配置表生成等工具链，适合需要长期维护的中大型项目。
框架代码按照是否可热更进行了明确分层。
Frame_Base -> 不可热更，最基础的框架代码 Frame_Game -> 不可热更，项目非热更代码的框架 Game -> 不可热更，项目应用层启动逻辑 Frame_HotFix -> 可热更，框架层热更代码 HotFix -> 可热更，项目应用层热更代码
依赖关系大致为：
Frame_Base -> Frame_HotFix -> HotFix Frame_Base -> Frame_Game -> Game Game -> HotFix
这种分层方式可以让框架层和业务层都有较高的热更新能力，同时又保留必要的启动稳定性。
集成 HybridCLR。
除启动和热更新下载逻辑外，大部分代码都可以参与热更新。
集成 Obfuz。
用于提升发布后的代码安全性。
提供完整 UI 封装，避免业务层直接访问 Unity 原生组件。
框架尽量不依赖 UGUI 的锚点和自动布局组件，而是倾向于通过代码显式控制 UI 的位置、尺寸、显示状态和输入逻辑。
不使用 UGUI 默认 EventSystem 作为主要输入派发方式，而是自己实现统一输入检测。
部分 Unity 原生组件仍然可以按需使用 EventSystem，例如 ScrollRect。
统一封装资源访问。
业务层无需关心资源来自编辑器还是 AssetBundle。
提供：
其中按位序列化可进一步降低网络带宽占用。
命令系统用于封装具有完整逻辑意义的事件。
它可以用于：
示例：
数据改变 ↓ 发送命令 ↓ 更新数据 ↓ 刷新界面 ↓ 网络同步
调用方只需要关心触发了什么事件，而不需要关心事件内部涉及哪些模块。
部分逻辑使用组件思想进行组织，通过组合代替复杂继承。
Character ├─ ComponentA ├─ ComponentB └─ ComponentC
适合拆分可复用、可独立更新的功能逻辑。
基于 PrefabPool 抽象出 EffectPool。
QuickEffect 适用于非循环、不带拖尾、需要频繁同时播放的粒子特效。
包含大量基础工具函数，例如：
同时提供大量 Scope 设计，用于实现类似 C++ RAII 的自动释放与状态恢复。
框架包含大量单元测试，主要覆盖：
这部分测试用于保证框架中的基础工具函数和核心逻辑长期稳定。
Editor 中提供了大量项目检查和辅助工具，例如：
这些工具主要用于减少大型项目长期维护过程中的隐性错误。
不同框架的目标并不相同，下表只用于说明设计取向，不代表优劣对比。
MyFramework 并不是为了追求最新潮的架构，也不是为了追求最少代码量。
它更关注：
代码定位清晰，问题出现后能够快速查找。
尽量减少对 Unity 自动行为和第三方插件的过度依赖。
框架中很多地方倾向于显式执行，而不是依赖隐藏生命周期。
优先解决商业项目中真正会遇到的问题：
框架更偏向传统游戏引擎开发思路，强调明确的生命周期、明确的调用关系和统一的代码风格。
MyFramework 现在以 UPM Package 形式组织，框架代码位于：
Packages └── com.zhourui.myframework ├── Runtime │ ├── Frame_Base │ ├── Frame_Game │ └── Frame_HotFix ├── Editor │ ├── Editor_Frame │ └── EditorRes_Frame ├── ProjectTemplate~ ├── package.json └── README.md
安装插件后，用户工程中由初始化菜单生成项目入口和默认文件：
Assets ├── Resources │ ├── Scene │ │ └── start.unity │ └── Settings │ └── FrameSettings.asset └── Scripts ├── AutoGenerated ├── Game └── HotFix
推荐：
Unity 2022.3 LTS 或更高版本
作者当前项目使用：
Unity 6000.2
在 Package Manager 中通过 Git URL 安装：
https://github.com/ZHOURUIH/MyFramework.git?path=/Packages/com.zhourui.myframework#release
国内访问 GitHub 不稳定时，可以使用 Gitee：
https://gitee.com/inothingtodo/MyFramework.git?path=/Packages/com.zhourui.myframework#release
安装完成后执行：
需要同时安装 HybridCLR + Obfuz 时执行：
初始化完成后，默认启动场景为：
Assets/Resources/Scene/start.unity
直接打开该场景运行即可。
为了更直观地展示 MyFramework 在实际 Unity 项目中的使用方式，现已提供一个基于本框架开发的完整塔防游戏 Demo：
项目地址：
https://github.com/ZHOURUIH/MyFramework_TDDemo
MyFramework_TDDemo 不是单个功能的代码片段，而是一个按照 MyFramework 项目结构组织的完整 Unity 工程，可以用于了解框架从项目启动、场景切换到具体游戏业务的整体落地方式。
Demo 当前实现了以 Rogue-like 为核心的塔防战斗玩法，主要包含：
通过该 Demo 可以重点了解以下内容：
Game / HotFix / AutoGenerated
推荐使用：
Unity 2022.3 LTS
克隆项目：
git clone https://github.com/ZHOURUIH/MyFramework_TDDemo.git
使用 Unity 打开工程，等待 Package Manager 完成依赖加载后，打开启动场景：
然后直接运行即可。
Demo 已经在 Packages/manifest.json 中配置 MyFramework、HybridCLR 和 Obfuz 等依赖，一般不需要再次手动导入框架。
Packages/manifest.json
Demo 主要用于展示 MyFramework 的项目结构、开发流程和实际使用方式。建议先运行 Demo 了解整体流程，再结合框架文档查看具体模块。
欢迎交流 Unity 游戏开发、框架设计、客户端开发、服务器开发等相关内容。
群内主要讨论：
详细说明请查看文档目录：
https://github.com/ZHOURUIH/MyFramework/tree/master/文档
服务器项目：
与客户端框架配套使用。
https://github.com/ZHOURUIH/MyFramework_Tool
如果这个项目对你有帮助，欢迎点一个 Star ⭐
你的支持会让我持续完善框架。
MIT
版权所有：中国计算机学会技术支持：开源发展技术委员会 京ICP备13000930号-9 京公网安备 11010802047560号
🎮 MyFramework
一个偏传统游戏引擎开发思路的 Unity 游戏框架与工具链。
MyFramework 不是单纯封装 Unity API 的运行时框架，而是一套围绕实际商业项目开发流程整理出来的工程体系，重点关注：
框架从 0 开始设计并持续迭代多年，目前已经应用于：
支持平台：
✅ Windows ✅ Android ✅ iOS ✅ WebGL
📦 安装与使用
MyFramework 已支持通过 Unity Package Manager 以 Git 插件形式安装。
1. 通过 Git URL 安装
推荐使用发布分支安装，用户不需要手动指定具体版本号。
GitHub：
Gitee：
安装方式：
然后输入上面的 Git URL。
2. 初始化工程
安装插件后，新建工程中还没有默认启动场景、业务入口脚本和运行时配置文件，需要执行初始化菜单。
普通初始化：
带 HybridCLR + Obfuz 的初始化：
初始化会自动处理：
如果选择 HybridCLR + Obfuz 初始化，还会自动处理：
3. 输入系统设置
框架和默认启动场景仍然会使用部分旧输入接口，例如
UnityEngine.Input和StandaloneInputModule。如果工程启用了 Input System Package，并且运行时报：
需要在 Unity 中手动设置：
修改后通常需要重启 Unity 编辑器才能完全生效。
🚀 核心亮点
MyFramework 最主要的特点不是某一个单独模块，而是一套比较完整的项目开发工作流。
1. UI 自动生成
通过在 UI Prefab 上配置需要访问的节点，自动生成 UI 脚本代码与注册逻辑，减少大量重复的查找节点和绑定代码。
支持：
2. 配置表工具链
使用 CSV 作为配置表格式，并配套自研表格编辑器。
配置表工具链支持：
配置表编辑阶段即可发现大量错误，减少运行时问题。
3. 网络协议代码生成
根据协议配置自动生成客户端与服务器消息代码。
支持：
4. 客户端 + 服务器配套
MyFramework 有配套服务器框架：
https://github.com/ZHOURUIH/MyServerFramework
客户端与服务器可以共享协议生成、配置表生成等工具链，适合需要长期维护的中大型项目。
5. 热更新分层
框架代码按照是否可热更进行了明确分层。
依赖关系大致为：
这种分层方式可以让框架层和业务层都有较高的热更新能力，同时又保留必要的启动稳定性。
📌 项目验证情况
✨ 项目特色
🔥 HybridCLR 热更新
集成 HybridCLR。
支持：
除启动和热更新下载逻辑外，大部分代码都可以参与热更新。
🔒 Obfuz 混淆
集成 Obfuz。
支持：
用于提升发布后的代码安全性。
🖥 UI 框架
提供完整 UI 封装，避免业务层直接访问 Unity 原生组件。
支持：
框架尽量不依赖 UGUI 的锚点和自动布局组件，而是倾向于通过代码显式控制 UI 的位置、尺寸、显示状态和输入逻辑。
🧭 自定义输入系统
不使用 UGUI 默认 EventSystem 作为主要输入派发方式，而是自己实现统一输入检测。
支持：
部分 Unity 原生组件仍然可以按需使用 EventSystem，例如 ScrollRect。
📦 资源管理系统
统一封装资源访问。
支持：
业务层无需关心资源来自编辑器还是 AssetBundle。
🌐 网络框架
支持：
提供：
其中按位序列化可进一步降低网络带宽占用。
⚙ 命令系统
命令系统用于封装具有完整逻辑意义的事件。
它可以用于：
示例：
调用方只需要关心触发了什么事件，而不需要关心事件内部涉及哪些模块。
🧩 组件系统
部分逻辑使用组件思想进行组织，通过组合代替复杂继承。
适合拆分可复用、可独立更新的功能逻辑。
🎬 特效系统
基于 PrefabPool 抽象出 EffectPool。
支持：
QuickEffect 适用于非循环、不带拖尾、需要频繁同时播放的粒子特效。
🧰 基础工具库
包含大量基础工具函数，例如：
同时提供大量 Scope 设计，用于实现类似 C++ RAII 的自动释放与状态恢复。
🧪 单元测试
框架包含大量单元测试，主要覆盖：
这部分测试用于保证框架中的基础工具函数和核心逻辑长期稳定。
🛠 工程检查工具
Editor 中提供了大量项目检查和辅助工具，例如：
这些工具主要用于减少大型项目长期维护过程中的隐性错误。
📋 功能概览
📈 与常见框架的定位差异
🎯 设计理念
MyFramework 并不是为了追求最新潮的架构，也不是为了追求最少代码量。
它更关注：
1. 可维护
代码定位清晰，问题出现后能够快速查找。
2. 可控
尽量减少对 Unity 自动行为和第三方插件的过度依赖。
框架中很多地方倾向于显式执行，而不是依赖隐藏生命周期。
3. 可落地
优先解决商业项目中真正会遇到的问题：
4. 长期维护
框架更偏向传统游戏引擎开发思路，强调明确的生命周期、明确的调用关系和统一的代码风格。
📁 主要目录结构
MyFramework 现在以 UPM Package 形式组织，框架代码位于：
Package 分层说明
安装插件后，用户工程中由初始化菜单生成项目入口和默认文件：
用户工程分层说明
🚀 快速开始
环境
推荐：
作者当前项目使用：
安装
在 Package Manager 中通过 Git URL 安装：
国内访问 GitHub 不稳定时，可以使用 Gitee：
初始化
安装完成后执行：
需要同时安装 HybridCLR + Obfuz 时执行：
初始化完成后，默认启动场景为：
直接打开该场景运行即可。
🎮 塔防游戏 Demo
为了更直观地展示 MyFramework 在实际 Unity 项目中的使用方式，现已提供一个基于本框架开发的完整塔防游戏 Demo：
项目地址：
https://github.com/ZHOURUIH/MyFramework_TDDemo
MyFramework_TDDemo 不是单个功能的代码片段，而是一个按照 MyFramework 项目结构组织的完整 Unity 工程，可以用于了解框架从项目启动、场景切换到具体游戏业务的整体落地方式。
Demo 内容
Demo 当前实现了以 Rogue-like 为核心的塔防战斗玩法，主要包含：
展示的框架能力
通过该 Demo 可以重点了解以下内容：
Game / HotFix / AutoGenerated项目代码分层运行 Demo
推荐使用：
克隆项目：
使用 Unity 打开工程，等待 Package Manager 完成依赖加载后，打开启动场景：
然后直接运行即可。
Demo 已经在
Packages/manifest.json中配置 MyFramework、HybridCLR 和 Obfuz 等依赖，一般不需要再次手动导入框架。💬 社区交流
欢迎交流 Unity 游戏开发、框架设计、客户端开发、服务器开发等相关内容。
群内主要讨论：
📖 文档
详细说明请查看文档目录：
https://github.com/ZHOURUIH/MyFramework/tree/master/文档
🖥 配套服务器框架
服务器项目：
https://github.com/ZHOURUIH/MyServerFramework
支持：
与客户端框架配套使用。
📖 通用工具的源码
https://github.com/ZHOURUIH/MyFramework_Tool
⭐ Star
如果这个项目对你有帮助，欢迎点一个 Star ⭐
你的支持会让我持续完善框架。
扫码加入微信群，欢迎交流框架使用、工具链、热更新、游戏开发等内容
License
MIT