完备路由系统

现在很多应用都在内部跳转中使用了路由系统，这种从web搬过来的东西。但是功能却并不完善，就像比较有名的JLRouter和MGJRouter。这里就来聊聊更加完善的系统的几个部分。

前言

现在很多的应用都在一个非常大的量级了，已经不可能由几个人的小团队来开发了，那么模块化就非常必要了。相比很多人说的组件化（Component），我觉得模块化（Module）更为贴切一点。

说到模块化，那么模块间的通信就非常重要了，如果仅仅是通过api来做通信，就不够灵活，而且可能会增加了集成成本。一旦涉及到接口变更就需要修改多个模块。这样路由系统便是页面间跳转的一个非常重要模块，可以说他承载了整个最核心的部分。一个好的，完善的路由系统可以让一个系统更加稳定和开发简单。而一个功能欠缺的路由系统则有可能将整个应用带入一个泥潭。

目前比较有名的几个实现，都非常简单，而且非常好用。但这是对一个整体的应用来说的，如果是一个多团队开发的应用，就有部分缺陷了。所以为了应对这种缺陷，蘑菇街和京东都开发了一个管理平台，来专门管理这些路由系统，解决这种缺陷。

这些路由实现在目前已经基本满足需求了，但是在未来可能会进行的模块拆分，则需要功能更加强大的路由系统。所以我提出一种更加完备的路由系统。可能这里有过度设计的成分，但是作为未来的扩展性，我觉得还是有必要的。

完备路由

既然我们是从web那里抄过来的想法，那么为什么不抄的完整一些呢？

回溯 history

目前的几个路由系统都没有提供这个功能，而这个功能我觉的是非常非常重要的一个功能。当我们需要判断上个页面是什么页面的时候，只能通过判断controller队列中的类型！这完全违背了黑箱这种原则。

同时我们可能需要回退多个页面或者回退到某个页面的时候，没有历史记录的支持，在合作开发的时候绝对是个灾难。

history给我们的功能好处也是非常多的。除了上述几个场景中特别需要以外，对我们的debug以及分析也是非常有帮助的。甚至我们可以记录和导出history来查看用户的操作流程，虽然不能代表所有的动作，但也可以展示用户的一系列行为，或者在crash分析中自动带上该信息。

自定义进入退出

我们的每个页面都不是固定的push的，也可能是present的，所以相应的返回也是不一样的，然而目前几个路由系统都只有进入的方式，并没有退出的方式。那么只能交给人来处理这种事情，当某个模块成为黑箱的时候，外部又怎么去判断呢？

所以进入(push)和回退(pop)操作都需要有对应的行为，这就承接了上一个history的必要性了。这样我们同样是进入(push)和回退(pop)，当行为是present时，就对应为present和dismiss。

甚至在内嵌的网页中也可以接入native的路由系统，那么这样的push和pop就对应了网页的跳转和返回了。同时这样也屏蔽了模块内部的具体行为，模块修改展示方式也不会影响外部的处理逻辑。更好的形成一个黑盒模块。

子路由

这个在web中是不存在的，但是在native的app中我觉得有必要。每个模块，或者内嵌的网页都应该是个子路由系统。

为什么需要子路由系统呢？这里举一个例子：

Root --[push]-> VC
                |
            [present]
                \
                 --> VC2 --[push]-> VC3 -->...

当我们需要去完成一个系列的完整动作的时候，往往会present出一个新的navigation来处理这一系列动作，而这些行为在任意一个节点都可能会返回，同时又可能在任意的一个地方present出来。那么如果要满足这种情景又需要人为的去处理很多逻辑，这就埋下了隐患。

如果我们把present出来的这一系列行为定义为子路由，那么如果需要返回时，只需要退出子路由中所有的history就可以了。

黑盒路由

如果项目变大以后，可能就会存在上百个路由，那么这些路由中实际有效的（其他模块可用，或者公开的）路由又有多少呢？我觉得应该会很少吧，因为外部进入一个其他模块的入口基本是固定的，所以我们为什么需要暴露这么多不必要的路由给外部呢。蘑菇街和京东为了管理这些路由干脆搞了一个管理系统，来防止路由冲突。那么为什么我们不让一个模块内的路由成为一个黑箱呢，只暴露外部需要的路由，而其他路由都经过保护不能随意访问。这样也防止外部访问不该访问的功能。

这个功能是承接子路由的实现，我们保持每个子路由内部的黑盒，可以减少我们的错误。

保持子路由的黑盒性的一个简单做法就是base url。依照restful来设计路由，不同子路由系统给与一个base url，比如登录模块的路由可以增加base url /auth。那么内部和外部的行为可以概括为：

// 外部
push("/auth")
push("/auth/password")
// 内部
push("~")
push("~/phone")
push("~/verify")
push("~/password")
// 退出整个模块
pop("~")

重定向

有些页面在某些条件下是不能进入的，这时候需要重定向去特定模块来完成这个条件，完成后再次进入该模块。所以我们需要重定向的功能，否则就会增加很多依赖项，导致不能真正的模块分离。

比如某个功能需要登录模块，在我们没有集成登录模块的时候就难以完成功能，而集成了登录模块又会导致模块化仅仅只是个表面上的分离了，可能在真正开发的时候还是把一大堆其他模块给搞进工程，那么这样的模块化有什么意义？如果拥有重定向就可以伪造一个重定向，让他自动放回需要的结果就可以了。这样就可以排除其他模块的干扰了和依赖了。

路径依赖

这个其实时承接上个需求的，可以相当于一个语法糖。

按照上个场景，我们如何去注册一个需要重定向的路由呢。那么我们可以引入一个路由依赖的功能，可以标记每个路由的依赖选项。比如登录的@requireLogin。

这算是一个扩展的功能吧。

中间件

目前主流的几个路由还有一个非常欠缺的功能就是中间件。我们无法去从路由系统内部知道我们经过了哪些操作，是否需要过滤某些操作。

这个话题其实也关系着黑盒路由和重定向的问题。依照服务端的中间件设计方式，我们应该需要为路由系统留出控制以及debug的入口。

拥有了中间件我们可以做什么？

• debug，打印所有的入口和出口，完善我们的日志
• 分模块开发的时候，可以mock其他有依赖的模块
• 监视，是否调用了非法的接口或者使用了非法的参数

个人觉得中间件是一个系统所必须的功能，可以提供外部实现更多的功能和更灵活的控制。

热插件

这是一个额外的话题。由于我们的路由注册基本上是在+load方法里面做的，所以当我们的路由越来越多的时候，启动性能也会越来越差，那么提供热插拔的功能是最好的。同时热插拔功能也相对应的提高了路由的黑盒性。

做成热插件的形式还有一些好处。比如abtest的时候，可以加载不同的插件来进入不同的页面。又或者在某个页面出了线上问题，需要降级为web来实现，也可以通过替换插件来替换不同的页面。

这是一个锦上添花的功能，所以我把他列到了最后。

总结

以上说的几个点可能给我们的编码增加一些复杂度，而且还需要去理解这些概念才能很好的运用。但这里的规划完全是以模块化为前提的，并且独立为一个系统，不去依赖UIKit。所以从长远来看这样的实现是绝对有好处的，如果有时间可以把这个想法实现出来。