1.流程

重要的类

注解

@Route

核心注解：标记一个路由的具体跳转

path: 该实体类对应的跳转路径

group: 路由分组

name: 该路由的名字

extras: 可能是用来做ab test

priority: 优先级；用途暂时不明；看上去是相同路由进行裁决

@Autowired

自动注入；用于从其他页面跳转到当前页面的时候对携带的参数进行自动注入

缺陷：只能和Activity和Fragment一起使用，且要求相关字段必须公开

@Interceptor

拦截器： ARouter的拦截器的作用有待细化

目前发现的缺陷：

不支持多个路由，路由路径是静态的，不支持通配符
服务不支持单例（是否应该通过外部支持?)

工作流程

1. 编写相关代码

对于Activity和Fragment，需要使用路由跳转，则使用@Route路由注解标记相关页面
对于Service,需要实现IProvider接口，并使用@Route标记该实现
对于拦截器，需要实现IInterceptor接口，并使用Interceptor注解进行标记

2. 注解处理器在编译的时候进行处理

涉及到的核心注解处理器
1. RouteProcessor
  
  对@Route注解所注解的类进行处理,主要包括Activity,Fragment,Service,以及Provider;使用代码生成工具JavaPoet将这些路由信息根据组写入到ARouter$$Group$$${group_name}.java
  
  实现Provider的服务还会单独写入到ARouter$$Group$$${module_name}.java
2. AutowiredProcessor
  
  针对@Autowired注解，新产生一个处理的类的代码
  
  这个类的包名和相关Activity和Fragment的包名一致，
  
  类名则为${activity_name}$$ARouter$$Autowired.java
  
  每个单独的注入都会生成一个新的文件
3. InterceptorProcessor
  
  对@Interceptor注解进行处理；生成ARouter$$Interceptor$$${module_name}.java
  
  处理流程和上面的流程类似
初始化

ARouter.init(application)

目前我理解的普通的流程 -> (在没有插件参与的情况下，需要扫描dex包;找出所有com.alibaba.android.arouter.routes下的类；根据类名是否开始为Root,或者其他类型的...) 将这些相关的路由加入到内存中去
跳转
1. 跳转有两种跳转方式
  1. 路径跳转 build(path).navigate(...)
    
    这种跳转方式可以跳转Activity,Fragment不能完全自己跳转，但能获取到目标Fragment,Service暂时不能跳转
    
    这种跳转方式也能获取具体服务的实现；由于设计成通用跳转的关系；因此返回值只能是Object,（跳转Activity不可能直接在调用方法结束之后就返回有效的数据) 因此获取服务的实现需要自己强转
  2. navigate(Class<T> type)
    
    这种跳转方式专门为跳转服务而设计；有具体的类型；但此种方式只能获取一个实现
2. 跳转的过程
  1. 构造PostCard对象
  2. 查找路由表，如果对应的路由表没有初始化；那么就初始化
  3. 对于跳转Activity,如果PostCard不是绿色通行的，需要获取拦截器，使用拦截器进行一番处理，拦截器是链式调用的，有最长的调用期限,其中还可能进行的工作有地址的替换，路由查找失败的降级处理
  4. 最终将PostCard中的数据拼装起来构造Intent,跳转到相关的Activity,如果是服务则直接provide
3. 个人总结的一些问题
  1. 不同模块定义相同的路由，会存在覆盖的问题；改进方法：不要用路由的path的第一部分为分组依据，以模块名称为分组依据
  2. 一个服务的实现只能有一个
  3. 一个具体的最终模块只支持一个跳转路径
  4. 路由的优先级似乎没有开放给外部使用
  5. 在不使用插件的情况下，如果一个应用比较庞大，第一次初始化需要耗费较多时间
  6. ARouter的路由不可继承
  7. 插件的工作：将注册路由的代码在编译时候生成；减少第一次初始化的时间