我要评论一、ios 组件化常用方式讨论
使用openurl进行组件的注册和调用
app 启动时实例化各组件模块，然后这些组件向 modulemanager 注册 url ，有些时候不需要实例化，使用 class 注册。
当组件a需要调用组件b时，向 modulemanager 传递 url ，参数跟随 url 以 get 方式传递，类似openurl 。然后由 modulemanager 负责调度组件b，最后完成任务。
方案分析
第一步的问题，在组件化的过程中，注册 url 并不是充分必要条件，组件是不需要向组件管理器注册url的。而且注册了 url 之后，会造成不必要的内存常驻，如果只是注册class，内存常驻量就小一点，如果是注册实例，内存常驻量就大了。
第二步。在 ios 领域里，一定是组件化的中间件为 openurl 提供服务，而不是 openurl 方式为组件化提供服务。
问题在于无法表达非常规对象。
如果是传递复杂对象，如 uiimage ，只能做如下表达
[a openurl:@"http://baidu.com/detail"
params:@{
@"id":"abc123",
@"type":"1",
@"image":[uiimage imagenamed:@"iosimage"]}
]如果不像上面这么做，复杂参数和非常规参数就无法传递。如果这么做了，那么事实上这就是拆分远程调用和本地调用的入口了。
url 注册对于实施组件化方案是不必要的，且通过 url 注册的方式形成的组件化方案，拓展性和可维护性都会被打折。
注册 url 的目的其实是一个服务发现的过程，在 ios 领域中，服务发现的方式是不需要通过主动注册的，使用 runtime 就可以了。另外，注册部分的代码的维护是一个相对麻烦的事情，每一次支持新调用时，都要去维护一次注册列表。如果有调用被弃用了，是经常会忘记删项目的。runtime 由于不存在注册过程，那就也不会产生维护的操作，维护成本就降低了。
二、对组件化的构思
以上方式主要是基于 mediator 模式和 target-action 模式，中间采用了 runtime 来完成调用。这套组件化方案将远程应用调用和本地应用调用做了拆分，而且是由本地应用调用为远程应用调用提供服务，与常用方案正好相反。
调用方式
先说本地应用调用，本地组件a在某处调用
[[mediator sharedinstance] performtarget:targetname action:actionname params:@{…}]向 mediator 发起跨组件调用，mediator 根据获得的 target 和 action 信息，通过 objective-c 的 runtime 转化生成 target 实例以及对应的 action 选择子，然后最终调用到目标业务提供的逻辑，完成需求。
在远程应用调用中，远程应用通过 openurl 的方式，由ios系统根据 info.plist 里的 scheme 配置找到可以响应 url 的应用，应用通过 appdelegate 接收到url之后，调用 mediator 的 openurl: 方法将接收到的url信息传入。当然， mediator 也可以用 openurl:options: 的方式顺便把随之而来的option 也接收，这取决于你本地业务执行逻辑时的充要条件是否包含 option 数据。传入 url 之后，mediator 通过解析 url ，将请求路由到对应的 target 和 action ，随后的过程就变成了上面说过的本地应用调用的过程了，最终完成响应。
以上就是ios 组件化初步构思的详细内容，更多关于ios组件化常用方式的资料请关注代码网其它相关文章。也希望大家可以多多关注代码网，后续我们将带来更精彩的更新！
发表评论