iOS 组件化学习
蘑菇街的方案: 蘑菇街组件化的技术方案
对应的demo
上面的反驳 Casa提出了不同意见,下半部分是下面蘑菇街修改的回应
对应的demo
蘑菇街的修改 自己方案做了进一步优化
大佬Bang的总结1 梳理总结
大佬mrpeak的总结2 iOS组件化方案
阿里的方案(有参考casa)casa对此的评价是�:用更臃肿的体量做了同样的事情
以下是看完上面文章的总结
- iOS组件化的方式:
1. catagory(Casa称之为target - action方式)
方式为:
【模块编写对应的中间层catagory - 中间层 - 模块调用catagory的方法】
catagory有两种方式:
- runtime,通过字符串映射获取类,用NSMethodSignature传递多个参数
- 由模块创立者管理,该引入的类引入,写法跟常规的类调用一样,以model代替dictionary作为参数传递
catagory可以引伸出的protocol方式:
【模块编写对应的catagory 和protocol - 中间层 - 模块引入protocol,调用catagory的方法】
这样@import module后使用protocol才能敲出protocol的方法,逻辑分工更加清晰
2. url
通过【模块注册url的操作block -中间层以url为key缓存block- 模块调用url调用block】
url只有一种方式:
字符串做key,dictionary做参数,无法传递复杂参数
url可以引出protocol:
【模块注册protocol -中间层以protocol 为key缓存实现了协议方法的Class- 模块通过中间层获取Class调用协议方法】
其实就基本等价于catagory的protocol方式
区别:
-
catagory的protocol是应用在中间层的,需要一行代码用来创建带protocol的中间层对象指针,一行代码调用协议方法(也能以[(id<Protocol>)center method]的形式一行代码完成),但由于XCode天生残疾,OC里面Class<Protocol>是敲不出protocol里的类方法的(能编译,但没有提示),也就不能把中间层做成只有类方法的形式
-
url的protocol是应用在模块内部对应的类,需要一行获取类的代码,一行创建实现协议的对象的代码(也可以中间层直接返回创建好的对象),一行调用协议方法的代码,写多了还挺烦人的
进一步的总结
- 不安全性:
-
以dictionary做参数能带来最大化的解藕,但会导致模块修改后运行时的错误无法被编译时检测,相比耦合性,稳定性更重要,所以参数传model会比dictionary更好
-
以url的形式也会带来模块修改后的运行时潜在错误,改成注册protocol能减少安全性问题
3 以url的形式很容易被外部入侵,尤其是接入APPDelegate.openURL后,需要额外的安全处理(比如内部调用的时候加key做判断,过滤掉一些外部调用)
-
书写方便:
使用纯catagory不需要手动做指针变换,不需要获取实现协议的类,不需要做其他额外的操作
-
动态性:
使用url的方式可以动态下发注册,蘑菇街以此实现当线上模块出现致命bug时可以动态切换到h5页面
综上,高安全性,书写方便的做法:
- 建立一个中间层空类,每个模块都需要引入这个类
- 使用类方法来处理通信减少书写
- 使用纯catagory,每个模块内部维护一份或多份中间层的catagory,该引用类就引用,怎么普通怎么写,没必要在模块内部用runtime,该暴露的model就暴露出来给其他模块,建立一个总结多分catagory的头文件,pod编写时把catagory和总结头文件暴露出来就行
- 使用的时候@import对应的模块,直接敲出中间层的方法(但这样就不适合OC++的项目了......只能单独import总结头文件)
- 必要时连push/present都可以在模块内部实现,然后需要时用block返回结果model
纯catagory接入动态性方案
当服务器下发到替换文件时(记得加密),在中间层主类中使用runtime把对应的catagory替换成打开网页,具体参考Aspects jrswizzle RSSwizzle等Method Swizzling的第三方
