参考地址 iOS 组件实现方案(Block)
组件概述
一、什么才是好架构
代码整齐，分类明确，没有
Common，没有Core；不用文档，或很少文档，就能让业务方上手；
思路和方法要统一，尽量不要多元；
没有横向依赖；
对上层业务方有适当的限制，也给业务方创造灵活实现的条件；
易测试，易拓展，超前性；
接口少，接口参数少，高内聚；
高性能；
二、为什么要组件
1, 我们都知道最基本的代码设计原则：“Don’t repeat yourself!”，每一个工程都会有自己的架构，即使是刚入门的开发者，写几天代码也会发现要把一些常用的重复代码单独拿出来放在一个叫 Common 的地方，实现代码复用。
说到 App 架构，大概分三种：
第一种是 APP 开发并不需要什么狗P架构；
第二种是有自己 NB 的架构；
第三种是要模块化够好，每个模块应该有自己的架构。
第一种是一些个人开发者，个人能力很强，经常一个人很快搞出来一个APP，他的印象中不需要弄太多的框框框住自己，但是其实他也是有一套自己的架构。
第二种是一些公司或者大公司，有一套NB的架构对于团队的意义就比较大了，可以保证稳定迭代，保证规范和持久可维护性。
第三种是BAT这样的有很多业务的超级公司，或者一些先进的开源开发者们，模块化能够更好的实现跨app的代码和功能的复用, 能够更好的共享资源，避免重复造轮子。
为什么要模块化，已经很明显了。
三、组件设计的优点
解决代码和业务的耦合问题，实现代码的复用度，还可以实现真正的功能复用，比如同样的功能模块如果实现了自完备性，可以在多个app中复用；
组件独立运行，代码自用率高，迭代效率高；
拆分粒度小，业务隔离且业务并行开发，跨团队开发代码控制和版本风险控制的实现；
模块化对代码的封装性、合理性都有一定的要求，提升开发人员架构能力；
项目架构清晰，可持续扩充业务，明确团队开发的业务边界，增加团队协作效率；
<span id="mark1">四、组件设计三大原则</span>
解耦且独立原则：每个组件只做好一件事情，不要让 Common 出现，只依懒下层组件并能够独立于同级组件进行独立编译，同层组件不允许出现直接相互依懒或引用，即横向依懒。
稳定自完备性原则：越底层的组件，应该越稳定，越抽象，越具有高复用度。最直观表现就是API很久都不用变化，所有的变化因子不会暴露出来，避免传递给依赖它的模块，那么设计的时候就越抽象，需要抽象总结的能力，一般表现在底层组件的设计上。自完备性表现为如果 A B 组件都需要调用一个函数 F，F 不太适合做成组件的时候，就应该在 A B 组件里都实现 F 功能，提升组件的复用度，自完备性有时候要优于代码复用，而更多时候也是为下沉做准备。
下沉且向下依赖原则：按照架构的层数从上到下依赖，不要出现下层模块依赖上层模块的现象，业务模块之间也绝对不耦合。随着业务增加，会发现新组件里的某些功能能从旧组件里直接复用，那么这时候下沉变得尤突出，下沉会让上层业务轻量和稳定的效果。
组件实现
一、架构演进
1、组件化之前各功能组件间的关系
在项目初期，一般为了能快速完成1.0需求功能上线，以及项目的业务模式、业务类型还没成型，组件化并没有那么迫切，不足矣去抽离一个组件式架构开发模式。随着某些业务的慢慢稳定及产品的一般形态确定下来后，一般在B轮融资或一年期的项目，就会考虑怎样粒度化，把一个大的项目拆成小的模块，技术上体现为可以在其自身内部进行功能开发，并且其自身是一个自完备的功能。而这个粒度化，就是组件的演进过程。如果不进行组件化就会出现下图所示业务功能的相互耦合。
下文中的
Req代表Request,Pro代表Provide。
组件实现之前相互耦合的业务功能模块：
image
2、组件化之后各功能组件间的关系
image
相比组件之前的关系图，组件之后的关系图第一感觉似乎变得更复杂了，没错，因为各功能组件都新增加了 API 和 Router 两个东西，且依懒关系引用也似乎变得更缭绕。其实，组件化是会新增更多的中间层或协调器之类的东西，只有靠这些东西的独立声明和独立实现才得以实现组件化，而上图中 API 和 Router 就是所谓的中间层。连接各组件之间的通信和调用关系。简化后的关系图如下：
image
上图是组件后的关系图，跟组件前的关系图对比，很明显各组件间不会有相互引用关系，所有引用通过一个叫 Middleware 的中间件进行连接。
3、引申出的架构全貌
组件化之前，第一要考虑的是分层，分层是根据依赖关系进行分层的，上层依赖下层，而分层是架构设计的一部分。下图是 iOS 项目的架构全貌：
image
a、五层架构概念
System：系统层，所有系统为上层开发者提供的系统库和框架；Third：第三方层，项目都会依懒一些成熟稳定的第三方库进行开发，这一层为上层开发提供了很多系统不提供的功能，大大减少开发者的工作量；Trunk：主干层，即多端复用层，就是针对公司自已业务而封装的一层，这一层可以跨公司内部 APP 复用，是集公司技术精髓的一层；Base：真正的 APP 基础层，这一层只为该 APP 独有的功能特性而封装的基础层，为该 APP 上层业务提供底层支持或功能复用；Business：业务层，真正业务方所能触达的地方，所有业务上的逻辑开发，都在这一层进行。
b、技术和业务的分层
五层架构概念里业务层之下的都称为技术层。
Technology Layer：技术层，该层只为业务层提供业务支持，该层不存在业务型代码，较业务层是一个个抽象的接口；Business Layer：业务层，在技术层的基本上，该层开发变得轻而易举，该只关注业务，不关注底层实现，比如支付的实现，网络请求是怎么得到数据的等等；技术层和业务层通过
Middleware中间件进行间接引用，不直接引用技术层。
c、多端复用
当一个公司有多个产品的时候，多端复用变得尤为重要，因为多个产品往往之间存在很多共性，那么在五层概念的第三层 Trunk 处再架设属于 APP2、APP3、... 的基础层为各 APP 上层业务服务。如图中与 MCUtilities 同层的 MCMUtilities。
二、在 iOS 上的业务组件化具体实现
架构演进里说到的都是由下往上层的讲解，在具体开发中，或具体为某一业务抽离组件化的流程里，则是由上往下的思路。这里会有更多的具体实现代码展示，将使用 MCShop 组件进行讲解：
1、组件的 API
组件 API 是属于中间件 Middleware 的一部分，用于 对接外部实现 或 对外提供实现 的重要桥梁，API 的设计好坏，极大地决定着组件的 解耦且独立原则，也最考验开发者组件设计能力，因为内部淋漓尽致的使用了各种回调<即函数指针>和传参，对这些指针参数的命名，需要极精准的定义，否则会让组件 API 难以理解。
组件架构模式下开发，时时刻刻都应该有 组件设计三大原则 的思想。API 的设计亦如此，我们以 MCShop 的 API 叫 MCShop.h 为例进行讲解：
满足
下沉且向下依赖原则，MCShop是向下依赖于MCUtilities进行开发，所以API头里只引入MCUtilities。#import "MCUtilities.h" @interface MCShop : NSObject + (instancetype)sharedShop; ...
我们为每个组件创建了一组
API，这组API定义了该组件所有需要的外部实现声明<Require>以及能对外提供的内部实现<Provide>的所有清单。#import "MCUtilities.h" @interface MCShop : NSObject + (instancetype)sharedShop; #pragma mark require // 活动详情 @property (nonatomic, copy) MCBaseVC *(^require_eventDetailVC)(NSString *eventId, MCEventType eventType); // 买单 @property (nonatomic, copy) MCBaseWKWebVC *(^require_buyOrderVC)(NSString *merchantNo, NSString *itemNo); // 商品详情 @property (nonatomic, copy) MCBaseVC *(^require_groupbuyInfoVC)(NSString *gbId); // 全部商品 @property (nonatomic, copy) MCBaseVC *(^require_allGroupbuyVC)(NSArray <NSDictionary *> *groupbuyInfoDics); // 券详情 @property (nonatomic, copy) MCBaseVC *(^require_couponDetailVC)(NSString *couponId, NSString *category); // 券核销详情 @property (nonatomic, copy) MCBaseVC *(^require_couponConsumeDetailVC)(NSString *couponId); // 室内导航 @property (nonatomic, copy) MCBaseVC *(^require_navFindShopAndCarVC)(NSString *URL); // 排队信息 @property (nonatomic, copy) MCBaseVC *(^require_appointmentBookInfoVC)(NSString *shopId); // 排队详情 @property (nonatomic, copy) MCBaseVC *(^require_appointmentBookDetailVC)(NSString *serialNo, NSString *orderNo); #pragma mark provide // 找店首页 - (MCBaseVC *)provide_searchShopVC; // 店铺详情 - (MCBaseVC *)provide_shopDetailVC:(NSString *)shopId; - (MCBaseVC *)provide_shopDetailVC:(NSString *)shopId viewDidDisappearCallBack:(void (^)(BOOL favorited))viewDidDisappearCallBack; // 适用商家 for MCGroupbuy - (MCBaseVC *)provide_shopApplyForGroupbuyVC:(NSString *)gbid; @end
很明显
API里只有对接外部实现<require>或对外提供实现<provide>两部分。所有
require是一组抽象接口定义；所有
provide是一组具体功能的实现；
2、组件内部开发
组件内部其实是一个比较宽范的开发空间，在基本底层库以后，内部开发变得轻而易举，所有内部的功能模块，除引用其自身开发所创建的引用类外，只依懒于自身的 API 进行开发。MCShop 组件内部的找店首页控制器 MCShopVC 只要依懒自身的 MCShop.h 进行开发。
组件内部开发应该遵循 稳定自完备性原则。
// 下面 7 个引入为找店首页控制器内部所持有的类。 #import "MCShopVC.h" #import "MCShopModel.h" #import "MCShopCell.h" #import "MCShopNaviView.h" #import "MCShopDetailVC.h" #import "MCShopSearchVC.h" #import "MCShopLocationVC.h" // 下面 MCShop.h 为依懒自身组件进行开发，不会出现其它任何组件或组件内部的类或常量。 #import "MCShop.h" static NSString *const kCellID = @"kCellID"; @interface MCShopVC () ...
内部开发最明显的特征就是，组件内的所有头文件的所有引入类的前缀都为该组件名称<此也为组件命名规范下的表现>。
3、组件的 Router
Router是组成中间件Middleware必不可少的一部分，所有组件的API与Router组成Middleware的全部，决定着组件之间所有的通信<请求和响应>。Router是写在主工程里的，主<壳>工程引入各组件，路由持有该组件的API单例，同时路由引入能提供该组件API里所有Require的组件，即为API寻找所有声明的实现，此为路由的精髓。依然以MCShop路由为例：MCBaseRouter.h：#import "MCBaseRouter.h" #import "MCShop.h" // 路由引用的对应的组件 @interface MCShopRouter : MCBaseRouter @property (nonatomic, strong) MCShop *shop; // 持有该组件的 API 单例 @end
MCBaseRouter.m：#import "MCShopRouter.h" #import "MCBuyOrderVC.h" // 买单 #import "MCCouponDetailVC.h" // 券详情 #import "MCCouponConsumeDetailVC.h" // 券核销详情 #import "WebVC.h" // 下面 3 个引入为：路由引入能提供该组件 API 里所有 Require 的组件 #import "MCGroupbuy.h" // 商品组件 #import "MCAppointment.h" // 美味不用等组件 #import "MCEvent.h"// 活动组件 @implementation MCShopRouter static MCShopRouter *shopRouter_; + (instancetype)sharedRouter { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ shopRouter_ = [[MCShopRouter alloc] init]; shopRouter_.shop = [MCShop sharedShop]; }); return shopRouter_; } - (void)configRouter { MCShop *shop = self.shop; // 以下为组件 API 寻找所对应的实现<或指定实现以备内部调用>，此为寻找活动详情页面。 shop.require_eventDetailVC = ^MCBaseVC *(NSString *eventId, MCEventType eventType) { // 上面引入活动组件后，活动详情页面只有活动组件能为其实现并提供该页面 // 所以 MCShopRouter 找到 MCEvent 的 API 的 provide_eventDetailVC 方法得到该页面 MCBaseVC *vc = [[MCEvent sharedEvent] provide_eventDetailVC:eventId eventType:eventType]; return vc; }; shop.require_buyOrderVC = ^MCBaseWKWebVC *(NSString *merchantNo, NSString *itemNo) { MCBuyOrderVC *vc = [[MCBuyOrderVC alloc] init]; vc.merchantNo = merchantNo; vc.itemNo = itemNo; return vc; }; shop.require_groupbuyInfoVC = ^MCBaseVC *(NSString *gbId) { MCBaseVC *vc = [[MCGroupbuy sharedGroupbuy] provide_groupbuyInfoVC:gbId]; return vc; }; shop.require_allGroupbuyVC = ^MCBaseVC *(NSArray<NSDictionary *> *groupbuyInfoDics) { MCBaseVC *vc = [[MCGroupbuy sharedGroupbuy] provide_groupbuyAllForShopVC:groupbuyInfoDics]; return vc; }; shop.require_couponDetailVC = ^MCBaseVC *(NSString *couponId, NSString *category) { MCCouponDetailVC *vc = [[MCCouponDetailVC alloc] init]; vc.couponId = couponId; vc.category = category; return vc; }; shop.require_couponConsumeDetailVC = ^MCBaseVC *(NSString *couponId) { MCCouponConsumeDetailVC *vc = [[MCCouponConsumeDetailVC alloc] init]; vc.couponId = couponId; return vc; }; shop.require_navFindShopAndCarVC = ^MCBaseVC *(NSString *URL) { WebVC *vc = [[WebVC alloc] initWithUrl:URL]; return vc; }; shop.require_appointmentBookInfoVC = ^MCBaseVC *(NSString *shopId) { MCBaseVC *vc = [[MCAppointment sharedAppointment] provide_appointmentBookInfoVC:shopId]; return vc; }; shop.require_appointmentBookDetailVC = ^MCBaseVC *(NSString *serialNo, NSString *orderNo) { MCBaseVC *vc = [[MCAppointment sharedAppointment] provide_appointmentBookDetailVC:serialNo orderNo:orderNo]; return vc; }; } @end组件路由是精简的函数调用，不会有太多的逻辑处理。其目录只是为组件寻找实现入口或获得回调入口。
4、中间件的概念
Middleware 中间件其实就是 API 和 Router 的集合体，两者之间完成相互的 Request 和 Provide 接口。
其主要表现为：
主要解决本地业务组件之间的通信问题；
从工程代码层面来说，组件化就是通过中间件解决组件间头文件直接引用、依赖混乱的问题；
纯中间件只负责挂接节点的通信问题，不应涉及挂接点具体业务的任何逻辑；
以上三点也是组件化技术层面的核心要素。
5、组件持续集成
严格的组件化后，每个组件有自已的 Git 仓库，独立更新及编译。
各独立的组件由 Cocoapods 工具进行版本管理，各组件更新至主工程由自动化脚本执行。
持续集成需要开发人员熟练 Cocoapods的使用和 Python 代码，此文主要在架构层面介绍组件化，其实现细节在此不做深入讲解。
