虽然全程都是`你们讲的好有道理`，但是还是耐心看完了！Ye！
四篇中，`bang`老师的分析比较易懂，看完再回头看豁然开朗！
一、
「组件化」策略 优势：
<1> 加快编译速度（不用编译主客那一大坨代码了）
<2> 自由选择开发姿势（MVC / MVVM / FRP）
<3> 方便 QA 有针对性地测试
<4> 提高业务开发效率
实现：
组件间通信，采用的 URL 跳转模式，理论上页面之间的跳转只需 open 一个 URL 即可。所以对于一个组件来说，只要定义「支持哪些 URL」即可。
1. 怎么知道有哪些可用的 URL？
把这些短链生成不同平台所需的文件，iOS 平台生成 .{h,m} 文件，Android 平台生成 .java 文件，并注入到项目中。这样开发人员只需在项目中打开该文件就知道所有的可用 URL 了。
2. 「组件A」要调用「组件B」的某个方法，比如在商品详情页要展示购物车的商品数量，就涉及到向购物车组件拿数据。
<1> 依托于MGJRouter，不过添加了新的方法- (id)objectForURL:，注册时也使用新的方法进行注册
<2> 稍微复杂但更具通用性的方法是使用「协议」 <-> 「类」绑定的方式，还是以购物车为例，购物车组件可以提供这么个 Protocol
3. 组件生命周期管理
理想中的组件可以很方便地集成到主客中，并且有跟AppDelegate一致的回调方法。这也是ModuleManager做的事情。
<1> 每个模块都实现了<ModuleProtocol>协议，其中有生命周期的方法。在`didFinishLaunchingWithOptions`中单例`ModuleManager`读plist获取所有的模块，拿出所有模块(都遵循上述协议)，调用其生命周期的方法。
<2> 系统的一些事件会有通知，比如 applicationDidBecomeActive 会有对应的UIApplicationDidBecomeActiveNotification，组件如果要做响应的话，只需监听这个系统通知即可。
<3> 没有通知的，比如- application:didRegisterUserNotificationSettings：在AppDelegate的各个方法里，手动调一遍组件的对应的方法，如果有就执行。
二、
1. 调用方式：
<1> 本地应用调用，本地组件 A 在某处调用[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}] 向CTMediator发起跨组件调用，CTMediator根据获得的target和action信息，通过objective-C的 runtime 转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻辑，完成需求。
<2> 远程应用调用中，远程应用通过openURL的方式，由iOS系统根据info.plist里的scheme配置找到可以响应URL的应用（在当前我们讨论的上下文中，这就是你自己的应用），应用通过AppDelegate接收到URL之后，调用 CTMediator 的 openUrl: 方法将接收到的URL信息传入。当然，CTMediator也可以用openUrl:options:的方式顺便把随之而来的option也接收，这取决于你本地业务执行逻辑时的充要条件是否包含option数据。传入URL之后，CTMediator通过解析URL，将请求路由到对应的 target 和 action，随后的过程就变成了上面说过的本地应用调用的过程了，最终完成响应。
2. 组件仅通过`Action`暴露可调用接口
3. 组件化方案中的去model设计 - 用字典
4. 去model的组件化方案中，影响效率的点有两个：<1> 调用方如何知道接收方需要哪些key的参数。<2> 调用方如何知道有哪些 target 可以被调用 - 用 category
三、
1. openURL只是页面间的调用方式 == url - block
2. 组件间的调用通过 protocol 来实现 == protocol - class
四、
很高兴刚看这篇文章的一点点时，发现页面跳转这个问题我也思考过，当时一直在纠结是否要将跳转的代码耦合在单一的类中。
1.
总结起来就是，组件通过中间件通信，中间件通过 runtime 接口解耦，通过 target-action 简化写法，通过 category 感官上分离组件接口代码。
2. 蘑菇街用的是另一种方式解决：注册表的方式，用URL表示接口，在模块启动时注册模块提供的接口。注册 - 缓存 - 调用获取 - 执行
（url-block 的模式）各个组件初始化时向 Mediator 注册对外提供的接口，Mediator 通过保存在内存的表去知道有哪些模块哪些接口。
Mediator 不能直接去调用组件的方法，因为这样会产生依赖，那我就要通过其他方法去调用，也就是通过 字符串->方法 的映射去调用。<1> runtime 接口的className + selectorName -> IMP，<2> 注册表的key -> block。而前一种是 OC 自带的特性，后一种需要内存维持一份注册表。
如果是 URL 的形式，那组件对外提供接口时就要同时考虑`本地调用`和`远程调用`两种情况，而远程调用有个限制，传递的参数类型有限制，只能传能被字符串化的数据，或者说只能传能被转成 json 的数据，像 UIImage 这类对象是不行的，所以如果组件接口要考虑远程调用，这里的参数就不能是这类非常规对象，接口的定义就受限了。
3. protocol - class 注册表的方式
这个方案跟刚才两个最大的不同就是，它不是直接通过 Mediator 调用组件方法，而是通过 Mediator 拿到组件对象，再自行去调用组件方法。
评论：
编译解耦 和 逻辑解耦
网友评论