Unity读书系列《Unity高级编程：主程手记》——架构

---

前言

这篇文章是《Unity高级编程：主程手记》的第一章。从标题就可以看出，该书不涉及通常意义上的基础知识，而是针对进阶内容。适合那些开发经验至少超过2年的老手，5年以上最佳。盼望各人能喜欢！接下来就让我们进入正文。
软件架构（software architecture）是一系列相关的抽象模式，用于引导大型软件体系各个方面的设计。软件架构是一个体系的草图。软件体系结构是构建计算机软件实践的基础。
这是网上搜到的定义，说真话有点高深，如果非得我表明清晰，我只能说，懂得都懂。哈哈，开个打趣，接下来我会用通俗易懂的语言来表明。
   面试官：“你觉得你是架构师吗？”
我：“我觉得我是!”
面试官：“归去等消息吧。”
——节选自某职业步调员语录
  

---

一、架构的意义

架构，简朴来说就是解决问题的方案；就比如我生活中开一个水果罐头，可以用大力气拧开，亦可以将罐头倒置放入热水中，两分钟后轻松拧开；填饱肚子可以自己做也可以订外卖，等等。
软件架构是关于怎样组织软件体系各个部分以及它们之间怎样交互的团体设计方案。可以将软件架构比喻为修建的蓝图，它引导着软件体系的搭建和发展，也可以将其理解为软件的架子。
我们以架子的类比来相识好的架构必要什么吧:
1、承载力

书架上能放多少东西，放多重的东西是甲方、乙方及步调员都关注的问题。
步调上来说，代码扩展本领怎样，能否承载多少个步调员共同开发，共同开发服从怎样是此中一个指标。
服务器来说，能承载多少的访问量和在线同步量是否满足软件必要及其重要。
客户端来说，能显示多少模型、UI、渲染多大的场景等都是承载力的表现，此中要思量到市场或甲方的通用硬件需求。
2、可扩展性

好的架子不但能放书，偶然也必要满足放瓶子、箱子、衣服的需求，固然听上去不合严谨的规范，但是你不满足估计合同都签不成，工资都拿不到（哈哈）。
架构的设计必要适应差别类型的需求，可添加差别类型的体系，兼容她们黑白常必要的。此中扩展性的关键在于，添加新体系的时间尽量不影响其她子体系的运行。不然哪怕你的架构再完善，性能再高，添加一个新体系就要重构，那代价没有一个公司能够承受，也是步调员不想看到的。
3、易用性

这是一个比较容易忽视的点。就像是产品给客户用，客户不满足就会产生不满，怨念和上当的感觉；架构设计出来给步调员使用也会出现这样的问题，不好用的架构会让开发服从大幅降落。实际上，本人工作中也碰到过这样的情况，综合工期、架构的需求、团队的设置进行合理化的架构才是王道。
易用性决定了架构的团体开发服从，步调员的上手快，各个体系的融合只必要花一些精力的话，就能让各体系各尽其职，每个负责对于体系的步调员专注的做相应的事情，服从天然蹭蹭的长。
4、可伸缩性

如果一个架子占地太大，偶然间也不太好，斲丧太大了。如果在不用的时间能收纳或折叠起来，随机应变岂不美哉？
当项目的承载力不必要很大时，则关闭部分功能，必要时再开启。淘宝双11和寻常的服务器承载力肯定差别。作为一个良好的架构，她能适应100人的协同开发，也应当适应1~3人的小团队开发。她或许在某个时期不是关键的因素，但雀氏是做出良好且完成架构的重要原因。
5、容错性以及错误的感知力

架子会有磕碰或者使用时出现的歪斜等小弊端，我们就算能保证刚开始使用时架子的牢固，也无法避免不当使用出现的问题。架构最重要的是稳定性，保证其不会因为小小的问题而散架，发生各种无法控制的异常。
软件架构同样是这样的，异常、Bug是稀松寻常的事情，我们无法预估其粉碎的时机。但是容错性会起到预防的作用，保证产品不会在使用时瓦解而无法使用；同时，也必要相应的备用方案（如日记）启动，方便复现和关照开发人员进行维护和修复。
   一个良好的软件架构不仅仅依靠于上述提到的五个关键本领，而且这些本领中某一项的突出也不能单凭其表现来评判架构的优劣，而是必要综合思量各种因素。随着时间的推移，软件大概会出现问题，这些问题大概会渐渐聚集在软件架构的薄弱环节，直至导致体系瓦解。因此，软件架构具有宏观的视角，通常必要思量久远发展。然而，即使我们构建了一个牢固、易用、灵活和可扩展的架构，随着时间的推移，它也大概会老化、无法跟上时代的变化。在这种情况下，你大概必要对架构进行“重构”。
在本节中，我们不谈重构，只谈架构，我们必要思考一个终极问题，怎样让所有因素都朝着好的、可靠的方向发展。
  二、软件架构的思维方式

我们在生活和学习中经常有思维方式的转换，软件架构亦是如此。软件研发和架构设计最重要的本领绝对是抽象本领，其实架构设计就和小朋友搭积木没有本质区别。我们必要在脑中形成抽象的概念，然后用模块的形式进行拆分，再实现这些子模块后将其组合就能形成想要的积木房子 ，咳咳，架构体系。接下来我们对这些抽象本领进行分析（参考文章—良好架构师必须掌握的架构思维）：

• 分层思维
  分层是我们应对和管理复杂性的基本思维武器。
  面对一个复杂体系，我们最必要的是岑寂的思考。抽象思维将一个复杂体系抽象出差别层次，从而清晰的描述出哪些是我们必要解决的，以及解决层级的先后次序，让复杂的业务逻辑和体系变得清晰可见。下面是引用文章的原图，一个架构层次的划分不肯定是横向，也大概是纵向的，纵向的层次贯穿其她横向层次，这个层次称为共享层。
  
  
  
  对于中小型的Spring Web应用步调，我们会设计成三层
  
  
  
  

Linux操纵体系的分层

TCP？/IP协议栈的分层

   今天的人类世界也是以分层方式一层层搭建和演化出来的，仔细思考，互联网体系也是层层构建出来的。
  

• 分治思维
  分而治之 (divide and combine 或者 split and merge) 也是应对和管理复杂性的一样平常性方法。用Unity专业的工作流举例，软件或游戏的逻辑编写是焦点功能；除此之外的打包发布、资源的部署、检测、版本控制、设置项目管理平台等都能细化出来成为一个个小问题。
  
  
  
  

对于一个无法解决的大问题，将其分成多少子问题，甚至再将子问题分解成子子问题直至解决，再将解决的问题组合成原问题的解，这就是分治思维。

• 演化思维
  社区里头经常有人在讨论：架构是设计出来的？照旧演化出来的？我个人基于十多年的经验认为，架构既是设计出来的，同时也是演化出来的，对于互联网体系，基本上可以说是三分设计，七分演化，而且是在设计中演化，在演化中设计，一个不停迭代的过程。
  在软件架构的过程中，一开始的架构设计很重要，一个好的架构必要瞻前顾后，具有演化式思维的架构师能在开始时思量到后续的演化特性，从而设计出良好的架构。随着架构师对业务的理解不停深入，业务和团队不停扩大，渐进式地把单块架构拆分成微服务架构的思路，就是演化式架构的思维，eBay、阿里皆是如此。下图为修建的演化。
  
  
  
  

二、构建Unity项目

1、前端和后端架构之间

前后端架构的目的都是高性能、高可用、可扩展、安全、可容性高。但对于前端来说，不但需满足这些目的特性，还必要照顾用户体验、视觉效果和操纵灵敏度等因素。前端和后端技术都是建立在同一体系层面，比如Windows、ios、Android等，必要开发者相识操纵体系的接口和基本运作原理。而对于专业团队来说，必要两套架构必要研究，一套是渲染引擎架构，一套是游戏业务架构。
这里只谈游戏业务架构，通常来讲，我们将游戏架构拆分成各个体系，包括网络框架、UI框架、数据框架、焦点战斗框架、AI框架等等。
2、作育架构设计思路

基本的架构设计思维在大学计算机课程（比如数据结构和算法）中找到，固然此中以理论知识为主。我们在工作中的不停的实践这些知识，随着经验的积聚，我们能解决问题的本领和眼界也就不停变大。
架构设计不是静态不变的，而是动态的。即使你掌握了抽象、分层、分治思维，也必要演化式思维，在设计的同时，借助反馈和进化的力量推动架构的持续演进。对这些思维的掌握深度和灵活应用的程度，直接决定了架构师解决问题的本领，也区分平凡应用型架构师和平台型/体系型架构师的一个分水岭。
3、Unity项目的分层设计

我们试着构建一个unity项目，将其分为五大层级：网络层、数据管理层、资源管理层、焦点逻辑框架层、UI框架层。

固然，这样的拆分比较笼统，此中焦点逻辑框架层包含的太多。
接下来我们将焦点逻辑框架拆成工具编辑器、脚色举动框架、AI框架、舆图场景与寻路框架，着色器与特性、设计平台等。她们有自身独立的框架，也可以相互调用，一起组合起来便成了焦点逻辑部分，或者是焦点玩法逻辑。

如上图，资源管理包含AssetBundle资源管理和Prefab资源管理；数据管理层也分为内存数据管理和外部数据管理。在实际项目中，我们大概还有常用库、工具库、动画控制这些功能，可以划分为额外的工具层级。
固然，对于差别的项目，我们也要有相应的侧重点。主打网络联机、社交的游戏如果网络模块不行，游戏再好玩也会丢失大量的玩家，潜力大大低落。同时，再商议决策时，可以将项目的差别重点提取出来，让擅长的同事去发掘处置惩罚，快速得出可行的解决方案；把最难把控的放在最优先的位置上去做，再慢慢进行细致化构建以及优化。
对项目进行细致化构建通常使用分而治之的方法逐个击破，举几个例子：

• 数据层：使用EXL导出Json格式照旧其他格式，定义基本的读取以及剖析接口；思量使用Luban进行此中固定命据层的取代，其他使用前后端交互。
  
• UI层：使用原生的UGUI照旧FGUI，针对界面基类、界面管理、输入变乱封装进行选择。
  
• 外部资源管理：是否使用AssetBundle，是否必要分类管理，是否加密。
  
• 寻路模块：用A星算法照旧跳点算法，用长间隔寻路照旧舆图数据管理。
  
• 工具库：时间函数、数学函数、数据加密封装、Debug调试工具。
  我们在不停完善架构的过程，原本简朴抽象的架构开始复杂化。就算每个模块都井井有条的演化，也会因为各种业务出现各种问题。这时我们必要跟进演化过程，进行剔除、重构、改善、修补等操纵来保证体系持续的发展下去。固然，我们也要注意架构的文档和此中体系框架的文档更新，有目的的整理和记载。
  

---

总结

架构是解决问题的方案，引导着软件体系的团体设计与发展。好的架构需具备承载力、可扩展性、易用性、可伸缩性和容错性。随着时间推移，架构需持续演进和优化，以适应不停变化的需求和挑衅。
我们探究了软件架构的重要性和关键本领，但这只是开始。我非常等待听到你的想法和经验。你对软件架构有什么见解，有用？无用？在你的项目中，你碰到过什么挑衅？接待在评论中分享你的想法，别忘了点赞