Why？
- Route(路由)众所周知是网络中的名次，具体来说是指IP层协议的内容，路由协议主要有OSPF、RIPS、BGP，那么Android里的Route指的是什么呢？
- Android里的Route也如同IP层的Route一样，作用类似寻址，但是寻的“址”并不是IP地址，而是页面，试想以下场景：
- 实际开发中某个点击事件要求跳转某个页面，但是在开发过程中并不能确定是要跳转到Activity A or B or C, 如果PM突然改变了跳转逻辑，按照最传统的方法我们只能修改代码发布新的apk，或者先进一点吧，采用热修复，但是无论怎么样其实都只是修改一个跳转的目标Activity罢了，都要让用户机器上的重新编译相关代码，而其实变化的只是半行代码。这点繁琐&简单工作都不应该再交付给程序员，但是PM又不写代码，那应该怎么样才能完美解决这个问题呢？
- Route则克服了相应的缺点：
- Route在编码阶段，建立对应的映射表／路由表，根据Server(后台)提供的一个标识符(Uri)来选择已经编写好的页面。这个页面可以是我们最熟悉的Activity，也可以是承载在WebView上的H5(当然，这两句话是废话)。
- 对比传统方式：优势不言而喻，无需重新提审，无需让用户Update
- 对比热修复：热修复也无需用户显示Update，对用户是隐式的，也是利用Server进行动态更新，但是热修复到手机上还是要进行代码更新，即修改对应的dex文件，而Route不需要更改dex，一方面热修复的方式做了不必要的操作，是一种效率上的低下；另一方面，热修复到底还是要编写新代码的，而Route只要修改Server发来的标识符(Uri)即可，这样的操作是可以不需要程序员的：
- 只要响应的前端开发者为PM写好对应的UI，让他们选择对应的标识符，就可以让非技术人员修改页面跳转了
How？
说起来很玄幻，但是其实实现起来并不难(但是第一个提出这种思想的人依旧很牛)
-
Route是通过Uri来确定目的跳转页面，Uri的格式是
scheme: scheme-part
scheme可以是自己定义的，比如说activity://testModule/testActivity，然后Route的框架通过解析这个Uri创建一个Intent(或者其他启动信息类，比如用来使用H5页面)，启动对应的页面，即有一个对应的路由表用来映射Uri和对应的页面跳转
一个优秀的Route框架应该是可以自动收集每个页面，建立Uri和UI的映射关系，生成路由表相应表项(可以通过Annotations来帮助框架收集)
Conclusion
- 要实现一个简单的Router其实并不难，重要的是思想；但如果你想要实现一个优雅的、接口灵活的Router，那工作量还是挺大的：比如说可能要借助注解，要利用Gradle插件自动匹配Uri和UI以生成路由表
Library
- AndRouter
- ...
