如果不是从KVRouter传送过来的童鞋请戳此跳转。
1 使用场景
- 扫一扫
我们都知道现在App很多都有扫一扫的功能，如果没有一套合适的方案，在每次扫一扫需要增加跳转页面的时候都需要更新App版本（你需要解析一个特定的链接来决定跳转哪个页面）。 - 网页点击跳转原生页面
网页跳转原生页面的需求也是很普遍的，而且网页与App相比最大的优点就是可以随时更新，所以网页上的功能是随时可变，如果App不随之做一些改变的话，那么不管对于你还是对于web前端小伙伴来说都是一场灾难。 - 任何需要跳转页面的场景（包括App启动广告页跳转）
- 其他适用场景
1.1 案件重现
- 角色介绍
小元
某创业公司iOS开发程序猿，一个月31天有一天不加班，一直被坑爹CEO许诺股票却连工资都发不起，更别谈什么年终奖。
大黄
与小元同在一家公司，职位是产品经理......（其他脑补）
-
扫一扫功能没有任何方案下的日常
大黄：我想在扫一扫里面增加一个可以跳转个人中心的功能。
小元：好的。
咔咔咔敲完代码，没几分钟。
小元：好了，现在需要提交一个新版本。
大黄：什么！就这么点东西就要更新个版本，用户会不会觉得有点烦，这样吧，你把我们下版本的功能今晚加个班做完，一起更上去。
小元脸上笑嘻嘻，心里MMP。 -
启用了动态定向方案的日常
大黄：我想在扫一扫里面增加一个可以跳转文章详情页的功能。
小元：好的。
咔咔咔敲完代码，没几分钟。
小元：好了，现在你打开App看一下。
大黄：嗯，是好了，牛*啊小元，这么高效，趁热今晚加个班，这个月的绩效就靠你了。
小元没说话，打开Google，搜索->狗肉火锅怎么做？在线等，挺急的。
花开两朵，各表一枝。
2 方案介绍
该方案使用一个json文件来实现跳转路径解析的数据更新，每次App启动都会去拉取服务器一个版本号，如果与本地版本号不一致，那么拉取服务器的最新文件来更新本地的跳转路径解析数据。
- 优点
能够实现不更新版本而跳转App的任一界面 - 缺点
不能跳转App里面没有的界面（功能还没上线，跳什么跳）
2.1 实现原理
通过设计一个中间人来处理来自于扫一扫或者其他需要用到该方案的URL请求，然后通过与本地的跳转路径解析数据进行匹配，获取到本地页面的跳转URL，获取到，那么跳转，获取不到，那么跳转该原始URL。（之前看过天猫架构师的一篇文章，天猫也是有这种动态定向的方案的，只不过他们是通过URL降级处理来解决当前版本无法识别的界面，我的方案是直接识别原始URL，通过原始URL与本地页面URL进行匹配，匹配不到直接跳转网页，不需要做降级处理）
看流程图最清楚。
页面动态定向方案.png
由于使用了KVRouter处理原生页面的跳转，所以该中间人并不需要做过多的事情，仅需要将原始URL转成App能识别的原生页面URL以及解析好参数进行传递即可。
2.2 方案要点
先来看一下我是如何保存路径匹配的数据的。
{
"key" : "www.baidu.com/*/lesson", //原始URL
"type" : 1, //该数据的处理类型，有的是跳页面，有的是直接跳回首页
"localpath" : "course/lesson/detail", //对应的原生页面URL，可以通过KVRouter进行跳转
"param" : { //参数列表
"id" : "courseid"
},
"needlogin" : 0 //是否需要登录
}
- 处理原始URL链接里面携带的参数名与原生页面参数名的不同
请看上面的参数列表，里面是一个字典，里面保存了该原始URL携带的参数名与我原生页面的参数名的映射关系，我在解析到原始URL的参数后，会根据这个参数列表，改变一下参数名，给跳转页面传递。
- 处理好不同请求来源的逻辑
目前项目有扫一扫和网页跳转使用到了该方案，扫一扫进来的请求，一般都是需要跳转一个新页面的，即使获取不到本地URL，跳转原始URL也是push一个新的网页，但是在网页跳转里面，如果是原生页面，那么直接推出一个新页面，如果是网页，那么需要在原网页进行跳转，所以这里需要做好不同来源请求的处理。
- 解决web前端URL正式服与测试服的差异
在上面的数据格式中，可以看到我使用到了通配符*，原因是我们公司web项目区分正式服和测试服的标识就是在链接的中间字符不同，这样做，可以避免在频繁切换正式服和测试服需要同时维护两套数据。
2.3 写在最后
其实这篇文章的要点全在那张流程图上，只要看懂了，其他都可以根据你项目的具体需求进行调整。
另外，由于使用了KVRouter，所以在中间人进行页面跳转的时候不需要做过多处理，整个项目的架构可以保持一致性。
