序言

随着公司业务的不断发展，项目的功能越来越复杂而传统的MVC或者MVVM架构已经无法高效的管理工程代码，因此需要用一种技术来更好地管理工程，于是研究了一下新项目的架构选型，经过一番选择，决定使用组件化的架构.

如果和我讨论或者想拿源码和资料的, 请联系我时，备注一下组件化 加我技术交流QQ群：656315826

什么是组件化

组件化开发，就是将一个臃肿，复杂的单一工程的项目, 根据功能或者属性进行分解，拆分成为各个独立的功能模块或者组件 ; 然后根据项目和业务的需求，按照某种方式, 任意组织成一个拥有完整业务逻辑的工程。这就是所谓的组件化开发。

优点

1、组件之间相互独立。各组件开发成员之间的代码想相互独立编写的，独立编译，独立运行和独立测试的。 2、资源的重复里用，尤其是功能性，工具性的代码，可以很轻松的重复里用 3、迭代的效率提高。通过迭代进行功能的增减，只需要进行组件的拆分和组合。很方便也很高效

缺点

1、增加了代码的冗余，组件化颗粒度越细，中间代码越多 2、增加了项目的复杂度，复杂度越高越容易出问题 3、学习成本高，对于开发人员对各种工具的掌握要求也比较高，对于新手来说入门较为困难。 4、由于工具和流程的复杂化，导致团队之间协作的成本变高，某些情况下可能会导致开发效率下降。

但长远来看，组件化带来的好处是远远大于坏处的，特别是随着项目的规模增大，这种好处会变得越来越明显。

怎么做组件化

以蘑菇街为例，使用 CocoaPods 来做这件事的话，我们可以拆到主工程可以一行代码都没有，只有一个 Podfile，类似于下面这样：

pod 'MGJiPhone-Foundation'
pod 'MGJiPhone-Hybrid'pod 'MGJiPhone-Detail'
pod 'MGJiPhone-Me'
pod 'MGJiPhone-Shop'
# ...

在最理想的情况下，这些子工程直接应该只存在上层到下层的依赖，即业务模块对底层基础模块的依赖，业务工程之间尽可能不出现横向依赖。从 limboy 的描述来看，蘑菇街各个子模块是可以单独编译出东西来的，这说明各个子模块之间的横向依赖已经很少，证明子模块之间的拆分已经比较成功了。

理想很丰满，现实很骨感。在我们对一个工程开刀的过程中，会发现事情远没有那么简单。继续以蘑菇街 App 为例，例如我们想拆分 Detail 模块（即商品详情模块），Detail 模块中可能包含了下面诸多依赖：

#import "MGJShopViewController.h"
#import "MGJShopRequest.h"
#import "MGJUser.h"
#import "MGJCart.h"
#import "MGJFoundation.h"
#import "MGJWebViewController.h"
#import "MGJHybridAPI.h"

为什么会出现这么多依赖？因为 Detail 模块本身的业务就需要涉及到和多个不同模块之间进行交换，例如从用户模块获得用户的信息，当用户购物时和购物车模块进行交互，展示商品内容时和 Web 和 Hybrid 模块进行交互等等。这是业务本身决定的，我们没办法改变。我们所能做的是尽可能地减少横向的依赖。

上面也提到了横向依赖这个概念。这里说明一下，业务模块没有依赖是不可能的，我们希望做到的是，它只依赖那些底层的基础模块，而不依赖于和它同级的业务模块。

基础依赖

哪些模块算是底层的基础依赖？一个最简单的判断办法就是，看这个部分的代码是不是稳定的。最常见的基础依赖，包括稳定的三方库，底层网络通信模块，常用的 category 等等。这些代码不会频繁改动，可以作为基础依赖。

基础依赖在保持稳定的基础之上，还需要做到高复用性和单一职责性。这就要涉及到大家经常会去做的一件事了——创建 Common 模块。Common 模块可能会存一些常用的 category，helper，utils 等等东西：

pod 'MGJiPhone-Common'

最开始的时候这么做会显的很方便，但是随着项目规模的增长，整个 Common 模块最终会成为依赖管理的噩梦。Common 本身作为一个模块集各种依赖于一身，缺乏内部的横向解耦，导致其整体的复用性非常差，简直是剪不断理还乱。因此最好一开始就避免创建 Common 模块，让每个模块都保持尽量少的职责：

pod 'MGJiPhone-Location'
pod 'MJGiPhone-Device'
pod 'MGJiPhone-NSStringCategory'
pod 'MGJiPhone-NSDateCategory'

横向依赖

把基础模块拆分完之后，下面需要对业务模块之间横向的依赖进行拆解。这部分是比较难也是容易碰到问题的。对于两个模块之间的 vc 常见的 push 操作：

LanguageViewController *vc = [[LanguageViewController alloc] init];
vc.selectedIndex = self.currentSelectedIndex;
[self.navigationController pushViewController:vc animated:YES];

可以通过引入 Router 来去除对于 vc 类的强依赖：

// 注册
[[HHRouter shared] map:@"/lang/:index/" toControllerClass:[LanguageViewController class]];// 获取
UIViewController *vc = [[HHRouter shared] matchController:@"/lang/1/"];
[self.navigationController pushViewController:vc animated:YES];

这种办法不仅可以用于 Controller，用于普通的对象也是可以的。Router 可以自动取得对应的类，并进行实例化。对于不需要实例化的模块来说，蘑菇街的解决办法中引入了 ObjectHandler：

[MGJRouter registerURLPattern:@"mgj://cart/ordercount" toObjectHandler:^id(NSDictionary *routerParamters){// do some calculationreturn @42;
}]

以及面向接口思想的 ModuleManager，做到了依赖于接口(protocol）而不依赖于实现。

以我浅薄的开发经验看来，基于 Router 的这种解决方案已经能处理大部分情况了，除了 HHRouter 之外，网上还有 JLRoutes，Routable-iOS，ABRouter 等等开源的方案说明大部分人还是认可这种解耦方式的。再加上 ModuleManager 这种面向接口的模块管理工具（代码实现可以参考念纪的 AppLord），如果用的好的话，已经能够把整个代码的依赖拆分的比较清楚了。

这套方案差不多是我目前为止看到的最优秀的解耦方案了，从中可以看到作者很多的积淀和思考。

代码获取

有步骤讲解视频以及优化后的项目源码资料.因为简书文章没有地方放.大家可以加一下我的群获取一下。在群里讨论一下组件化技术这一块。 QQ群号：656315826.