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

---

前言

这篇文章是《Unity高级编程：主程手记》的第一章。从标题就可以看出，该书不涉及通常意义上的基础知识，而是针对进阶内容。适合那些开发经验至少超过2年的老手。希望大家能喜欢！接下来就让我们进入正文。
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件体系结构是构建计算机软件实践的基础。
这是网上搜到的定义，说实话有点高深，如果非得我解释清楚，我只能说，懂得都懂。哈哈，开个玩笑，接下来我会用通俗易懂的语言来解释。

面试官：“你觉得你是架构师吗？”
我：“我觉得我是!”
面试官：“回去等消息吧。”
——节选自某职业程序员语录

---

一、架构的意义

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

1、承载力

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

2、可扩展性

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

3、易用性

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

4、可伸缩性

如果一个架子占地太大，有时候也不太好，消耗太大了。如果在不用的时候能收纳或折叠起来，随机应变岂不美哉？
当项目的承载力不需要很大时，则关闭部分功能，需要时再开启。淘宝双11和平常的服务器承载力肯定不同。作为一个良好的架构，她能适应100人的协同开发，也应当适应1~3人的小团队开发。她或许在某个时期不是关键的因素，但雀氏是做出优秀且完成架构的重要原因。

5、容错性以及错误的感知力

架子会有磕碰或者使用时出现的歪斜等小毛病，我们就算能保证刚开始使用时架子的牢固，也无法避免不当使用出现的问题。架构最重要的是稳定性，保证其不会因为小小的问题而散架，发生各种无法控制的异常。
软件架构同样是这样的，异常、Bug是稀松平常的事情，我们无法预估其损坏的时机。但是容错性会起到预防的作用，保证产品不会在使用时崩溃而无法使用；同时，也需要相应的备用方案（如日志）启动，方便复现和通知开发人员进行维护和修复。

一个优秀的软件架构不仅仅依赖于上述提到的五个关键能力，而且这些能力中某一项的突出也不能单凭其表现来评判架构的优劣，而是需要综合考虑各种因素。随着时间的推移，软件可能会出现问题，这些问题可能会逐渐聚集在软件架构的薄弱环节，直至导致系统崩溃。因此，软件架构具有宏观的视角，通常需要考虑长远发展。然而，即使我们构建了一个牢固、易用、灵活和可扩展的架构，随着时间的推移，它也可能会老化、无法跟上时代的变化。在这种情况下，你可能需要对架构进行“重构”。
在本节中，我们不谈重构，只谈架构，我们需要思考一个终极问题，如何让所有因素都朝着好的、可靠的方向发展。

二、软件架构的思维方式

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

1. 分成思维
   分层是我们应对和管理复杂性的基本思维武器。
   面对一个复杂系统，我们最需要的是冷静的思考。抽象思维将一个复杂系统抽象出不同层次，从而清晰的描述出哪些是我们需要解决的，以及解决层级的先后顺序，让复杂的业务逻辑和系统变得清晰可见。下面是引用文章的原图，一个架构层次的划分不一定是横向，也可能是纵向的，纵向的层次贯穿其她横向层次，这个层次称为共享层。
   
   对于中小型的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调试工具。
  我们在不断完善架构的过程，原本简单抽象的架构开始复杂化。就算每个模块都有条不紊的演化，也会因为各种业务出现各种问题。这时我们需要跟进演化过程，进行剔除、重构、改善、修补等操作来保证系统持续的发展下去。当然，我们也要注重架构的文档和其中系统框架的文档更新，有目的的整理和记录。

---

总结

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