在App Deeplink导航系统中
一开始的需求是这样的。我们希望可以通过某种方式，让用户可以在打开app的时候，直接，空降，跳到某个特定页面上，这特定页面可能是某篇文章，潜水日志，或某张照片，某则留言，然后还要照指定路径上一层退回上一页。所以Deeplink就被提出来，希望可以实现。
参考维基百科。简单说就是，利用一套预先定义好的URI路径，使用户可以恢复重定向到应用内部的特定页面/特定功能，甚至可以重新打开。
用例
- 投放到应用内的特定文章，特定商品等等指定内容
- 做新功能的介绍或展示
- 根据通知逐步到特定位置
你可以做…
- 在每一个需要重定向的页面处理。在某个地方解析URL转为参数，但在各别页面上处理下一级的替换。
最好的优点应该是直观，当每页的下一级都是有限范围的情况下，或许也很快可以实作完成。但是如果若要重新设置规格会随整个app功能增加，持续不断长大的时候，就有机会让复杂度与修改幅度倍数增长。
而若在每一页处理下一级的话，必须先把本页生出来，表示没处理好的时候用户会看到一页一页的转场跳进去。那么有点不是我想要的样子了。
当我要做的时候
当时，我们除了需要开发深层链接系统之外，原本有一套实作了一半的通知系统，共有8x个不同的通知类型。各有不同的通知消息。整并过后大约可减为2x种替换组合。既然deeplink与notification都需要进行类似的页面重定向，所以就决定，先将notification转换为deeplink，再用转出来的deeplink进行替换，即可使用一套代码处理所有替代行为。
- 实作DeeplinkHandler，将收到的link解析为路径与参数。
- 实作ViewControllerFactory，以参数初始化各ViewController而不使用data。
- 根据解析得到的路径将各个ViewController实体化，组出ViewStack。
- 在进行引导时，使用UINavigationController setViewControllers将ViewStack推上画面
- 回头将通知与有效载荷按照规格转换为deeplink格式
在主要行为完成之后，有几个地方可能需要额外处理：
- 合法的深层链接：当然我们不会希望随便收到什么链接进来通通都拿去去处理，结果不小心踩到坑就崩溃了。我们可以把路径跟参数key定为枚举，在解析时以字符串型别转换做简单的判别。也可以使用特定的schema与主机名作检查。
- 要求登录：也许有人某个特定页面需要用户登录才能显示内容。我们可以把对应的几个路径存入数组，在组成ViewStack之前，预先检查是否需要登录。
- 路径之间有相依性：如某个路径代表前一页的特定功能而非独立存在。则可设计简单的状态机，在解析时预做处理
在统整出这一套系统后，往后需要再加入新的页面，也非常容易。开发者只需要注意， 不要将整包资料从前一级画面带入。减少了画面间的相依性，各画面可独立被实体化，就很容易可以加入这个系统。
- 不需要为了加入deeplink支持，而修改一些很久没有更动的画面。
- 由于路径之间的关联被解构，甚至可以支持组出超越spec规范，10个重定向页面以上的deeplink，都可以正确克服无阻碍。
终极的嫌疑麻烦，是不怕麻烦。
如果你有个记性还不错的老板，常常喜欢说，
我们不是之前有做过一个什么系统，那现在可不可以拿来套用，这样做起来应该很快吧。
建议您在做新功能的时候，最好可以先考虑一下这个功能有没有可能在未来继续被放大利用。在时间允许的范围内，进行调整向未来兼容的框架或系统，这样才有机会越写越轻松。