iOS组件化——蘑菇街案例分析

序言

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

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

什么是组件化

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

优势

一、组件之间相互独立。各组件开发成员之间的代码想相互独立编写的，独立编译，独立运行和独立测试的。 二、资源的重复里用，尤为是功能性，工具性的代码，能够很轻松的重复里用 三、迭代的效率提升。经过迭代进行功能的增减，只须要进行组件的拆分和组合。很方便也很高效

缺点

一、增长了代码的冗余，组件化颗粒度越细，中间代码越多 二、增长了项目的复杂度，复杂度越高越容易出问题 三、学习成本高，对于开发人员对各类工具的掌握要求也比较高，对于新手来讲入门较为困难。 四、因为工具和流程的复杂化，致使团队之间协做的成本变高，某些状况下可能会致使开发效率降低。

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

怎么作组件化

以蘑菇街为例，使用 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 calculation
    return @42;
}]

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

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

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

代码获取

有步骤讲解视频以及优化后的项目源码资料.由于简书文章没有地方放.你们能够加一下个人群获取一下。在群里讨论一下组件化技术这一块。 QQ群号：656315826.