背景介绍
当前，在后台模块管理中，服务化，微服务化是大热门，是否可以借鉴到客户端的模块管理？
页面之间跳转，之前没想这么细。不过iOS8之后，将framework引入工程管理，接口怎么定义？以前的dll的接口定义当然是五花八门，接下去的framework估计也会重蹈覆辙。能否参考后台服务化的思想，将URL引入，让各framework之间的关系更简单清晰呢？
Three20曾经很热，现在已经退潮，其中的基于URL的Route思想是有借鉴意义的
URL在互联网被广泛接受，还有W3C标准。现在后台模块的服务化改造，其中的信息传递也是基于URL格式的。在客户端是否可以借鉴？
routable-ios就是一个这样的第三方库。 Routable, an in-app URL router for iOS and Android这篇文章就是介绍这种思想的。
HHRouter这个star也上千了。HHRouter 开源后日谈这篇文章写得也不错。
URL本质是字符串，并且有公认的标准，可以让iOS和Android共同遵守。再加上JSON，就可以在网络和本地广泛互联互通了。这是跨平台的方向，比价有吸引力。
个人想法
第一个场景是插件化，这个层面更多的是公司间的合作了。一个例子就是支付。主程序和插件之间，非常适合用URL这种模式来解耦。以前用过的银联支付插件，用代理模式返回支付结果，还要传一个ViewController作为参数，很不好用。用URL，参数放在query中，拉起支付插件，这个过程没有什么大的问题。插件处理完后，怎样把结果反馈给主程序？这个问题需要选合适的方法解决。URL中放Block，感觉不是非常优雅，目前还没看到令人信服的方案。用代理，还是用NSNotification？隔了个framework，估计也是个麻烦事。这方面需要进一步的思考。
第二个场景是平台化。主平台和各业务模块之间，也是非常适合用URL来拉起各个业务模块的。业务部门之间，基本上隔离的需求大于信息交换的需求。这种场景也存在信息回传的问题，不过比插件化的场景频率要低一点。像支付宝，微信企业号之类的。主工程就是一个容器，为各业务提供一个入口，用URL，能跳到相应的应用就可以了，当然要能回来。而两个业务之间基本上只有隔离，要联系的话，也是放在后台，客户端由各自拉取接口更新界面就可以了。平台化要彻底，最好的方式是将主工程做成一个容器，甚至首页的内容都能通过后台动态配置。相关技术比如ReactNative（动态特性，并且性能比H5要好），首页要保持简洁，减少性能的坑。业务模块之间往隔离方向走，各自为政，互不干涉。平台尽量不要做具体的事，只做管理者和中转站。业务之间有沟通的需求，平台也提供一个专门的Bridge组件提供沟通机制，将影响限定在有限的范围之内。业务最好是独立APP的形式，业务之间的沟通，平台最好不要参与，让各业务之间自己解决。这种场景，也是适合用URL的模式来通信的。
第三个场景是组件化。比如一个公司内部的产品，为了让业务部门更专注于各自业务，一些公共功能，做成公共组件，供各业务方调用。比如用户行为统计，日志，网络，缓存，加解密，手机信息等等。这种场景就是借用后台服务化的场景。最基础组件的可以叫微服务，只提供服务被调用，不调用其他模块（第三方库可以调用，比如AFNetworking）。一般这种组件，业务部门还不能直接使用。第二级的组件叫服务，能提供具体的服务给业务调用，同时自身也调用其他服务或者微服务实现具体功能。这些服务之间的调用是否可以采用URL的模式？现实情况是没有，比如著名的AFNetworking，FMDB等等，对外的接口还都是具体的API函数。不过，是否可以往URL与服务化的方向发展呢？比如网络库，以API的方式调用AFNetworking实现自己的网络通讯功能，同时以URL的方式对外提供服务，作为微服务组件。对于这种场景，iOS8、framework，提供了实现的方便条件，个人还是倾向framework之间用URL来通信。标准成熟，耦合低，字符串简单好理解。当然，目前还没看到具体的实现方案，也有很多未知的困难。
最后一种场景就是页面之间的跳转了，这个已经有第三方库这么做了。对于这个级别引入URL，暂时还没有完全支持。有些页面之间耦合紧密的，比如，跳出一个页面修改下名字，保存后在上一个页面看到修改的结果。这里天然的需求是耦合而不是隔离。组件一旦framework化，天然已经有一堵墙，隔离的需求大于耦合。同时组件是为了复用，而页面往往是为了展示具体场景，是具体的使用者，并没有多少复用的需求。所以这两者有本质的区别。暂时，这种场景还没有URL化的强烈倾向。
参考文章
iOS页面跳转之Router Swift实现同事的文章，写得还不错，还有Demo例子Router
