蘑菇街的方案: 蘑菇街组件化的技术方案
对应的demo

上面的反驳 Casa提出了不同意见,下半部分是下面蘑菇街修改的回应
对应的demo

蘑菇街的修改 自己方案做了进一步优化

大佬Bang的总结1 梳理总结

大佬mrpeak的总结2 iOS组件化方案

阿里的方案(有参考casa)casa对此的评价是�:用更臃肿的体量做了同样的事情

以下是看完上面文章的总结

• iOS组件化的方式:

1. catagory(Casa称之为target – action方式)

方式为:

【模块编写对应的中间层catagory – 中间层 – 模块调用catagory的方法】

catagory有两种方式:

1. runtime,通过字符串映射获取类,用NSMethodSignature传递多个参数
2. 由模块创立者管理,该引入的类引入,写法跟常规的类调用一样,以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方式

区别:

1. catagory的protocol是应用在中间层的,需要一行代码用来创建带protocol的中间层对象指针,一行代码调用协议方法(也能以[(id<Protocol>)center method]的形式一行代码完成),但由于XCode天生残疾,OC里面Class<Protocol>是敲不出protocol里的类方法的(能编译,但没有提示),也就不能把中间层做成只有类方法的形式

2. url的protocol是应用在模块内部对应的类,需要一行获取类的代码,一行创建实现协议的对象的代码(也可以中间层直接返回创建好的对象),一行调用协议方法的代码,写多了还挺烦人的

进一步的总结

• 不安全性:

1. 以dictionary做参数能带来最大化的解藕,但会导致模块修改后运行时的错误无法被编译时检测,相比耦合性,稳定性更重要,所以参数传model会比dictionary更好

2. 以url的形式也会带来模块修改后的运行时潜在错误,改成注册protocol能减少安全性问题

3 以url的形式很容易被外部入侵,尤其是接入APPDelegate.openURL后,需要额外的安全处理(比如内部调用的时候加key做判断,过滤掉一些外部调用)

• 书写方便:

  使用纯catagory不需要手动做指针变换,不需要获取实现协议的类,不需要做其他额外的操作

• 动态性:

  使用url的方式可以动态下发注册,蘑菇街以此实现当线上模块出现致命bug时可以动态切换到h5页面

综上,高安全性,书写方便的做法:

1. 建立一个中间层空类,每个模块都需要引入这个类
2. 使用类方法来处理通信减少书写
3. 使用纯catagory,每个模块内部维护一份或多份中间层的catagory,该引用类就引用,怎么普通怎么写,没必要在模块内部用runtime,该暴露的model就暴露出来给其他模块,建立一个总结多分catagory的头文件,pod编写时把catagory和总结头文件暴露出来就行
4. 使用的时候@import对应的模块,直接敲出中间层的方法(但这样就不适合OC++的项目了……只能单独import总结头文件)
5. 必要时连push/present都可以在模块内部实现,然后需要时用block返回结果model

纯catagory接入动态性方案

当服务器下发到替换文件时(记得加密),在中间层主类中使用runtime把对应的catagory替换成打开网页,具体参考Aspects jrswizzle RSSwizzle等Method Swizzling的第三方