iOS应用组件化

iOS应用组件化：

为什么需要组件化

1. 在业务极速增大的情况下，各个团队并不知道其它团队具体的业务实现和跳转，而且并不需要知道，如何进行各个业务的通信
2. 当业务增大的情况下，某个业务或许会被多个项目引用，有可能还还被交叉使用，如何解决引用问题

我口中的组件化到底是神马意思

解放大量的重复工作，减少在各个项目集成时的困扰。比如我在做业务的时候，需要到支付系统手机收银台，并行开发，这时候我不需要知道他那边的进度如何，他把一个url模式的东西给我，我直接进行url跳转即可。

组件化的流程

1. 启动时首先各个业务去组件中心进行注册
2. 对各个业务组件进行初始化
3. 调用业务组件的url

用协议模式打开对应Controller

在开发iOS的时候，经常会遇到根据一个值为string的key去打开一个controller，然后陪着一些参数。例如远程通知，webview打开本地页面等等。或者两个子模块应用并行开发，需要在特定地方打开对方某个controller。

打开某个controller，需要考虑的几点东西：

1. 如何得到指定的vc
2. 参数传递
3. 上级页面的操作，如：订单详情，返回上级页面为订单列表

这里我给一个指定的url：

xxxdemo://push/second/third?second[a]=1&second[b]=2&third[a]=3&third[b]=4&e=5&f[a][]=6&f[a][]=7&second[c][]=1&second[c][]=2

这里是标准的url格式，当我们在参数中需要添加一个url的时候，我们需要对url进行urlencode再放入(例：xxxdemo://open/third?url=www.baidu.com%3Ftoken%3D123%26a%3D3&b=1)

1.如何得到指定的vc

方法	优点	缺点
使用对应表	简单易懂，而且性能比较好	扩展性差，难维护
使用类名对应	简单，性能好，扩展好	比较蠢，android和iOS不通用
使用协议查询	扩展性好，便于维护	在查询过程会比其它方法消耗更多资源

这里我们使用第三种，因为作为一个通用库，考虑的更多是其它项目通用性，可扩展性以及维护。

在库中，我们会给出一个协议，当业务方在业务中实现这个协议，那么就相当于在我们的注册表中注册了，我们把对应的内容拿出来为映射的key值，然后存储在我们的沙盒里面。下一次，只需要根据版本号是否增加，去判断是否需要更新这个文件（当然在debug环境下，是都更新的）。

在调用的时候，我们只需要去寻找这个key，然后根据value去找到这个class，最后把参数根据实现协议的另外一个方法传入，如此便可。

使用url则是得到url里面的paths、pathComponents，如果用pathComponents，需要移除："/"，然后根据paths去获取不同的value，可以对应多个viewcontroller。

2.如何传递参数

如果打开单个viewcontroller，那么在viewcontroller里面实现协议，然后把url的query传入即可，但是有些时候，我们会遇到一次打开多个页面的情况。

首先，在对url进行解析的时候，判断是否为多个paths，单个则直接把所有query传入，多个，则先根据query里面的key值找出对应那一个path的所有参数，然后传入

3.上级页面的操作，如：订单详情，返回上级页面为订单列表

这个问题在1中已经解决。

这里的demo我不放出来，如果需要思路可以直接找我