iOS应用架构谈 模块化方案
Paste_Image.png
模块化方案
一、蘑菇街：MGJRouter ------URL Router 模块化方法
URLRouter可以参考开源界比较成熟的方案MGJRouter、JLRouter、HHRouter，把每一个模块以一个URL的形式作为独立存在的界限范围。URLRouter需要在内存中维护一张URL表作为key来实现对应的push或者唤起对应的模块。类似get方式的openURl它在传递参数过程中不能传递类似于对象这样的数据，只能传递普通类型数据。
例：
注册
[MGJRouter registerURLPattern:@"mgj://detail" toHandler:^(NSDictionary *routerParameters) {
// create view controller with id
// push view controller
}];
远程调用方式：无法表达非常规对象
[MGJRouter openUrl:"mgj://detail?id=123&type=0"];
本地调用方式 ：如下方式可使用非常规对象。
[MGJRouter openUrl:"mgj://detail" params:@{
@"id":"123",
@"type":"0",
@"image":[UIImage imageNamed:@"test"]
}]
使用ModuleManager管理模块加载--类似github源码：FRDModuleManager
appModuleManager.addModule(AppModuleA())
appModuleManager.addModule(AppModuleB())
二、casatwy：CTMediator ------Target Action 模块化方案
TargetAction也是基于苹果原生的Runtime的优势，其优势很大在于可以做到无需加载内存，并且在调用中没有相关的依赖。在调用中的缺陷在于只有在运行池中才可以知道对应的组件是否存在，若不存在会造成对应的Crash。另外代码中会出现HardCode,代码变得晦涩难懂，调用其他模块方法没有提示。使用CTMediator 分类的方式解决调用提示问题也有点重复造轮子的意思。
[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}]
三、阿里巴巴：BeeHive ------ Protocol class 模块化方案
Protocolclass是利用原始class以及对应的Protocol用到的Serviceinterface去进行实现以及接口的分离，让大部分的业务方只需要基于Protocol的interface进行调用。缺点是其过程中会涉及到内存占用的问题，另外调用方和响应方都必须依赖于同一个service协议文件，每个service协议需单独一个库，pod库数量大量增加。
注册
[[BeeHive shareInstance] registerService:@protocol(HomeServiceProtocol) service:[BHViewController class]];
使用
#import "BHService.h"
id< HomeServiceProtocol > homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];
// use homeVc do invocation
方案选择
每个方案都有各自优缺点，请根据需求自行选择。
Limboy蘑菇街文章阅读
蘑菇街MGJRouter:组件化之路
蘑菇街Protocol class:组件化之路-续
casaTwy文章阅读
iOS应用架构谈 开篇
iOS应用架构谈 view层的组织和调用方案
iOS应用架构谈 网络层设计方案
iOS应用架构谈 本地持久化方案及动态部署
iOS应用架构谈 组件化方案
阿里BeeHive 文章阅读
BeeHive：大型iOS项目解耦实践
BeeHive: 源码解读
BeeHive:iOS模块化之路
其他
jiaModule方式 https://github.com/wujunyang/jiaModuleDemo
58同城：http://mp.weixin.qq.com/s/PbOh-l0E4bD3HoKj0GzYWQ
