博客> iOS组件化——蘑菇街案例分析
iOS组件化——蘑菇街案例分析
2小时前 评论:0 阅读:1224 胖子爱吃素
iOS开发 程序员 架构 组件化

序言

随着公司业务的不断发展,项目的功能越来越复杂而传统的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 calculation
    return @42;
}]

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

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

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

代码获取

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

收藏
0
sina weixin mail 回到顶部