iOS应用架构谈-模块化方案

模块化方案

一、蘑菇街：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](https://github.com/lincode/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