iOS组件化方案

公共基础服务

• 网络服务
• 本地资源服务
• 缓存服务
• 常用的Extension工具集合（字符串的处理，日期时间的格式化）

1.URL注册方案

• JLRoutes
  JLRoutes全局会保存一个Map，这个Map会以scheme为Key，JLRoutes为Value。所以在routeControllerMap里面每个scheme都是唯一的。
  在每个JLRoutes里面都保存了一个数组，这个数组里面保存了每个路由规则JLRRouteDefinition里面会保存外部传进来的block闭包，pattern，和拆分之后的pattern。

在每个JLRoutes的数组里面，会按照路由的优先级进行排列，优先级高的排列在前面。

注册服务：

[JLRoutes addRoute:@"/:object/:action/:primaryKey" handler:^BOOL(NSDictionary *parameters) {
  NSString *object = parameters[@"object"];
  NSString *action = parameters[@"action"];
  NSString *primaryKey = parameters[@"primaryKey"];
  // do something here
  return YES;
}];

调用：

[JLRoutes routeURL:url];

优点：

服务器可以动态的控制页面跳转，可以统一处理页面出问题之后的错误处理，可以统一三端，iOS，Android，H5 / RN / Weex 的请求方式。

缺点：

1.URL短连接分布式注册时候，导航的硬编码太多，容易写错导致调用失败
2.class的load方法完成注册，太多对启动app时主线程有影响
3.内存常驻比较严重,所有的ur,class,实例, block 必须提前注册好,使用时对象释放可能出错

2.Target-Action方案

CTMediator

本地应用调用
本地组件A在某处调用[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}]向CTMediator发起跨组件调用，CTMediator根据获得的target和action信息，通过objective-C的runtime转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻辑，完成需求。

远程应用调用
远程应用通过openURL的方式，由iOS系统根据info.plist里的scheme配置找到可以响应URL的应用（在当前我们讨论的上下文中，这就是你自己的应用），应用通过AppDelegate接收到URL之后，调用CTMediator的openUrl:方法将接收到的URL信息传入。当然，CTMediator也可以用openUrl:options:的方式顺便把随之而来的option也接收，这取决于你本地业务执行逻辑时的充要条件是否包含option数据。传入URL之后，CTMediator通过解析URL，将请求路由到对应的target和action，随后的过程就变成了上面说过的本地应用调用的过程了，最终完成响应。

针对请求的路由操作很少会采用本地文件记录路由表的方式，服务端经常处理这种业务，在服务端领域基本上都是通过正则表达式来做路由解析。App中做路由解析可以做得简单点，制定URL规范就也能完成，最简单的方式就是scheme://target/action这种，简单做个字符串处理就能把target和action信息从URL中提取出来了。

优点：

1.充分的利用Runtime的特性，无需注册这一步。Target-Action方案只有存在组件依赖Mediator这一层依赖关系。在Mediator中维护针对Mediator的Category，每个category对应一个Target，Categroy中的方法对应Action场景。Target-Action方案也统一了所有组件间调用入口。
2.有一定的安全保证，它对url中进行Native前缀进行验证。

缺点：

Target_Action在Category中将常规参数打包成字典，在Target处再把字典拆包成常规参数，这就造成了一部分的硬编码。

3.Protocol-Class注册方案

项目案例：
CRMainProject

优点：

没有硬编码

缺点：

1.每个Protocol都要向ModuleManager进行注册。
2.ModuleEntry是同时需要依赖ModuleManager、ModuleEntryProtocol和组件里面的页面或者组件两者的