ARouter 源码浅析第二篇

请参考ARouter源码浅析

服务管理

依赖注入

经过依赖注入的方式咱们能够像上一篇文章中获取跳转参数同样获取服务，具体的实现咱们仍是经过源码来看一下吧。 当咱们队一个自定义的service标注上@Autowired注解的时候，从新编译之后，APT会为咱们自动生成以下代码:

至于inject方法在哪被调用上一篇文章已经分析过了，这里能够看到服务的注入跟参数的注入仍是有区别的，具体的实现是插件帮咱们作了，我节选了一点代码添上以下：

注意我圈出来的代码，这里区分了服务和普通类型分别生成不一样的代码。而服务内部注入的实例仍是经过普通方式获取的，也就是我下面要分析的第二种获取服务的方式。

普通方式

普通方式也分为2种，一种是根据name，另外一种就是根据type。 下面只分析第一种根据name来获取服务的方式，由于根据type来获取实例是差很少的。 ###_ARouter#_navigation

private Object _navigation(final Context context, final Postcard postcard, final int requestCode, final NavigationCallback callback) {
        final Context currentContext = null == context ? mContext : context;

        switch (postcard.getType()) {
            case ACTIVITY:
                ……
                break;
            case PROVIDER:
                //注意这行代码
                return postcard.getProvider();
            case BOARDCAST:
            case CONTENT_PROVIDER:
            case FRAGMENT:
                Class fragmentMeta = postcard.getDestination();
                try {
                    Object instance = fragmentMeta.getConstructor().newInstance();
                    if (instance instanceof Fragment) {
                        ((Fragment) instance).setArguments(postcard.getExtras());
                    } else if (instance instanceof android.support.v4.app.Fragment) {
                        ((android.support.v4.app.Fragment) instance).setArguments(postcard.getExtras());
                    }

                    return instance;
                } catch (Exception ex) {
                    logger.error(Consts.TAG, "Fetch fragment instance error, " + TextUtils.formatStackTrace(ex.getStackTrace()));
                }
            case METHOD:
            case SERVICE:
            default:
                return null;
        }

        return null;
    }
复制代码

最后会根据postcard.getType()类型来匹配PROVIDER，而后返回provider实例，而provider的set是在LogisticsCenter#completion中：

好了，实例获取到了其余的也就没什么好分析的了。 这里提醒一下， 根据type来获取实例有局限性，只支持全局只有一个实现了相应接口的实现类，不然获取到的实例是系统扫描到的实现最后一个实例，同上一篇文章的PathReplaceService。

WHY:那为何根据type和根据那么来获取实例会有区别呢？经过源码咱们发现type是从providersIndex Map中去获取实例的，而name是从providers Map中去获取实例的。

相信到这你们应该已经明白了吧。

拦截器

咱们在实现拦截器的时候须要实现IInterceptor，而IInterceptor也实现了IProvider，因此IInterceptor也是一个服务。因此interceptor的实例获取方式也是跟普通的service是同样的，这里不作分析。

对应上文的普通服务。 下面让咱们来找一下具体获得拦截逻辑是在哪实现的呢？请看下面的代码：

InterceptorServiceImpl#_excute

InterceptorServiceImpl属于arouter核心服务类

InterceptorServiceImpl#doInterceptions

_ARouter#navigation

到这又回到咱们上一篇文章页面跳转主流程的逻辑，他其实就是在真正跳转以前，先判断有没有符合的拦截器，有的话则先进行拦截器里的操做。这里要注意一点的是： 拦截器是有优先级的，按照priority排序，priority越小优先级越高。这是由于 interceptorsIndex的类型是TreeMap，他具备如下两条特性：

一、TreeMap如不指定排序器，默认将按照key值进行升序排序，若是指定了排序器，则按照指定的排序器进行排序。 二、具体的排序规则，开发人员能够在int compare()方法中进行指定。

到此，拦截器的实现原理咱们也就分析清楚了。

降级策略

咱们知道使用系统自带的StartActivity()启动后就没法插手其中任何环节了，只能交给系统管理，这就致使了在跳转失败的状况下没法降级，而是会直接抛出运营级的异常，甚至致使崩溃，这个给用户的感受就不是很好。因此ARouter就为咱们提供了降级策略，主要分为2中方式，单独降级和全局降级（demo中这样称呼的）。

单独降级（接口回调）&全局降级

以下代码所示:

主要回调的就是onLost，那它又是在何时才被调用的呢？咱们看以下代码

它在completion中主动抛出异常被捕获时调用的，若是callback不为null就会被调用，由此也能够看出单独降级的优先级是高于全局降级的，else中的代码就是全局降级的代码。使用方式也跟普通的服务是同样的这里就不分析了。 咱们再看看LogisticsCenter.completion这个方法，这个是与编译期间生成的映射文件直接打交道的模块。先在加载到内存的节点仓库中查找是否有该目标节点的存在，没有就到组仓库中找，找不到就报错NoRouteFoundException，这就到了咱们上面的逻辑中。

LogisticsCenter#completion

public synchronized static void completion(Postcard postcard) {
        if (null == postcard) {
            throw new NoRouteFoundException(TAG + "No postcard!");
        }

        RouteMeta routeMeta = Warehouse.routes.get(postcard.getPath());
        if (null == routeMeta) {    // Maybe its does't exist, or didn't load.
            Class<? extends IRouteGroup> groupMeta = Warehouse.groupsIndex.get(postcard.getGroup());  // Load route meta.
            if (null == groupMeta) {
                throw new NoRouteFoundException(TAG + "There is no route match the path [" + postcard.getPath() + "], in group [" + postcard.getGroup() + "]");
            }
        }
}

复制代码

#总结 通过两篇文章，咱们基本上已经把ARouter的主要功能都分析了。其实看着很神奇的功能，只要咱们深刻到源码里就会发现其实也就那么回事。不过咱们仍是能从优秀获得框架中学到不少优秀的设计思想和前沿的技术的，好比IOC、APT， AOP等。