【Unity自动化游戏框架】通用自动化游戏框架 爽到起飞的工作流 巨幅提升效率 质量 产能_unity 游戏框架

https://github.com/sunsvip/GF_HybridCLRhttps://github.com/sunsvip/GF_HybridCLR

开始GF_HybridCLR自动化通用游戏框架，功能设计和用法的系列博文；

视频中demo测试包下载，以及万人同屏方案性能测试，有需要的老板可以某宝【搜店铺】：【游戏开发资源商店】：https://pan.baidu.com/s/1ML0DC8s0RkkTAraN9maltw?pwd=bluehttps://pan.baidu.com/s/1ML0DC8s0RkkTAraN9maltw?pwd=blue

前言:

"工欲善其事必先利其器",  好的框架是对开发工作流的规范化、简单化，当然，高性能是基础必要条件。一个完善的游戏框架不仅能大幅提高开发效率、提高项目质量，还能让程序员码字的时候思路清晰、心情舒畅。

从业以来，接触过很多客户端"框架"，架构主要是MVC、 ECS当然最多的还是Manager of managers。诸多心酸，懂的人都懂。设计通用框架的前提，必须要项目经验丰富，熟知项目开发上下游痛点。并且至少吃过细糠，熟悉市面上已有的优秀客户端框架是如何设计的。一定不要盲目重复造轮子，为了设计而设计，以自己的开发习惯为中心，在不了解游戏开发痛点、也不知道优秀通用框架都具备哪些必要特性的情况下闭门造车，毫不权衡、不考虑团队和项目需求。毫无疑问，适用于团队开发的通用游戏框架，必须考虑团队技术成员的整体能力，应该是保证高性能的同时，规范简化开发流程、降低开发门槛、提升开发效率。

当然，以上都是废话，最重要的是不用加班了。因为提高效率和质量，能避免堆成屎山，避免大量无谓的内耗加班。

GameFramework简介：

GameFramework是一款设计非常优秀的开源游戏框架。我最早接触于2018年，在诸多陌生的开源客户端框架里，选择了star最多的一个。在自己的毕业设计《MOBA游戏战地王者的设计与开发》中一边学习GF一边应用于毕设项目开发。接触之初，由于能力问题，很不习惯GF的开发方式。因为在此之前的习惯都是直接在场景中挂几个MonoBehavior一点运行游戏就跑起来了，毫不考虑性能、灵活、可配置、团队协作等等，在做毕设这种相对完整、大型的项目时，这种方式一团糟，已经远远无法满足需要。我非常清楚，如果一直呆在自己的眼界中的"舒适区"，保持自己的“习惯”，从不"睁眼看世界"，不进行变革升级，那么这个人分分钟将被急速发展的互联网技术淘汰，成为行业寒冬下，“优化”名单里的首选。

有些新手刚接触时给出"过度设计"的评价，熟悉框架之后才会明白这么设计有多么精巧。实际上GF暴露给用户层的接口非常简洁，总结一下就是GameObject显示/隐藏只需ShowEntity()、HideEntity(), UI打开/关闭只需OpenUIForm(), CloseUIForm(); 用户层只管调用，至于内部复杂的对象池复用、释放，资源加载、释放，都由GF框架内部自动管理。 API或生命周期函数命名的规范化也是GF的一大亮点。GF内部实现大量使用了接口(Interface)，以至于初学者想跳转查看内部实现，结果都跳转到了抽象接口，因此认为"过度设计"； 

GF把核心模块与游戏引擎解耦，抽离出了一个核心叫GameFramework程序集, 而引擎相关接口封装为UnityGameFramework, 去实现GameFramework的各种功能接口；GameFramework程序集就实现了跨引擎。并且GF使用了大量解耦设计，比如Helper接口，我们只需实现Helper接口就能对各个功能模块自定义；

这也就是为什么GF已经三年没有更新，却依然没有被淘汰，依然能跟得上时代的原因。比如随着时间的发展，技术不断更新进步，其间出现了更好的json插件或者zstring(无GC的字符串格式化、连接插件)，我们只需使用这些插件实现GF序列化、文本处理接口，就可以一键切换使GF用上这些新特性。

如果我写不出更好的框架，就绝不会自己去重复造轮子。当然，我始终喜欢用最新、最好的技术。也一直在刷着当前市面上最新的技术，以及是否出现更完美的游戏客户端框架，如果有更好的选择，我会毫不犹豫选择更好的。技术世界就是这样，永远追逐最佳方案。

HybridCLR简介:

HybridCLR是新一代的C#热更方案，通过修改Unity对应版本的il2cpp源码使其拥有运行时动态加载assembly的能力。可以用纯C#开发工作流，无感知的支持代码热更，极大提高了热更项目开发效率。

偶尔会听到神言论，说将来Unity转向XXX技术，学习NNN无用论，每个时代有每个时代的最佳方案，我们要做的不是杞人忧天，考虑布局一百年，而让自己固步自封，任何技术都不能吃一辈子。无论Unity何时转向NativeAOT，无论届时HybridCLR能否完美适配，都不能影响当下HybridCLR是热更新首选方案。

自动化：

自动化、简单化、高效化是GF_HybridCLR的宗旨， "懒"是核心驱动力。功能随着本人从业以来参与设计研发无数个项目中，遇到的痛点以及推敲可能遇到的问题，以及作为设计师对用户体验的极致追求。把多年来的沉淀总结完善到了框架内，作为自动化工具链；

1，功能工具栏

首先映入眼帘的是醒目的框架工具栏，这些是点击频率最高的按钮，位置必须醒目，用户体验上必须拒绝拖沓，使用频率高的菜单，能点一下绝不点两下。

当然，有一些无关痛痒的、自动化流程自动执行的命令(如刷新数据表)，为了给用户留出选择权(我可以不用，但你不能没有), 这些优先级低的命令，才会以Unity顶部菜单栏的形式留给用户，如：

 好的工作流，就像写一篇好文章一样，层次丰富、言简意赅、主题清晰、用意明了。不宜用力过猛，恰到好处；

Toolbar工具栏功能设计：

 ① 场景切换：

你有没有打开一个项目后，再一层一层翻目录找启动场景？

你有没有半路进入一个项目组后，打开项目一脸懵，不知场景在哪？怎么启动？

谢特？这么影响用户体验的痛点怎么能存在？

直接点击弹出场景选择下拉列表, 点击即可切换场景。

②一键打包/打热更工具：

你有没有打包前要设置一堆参数？

如果接了HybridCLR热更，还要执行一堆前置工作，配置手忙脚乱，丢三落四，漏掉某个步骤就会出现莫名其妙的问题，再重新来过？

打包工具窗口全部解决，并且支持部署Jenkins远程打包、单机/热更模式一键切换。

③ App基础配置：

什么？配置项七零八落？菜单九进九出？

策划总忘记导表、生成表代码？

App Config把项目配置齐聚一堂，设计分辨率、流程、数据表、常量表、多语言都在这里；

勾选即启用，配置表、常量表、多语言，自动检测文件改变，自动刷新导出到工程；

④工具集：

什么？包体优化困难？

多语言填写麻烦、容易遗漏？废弃的多语言Key没人处理，冗余越来越严重？

...

 游戏开发中常用的功能汇聚于此，并且支持轻松扩展，只需继承工具基类编写自己的功能，工具栏内就会自动显示你的自定义工具入口；

框架内置了痛点覆盖面相当广的工具集，如：代码裁剪配置工具、包体优化工具集(图片/图集压缩、动画文件压缩)、语言国际化自动扫描翻译工具、一键换字体、图片艺术字生成、AOT元数据补充配置、ChatGPT AI助手等；

都是直击痛点的工具，功能太多，不逐一说明；

包体优化工具集：批量处理大规模文件，大幅优化包体大小

多语言工具： 一键精准扫描代码、Prefab、数据表中的多语言文本；一键增删支持语种；自动生成多语言excel、自动翻译多语言；

⑤打开代码工程:

 啥？想打开代码工程还要找个脚本去打开？

Assets->Open C# Project还要翻菜单？

直接Toolbar一键打开代码工程，用户体验第一位，分秒必争；

2，UI代码生成工具:

你还在手动写UI变量？还在拖拖拽拽？

UI代码生成工具，直接点击Hierarchy节点批量选择添加UI变量、批量添加按钮回调事件；

隔离式生成partial独立UI变量代码，一键添加变量自动绑定、自动命名、支持数组；编码效率飞跃提升；

API接口的简化扩展: 

GameFramework虽然已经极大的将接口封装简化，但毕竟有灵活性包袱。很多接口需要提供的参数过多，针对这些问题通过静态扩展的方式，大幅简化扩展接口，可以说将开发门槛降低到海平面以下，傻瓜式接口调用。

你还在为找功能类、背API而烦恼？GF_HybridCLR中，所有功能只需GF.XXX即可访问，模块极致清晰，即使是首次使用，也能通过API名称精准找到想要使用的功能接口。

以及扩展了游戏项目中各种常用功能，太多太多。。感兴趣的可以亲自试试，告诉你什么叫细糠！

最后也祝愿行业寒冬下的同仁，永远拥有最高的竞争力，永远得心应手、游刃有余。也祝愿大家和我一样，从来没加过班、从来不用加班。