4、iOS架构设计（iOS高手课读书笔记）

当业务需求量和团队规模达到一定程度后，任何一款app都需要考虑架构设计的理性。
那么，如何设计一个能支持大规模app的架构呢？

苹果官方推荐的 App 开发模式是 MVC，随之衍生出其他很多类MVC的设计模式MVP、MVVM、MVCS，它们在不同程度上增强了视图、数据的通信方式，使得逻辑、视图、数据之间的通信更灵活、规整、易于扩展。在app浪潮初期，几乎所有app采用的都是这种类MVC结构。原因在于，MVC是很好的面向对象编程范式，非常适合个人开发者或小团队开发。但是，项目大了人员多了以后，这种架构就扛不住了。因为，这时功能的量级不一样了。一个大功能会由多个功能合并而成，每个功能都成了一个独立的业务，团队成员也会按照业务分成不同的团队。此时，简单的逻辑、视图、数据划分再也无法满足app大规模工程化的需求。
所以，接下来就得考虑模块粒度如何划分、如何分层，以及多团队如何如何协作这三个问题。解决了这三个问题后 ，就可以对模块内部做进一步优化。模块久经考验后，就能成为通用功能对外输出，方便更多团队。
总的来说，架构是需要演进的。如果项目规模大了架构还不演进，就会拖累业务的发展。
简单架构向大型项目架构演进中，就需要解决三个问题，即：模块粒度应该如何划分？如何分层？多团队如何协作？而三者中，模块粒度的划分是架构设计中非常关键的一步，最好可以在不同阶段采用不同的粒度划分模块。

模块粒度如何划分？
首先，模块划分要遵循一定的原则。如果划分规则不规范、不清晰，就会导致代码耦合严重的问题，并加大架构重构的难度。
其次，需要搞清楚模块的粒度采用什么标准进行划分，也就是遵循的原则是什么。
对于iOS这种面向对象编程的开发模式来说，应遵循以下五个原则，即SOLID原则。
单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
开闭原则：扩展是开放的，修改是封闭的。
里氏替换原则：子类对象是可以替代基类对象的。
接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS开发就是高层业务方法依赖于协议。
同时，遵循这五个原则是开发出容易维护和扩展的架构的基础。
最好，粒度选择要合适。切记大型项目的模块粒度过大或者过小都不合适。
其中，组件可以认为是可组装的、独立的业务单元，具有高内聚、低耦合的特性，是一种比较适中的粒度。iOS组件，应该是包含UI控件、相关多个小功能的集合，是一种粒度适中的模块。
并且采用组件的话，对于代码逻辑和模块间的通信方式的改动都不大，完成老代码切换也就相对容易。可以先按照物理划分，也就是将多个相同功能的类移动到同一文件夹下，然后做成CocoaPods包进行管理。

如何分层？
组件解耦并不是要求每个组件都没有耦合，组件间也需要有上下层依赖关系。组件间的上下层关系划分清楚了，就会容易维护和管理。一般建议，组件间层级最多不要超过三层，可以如此设置：
底层可以是于业务无关的基础插件，如网络和存储等；
中间层一般是通用的业务组件，如账号、埋点、支付、购物车等；
最上层是迭代业务组件，更新频率最高。
这样的三层结构，尤其有利于多个团队分别开发维护。
同时，也不用把所有的功能都做成组件，只有那些会被多个业务或者团队使用的功能模块才需要需要做成组件。一旦决定某业务功能模块要改成组件，就要严格按照SOLID原则去改造组件，因为返工和再优化的机会很难有。

多团队之间如何分工？
总体来说，团队分工要灵活，不能把人员隔离固化。核心上，团队分工要围绕着具体业务进行功能模块提炼，去解决重复建设的问题，在这个基础上把提炼出的模块做精做扎实。

好的架构什么样？
组件化是解决项目大、人员多的一种很好手段。组件间关系协调却没有固定的标准，协调的优劣，是衡量架构优劣的一个基本标准。因此在实践中，一般分为了协议式和中间者两种架构设计方案。
协议式架构设计主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现可在不同地方，从而达到分布管理和维护组件的目的。这种方式也遵循了依赖反转原则，是一种很好的面向对象编程实践。但是，此方案的缺点也明显，主要提现在两方面：1、由于协议式编程缺少统一调度层，导致难于集中管理，特别是项目规模变大、团队变多的情况下，架构管控就会越来越重要；2、协议式编程接口定义模式过于规范，从而使得架构的灵活性不够高，当需要引入一个新的设计模式来开发时，就会发现很难融入到当前架构中，缺乏架构的统一性。
虽然协议式架构有此两方面的局限性，但由于其简单易用的特定依然被很多公司采用。
另一种常用的架构形式是中间者架构。它采用中间者统一管理的方式，来控制app的整个生命周期中组件间的调用关系。同时，iOS对于组件接口的设计也需要保持一致性，方便中间者统一调用。
拆分的组件都会依赖于中间者，但是组件之间就不存在相互依赖关系。在中间者上也能够轻松添加新的设计模式，从而使得架构更容易扩展。
好的架构一定是健壮的、灵活的。中间者架构的易管控带来的架构更稳固，易扩展带来的灵活性，使得中间者这种架构设计模式值得推荐。casatwy以前设计了一个CTMediator就是按照中间者架构思路设计的。https://github.com/casatwy/CTMediator。

在架构设计时，更多的还是需要在功能逻辑和组件划分上做到同层级解耦，上下层依赖清晰，这样的结构才能使得上层组件易插拔，下层组件更稳固。而中间者架构模式更容易维护这种结构，中间者的易管控和易扩展性，也使得整体架构能够长期保持稳健与活力。是很多人心目中最好的架构。

小结
架构的设计不是要等到工程到了燃眉之急时再去参考别的架构，来个大重构。好的架构，需要在业务开发过程中及时发现开发的痛点，进行有针对性的改良，不然就会和实际开发越走越远。
好的架构能够在一定的规范内同时能偶支持高灵活度，这种度的把握是需要架构师长期跟随团队开发，随着实际业务需求的演进进行分析和把握的。
作为一名开发者，除了日常需求开发和技术方案调研、设计外，还需要了解所在项目的整体架构，想想哪些地方可以改进，业界有哪些更好的架构思想是可以落地到自己项目中的。有了从项目整体上去思考的意识，才能站在更高的视角上去思考问题。这也是对架构师的基本要求。