模块解耦手段
实现模块之间真正的解耦才算是真正的模块化
自己的理解
1 面向接口调用(遵守协议,实现协议方法,依赖协议), 即新开一个对象ModuleManager,提供一个registerClass:forProtocol的方法,注册protocol与class进行配对,调用是,通过protocol找到class返回给业务方,这里protocol的两个作用,1是key值,2是起到定义调用接口的作用,可以定义任意类型的参数
2 面向自定义协议调用,采用现成的协议如url协议,统一实现本地和远程跳转,实现业务解耦,(真正解耦采用注册机制, 单例中有个字典属性,注册url的key,和block的值) (原理是将url与block进行映射, url起到两个作用,一个是作为key值与block进行映射, 二是可以直接接参数像普通url后面跟参数一样,如果传递非常规参数,可以在url后面添加param)
1, 2同url注册形式一样，都得维持注册表。被调用方与调用方，虽然不相互依赖，但都得依赖这个协议
3利用运行时的反射机制 OC的反射机制是通过一个字符串找到一个类的类对象
基于Mediator模式和Target-Action模式，中间采用了runtime来完成调用。这套组件化方案将远程应用调用和本地应用调用做了拆分
实现原理
[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{…}]向CTMediator发起跨组件调用，CTMediator根据获得的target和action信息，通过objective-C的runtime转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻辑，完成需求。其中用CTMediator分类调用CTMediator类的方法时,实现了对修改关闭,对扩展开发的设计原则,也可以直接调用CTMediator
CTMediator
/*
scheme://[target]/[action]?[params]
url sample:
aaa://targetA/actionB?id=1234
*/
// 远程App调用入口
- (id _Nullable)performActionWithUrl:(NSURL * _Nullable)url completion:(void(^_Nullable)(NSDictionary * _Nullable info))completion;
// 本地组件调用入口
- (id _Nullable )performTarget:(NSString * _Nullable)targetName action:(NSString * _Nullable)actionName params:(NSDictionary * _Nullable)params shouldCacheTarget:(BOOL)shouldCacheTarget{
Class targetClass = NSClassFromString(targetClassString);
target = [[targetClass alloc] init];
采用运行时构建可执行的NSInvocation。在内部都给其添加了前缀
NSString * targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
if ([target respondsToSelector:action]) {
return [self safePerformAction:action target:target params:params];
}
}
- (id)safePerformAction:(SEL)action target:(NSObject *)target params:(NSDictionary *)params {
// 容错处理 ...
if (strcmp(retType, @encode(CGFloat)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
CGFloat result = 0;
[invocation getReturnValue:&result];
return @(result);
}
// ...
// 重点:
return [target performSelector:action withObject:params];
}
// CTMediator分类中调用原来类中的方法
@implementation CTMediator (CTMediatorModuleAActions)
- (UIViewController *)CTMediator_viewControllerForDetail
{
UIViewController *viewController = [self performTarget:kCTMediatorTargetA
action:kCTMediatorActionNativeFetchDetailViewController
params:@{@"key":@"value"}
shouldCacheTarget:NO
];
if ([viewController isKindOfClass:[UIViewController class]]) {
// view controller 交付出去之后，可以由外界选择是push还是present
return viewController;
} else {
// 这里处理异常场景，具体如何处理取决于产品
return [[UIViewController alloc] init];
}
}
// Target_A
@implementation Target_A
- (UIViewController *)Action_nativeFetchDetailViewController:(NSDictionary *)params
{
// 因为action是从属于ModuleA的，所以action直接可以使用ModuleA里的所有声明
DemoModuleADetailViewController *viewController = [[DemoModuleADetailViewController alloc] init];
viewController.valueLabel.text = params[@"key"];
return viewController;
}
// ViewController中调用CTMediator
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
[tableView deselectRowAtIndexPath:indexPath animated:YES];
if (indexPath.row == 0) {
UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail];
// 获得view controller之后，在这种场景下，到底push还是present，其实是要由使用者决定的，mediator只要给出view controller的实例就好了
[self presentViewController:viewController animated:YES completion:nil];
}
-
从.h文件里可以看到，外部的调用将远程与本地分开，内部实现时远程利用了本地（通过解析url,将url转换成了本地的调用）。
-
Mediator分别对每一个模块有个一个分类，提供对外部的调用的列表。这些分类被需要调用的模块所依赖。也就是只需要依赖Mediator就可以了，是单向依赖。
-
为了更好的实现组件对外接口的管理。此种方案专门针对每个模块有一个Target_A类似的对外服务接口的实现。
-
用户调用都是通过对Mediator的分类，对固定的模块的类的名字的反射，来对Target_A的调用，当然就调用到了A的服务。
-
此种方式为了使代码方便管理，会为每个模块提供Target和一个对Mediator的分类。
-
Mediator与其分类可以是单独一个repo，方便其他组件依赖。也就是其他组件只依赖于这个中间件。解耦与组件化就完成了。
对自己理解的总结
组件化就是在与解耦，解耦的方式大致就是上面提到的三种方法（也可能有其他办法，但至少现在我看到的最好实践就这三）。然后是基于各个原理的工程化实践。从工程实践来看casa的Mediator+target-action更胜一筹。思路清晰，调用统一，没有注册机制的维护，模块的服务的实现（Target）在同一个地方，不用耦合到真正的模块里。
多说一句，滴滴组件化，页面间的跳转采用openURL,页面在+(void)load方法里进行注册，ONERoute内部保存一份URL与Class的对应表。当调用openURL时，会查找到相应的类，然后生成相应的实例对象。
大神思想和总结
蘑菇街的原文地址在这里：《蘑菇街 App 的组件化之路》，没有耐心看完原文的朋友，我在这里简要介绍一下蘑菇街的组件化是怎么做的：
- App启动时实例化各组件模块，然后这些组件向ModuleManager注册Url，有些时候不需要实例化，使用class注册。
- 当组件A需要调用组件B时，向ModuleManager传递URL，参数跟随URL以GET方式传递，类似openURL。然后由ModuleManager负责调度组件B，最后完成任务。
这里的两步中，每一步都存在问题。
第一步的问题在于，在组件化的过程中，注册URL并不是充分必要条件，组件是不需要向组件管理器注册Url的。而且注册了Url之后，会造成不必要的内存常驻，如果只是注册Class，内存常驻量就小一点，如果是注册实例，内存常驻量就大了。至于蘑菇街注册的是Class还是实例，Limboy分享时没有说，文章里我也没看出来，也有可能是我看漏了。不过这还并不能算是致命错误，只能算是小缺陷。
真正的致命错误在第二步。在iOS领域里，一定是组件化的中间件为openUrl提供服务，而不是openUrl方式为组件化提供服务。
什么意思呢？
也就是说，一个App的组件化方案一定不是建立在URL上的，openURL的跨App调用是可以建立在组件化方案上的。当然，如果App还没有组件化，openURL方式也是可以建立的，就是丑陋一点而已。
为什么这么说？
因为组件化方案的实施过程中，需要处理的问题的复杂度，以及拆解、调度业务的过程的复杂度比较大，单纯以openURL的方式是无法胜任让一个App去实施组件化架构的。如果在给App实施组件化方案的过程中是基于openURL的方案的话，有一个致命缺陷：非常规对象无法参与本地组件间调度。关于非常规对象我会在详细讲解组件化方案时有一个辨析
实际App场景下，如果本地组件间采用GET方式的URL调用，就会产生两个问题：
根本无法表达非常规对象
比如你要调用一个图片编辑模块，不能传递UIImage到对应的模块上去的话，这是一个很悲催的事情。 当然，这可以通过给方法新开一个参数，然后传递过去来解决。比如原来是:
[a openUrl:"http://casa.com/detail?id=123&type=0"];
同时就也要提供这样的方法：
[a openUrl:"http://casa.com/detail" params:@{
@"id":"123",
@"type":"0",
@"image":[UIImage imageNamed:@"test"]
}]
如果不像上面这么做，复杂参数和非常规参数就无法传递。如果这么做了，那么事实上这就是拆分远程调用和本地调用的入口了
另外，在本地调用中使用URL的方式其实是不必要的，如果业务工程师在本地间调度时需要给出URL，那么就不可避免要提供params，在调用时要提供哪些params是业务工程师很容易懵逼的地方。。。在文章下半部分给出的demo代码样例已经说明了业务工程师在本地间调用时，是不需要知道URL的，而且demo代码样例也阐释了如何解决业务工程师遇到传params容易懵逼的问题。
URL注册对于实施组件化方案是完全不必要的，且通过URL注册的方式形成的组件化方案，拓展性和可维护性都会被打折
注册URL的目的其实是一个服务发现的过程，在iOS领域中，服务发现的方式是不需要通过主动注册的，使用runtime就可以了。另外，注册部分的代码的维护是一个相对麻烦的事情，每一次支持新调用时，都要去维护一次注册列表。如果有调用被弃用了，是经常会忘记删项目的。runtime由于不存在注册过程，那就也不会产生维护的操作，维护成本就降低了。
由于通过runtime做到了服务的自动发现，拓展调用接口的任务就仅在于各自的模块，任何一次新接口添加，新业务添加，都不必去主工程做操作，十分透明。
小总结
蘑菇街采用了openURL的方式来进行App的组件化是一个错误的做法，使用注册的方式发现服务是一个不必要的做法。而且这方案还有其它问题，随着下文对组件化方案介绍的展开，相信各位自然心里有数。
正确的组件化方案
先来看一下方案的架构图
--------------------------------------
| [CTMediator sharedInstance] |
| |
| openUrl: <<<<<<<<< (AppDelegate) <<<< Call From Other App With URL
| |
| |
| parseUrl |
| |
| | |
| | |
.................................|...............................
| | |
| |/ |
| |
| performTarget:action:params: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Call From Native Module
| |
| | |
| |/ |
| |
| ------------- |
| | | |
| | runtime | |
| | | |
| ------------- |
| . . |
---------------.---------.------------
. .
. .
. .
. .
. .
. .
. .
. .
-------------------.----------- ----------.---------------------
| . | | . |
| Target | | Target |
| | | |
| / | \ | | / | \ |
| / | \ | | / | \ |
| | | |
| Action Action Action ... | | Action Action Action ... |
|Business A | | Business B |
------------------------------- --------------------------------
这幅图是组件化方案的一个简化版架构描述，主要是基于Mediator模式和Target-Action模式，中间采用了runtime来完成调用。这套组件化方案将远程应用调用和本地应用调用做了拆分，而且是由本地应用调用为远程应用调用提供服务，
调用方式
先说本地应用调用，本地组件A在某处调用[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{…}]向CTMediator发起跨组件调用，CTMediator根据获得的target和action信息，通过objective-C的runtime转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻辑，完成需求。
在远程应用调用中，远程应用通过openURL的方式，由iOS系统根据info.plist里的scheme配置找到可以响应URL的应用（在当前我们讨论的上下文中，这就是你自己的应用），应用通过AppDelegate接收到URL之后，调用CTMediator的openUrl:方法将接收到的URL信息传入。当然，CTMediator也可以用openUrl:options:的方式顺便把随之而来的option也接收，这取决于你本地业务执行逻辑时的充要条件是否包含option数据。传入URL之后，CTMediator通过解析URL，将请求路由到对应的target和action，随后的过程就变成了上面说过的本地应用调用的过程了，最终完成响应。
针对请求的路由操作很少会采用本地文件记录路由表的方式，服务端经常处理这种业务，在服务端领域基本上都是通过正则表达式来做路由解析。App中做路由解析可以做得简单点，制定URL规范就也能完成，最简单的方式就是scheme://target/action这种，简单做个字符串处理就能把target和action信息从URL中提取出来了。
组件仅通过Action暴露可调用接口
所有组件都通过组件自带的Target-Action来响应，也就是说，模块与模块之间的接口被固化在了Target-Action这一层，避免了实施组件化的改造过程中，对Business的侵入，同时也提高了组件化接口的可维护性。
--------------------------------
| |
| Business A |
| |
--- ---------- ---------- ---
| | | | | |
| | | | | |
...........| |........| |........| |...........
. | | | | | | .
. | | | | | | .
. --- --- --- --- --- --- .
. | | | | | | .
. |action| |action| |action| .
. | | | | | | .
. ---|---- -----|-- --|----- .
. | | | .
. | | | .
. ----|------ --|--------|-- .
. | | | | .
. |Target_A1| | Target_A2 | .
. | | | | .
. ----------- -------------- .
. .
. .
..................................................
大家可以看到，虚线圈起来的地方就是用于跨组件调用的target和action，这种方式避免了由BusinessA直接提供组件间调用会增加的复杂度，而且任何组件如果想要对外提供调用服务，直接挂上target和action就可以了，业务本身在大多数场景下去进行组件化改造时，是基本不用动的。
复杂参数和非常规参数，以及组件化相关设计思路
这里我们需要针对术语做一个理解上的统一：
复杂参数是指由普通类型的数据组成的多层级参数。在本文中，我们定义只要是能够被json解析的类型就都是普通类型，包括NSNumber， NSString， NSArray， NSDictionary，以及相关衍生类型，比如来自系统的NSMutableArray或者你自己定义的都算。
总结一下就是：在本文讨论的场景中，复杂参数的定义是由普通类型组成的具有复杂结构的参数。普通类型的定义就是指能够被json解析的类型。
非常规参数是指由普通类型以外的类型组成的参数，例如UIImage等这些不能够被json解析的类型。然后这些类型组成的参数在文中就被定义为非常规参数。
总结一下就是：非常规参数是包含非常规类型的参数。非常规类型的定义就是不能被json解析的类型都叫非常规类型。
边界情况：
假设多层级参数中有存在任何一个内容是非常规参数，本文中这种参数就也被认为是非常规参数。
如果某个类型当前不能够被json解析，但通过某种转化方式能够转化成json，那么这种类型在场景上下文中，我们也称为普通类型。
然后我来解释一下为什么应该由本地组件间调用来支持远程应用调用：
在远程App调用时，远程App是不可能通过URL来提供非常规参数的，最多只能以json string的方式经过URLEncode之后再通过GET来提供复杂参数，然后再在本地组件中解析json，最终完成调用。在组件间调用时，通过performTarget:action:params:是能够提供非常规参数的，于是我们可以知道，远程App调用时的上下文环境以及功能是本地组件间调用时上下文环境以及功能的子集。
因此这个逻辑注定了必须由本地组件间调用来为远程App调用来提供服务，只有符合这个逻辑的设计思路才是正确的组件化方案的设计思路，其他跟这个不一致的思路一定就是错的。因为逻辑上子集为父集提供服务说不通，所以强行这么做的话，用一个成语来总结就叫做倒行逆施。
另外，远程App调用和本地组件间调用必须要拆分开，远程App调用只能走CTMediator提供的专用远程的方法，本地组件间调用只能走CTMediator提供的专用本地的方法，两者不能通过同一个接口来调用。
这里有两个原因：
远程App调用处理入参的过程比本地多了一个URL解析的过程，这是远程App调用特有的过程。这一点我前面说过，这里我就不细说了。
架构师没有充要条件条件可以认为远程App调用对于无响应请求的处理方式和本地组件间调用无响应请求的处理方式在未来产品的演进过程中是一致的
在远程App调用中，用户通过url进入app，当app无法为这个url提供服务时，常见的办法是展示一个所谓的404界面，告诉用户"当前没有相对应的内容，不过你可以在app里别的地方再逛逛"。这个场景多见于用户使用的App版本不一致。比如有一个URL只有1.1版本的app能完整响应，1.0版本的app虽然能被唤起，但是无法完成整个响应过程，那么1.0的app就要展示一个404了。
在组件间调用中，如果遇到了无法响应的请求，就要分两种场景考虑了。
场景1
如果这种无法响应的请求发生场景是在开发过程中，比如两个组件同时在开发，组件A调用组件B时，组件B还处于旧版本没有发布新版本，因此响应不了，那么这时候的处理方式可以相对随意，只要能体现B模块是旧版本就行了，最后在RC阶段统测时是一定能够发现的，只要App没发版，怎么处理都来得及。
场景2
如果这种无法响应的请求发生场景是在已发布的App中，有可能展示个404就结束了，那这就跟远程App调用时的404处理场景一样。但也有可能需要为此做一些额外的事情，有可能因为做了额外的事情，就不展示404了，展示别的页面了，这一切取决于产品经理。
那么这种场景是如何发生的呢？
我举一个例子：当用户在1.0版本时收藏了一个东西，然后用户升级App到1.1版本。1.0版本的收藏项目在本地持久层存入的数据有可能是会跟1.1版本收藏时存入的数据是不一致的。此时用户在1.1版本的app中对1.0版本收藏的东西做了一些操作，触发了本地组件间调用，这个本地间调用又与收藏项目本身的数据相关，那么这时这个调用就是有可能变成无响应调用，此时的处理方式就不见得跟以前一样展示个404页面就结束了，因为用户已经看到了收藏了的东西，结果你还告诉他找不到，用户立刻懵逼。。。这时候的处理方式就会用很多种，至于产品经理会选择哪种，你作为架构师是没有办法预测的。如果产品经理提的需求落实到架构上，对调用入口产生要求然而你的架构又没有拆分调用入口，对于你的选择就只有两个：要么打回产品需求，要么加个班去拆分调用入口。
当然，架构师可以选择打回产品经理的需求，最终挑选一个自己的架构能够承载的需求。但是，如果这种是因为你早期设计架构时挖的坑而打回的产品需求，你不觉得丢脸么？
鉴于远程app调用和本地组件间调用下的无响应请求处理方式不同，以及未来不可知的产品演进，拆分远程app调用入口和本地组件间调用入口是功在当代利在千秋的事情。
组件化方案中的去model设计
组件间调用时，是需要针对参数做去model化的。如果组件间调用不对参数做去model化的设计，就会导致业务形式上被组件化了，实质上依然没有被独立。
假设模块A和模块B之间采用model化的方案去调用，那么调用方法时传递的参数就会是一个对象。
如果对象不是一个面向接口的通用对象，那么mediator的参数处理就会非常复杂，因为要区分不同的对象类型。如果mediator不处理参数，直接将对象以范型的方式转交给模块B，那么模块B必然要包含对象类型的声明。假设对象声明放在模块A，那么B和A之间的组件化只是个形式主义。如果对象类型声明放在mediator，那么对于B而言，就不得不依赖mediator。但是，大家可以从上面的架构图中看到，对于响应请求的模块而言，依赖mediator并不是必要条件，因此这种依赖是完全不需要的，这种依赖的存在对于架构整体而言，是一种污染。
如果参数是一个面向接口的对象，那么mediator对于这种参数的处理其实就没必要了，更多的是直接转给响应方的模块。而且接口的定义就不可能放在发起方的模块中了，只能放在mediator中。响应方如果要完成响应，就也必须要依赖mediator，然而前面我已经说过，响应方对于mediator的依赖是不必要的，因此参数其实也并不适合以面向接口的对象的方式去传递。
因此，使用对象化的参数无论是否面向接口，带来的结果就是业务模块形式上是被组件化了，但实质上依然没有被独立。
在这种跨模块场景中，参数最好还是以去model化的方式去传递，在iOS的开发中，就是以字典的方式去传递。这样就能够做到只有调用方依赖mediator，而响应方不需要依赖mediator。然而在去model化的实践中，由于这种方式自由度太大，我们至少需要保证调用方生成的参数能够被响应方理解，然而在组件化场景中，限制去model化方案的自由度的手段，相比于网络层和持久层更加容易得多。
因为组件化天然具备了限制手段：参数不对就无法调用！无法调用时直接debug就能很快找到原因。所以接下来要解决的去model化方案的另一个问题就是：如何提高开发效率。
在去model的组件化方案中，影响效率的点有两个：调用方如何知道接收方需要哪些key的参数？调用方如何知道有哪些target可以被调用？其实后面的那个问题不管是不是去model的方案，都会遇到。为什么放在一起说，因为我接下来要说的解决方案可以把这两个问题一起解决。
解决方案就是使用category
mediator这个repo维护了若干个针对mediator的category，每一个对应一个target，每个category里的方法对应了这个target下所有可能的调用场景，这样调用者在包含mediator的时候，自动获得了所有可用的target-action，无论是调用还是参数传递，都非常方便。接下来我要解释一下为什么是category而不是其他：
category本身就是一种组合模式，根据不同的分类提供不同的方法，此时每一个组件就是一个分类，因此把每个组件可以支持的调用用category封装是很合理的。
在category的方法中可以做到参数的验证，在架构中对于保证参数安全是很有必要的。当参数不对时，category就提供了补救的入口。
category可以很轻松地做请求转发，如果不采用category，请求转发逻辑就非常难做了。
category统一了所有的组件间调用入口，因此无论是在调试还是源码阅读上，都为工程师提供了极大的方便。
由于category统一了所有的调用入口，使得在跨模块调用时，对于param的hardcode在整个App中的作用域仅存在于category中，在这种场景下的hardcode就已经变成和调用宏或者调用声明没有任何区别了，因此是可以接受的。
这里是业务方使用category调用时的场景，大家可以看到非常方便，不用去记URL也不用纠结到底应该传哪些参数。
if (indexPath.row == 0) {
UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail];
// 获得view controller之后，在这种场景下，到底push还是present，其实是要由使用者决定的，mediator只要给出view controller的实例就好了
[self presentViewController:viewController animated:YES completion:nil];
}
if (indexPath.row == 1) {
UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail];
[self.navigationController pushViewController:viewController animated:YES];
}
if (indexPath.row == 2) {
// 这种场景下，很明显是需要被present的，所以不必返回实例，mediator直接present了
[[CTMediator sharedInstance] CTMediator_presentImage:[UIImage imageNamed:@"image"]];
}
if (indexPath.row == 3) {
// 这种场景下，参数有问题，因此需要在流程中做好处理
[[CTMediator sharedInstance] CTMediator_presentImage:nil];
}
if (indexPath.row == 4) {
[[CTMediator sharedInstance] CTMediator_showAlertWithMessage:@"casa" cancelAction:nil confirmAction:^(NSDictionary *info) {
// 做你想做的事
NSLog(@"%@", info);
}];
}
基于其他考虑还要再做的一些额外措施
基于安全考虑
我们需要防止黑客通过URL的方式调用本属于native的组件，比如支付宝的个人财产页面。如果在调用层级上没有区分好，没有做好安全措施，黑客就有通过safari查看任何人的个人财产的可能。
安全措施其实有很多，大部分取决于App本身以及产品的要求。在架构层面要做的最基础的一点就是区分调用是来自于远程App还是本地组件，我在demo中的安全措施是采用给action添加native前缀去做的，凡是带有native前缀的就都只允许本地组件调用，如果在url阶段发现调用了前缀为native的方法，那就可以采取响应措施了。这也是将远程app调用入口和本地组件调用入口区分开来的重要原因之一。
当然，为了确保安全的做法有很多，但只要拆出远程调用和本地调用，各种做法就都有施展的空间了。
基于动态调度考虑
动态调度的意思就是，今天我可能这个跳转是要展示A页面，但是明天可能同样的跳转就要去展示B页面了。这个跳转有可能是来自于本地组件间跳转也有可能是来自于远程app。
做这个事情的切点在本文架构中，有很多个：
以url parse为切点
以实例化target时为切点
以category调度方法为切点
以target下的action为切点
如果以url parse为切点的话，那么这个动态调度就只能够对远程App跳转产生影响，失去了动态调度本地跳转的能力，因此是不适合的。
如果以实例化target时为切点的话，就需要在代码中针对所有target都做一次审查，看是否要被调度，这是没必要的。假设10个调用请求中，只有1个要被动态调度，那么就必须要审查10次，只有那1次审查通过了，才走动态调度，这是一种相对比较粗暴的方法。
如果以category调度方法为切点的话，那动态调度就只能影响到本地件组件的跳转，因为category是只有本地才用的，所以也不适合。
以target下的action为切点是最适合的，因为动态调度在一般场景下都是有范围的，大多数是活动页需要动态调度，今天这个活动明天那个活动，或者今天活动正在进行明天活动就结束了，所以产生动态调度的需求。我们在可能产生动态调度的action中审查当前action是否需要被动态调度，在常规调度中就没必要审查了，例如个人主页的跳转，商品详情的跳转等，这样效率就能比较高。
大家会发现，如果要做类似这种效率更高的动态调度，target-action层被抽象出来就是必不可少的，然而蘑菇街并没有抽象出target-action层，这也是其中的一个问题。
当然，如果你的产品要求所有页面都是存在动态调度需求的，那就还是以实例化target时为切点去调度了，这样能做到审查每一次调度请求，从而实现动态调度。
说完了调度切点，接下来要说的就是如何完成审查流程。完整的审查流程有几种，我每个都列举一下：
App启动时下载调度列表，或者定期下载调度列表。然后审查时检查当前action是否存在要被动态调度跳转的action，如果存在，则跳转到另一个action
每一次到达新的action时，以action为参数调用API获知是否需要被跳转，如果需要被跳转，则API告知要跳转的action，然后再跳转到API指定的action
这两种做法其实都可以，如果产品对即时性的要求比较高，那么采用第二种方案，如果产品对即时性要求不那么高，第一种方案就可以了。由于本文的方案是没有URL注册列表的，因此服务器只要给出原始target-action和对应跳转的target-action就可以了，整个流程不是只有注册URL列表才能达成的，而且这种方案比注册URL列表要更易于维护一些。
另外，说采用url rewrite的手段来进行动态调度，也不是不可以。但是这里我需要辨析的是，URL的必要性仅仅体现在远程App调度中，是没必要蔓延到本地组件间调用的。这样，当我们做远程App的URL路由时（目前的demo没有提供URL路由功能，但是提供了URL路由操作的接入点，可以根据业务需求插入这个功能），要关心的事情就能少很多，可以比较干净。在这种场景下，单纯以URL rewrite的方式其实就与上文提到的以url parse为切点没有区别了。
iOS应用架构谈 组件化方案
1007
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
