iOS组件化思路－大神博客研读和思考-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84619467/article/details/139781639

2016.03.10 蘑菇街App的组件化之路: http://limboy.me/ios/2016/03/10/mgj-components.html

为什么要组件化？

组件和组件之间没有明确的约束；
组件单独开发、单独测试，不能揉入主项目中开发，测试也可以针对性的测试；

如何管理短链？（url跳转）

[MGJRouter registerURLPattern:@“mgj://detail?id=:id” toHandler:^(NSDictionary *routerParameters) {

NSNumber *id = routerParameters[@“id”];

// create view controller with id

// push view controller

}];

[MGJRouter openURL:@"mgj://detail?id=404”]

短链如何管理？

后台专门管理短链；平台生成所需的文件，ios平台生成h，m文件，android生成java文件，注入到项目中；
开发人员查看生成文件了解所有可用URL；
缺点：无法把参数传递也通过生成方式获得；

同步的Action调用？（服务调用）

方法一：通过url的方式

[MGJRouter registerURLPattern:@“mgj://cart/ordercount” toObjectHandler:^id(NSDictionary *routerParamters){

// do some calculation

return @42;

}]

NSNumber *orderCount = [MGJRouter objectForURL:@"mgj://cart/ordercount”]

方法二：通过protocol－class对应的方式

把公共协议文件统一放到PublicProtocolDomain.h中，所有业务组件只依赖这个文件；protocol只能通过类方法提供？

@protocol MGJCart

(NSInteger)orderCount;

@end

[ModuleManager registerClass:MGJCartImpl forProtocol:@protocol(MGJCart)]

[ModuleManager classForProtocol:@protocol(MGJCart)]

组件生命周期的管理：（组件管理）

启动初始化时，实例APP中所有组件的module实例，让每个组件的module实例执行一遍didFinishLaunchingWithOptions方法：在这方法中每个组件注册自己的URL，使用class注册；每个组件可以自行监控系统的通知，如UIApplicationDidBecomeActiveNotification, 对于没有系统通知消息则将此方法写入module的protocol中，依次执行实例的这些protocol方法；

[[ModuleManager sharedInstance] loadModuleFromPlist:[[NSBundle mainBundle] pathForResource:@“modules” ofType:@“plist”]];

NSArray *modules = [[ModuleManager sharedInstance] allModules];

for (id module in modules) {

if ([module respondsToSelector:_cmd]) {

[module application:application didFinishLaunchingWithOptions:launchOptions];

}

组件化版本管理的问题

版本同步问题： API接口改动升级（旧接口不存在了，不向下兼容），版本的中位号发生改变；需要所有依赖其的调用都发生改变，才能保证壳工程和主工程能够同步编译通过；
pod update之后编译太长：考虑通过framework的方式进行修改；
持续集成问题：不能只是把podspec直接扔到private repo里完事，需要扔到主工程进行打包编译，编译通过允许提供版本升级，不通过扔回去进行处理；CI编译检查，通过之后再将版本号升级到private repo中，同时修改主工程中Podfile的版本依赖号；但如果是其它工程呢，被多个业务工程所依赖，如何办？

蘑菇街开源组件：

MGJRouter： https://github.com/mogujie/MGJRouter.git

JLRoutes 的问题主要在于查找 URL 的实现不够高效，通过遍历而不是匹配。还有就是功能偏多。
HHRouter 的 URL 查找是基于匹配，所以会更高效，MGJRouter 也是采用的这种方法，但它跟 ViewController 绑定地过于紧密，一定程度上降低了灵活性。

（2）反革命的组件化方案

文章来源：

2016.03.13 iOS应用架构谈组件化方案http://casatwy.com/iOS-Modulization.html
2016.03.14 iOS应用架构谈组件化方案(补充)

蘑菇街的方案为什么不好？

url注册对于实施组件化是完全没有必要的，拓展性和可维护性都降低；
基于openURL的方案的话，有一个致命缺陷：非常规对象无法参与本地组件间调度；但是可以通过传递params来解决，但是这样区分了远程调用和本地调用的入口；
模块内部是否仍然需要使用URL去完成调度？是没有必要的，为啥要复杂化？

反革命的组件化方案：

基于Mediator模式和Target－Action模式：

[CTMediator sharedInstance]

openUrl:url] //call from other app with url

parseUrl

performTarget:action:params //call form Native Module

runtime

[TargetA action1], [TargetA action2]

[TargetB action1], [TargetB action2]

反革命组件化方案的调用方式：

本地跨组件间调用：

[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{…}]

远程应用调用：

openUrl + parseUrl的方式；针对请求的路由操作，直接将Target和Action的名字封装到url中；

反革命组件化方案的好处：

将远程调用和本地调用做了拆分，而且由本地应用调用位远程应用调用提供服务；
组件仅通过Action暴露可调用接口；
组件化方案必需去Model设计：只有调用方依赖Mediator，响应方依赖是没有必要的；
调用方如何知道接收方需要哪些Key的参数，如何知道有哪些target可被调用？：在mediator中维护针对Mediator的Category，每个category对应一个target，categroy中的方法对应Action场景；