一、iOS组件化常见方案探讨
首先探讨一种最为常见的方案——通过openURL进行注册与组件调用。
具体流程如下：在App启动时，各组件模块实例化后向ModuleManager注册URL。有时也可以不实例化，直接用class注册。当组件A需要调用组件B时，只需向ModuleManager传递一个URL，参数以GET形式附加在URL后，与开放式的openURL类似。ModuleManager负责调度组件B，完成调用任务。
方案优劣分析
然而，这一方案存在若干值得商榷之处。
首先，在组件化过程中注册URL并非必要。组件完全可以省略向管理器注册URL的步骤。注册操作反而会增加额外的内存开销——注册Class尚属轻量，但若注册实例，则会占用可观的内存。
此外，在iOS开发中，正确的设计应当是让组件化的中间件为openURL提供服务，而非相反。换言之，openURL只是一种实现手段，而非组件化的核心基础。
更为关键的问题是，openURL方式难以传递非常规对象。
例如，若需传递一个UIImage对象，代码将如下所示：
[a openUrl:@"https://baidu.com/detail"
params:@{
@"id":"abc123",
@"type":"1",
@"image":[UIImage imageNamed:@"iOSImage"]}
]
若不采用这种写法，复杂参数根本无法传递。但若采用，则该入口同时处理远程调用与本地调用，导致功能边界变得模糊。
从本质上讲，URL注册是为了实现服务发现。然而在iOS开发中，服务发现完全无需主动注册——借助Runtime即可完成。此外，维护一份注册列表相当繁琐：每次新增调用都需要更新列表，而弃用的调用又时常被遗忘删除。由于Runtime无需注册过程，自然免去了这些维护成本。
综上所述，通过URL注册实现组件化不仅没有必要，而且会降低扩展性与可维护性。
二、组件化方案的新构思
现在来看另一种思路。其核心基于Mediator模式与Target-Action模式，并通过Runtime完成调用。有趣的是，该方案将远程应用调用与本地应用调用区分开来，且由本地应用调用为远程应用调用提供服务——这与前述常见方案正好相反。
调用方式详解
首先介绍本地应用调用。
当本地组件A需要调用其他组件时，只需执行如下代码：
[[Mediator sharedInstance] performTarget:targetName action:actionName params:@{…}]
Mediator获取target和action信息后，通过Objective-C的Runtime动态生成target实例及对应的action选择子，最终调用目标业务提供的逻辑。整个过程无需预先注册，也不需维护任何表格。
接下来看远程应用调用。
远程应用通过openURL方式触发，iOS系统根据info.plist中的scheme配置，找到能够响应URL的应用。应用在AppDelegate中收到URL后，调用Mediator的openUrl:方法将URL传入。若需同时接收option数据，也可使用openUrl:options:，具体取决于本地业务执行时是否依赖option。
URL进入Mediator后会被解析，请求被路由至对应的target和action，后续流程与本地调用完全一致。
