route，路由。这个词在前端中很常见。不过我今天要说的是移动端的route。
而是app中的路由，也就是可以成为urlRoute。这个urlRoute主要用于app内页面间的跳转。每个页面的跳转都通过一个特定的url的形式来跳转。
其实说了这么多主要是为了介绍一个框架。好吧，先把地址放出来吧（ https://github.com/campusappcn/iOSUrlRoute ），以下的urlRoute的内容基本上是围绕着这个框架在讲的。如果满意请大家小手都下star下哈。
那么在app内运用urlRoute的形式来跳转有什么好处呢？
我觉得最大的好处就是页面间的解耦合。原先我们从A页面跳转到B页面，可以是pushVC或者presentVC，甚至是addSubView。但是不管怎么做你都需要在A页面相关的地方（有个能是在A的VC中，也有可能是在A的ViewModel中）导入B，初始化B之类的一系列操作。我相信这一些列的步骤，大家肯定很熟悉。也许有人可能会差异，难道不是这样做么？或者说这样做有什么不好么？……那么我先来说几种情况吧。1）如果B页面还没有完成，2）B页面有可能会被替换成其他页面。这里就列举这两种情况（好吧，其实一时半会儿我也想不到更多的=，=）如果这两种情况的时候，用上述的步骤是不是会觉得很头痛，因为B页面压根儿就还没完成，也许是分工给了你的同事，也许是你自己还没完成。那么在A页面中跳转的部分，就不得不缓缓，等到B页面完成或者说创建好了之后才能在来完成A页面跳转的部分内容。对于B有可能会被替换，那么久更头痛了。如果你是分开在各个页面中写的跳转代码的话，那么你就要全局搜索，来改动了（这可是一项不小的体力活）。
那么如果这时候用urlRoute呢，因为urlRoute是通过一个特殊的url来判断跳转，也就是说其实页面A并不是知道实质上跳转到的是哪个页面，他只是告诉了控制urlRoute的中心，我要跳转到B页面，那么具体怎么如何跳转，甚至跳转到哪个页面都是有urlRoute的中心在执行的。所以说A页面和B页面完全没有了关联。
第二个优点可以很动态的控制跳转的路径。其实这个也是我最初接触到app内路由的原因。当时我接触的场景是这样的。app内，由于某个页面出现了问题，急需要用其他页面来代替（网页）,或者说某个特定的页面因为需要做活动，急需替换成一个其他的活动网页。这时候提交更新肯定是来不及了。那么在不更新代码的情况下要如何做呢。当然热更新可以做，直接重写跳转代码所在的那个方法。虽然可以做，但是不优雅（=，=）,不优雅的原因在于:用热更新本身的执行效率会有影响，再者有点杀鸡用牛刀的感觉。当然这时候urlRoute就华丽的出场了，只要把跳转到那么特定页面的路由所配置的跳转路径动态替换下就可以了。当然这只是一个特定的场景，其实在很多时候动态的配置路由来控制跳转路径还是很有用的。再举一个例子，比如说做ABTest,关于打开app的时候先呈现什么内容给用户，这种场景用路由动态得控制也是非常赞的。
听了上面的介绍，是不是突然间觉得用urlRoute来控制页面间的跳转是件多么美好的事情。
那么下面将继续给你呈现更加美好的东东。
有不少同学可能会说，路由跳转固然是好，但是我如何传值到下个页面呢，或者说我从页面pop返回的时候，我在特定情况下需要刷新当前页面，这些光靠这个urlRoute的框架好像完成不了吧。不不不~这些在urlRoute这个框架中都考虑到。对于传参的情况是通过key&value的形式传递过去，那么也就是说如果从A到B页面，需要传参，就必须知道B页面所需要的参数的名称和类型。通过key&value的形式交给urlRoute中心去处理，在B页面通过key来获得value。而对于需要回调刷新之类的问题，是通过注册block来解决的。
当然这个框架除了以上这些外，还可以处理在app外打开app传值进入跳转到特定页面的场景。
urlRoute的宗旨是，把app内所有有关于页面间的跳转全部控制起来。这是一个伟大的事业~