看了一篇关于移动端路由的文章一步步构建iOS路由, 感觉写的多, 写的也很好, 所以我决定去看看源码, 在用我自己的语言来重新总结一下.

其实说到路由, 不由得就想起了组件化, 但是这两者是有本质化区别的, 路由只是实现组件化甚至插件化的一种手段而已, 作者之前也写过一篇关于组件化的文章, 就不多说了.

路由的作用在我看来就是把 任务/行为 都封装成一个一个请求,或者我们称之为任务. 然后由路由器统一管理和处理, 从而就可以很好地监听任务的执行.

其实更极端点的说法就是路由器就是一个任务调度中心, 我们可以获取整个任务的前因和后果, 其实这里是一个打印 log 的好地方, 集中处理记录所有的行为. 当然我们如果通过中间件这种方式来操作.

大家可以先看看原作者的博文, 再来看我这个狗尾续貂之作.

简单说一下路由器的工作流吧

1. 首先我们获取到一个 url, 可以是 内部调用 也可以是外部调用, https://www.abc.com/123, action://doSomething 这其中包括两个部分 scheme 和 path, 我们在适配的时候会根据这两部分得到对应的 handler
2. 我们向路由器根据 url 注册 handler 和 blockHandler, 这里的 url 支持正则和如有参数, 以代码中的例子

   [self.router registerHandler:[[WLRSignHandler alloc]init] forRoute:@"/signin/:phone([0-9]+)"];
   

3. 我们还可以设置一些满足 WLRRouteMiddleware 协议的中间件, 来处理和终止我们的每次 request
4. 之前都是一些配置工作,现在我们开始正式的工作流
5. WLRRouter 去 handler 对应的 url, 如果 被适配器 WLRRouteMatcher适配到, 则生成对应的 WLRRouteRequest, 否则结束任务.
6. 用所有的中间件依次处理 WLRRouteRequest, 发生错误或者任务被中间件中断则结束
7. 找到对应的 handler 来执行 WLRRouteRequest

更细节的东西我建议大家去看源码,或者 WLRRoute 作者的博客.

一些思考和改善

首先说现在的功能其实已经可以满足大多数的使用场景, 但是如果我们把路由看做一个功能强大的任务调度中心的话, 那么就引出了下面的我的一系列思考和问题.
具体的解决方案我就不说了, 我希望大家自己想一下, 我提出的这些问题是否是有必要的, 如果有必要, 应该如何设计代码?

中间件的优化?

目前的中间件能做的事情就是在任务开始之前得到 request , 然后进行操作, 可以返回结果结束任务, 或者直接抛出错误.
但是, 我们的任务不仅仅是推出一个新的界面的话, 如果也包括执行一段逻辑的话, 那么是否中间件也要对 request 的 reponse 进行处理呢? 比如判断逻辑执行的效率, 计算执行时间等等.
在我的想法中, 中间件是这么执行的, 感觉可以做很多事情的样子

- Middleware1
   - Middleware2
       - handler
    -Middleware2
- Middleware1

任务异步执行?

其实现在作者是有任务执行的, 是使用 block 的时候, 但是在我看来其实都不应该分 block 和 handler, 应该都封装成 handler, 换句话暴露在外面的 block 接口只是一个语法糖, 里面改成 同时支持同步和异步执行的 handler

添加上下文 Context?

移动端路由一个很大的不同就是传递参数比较纠结, 如果只通过 url, 我们只能传递一些字符串参数, 不能传递对象. 尤其是在 app 内唤起路由的时候, 往往传递对象参数是一个很重要的需求.
庆幸的是,我们的请求被封装成了 WLRRouteRequest, 那么是否可以让这个对象持有这些参数, 在 handler 中直接读取呢?
那么继续想下去, 我们其实有可能在处理任务的时候需要很多参数,有些参数可能是一些环境参数,把所有东西都放到 request 中? 我在想, 是否可以给每个 request 创建 一个 context, 然后把这些参数都赋值给 上下文呢

所有请求都使用统一的中间件?

目前, 我们的所有中间件都是全局的, 但是可能我你需要所有请求都执行对应的中间件呢?
我其实期望的是可以针对对应的适配器添加对应的中间件, 比如我有一些任务是对数据库的操作, 那么我系网针对这些任务添加记录时间的中间件.

组适配器?

如果我们有几个任务的 url 的前缀相同, 我们是否可以先通过前缀得到一个
WLRGroupRouteMatcher, 然后再一一添加子适配器的 handler, 我认为这样的话可能逻辑更清晰, 而且可以做很多封装, 把复杂的需要重复添加事情放到这里面.

适配器的效率问题?

现在库中的适配器是每次遍历, 那么当适配器很多的时候, 肯定会发生效率问题, 那么我们是否可以根据 scheme, 前缀, 某一个通用参数甚至是传进来一个参数来提高我们适配的效率呢

异步的优化?

如果我们添加了很多异步 handler, 有两个问题必然会出现
1 异步的调度, 我们需要使用 NSOperation 或者 GCD
2 在一个异步路由任务中创建了一个新的异步路由任务

结语

好吧,好吧,我都知道,我们在移动端可能根本就不需要一个这么复杂的路由器.
这个听着更像是一个后端的网络框架的雏形.
但是我想说的是, 闲着也是闲着, 随便瞎想想呗.