这个知识点，出来两年了，现在在网上搜索，没有看到相关分享。一个非常好用的Api，Android 10 才增加的，解决悬浮窗口的一个痛点，下面把我的经验跟大家分享一下，希望大能够受用。

悬浮窗口的痛点（View is attach）

为什么说 “View is attach的判断是悬浮窗口的痛点”？

在Android 10 之前

WinodwManager 提供了 addView、removeView 操作，没有查询接口，如何判断view是否被add，所能想到的方式就是view is attach。加上 “ View not attached to window manager” 的 源码log，使开发者确信，通过View.isAttachedToWindow判断，就可以判断 view是否在window上，没有调查使用中可能出现的风险。

可悲的是，没有其他好的Api之前，使用View.isAttachedToWindow 也几乎变成了一个唯一的选择。

Android 10 推了新的API，让开发者多了一个更好的选择。

通过一个案例，来说明这个API，并解决这个痛点。

案例回顾

悬浮窗口的使用

windowManager.addView(view, layoutParams);//新增窗口

windowManager.removeView(view);移除窗口

 

但新增或者移除容易导致Crash，log如下

如：同一个view 被add 两次

05-21 03:19:13.285 3463 3463 W System.err: java.lang.IllegalStateException: View XXX{7afdd92 V.E...... ......I. 0,0-56,290} has already been added to the window manager.



05-21 03:19:13.285 3463 3463 W System.err:  at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:359)



05-21 03:19:13.285 3463 3463 W System.err:  at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:96)

 

移除一个，没有Attach 的窗口

W System.err: java.lang.IllegalArgumentException: View=XXXX{25626d6 V.E...... ........ 0,0-56,229} not attached to window manager



08-19 07:08:08.832 25836 25836 W System.err:   at android.view.WindowManagerGlobal.findViewLocked(WindowManagerGlobal.java:517)



08-19 07:08:08.832 25836 25836 W System.err:   at android.view.WindowManagerGlobal.removeView(WindowManagerGlobal.java:426)



08-19 07:08:08.832 25836 25836 W System.err:   at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:123)

 

通常的解决方式：log提示 not attached -> 刚好可以使用View.isAttachedToWindow 去判断代码如下：

if(view.isAttachedToWindow()){

    try {

        windowManager.removeView(textView);

    } catch (Exception e) {

        e.printStackTrace();

    }

}

if(!view.isAttachedToWindow()){

    try {

        windowManager.addView(view,layoutParams);

    } catch (Exception e) {

        e.printStackTrace();

    }

}

 

遇到的问题

使用以上代码，但在项目中还是有极低概率还是会出现crash。

也就是 isAttachedToWindow ≠ view is add window

解决问题

• 方案一：

  应用中给View标志位，表示view 是否被add。但是总觉得本地标识，没有系统api准确，该方案不算太好。偶现的问题，必然有必现的过程，后面进行了深入的分析。

  项目中遇到的问题是：同一个view，windowManager.addView 被连续执行了两次，也不是异步造成的。

  最后发现，两次调用时间间隔极短，isAttachedToWindow 还没有来得及改变。

  经详细调查有了方案二。

• 方案二：

  使用 WindowInspector，此类在Android 10 framework 才增加，且只有getGlobalWindowViews 这一个静态方法

  view.isAttachedToWindow() 改为 WindowInspector.getGlobalWindowViews().contains(view)
  
   

源码分析

getGlobalWindowViews

看下主要类的调用关系，以及主要的方法

/**

* addView 与 removeView 都会调用此方法

* addView  required：false 如果 index !=0  同一个View重复add，抛异常

* removeView required：true  index < 0 ,没有找到View,抛异常

*/

private int findViewLocked(View view, boolean required) {

    final int index = mViews.indexOf(view);

    if (required && index < 0) {

        throw new IllegalArgumentException("View=" + view + " not attached to window manager");

    }

    return index;

}

 

通过以上分析：WindowManagerGlobal 中 mView 是问题的关键，管理着所属应用的所有View。

Android 10，提供了 WindowInspector.getGlobalWindowViews()。可以获取mViews。修改代码如下

if(WindowInspector.getGlobalWindowViews().contains(view)){

    windowManager.removeView(view);

}

if(!WindowInspector.getGlobalWindowViews().contains(view)){

    windowManager.addView(view，layoutParams);

}

 

分析到这里，问题就解决了。那isAttachedToWindow 怎么就不行呢？

isAttachedToWindow

以下时序图看出：

当刷新线程走完后，才认为是attach。

两者区别是：attach 当view 被add ，且被刷新了。

总结

经过上文分析，从view add -> attach , 区别是view 是否被刷新。

分析了下：为什么要重新用WindowInspector，而不是用WIndowManager WindowManager：是对Window 的管理，查询觉得不合适吧，所以用了WindowInspector类

下面说明下可能出现的一些误区。

1、getGlobalWindowViews 获取的View列表 ，其实是WindowManagerGlobal.mViews 的浅拷贝，所以增删改，都不会应该WindowManagerGlobal 中mViews的结构。

2、强调下，不要被Global迷惑,Global的范围是应用级别的，获取不到其他应用的窗口。

随着面试和工作中多次遇到ARouter的使用问题，我决定把ARouter的源码从头到尾理一遍。 让我瞧瞧你到底有几斤几两，为啥大家在项目组件化中都用你做路由框架。

前言

在开发一个项目的时候，我们总是希望架构出的代码能够自由复用，**自由组装。**实现业务模块的范围的单一职责。并且抽离出各种各样可重复使用的组件。 而在组件化过程中，路由是个绕不过去的坎。 当模块可以自由拼装拆除的时候，类的强引用方式变得不可取。因为有些类很可能在编译期间就找不到了。所以就需要有种方式能通直接过序列化的字符串来拉起对应的功能或者页面。也就是通常的路由功能。 ARouter也是接受度比较高的一个开源路由方案。 于是我写了这篇文章，对ARouter的源码原理进行一个全面的分析梳理。 看完文章过后，将能学习到Arouter 的使用原理，注解处理器的开发方式，gradle插件如何对于和class文件转dex进行中间处理。

名词介绍

apt:APT(Annotation Processing Tool)即注解处理器，是一种处理注解的工具，确切的说它是javac的一个工具，它用来在编译时扫描和处理注解。注解处理器以Java代码(或者编译过的字节码)作为输入，生成**.java文件**作为输出。ARouter中通过处理注解生成相关路由信息类 asm:ASM 库是一款基于 Java 字节码层面的代码分析和修改工具。ASM 可以直接生产二进制的 class 文件，也可以在类被加载入 JVM 之前动态修改类行为。在ARouter中用于arouter_register插件插入初始化代码。官方链接

目录

1. 项目模块结构
2. ARouter路由使用分析
3. ARouter初始化分析
4. ARouter注解处理代码生成：arouter-compiler
5. ARouter自动注册插件：arouter-register
6. ARouter idea 插件：arouter helper
7. 自动代码生成
8. gradle插件

一. 项目模块结构

官方仓库 我们克隆github的ARouter源码，打开项目就是如下的项目结构图。

• ARouter :api入口类
• LogisticsCenter :路由逻辑中心维护所有路由图谱
• Warehouse :保存所有路由映射，通过他找到所以字符串对应的路由信息。这些信息都是从解析注解标记自动生成。//todo 可能不正确
• RouteType :路由类型，现在有: *ACTIVITY，SERVICE，PROVIDER，CONTENT_PROVIDER，BOARDCAST，METHOD，FRAGMENT，UNKNOWN*
• RouteMeta：路由信息类，包含路由类型，路由目标类class,路由组group名等。

二. ARouter 路由使用分析

ARouter的接入和使用参考官方说明就可以了。

接下来从常用Activity 跳转入手来了解路由导航处理

从最常用的api入手，我们就能知道ARouter 最主要的运转原理，了解他是怎么支撑实现跳转这个我们最常用的功能的。 跳转Activity代码如下:

ARouter.getInstance().build("/test/activity").navigation();

 

这一句代码就完成了activity跳转

要点步骤如下：

1. 通过PathReplaceService 预处理路径，并从path:"/test/activity" 中抽取出 group: "test"
2. 将path 和group 作为参数创建 Postcard 实例
3. 调用 postcard#navigation ，最终导航到_ARouter#navigation
4. 通过 group 和 path 从Warehouse.``*routes*获取具体路径信息RouteMeta，完善postcard。

详细说明

前面提到的一些用户自定义的 Service

第一步抽取 group

而不管是跳转Activity,获取Fragment还是获取Provider。 ARouter.getInstance().build("/test/activity")是 ARouter最核心的路由api。而这个build出来的，是Postcard类。 我们先看build代码的执行路径：

protected Postcard build(String path) {

    if (TextUtils.isEmpty(path)) {

        throw new HandlerException(Consts.TAG + "Parameter is invalid!");

    } else {

        ///  用户自定义路径处理类。默认为空。 ARouter.getInstance().navigation 直接获取Provider后文分析

        PathReplaceService pService = ARouter.getInstance().navigation(PathReplaceService.class);

        if (null != pService) {

            path = pService.forString(path);

        }

        ///获取path中包含的 group 作为参数二

        return build(path, extractGroup(path), true);

    }

}

 

代码中可以看到，其中通过ARouter.``*getInstance*``().navigation(PathReplaceService.class)获取路径替换类，对路径进行了预处理操作(默认没有自定义实现类)。通过extractGroup方法从 path中获取了 group信息。

private String extractGroup(String path) {

    if (TextUtils.isEmpty(path) || !path.startsWith("/")) {

        throw new HandlerException(Consts.TAG + "Extract the default group failed, the path must be start with '/' and contain more than 2 '/'!");

    }



    try {

        String defaultGroup = path.substring(1, path.indexOf("/", 1));

        if (TextUtils.isEmpty(defaultGroup)) {

            throw new HandlerException(Consts.TAG + "Extract the default group failed! There's nothing between 2 '/'!");

        } else {

            return defaultGroup;

        }

    } catch (Exception e) {

        logger.warning(Consts.TAG, "Failed to extract default group! " + e.getMessage());

        return null;

    }

}

 

从extractGroup 源码可知，抽取group的时候对路由路径 "/test/activity" 做了校验：

1. 一定要"/" 开头
2. 至少要有两个"/"
3. 第一个反斜杠后面的就是group

所以path路径一定要是类似 的格式，或者多来几个"/"。

第二步：创建Postcard实例

很简单，直接new出来了

return new Postcard(path, group);

 

第三步：调用_ARouter#navigation

这块代码是路由的安卓核心跳转代码 很长一大串:

protected Object navigation(final Context context, final Postcard postcard, final int requestCode, final NavigationCallback callback) {

    ///1.自定义预处理代码

    PretreatmentService pretreatmentService = ARouter.getInstance().navigation(PretreatmentService.class);

    if (null != pretreatmentService && !pretreatmentService.onPretreatment(context, postcard)) {

        // 预处理拦截了 返回

        return null;

    }



    // 设置context

    postcard.setContext(null == context ? mContext : context);



    try {

        ///2.通过路由信息，找到对应的路由信息 RouteMeta ，根据路由类型 RouteType 

        ///完善posrcard   

        LogisticsCenter.completion(postcard);

    } catch (NoRouteFoundException ex) {

        ///... 省略异常日志和弹窗展示。以及相关回调方法

        ///值得一提的是走了 DegradeService 的自定义丢失回调

    }



    if (null != callback) {

        callback.onFound(postcard);

    }



    ///3.如果不是绿色通道，需要走拦截器：InterceptorServiceImpl

    if (!postcard.isGreenChannel()) {   // It must be run in async thread, maybe interceptor cost too mush time made ANR.

        interceptorService.doInterceptions(postcard, new InterceptorCallback() {

            @Override

            public void onContinue(Postcard postcard) {

                ///4.继续导航方法

                _navigation(postcard, requestCode, callback);

            }

            @Override

            public void onInterrupt(Throwable exception) {

               ///省略拦截后的一些代码

               }

        });

    } else {

        ///4.继续导航方法

        return _navigation(postcard, requestCode, callback);

    }



    return null;

}

 

简单总结一下主要代码步骤：

1. 如有自定义预处理导航逻辑，执行并检查拦截
2. 通过path路径找到对应的routemeta路由信息，用该信息完善postcard对象（LogisticsCenter.completion方法中完成，细节后文分析）
3. 如果不是绿色通道，需要走拦截器：InterceptorServiceImpl 。该拦截器服务类中完成拦截器一一执行。(2的源码细节可知，PROVIDER和FRAGMENT类型是绿色通道)
4. 继续导航方法，调用_navigation。

看代码：

private Object _navigation(final Postcard postcard, final int requestCode, final NavigationCallback callback) {

    final Context currentContext = postcard.getContext();



    switch (postcard.getType()) {

        case ACTIVITY:

            // Build intent

            final Intent intent = new Intent(currentContext, postcard.getDestination());

            //...省略完善intent代码

            // Navigation in main looper.

            runInMainThread(new Runnable() {

                @Override

                public void run() {

                    startActivity(requestCode, currentContext, intent, postcard, callback);

                }

            });



            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;

}

 

很明显，代码中注意对各种类型的路由做了处理。

• *ACTIVITY：*新建Intent ，通过postcard信息，完善intent走context.startActivity 或者 context.startActivityForResult。
• PROVIDER：postcard.getProvider() 获取provider实例（实例化代码在LogisticsCenter.completion）
• FRAGMENT，BOARDCAST，CONTENT_PROVIDER：routeMeta.getConstructor().newInstance() 通过路由信息实例化出实例，如果是Fragment的话，则另外再设置extras信息。
• METHOD，SERVICE：返回空，啥也不做。说明该类型路由调用*navigation*没啥意义。

看到这里，对于Activity 的路由跳转就很直观了，就是调用了startActivity 或者 startActivityForResult 方法，其他provider fragment等实例的获取也十分得清晰明了了，接下来讲讲上面提到的补全postcard关键代码。

关键代码：LogisticsCenter.completion 分析

完善postcard信息代码是通过LogisticsCenter.completion 方法完成的。现在来梳理一下这一块代码：

/**

 * 通过RouteMate 完善 postcard

 * @param postcard Incomplete postcard, should complete by this method.

 */

public synchronized static void completion(Postcard postcard) {

    //省略空判断

    RouteMeta routeMeta = Warehouse.routes.get(postcard.getPath());

    if (null == routeMeta) {

        // 如果路由的组group没有找到，直接抛异常

        if (!Warehouse.groupsIndex.containsKey(postcard.getGroup())) {

            throw new NoRouteFoundException(TAG + "There is no route match the path [" + postcard.getPath() + "], in group [" + postcard.getGroup() + "]");

        } else {

            //...省略一些日志代码

            // 1.动态添加组元素（从groupsIndex 中找到对应 IRouteGroup的生成类，再对组元素进行加载）

            addRouteGroupDynamic(postcard.getGroup(), null);

            completion(postcard);   // Reload

        }

    } else {

        postcard.setDestination(routeMeta.getDestination());

        postcard.setType(routeMeta.getType());

        postcard.setPriority(routeMeta.getPriority());

        postcard.setExtra(routeMeta.getExtra());



        Uri rawUri = postcard.getUri();

        ///2.如果有uri 信息，解析uri相关参数。解析出AutoWired的参数的值

        if (null != rawUri) {   // Try to set params into bundle.

            Map<String, String> resultMap = TextUtils.splitQueryParameters(rawUri);

            Map<String, Integer> paramsType = routeMeta.getParamsType();



            if (MapUtils.isNotEmpty(paramsType)) {

                // Set value by its type, just for params which annotation by @Param

                for (Map.Entry<String, Integer> params : paramsType.entrySet()) {

                    setValue(postcard,

                            params.getValue(),

                            params.getKey(),

                            resultMap.get(params.getKey()));

                }

                // Save params name which need auto inject.

                postcard.getExtras().putStringArray(ARouter.AUTO_INJECT, paramsType.keySet().toArray(new String[]{}));

            }

            // Save raw uri

            postcard.withString(ARouter.RAW_URI, rawUri.toString());

        }

        ///3.获取provider实例，如果初始获取，初始化该provider， 最后赋值给postcard 

        switch (routeMeta.getType()) {

            case PROVIDER:  // if the route is provider, should find its instance

                // Its provider, so it must implement IProvider

                Class<? extends IProvider> providerMeta = (Class<? extends IProvider>) routeMeta.getDestination();

                IProvider instance = Warehouse.providers.get(providerMeta);

                if (null == instance) { // There's no instance of this provider

                    IProvider provider;

                    try {

                        provider = providerMeta.getConstructor().newInstance();

                        provider.init(mContext);

                        Warehouse.providers.put(providerMeta, provider);

                        instance = provider;

                    } catch (Exception e) {

                        logger.error(TAG, "Init provider failed!", e);

                        throw new HandlerException("Init provider failed!");

                    }

                }

                postcard.setProvider(instance);

                postcard.greenChannel();    // Provider should skip all of interceptors

                break;

            case FRAGMENT:

                postcard.greenChannel();    // Fragment needn't interceptors

            default:

                break;

        }

    }

}

 

梳理一下这一块的代码,这一部分代码完善了postcard信息,总共分成了三个要点

1. **获取路由信息：**如果路由信息找不到，通过组信息，重新动态添加组group内所有路由 ，调用*addRouteGroupDynamic* 。
2. **获取uri内的参数：**如果postcard创建的时候有传递uri。解析uri里面所有需要AutoInject的参数。放置到postcard中。
3. **获取Provider实例，配置是否不走拦截器的绿色通道：**不存在的Provider通过路由信息的 getDestination 反射创建实例并初始化，存在的直接获取。

分析到这里。各种RouteType的跳转，实例获取都已经明了了。 现在剩下的问题是，WareHouse里面的路由信息数据是哪里来的？前面提到了动态添加组内路由的方法*addRouteGroupDynamic*。我们来看看：

public synchronized static void addRouteGroupDynamic(String groupName, IRouteGroup group) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {

    if (Warehouse.groupsIndex.containsKey(groupName)){

        // If this group is included, but it has not been loaded

        // load this group first, because dynamic route has high priority.

        Warehouse.groupsIndex.get(groupName).getConstructor().newInstance().loadInto(Warehouse.routes);

        Warehouse.groupsIndex.remove(groupName);

    }



    // cover old group. 

    if (null != group) {

        group.loadInto(Warehouse.routes);

    }

}

 

可以看到Warehouse.routes 里面的所有路由信息，都是从 IRouteGroup.loadInto 加载出来的。而IRouteGroup 都存在Warehouse.``*groupsIndex* 中。 这时候新的问题出现了，Warehouse.``*groupsIndex*的数据是哪里来的呢? 下一节 ARouter 初始化分析就有答案。

tips:提到的对外可自定义配置:

简单罗列下源码中提到的可自定义配置的IProvider。便于使用的时候自定义。

• PathReplaceService ///路由自定义处理替换
• DegradeService //没有找到路由的通用回调
• PretreatmentService ///navigation 预处理拦截

通过Class 获取IProvider实例

前面提到的PathReplaceService 等用户自定义类，都是通过ARouter.getInstance().navigation(clazz) 方式获取的。 这一块代码又是怎么从路由信息中获取到实例的呢？看看具体的navigation代码：

protected <T> T navigation(Class<? extends T> service) {

    try {

        //1.通过类名从Provider路由信息索引中，获取路由信息，组建postcart

        Postcard postcard = LogisticsCenter.buildProvider(service.getName());



        // Compatible 1.0.5 compiler sdk.

        // Earlier versions did not use the fully qualified name to get the service

        if (null == postcard) {

            // No service, or this service in old version.

             //1.通过类名从Provider路由信息索引中，获取路由信息，组建postcart

                postcard = LogisticsCenter.buildProvider(service.getSimpleName());

        }



        if (null == postcard) {

            return null;

        }



        // Set application to postcard.

        postcard.setContext(mContext);

        //2.完善postcard ,该方法里面创建provider

        LogisticsCenter.completion(postcard);

        return (T) postcard.getProvider();

    } catch (NoRouteFoundException ex) {

        logger.warning(Consts.TAG, ex.getMessage());

        return null;

    }

}

 

很明显，主要代码就是 LogisticsCenter.``*buildProvider*``(service.getName()) ,获取到了postcard。后面完善postcard 和 获取provider实例的代码都已经在上文讲过。 所以我们就看*buildProvider* 方法:

public static Postcard buildProvider(String serviceName) {

    RouteMeta meta = Warehouse.providersIndex.get(serviceName);



    if (null == meta) {

        return null;

    } else {

        return new Postcard(meta.getPath(), meta.getGroup());

    }

}

 

和路由组信息获取类似，Provider的路由信息从 Warehouse.``*providersIndex* 维护的映射表中获取。 所以*providersIndex*是专门用来给没有@Route 路由信息的Provider创建实例用的。这就是维护*providersIndex*的用途。 接下来的问题就转为了 *providersIndex* 里面的数据是哪里来的。

小结

路由跳转以及获取Provider等实例的原理可以简单总结下：

1. 先是获取postcard，可能是直接通过路由路径和uri构建, 如"/test/activity1"，也可能是通过Provider 类名从索引获取，如PathReplaceService.class.getName()
2. 然后通过RouteMate完善 postcard。获取诸如类名信息,路由类型，provider实例等信息。
3. 最后导航，根据路由类型作出跳转或者返回对应实例。

关键点在于WareHouse 维护的路由图谱。

三. ARouter初始化分析

我们看下对用户提供的ARouter#init方法：

public static void init(Application application) {

    if (!hasInit) {

        logger = _ARouter.logger;

        _ARouter.logger.info(Consts.TAG, "ARouter init start.");

        ///调用初始化代码

        hasInit = _ARouter.init(application);

        ///初始化完成后，加载拦截器服务，并初始化所有拦截器

        if (hasInit) {

            _ARouter.afterInit();

        }

        _ARouter.logger.info(Consts.TAG, "ARouter init over.");

    }

}

 

代码关键就两步，

1. 初始化ARouter
2. 获取拦截器服务实例初始化所有拦截器

初始化ARouter

init代码最终调用到了LogisticsCenter#init

通过代码我们了解到了这么几个过程:

1. 方式一 : ARouter-auto-register 插件加载路由表（如果有该插件），该方式详细分析见第五节。
2. 方式二 :
3. 在需要的时候扫描所有 dex文件,找到所有包名为com.alibaba.android.ARouter.routes的类,类名放到routerMap 集里面。
4. 实例化上面找到的所有类，并通过这些集类加载对应的集映射索引到WareHouse中。

很显然，com.alibaba.android.ARouter.routes 包名下面的类都是自动生成的路由表类。 通过搜索我们能找到样例代码中生成的该包名对象们:  module_java 生成的IRouteRoot 代码如下所示

public class ARouter$$Root$$modulejava implements IRouteRoot {

  @Override

  public void loadInto(Map<String, Class<? extends IRouteGroup>> routes) {

    routes.put("m2", ARouter$$Group$$m2.class);

    routes.put("module", ARouter$$Group$$module.class);

    routes.put("test", ARouter$$Group$$test.class);

    routes.put("yourservicegroupname", ARouter$$Group$$yourservicegroupname.class);

  }

}

 

这样我们就完全清楚了 WareHouse里面维护的所有路由信息是哪里来的了。追本溯源。接下来我们只需要知道 ARouter$$Root$$modulejava 等类，是啥时候怎么生成的。我们在下面一小节进行分析。初始化ARouter的过程,其实就是填充Warehouse 的*providersIndex*，*groupsIndex*，*interceptorsIndex*

初始化后续:初始化所有拦截器

初始化完成，看看初始化完成后的操作afterInit

static void afterInit() {

    // Trigger interceptor init, use byName.

    interceptorService = (InterceptorService) ARouter.getInstance().build("/ARouter/service/interceptor").navigation();

}

 

这一块代码就是navigation 获取到了InterceptorService。上面也讲过,在执行navigation的时候，会调用IProvider的init方法。所以我们需要找到InterceptorService 的实现类，并看看他的init做了什么。项目中其实现类是InterceptorServiceImpl,找到init代码如下：

@Override

public void init(final Context context) {

    LogisticsCenter.executor.execute(new Runnable() {

        @Override

        public void run() {

            if (MapUtils.isNotEmpty(Warehouse.interceptorsIndex)) {

                for (Map.Entry<Integer, Class<? extends IInterceptor>> entry : Warehouse.interceptorsIndex.entrySet()) {

                    Class<? extends IInterceptor> interceptorClass = entry.getValue();

                    try {

                        IInterceptor iInterceptor = interceptorClass.getConstructor().newInstance();

                        iInterceptor.init(context);

                        Warehouse.interceptors.add(iInterceptor);

                    } catch (Exception ex) {

                        throw new HandlerException(TAG + "ARouter init interceptor error! name = [" + interceptorClass.getName() + "], reason = [" + ex.getMessage() + "]");

                    }

                }



                interceptorHasInit = true;

                logger.info(TAG, "ARouter interceptors init over.");

                synchronized (interceptorInitLock) {

                    interceptorInitLock.notifyAll();

                }

            }

        }

    });

}

 

代码很明白的告诉我们，该初始化代码从拦截器路由信息索引里面加载并实例化了所有拦截器。然后通知等待的拦截器开始拦截。

小结

看完初始化代码之后,明白了WareHouse的数据来源,现在问题变成了com.alibaba.android.ARouter.routes 包名的代码何时生成。我们且看下回分解。

前言

之前对协程做了一个简单的介绍，回答了协程到底是什么的问题,感兴趣的同学可以了解下：【带着问题学】协程到底是什么?
通过上文，我们了解了以下内容
1.kotlin协程本质上对线程池的封装
2.kotlin协程可以用同步方式写异步代码，自动实现对线程切换的管理

这就引出了本文的主要内容，kotlin协程到底是怎么切换线程的?
具体内容如下:

1. 前置知识

1.1 CoroutineScope到底是什么?

CoroutineScope即协程运行的作用域,它的源码很简单

public interface CoroutineScope {

    public val coroutineContext: CoroutineContext

}

 

可以看出CoroutineScope的代码很简单，主要作用是提供CoroutineContext，协程运行的上下文
我们常见的实现有GlobalScope,LifecycleScope,ViewModelScope等

1.2 GlobalScope与ViewModelScope有什么区别?

public object GlobalScope : CoroutineScope {

    /**

     * 返回 [EmptyCoroutineContext].

     */

    override val coroutineContext: CoroutineContext

        get() = EmptyCoroutineContext

}



public val ViewModel.viewModelScope: CoroutineScope

    get() {

        val scope: CoroutineScope? = this.getTag(JOB_KEY)

        if (scope != null) {

            return scope

        }

        return setTagIfAbsent(

            JOB_KEY,

            CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)

        )

    }

 

两者的代码都挺简单，从上面可以看出
1.GlobalScope返回的为CoroutineContext的空实现
2.ViewModelScope则往CoroutineContext中添加了Job与Dispatcher

我们先来看一段简单的代码

	fun testOne(){

		GlobalScope.launch {

            print("1:" + Thread.currentThread().name)

            delay(1000)

            print("2:" + Thread.currentThread().name)

        }

	}

	//打印结果为：DefaultDispatcher-worker-1

    fun testTwo(){

        viewModelScope.launch {

            print("1:" + Thread.currentThread().name)

            delay(1000)

            print("2:" + Thread.currentThread().name)

        }

    }

    //打印结果为: main

 

上面两种Scope启动协程后，打印当前线程名是不同的，一个是线程池中的一个线程，一个则是主线程
这是因为ViewModelScope在CoroutineContext中添加了Dispatchers.Main.immediate的原因

我们可以得出结论：协程就是通过Dispatchers调度器来控制线程切换的

1.3 什么是调度器？

从使用上来讲，调度器就是我们使用的Dispatchers.Main,Dispatchers.Default，Dispatcher.IO等
从作用上来讲，调度器的作用是控制协程运行的线程
从结构上来讲，Dispatchers的父类是ContinuationInterceptor,然后再继承于CoroutineContext
它们的类结构关系如下：

这也是为什么Dispatchers能加入到CoroutineContext中的原因,并且支持+操作符来完成增加

1.4 什么是拦截器

从命名上很容易看出，ContinuationInterceptor即协程拦截器，先看一下接口

interface ContinuationInterceptor : CoroutineContext.Element {

    // ContinuationInterceptor 在 CoroutineContext 中的 Key

    companion object Key : CoroutineContext.Key<ContinuationInterceptor>

    /**

     * 拦截 continuation

     */

    fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T>



    //...

}

 

从上面可以提炼出两个信息
1.拦截器的Key是单例的，因此当你添加多个拦截器时，生效的只会有一个
2.我们都知道，Continuation在调用其Continuation#resumeWith()方法，会执行其suspend修饰的函数的代码块，如果我们提前拦截到，是不是可以做点其他事情？这就是调度器切换线程的原理

上面我们已经介绍了是通过Dispatchers指定协程运行的线程，通过interceptContinuation在协程恢复前进行拦截，从而切换线程
带着这些前置知识，我们一起来看下协程启动的具体流程，明确下协程切换线程源码具体实现

2. 协程线程切换源码分析

2.1 launch方法解析

我们首先看一下协程是怎样启动的，传入了什么参数

public fun CoroutineScope.launch(

    context: CoroutineContext = EmptyCoroutineContext,

    start: CoroutineStart = CoroutineStart.DEFAULT,

    block: suspend CoroutineScope.() -> Unit

): Job {

    val newContext = newCoroutineContext(context)

    val coroutine = if (start.isLazy)

        LazyStandaloneCoroutine(newContext, block) else

        StandaloneCoroutine(newContext, active = true)

    coroutine.start(start, coroutine, block)

    return coroutine

}

 

总共有3个参数：
1.传入的协程上下文
2.CoroutinStart启动器，是个枚举类，定义了不同的启动方法，默认是CoroutineStart.DEFAULT
3.block就是我们传入的协程体，真正要执行的代码

这段代码主要做了两件事:
1.组合新的CoroutineContext
2.再创建一个 Continuation

2.1.1 组合新的CoroutineContext

public actual fun CoroutineScope.newCoroutineContext(context: CoroutineContext): CoroutineContext {

    val combined = coroutineContext + context

    val debug = if (DEBUG) combined + CoroutineId(COROUTINE_ID.incrementAndGet()) else combined

    return if (combined !== Dispatchers.Default && combined[ContinuationInterceptor] == null)

        debug + Dispatchers.Default else debug

}

 

从上面可以提炼出以下信息:
1.会将launch方法传入的context与CoroutineScope中的context组合起来
2.如果combined中没有拦截器，会传入一个默认的拦截器，即Dispatchers.Default,这也解释了为什么我们没有传入拦截器时会有一个默认切换线程的效果

2.1.2 创建一个Continuation

val coroutine = if (start.isLazy)

        LazyStandaloneCoroutine(newContext, block) else

        StandaloneCoroutine(newContext, active = true)

    coroutine.start(start, coroutine, block)

 

默认情况下，我们会创建一个StandloneCoroutine
值得注意的是，这个coroutine其实是我们协程体的complete，即成功后的回调，而不是协程体本身
然后调用coroutine.start，这表明协程开始启动了

2.2 协程的启动

public fun <R> start(start: CoroutineStart, receiver: R, block: suspend R.() -> T) {

    initParentJob()

    start(block, receiver, this)

}

 

接着调用CoroutineStart的start来启动协程，默认情况下调用的是CoroutineStart.Default

经过层层调用，最后到达了：

internal fun <R, T> (suspend (R) -> T).startCoroutineCancellable(receiver: R, completion: Continuation<T>) =

    runSafely(completion) {

        // 外面再包一层 Coroutine

        createCoroutineUnintercepted(receiver, completion)

            // 如果需要，做拦截处理

            .intercepted()

            // 调用 resumeWith 方法      

            .resumeCancellableWith(Result.success(Unit))

    }

 

这里就是协程启动的核心代码，虽然比较短，却包括3个步骤：
1.创建协程体Continuation
2.创建拦截 Continuation,即DispatchedContinuation
3.执行DispatchedContinuation.resumeWith方法

2.3 创建协程体Continuation

调用createCoroutineUnintercepted,会把我们的协程体即suspend block转换成Continuation,它是SuspendLambda，继承自ContinuationImpl
createCoroutineUnintercepted方法在源码中找不到具体实现，不过如果你把协程体代码反编译后就可以看到真正的实现
详情可见：字节码反编译

2.4 创建DispatchedContinuation

public actual fun <T> Continuation<T>.intercepted(): Continuation<T> =

    (this as? ContinuationImpl)?.intercepted() ?: this



//ContinuationImpl

public fun intercepted(): Continuation<Any?> =

        intercepted

            ?: (context[ContinuationInterceptor]?.interceptContinuation(this) ?: this)

                .also { intercepted = it }     



//CoroutineDispatcher

public final override fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T> =

      DispatchedContinuation(this, continuation)           

 

从上可以提炼出以下信息
1.interepted是个扩展方法，最后会调用到ContinuationImpl.intercepted方法
2.在intercepted会利用CoroutineContext，获取当前的拦截器
3.因为当前的拦截器是CoroutineDispatcher，因此最终会返回一个DispatchedContinuation，我们其实也是利用它实现线程切换的
4.我们将协程体的Continuation传入DispatchedContinuation,这里其实用到了装饰器模式，实现功能的增强

这里其实很明显了，通过DispatchedContinuation装饰原有协程，在DispatchedContinuation里通过调度器处理线程切换，不影响原有逻辑，实现功能的增强

2.5 拦截处理

    //DispatchedContinuation

    inline fun resumeCancellableWith(

        result: Result<T>,

        noinline onCancellation: ((cause: Throwable) -> Unit)?

    ) {

        val state = result.toState(onCancellation)

        if (dispatcher.isDispatchNeeded(context)) {

            _state = state

            resumeMode = MODE_CANCELLABLE

            dispatcher.dispatch(context, this)

        } else {

            executeUnconfined(state, MODE_CANCELLABLE) {

                if (!resumeCancelled(state)) {

                    resumeUndispatchedWith(result)

                }

            }

        }

    }

 

上面说到了启动时会调用DispatchedContinuation的resumeCancellableWith方法
这里面做的事也很简单：
1.如果需要切换线程，调用dispatcher.dispatcher方法，这里的dispatcher是通过CoroutineConext取出来的
2.如果不需要切换线程，直接运行原有线程即可

2.5.2 调度器的具体实现

我们首先明确下，CoroutineDispatcher是通过CoroutineContext取出来的,这也是协程上下文作用的体现
CoroutineDispater官方提供了四种实现：Dispatchers.Main,Dispatchers.IO,Dispatchers.Default,Dispatchers.Unconfined
我们一起简单看下Dispatchers.Main的实现

internal class HandlerContext private constructor(

    private val handler: Handler,

    private val name: String?,

    private val invokeImmediately: Boolean

) : HandlerDispatcher(), Delay {

    public constructor(

        handler: Handler,

        name: String? = null

    ) : this(handler, name, false)



    //...



    override fun dispatch(context: CoroutineContext, block: Runnable) {

        // 利用主线程的 Handler 执行任务

        handler.post(block)

    }

}

 

可以看到，其实就是用handler切换到了主线程
如果用Dispatcers.IO也是一样的，只不过换成线程池切换了

如上所示，其实就是一个装饰模式
1.调用CoroutinDispatcher.dispatch方法切换线程
2.切换完成后调用DispatchedTask.run方法，执行真正的协程体

3 delay是怎样切换线程的?

上面我们介绍了协程线程调度的基本原理与实现,下面我们来回答几个小问题
我们知道delay函数会挂起，然后等待一段时间再恢复。
可以想象，这里面应该也涉及到线程的切换，具体是怎么实现的呢？

public suspend fun delay(timeMillis: Long) {

    if (timeMillis <= 0) return // don't delay

    return suspendCancellableCoroutine sc@ { cont: CancellableContinuation<Unit> ->

        // if timeMillis == Long.MAX_VALUE then just wait forever like awaitCancellation, don't schedule.

        if (timeMillis < Long.MAX_VALUE) {

            cont.context.delay.scheduleResumeAfterDelay(timeMillis, cont)

        }

    }

}



internal val CoroutineContext.delay: Delay get() = get(ContinuationInterceptor) as? Delay ?: DefaultDelay

 

Dealy的代码也很简单，从上面可以提炼出以下信息
delay的切换也是通过拦截器来实现的，内置的拦截器同时也实现了Delay接口
我们来看一个具体实现

internal class HandlerContext private constructor(

    private val handler: Handler,

    private val name: String?,

    private val invokeImmediately: Boolean

) : HandlerDispatcher(), Delay {

    override fun scheduleResumeAfterDelay(timeMillis: Long, continuation: CancellableContinuation<Unit>) {

        // 利用主线程的 Handler 延迟执行任务，将完成的 continuation 放在任务中执行

        val block = Runnable {

            with(continuation) { resumeUndispatched(Unit) }

        }

        handler.postDelayed(block, timeMillis.coerceAtMost(MAX_DELAY))

        continuation.invokeOnCancellation { handler.removeCallbacks(block) }

    }



    //..

}

 

1.可以看出，其实也是通过handler.postDelayed实现延时效果的
2.时间到了之后，再通过resumeUndispatched方法恢复协程
3.如果我们用的是Dispatcher.IO，效果也是一样的，不同的就是延时效果是通过切换线程实现的

4. withContext是怎样切换线程的?

我们在协程体内，可能通过withContext方法简单便捷的切换线程，用同步的方式写异步代码，这也是kotin协程的主要优势之一

    fun test(){

        viewModelScope.launch(Dispatchers.Main) {

            print("1:" + Thread.currentThread().name)

            withContext(Dispatchers.IO){

                delay(1000)

                print("2:" + Thread.currentThread().name)

            }

            print("3:" + Thread.currentThread().name)

        }

    }

    //1，2，3处分别输出main,DefaultDispatcher-worker-1,main

 

可以看出这段代码做了一个切换线程然后再切换回来的操作，我们可以提出两个问题
1.withContext是怎样切换线程的?
2.withContext内的协程体结束后，线程怎样切换回到Dispatchers.Main?

public suspend fun <T> withContext(

    context: CoroutineContext,

    block: suspend CoroutineScope.() -> T

): T {  

    return suspendCoroutineUninterceptedOrReturn sc@ { uCont ->

        // 创建新的context

        val oldContext = uCont.context

        val newContext = oldContext + context

        ....

        //使用新的Dispatcher，覆盖外层

        val coroutine = DispatchedCoroutine(newContext, uCont)

        coroutine.initParentJob()

        //DispatchedCoroutine作为了complete传入

        block.startCoroutineCancellable(coroutine, coroutine)

        coroutine.getResult()

    }

}



private class DispatchedCoroutine<in T>(

    context: CoroutineContext,

    uCont: Continuation<T>

) : ScopeCoroutine<T>(context, uCont) {

	//在complete时会会回调

    override fun afterCompletion(state: Any?) {

        afterResume(state)

    }



    override fun afterResume(state: Any?) {

        //uCont就是父协程，context仍是老版context,因此可以切换回原来的线程上

        uCont.intercepted().resumeCancellableWith(recoverResult(state, uCont))

    }

}

 

这段代码其实也很简单，可以提炼出以下信息
1.withContext其实就是一层Api封装，最后调用到了startCoroutineCancellable,这就跟launch后面的流程一样了，我们就不继续跟了
2.传入的context会覆盖外层的拦截器并生成一个newContext，因此可以实现线程的切换
3.DispatchedCoroutine作为complete传入协程体的创建函数中，因此协程体执行完成后会回调到afterCompletion中
4.DispatchedCoroutine中传入的uCont是父协程，它的拦截器仍是外层的拦截器，因此会切换回原来的线程中

总结

本文主要回答了kotlin协程到底是怎么切换线程的这个问题，并对源码进行了分析
简单来讲主要包括以下步骤：
1.向CoroutineContext添加Dispatcher，指定运行的协程
2.在启动时将suspend block创建成Continuation,并调用intercepted生成DispatchedContinuation
3.DispatchedContinuation就是对原有协程的装饰，在这里调用Dispatcher完成线程切换任务后，resume被装饰的协程，就会执行协程体内的代码了

其实kotlin协程就是用装饰器模式实现线程切换的
看起来似乎有不少代码，但是真正的思路其实还是挺简单的，这大概就是设计模式的作用吧
如果本文对你有所帮助，欢迎点赞收藏~

概览

通知是 android 系统存在至今为止被变更最为频繁的 api 之一，android 4.1、4.4、5.0、7.0、8.0 都对通知做过比较大的改动。到了 8.0 通知功能趋于稳定，至今没有做过更大的改动。

对一个 api 进行如此大的照顾那么这必然是个非常重要的 api 了。那么就跟随我一起揭开通知一点都不神秘的面纱吧。

注：本文主要讲应用

通知使用

创建简单通知

我们使用 NotificationCompat 来创建通知，使用 NotificationCompat 可以兼容所有的系统版本，不需要我们去手动兼容版本。

创建通知分为两个步骤：

• 创建渠道
• 创建通知

关于渠道

创建渠道

notificationManager.createNotificationChannel(channel)

 

安卓 8.0 系统要求必须创建渠道才能展示通知，所以我们在 8.0 的系统版本中，必须添加创建渠道的方法。

创建渠道不一定非要在展示通知的时候做，同一个渠道只需要被创建一次即可（多次亦可）。我们可以在我们即将展示通知的时候创建，可以再应用启动的时候创建，也可以在 activity 中创建。总之渠道创建非常灵活

如果渠道已经存在我们仍然调用了创建渠道方法，那么什么也不会做，很安全

下面代码是我们创建渠道的完整代码：

private val channelName = "安安安安卓"

private val channelId = "channelId"

fun createNotificationChannel(context: Context): NotificationChannel? {

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

            val descriptionText = "渠道描述"

            val importance = NotificationManager.IMPORTANCE_DEFAULT

            val channel = NotificationChannel(channelId, channelName, importance).apply {

                description = descriptionText

            }

            val notificationManager: NotificationManager =

                context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

            notificationManager.createNotificationChannel(channel)

            return channel

        }

        return null

    }

 

渠道重要性设置

需要注意，渠道的优先级和通知的优先级是不同的，注意区分

val importance = NotificationManager.IMPORTANCE_DEFAULT

val channel = NotificationChannel(channelId, channelName, importance)

 

上面的代码创建了通知的重要程度，我们需要说明一下 NotificationChannel 的第三个参数，也就是渠道的重要程度，这个设置不同的值，用户收到通知后手机的展示包括声音、震动、是否弹出都会不同，下面看一下参数的四种设置（四个参数在不同手机的渠道展示不同）：

• IMPORTANCE_HIGH 收到通知发出提示语，并且会浮动提示用户(小米手机表示紧急)
• IMPORTANCE_DEFAULT 收到通知发出提示语，不会浮动提示（小米手机表示高）
• IMPORTANCE_LOW 收到通知不会发出声音，状态栏有小图标展示（小米手机表示中）
• IMPORTANCE_MIN 根本看不到通知（所以你压根就别用就 ok 了），不过似乎可以用于禁用通知的场景（小米手机表示低）

禁用某个渠道的通知方法

我们使用创建渠道的方式实现禁用通知，如下：

比如我们第一次创建渠道的时候代码如下：

val importance = NotificationManager.IMPORTANCE_HIGH

            val channel = NotificationChannel(channelId, channelName, importance)

 

这行代码会创建一个有声音提示、横幅展示（google 文档管这个叫偷窥模式 😄）的渠道。

如果此时用户通过我们 app 内部的设置想不在收到我们这个渠道的通知，我们需要如下代码这样做：

val importance = NotificationManager.IMPORTANCE_MIN

            val channel = NotificationChannel(channelId, channelName, importance)

 

与上一处的代码的区别是把 IMPORTANCE_HIGH 改成了 IMPORTANCE_MIN，因此我们的渠道就变成了 低级别通知渠道，收到通知也无法展示，因此用户根本看不到通知，从而实现了通知禁用。

还有一点需要注意，我们可以通过代码将一个高优先级的渠道设置为低优先级渠道，但是无法将低优先级渠道设置为高优先级渠道。

关于通知

创建通知

通知大家都太熟悉，直接上代码，记得看注释

private val channelName = "安安安安卓"

    private val channelId = "channelId"

    fun showNotification(context: Context) {

        val notification = NotificationCompat.Builder(context, channelName)//这里的渠道名就是你自己想展示通知对应的渠道分组

            .setSmallIcon(R.drawable.apple)//设置状态栏展示的通知样式

            .setLargeIcon(BitmapFactory.decodeResource(context.resources, R.drawable.apple))//设置通知中的图标样式

            .setContentTitle("公众号")//设置通知标题

            .setContentText("安安安安卓")//设置通知正文

            .setChannelId(channelId)//设置通知渠道，这个渠道id必须是和我们创建渠道时候的id对应

            .setPriority(NotificationCompat.PRIORITY_DEFAULT).build()//设置通知优先级

        NotificationManagerCompat.from(context).notify(13, notification)

    }

 

强调一下：展示通知之前一定要先创建渠道

通知中的优先级

设置方法：NotificationCompat.Builder.setPriority 通知优先级极容易跟渠道优先级混淆，一定要注意区分 通知优先级有以下几种：

• PRIORITY_DEFAULT = 0;默认优先级
• PRIORITY_LOW = -1; 低优先级
• PRIORITY_MIN = -2;最低优先级
• PRIORITY_HIGH = 1;高优先级
• PRIORITY_MAX = 2;最高优先级

这个参数主要是给我们的通知进行排序，重要的通知放在前面展示。这可以帮助我们第一时间找到最重要的通知进行处理，这很实用不是

创建代码

我们可以再创建 NotificationCompat.Builder 的时候加上如下调用就可以展示展开式通知：

 .setStyle(

                NotificationCompat.BigTextStyle()

                    .bigText("本文由 公众号 \"安安安安卓\"作者原创，禁抄袭\n 北国风光，" +

                            "千里冰封，万里雪飘，望长城内外，惟余莽莽，大河上下，顿失滔滔，山舞银蛇，原驰蜡象，欲与天公试比高。" +

                            "须晴日，看银装素裹，分外妖娆")

            )

 

通知默认是展开式的，长按通知可以在短文本和长文本之间来回切换

设置通知的点击事件

如下代码实现一个可点击的通知栏

  fun showNotification(context: Context) {

        val intent = Intent(context,OnlyShowActivity::class.java).apply {

            flags=Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

        }

        val pendingIntent=PendingIntent.getActivity(context,0,intent,0)

        val notification = NotificationCompat.Builder(context, channelId)

            .setContentText("点击通知跳转的一个页面中")

            .setContentTitle("可点击通知")

            .setSmallIcon(R.drawable.apple)

            .setLargeIcon(BitmapFactory.decodeResource(context.resources, R.drawable.apple))

            .setAutoCancel(true)//设置点击了通知，则通知自动消失

            .setContentIntent(pendingIntent)

            .build()

        NotificationManagerCompat.from(context).notify(++count, notification)

    }

 

给通知栏设置按钮

我们可以通过 addAction 给通知设置 action，同时可以指定一个 PendingIntent。

fun showBtnNotification(context: Context) {

        val intent = Intent(context, OnlyShowActivity::class.java)

        intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK

        val pendingIntent = PendingIntent.getActivity(context, 0, intent, 0)

        val notification = NotificationCompat.Builder(context, channelId)

            .setSmallIcon(R.drawable.apple)

            .setLargeIcon(BitmapFactory.decodeResource(context.resources, R.drawable.apple))

            .setContentText("安安安安卓，北国风光，千里冰封，万里雪飘")

            .setContentTitle("按钮通知")

            .addAction(R.drawable.person, "李白", pendingIntent)

            .addAction(R.drawable.apple, "杜甫", pendingIntent)

            .addAction(R.drawable.apple, "王维", pendingIntent)

            .setAutoCancel(true)

            .build()

        NotificationManagerCompat.from(context).notify(++count, notification)

    }

 

设置进度条

 private val countdown = object : CountDownTimer(15 * 1000, 1000) {

        private val perdegree = 100 / 15

        var count = 0

        override fun onTick(millisUntilFinished: Long) {

            count++

            showNotification(count * perdegree)//更新进度

        }



        override fun onFinish() {

            showNotification(100)

            count = 0

        }

    }



    /**

     * 启动一个可动的进度条

     */

    fun start() {

        countdown.start()

    }



    private fun showNotification(progress: Int) {

        val builder = NotificationCompat.Builder(context, channelId)

            .setSmallIcon(R.drawable.apple)

            .setLargeIcon(BitmapFactory.decodeResource(context.resources, R.drawable.person))

            .setColor(Color.GREEN)

            .setContentTitle("这是个进度标题")



        NotificationManagerCompat.from(context).apply {

            builder.setProgress(100, progress, false)

            builder.setContentText("下载进度 $progress%")

            notify(count, builder.build())

        }

    }

 

设置自定义通知

我们可以通过 RemoteViews 指定一个布局，通过 setCustomContentView 设置我们的自定义布局 代码：

 fun showNotification(context: Context){

        val remoteViews = RemoteViews(context.packageName, R.layout.item_notification)

        val notification = NotificationCompat.Builder(context, channelId)

            .setContentTitle("这个通知的布局是自定义的")

            .setContentText("安安安安卓")

            .setSmallIcon(R.drawable.apple)

            .setLargeIcon(BitmapFactory.decodeResource(context.resources, R.drawable.person))

            .setCustomContentView(remoteViews)

            .build()

        NotificationManagerCompat.from(context).notify(count,notification)

    }

 

我们的 xml 代码预览图：

最终效果图：

其它的知识点

1. 从 android8.1 开始，应用一秒钟最多只能发出一次通知提示音，如果出现多条通知只有一条通知可以出发提示音
2. 创建通知的几种样式：NotificationCompat.BigPictureStyle、NotificationCompat.BigTextStyle、NotificationCompat.DecoratedCustomViewStyle
3. NotificationCompat.Builder.setGroup 方法可以创建一组通知
4. NotificationManager.getNotificationChannel()或 NotificationManager.getNotificationChannels()两个方法可以获取通知的渠道，通过获取到的渠道可以获取此渠道是否开启声音、渠道通知的重要级别。我们可以据此提示用户打开相应的设置，下面代码展示了打开通知渠道的方法：

  Intent intent = new Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS);

    intent.putExtra(Settings.EXTRA_APP_PACKAGE, getPackageName());

    intent.putExtra(Settings.EXTRA_CHANNEL_ID, myNotificationChannel.getId());

    startActivity(intent);



 

5. 删除渠道的方法 deleteNotificationChannel()
6. 我们可以调用渠道的 NotificationChannel.setShowBadge(false)方法关闭桌面图标圆点。这个其实很有用，比如当你用通知展示下载进度条的时候这条通知明显是不需要展示圆点的，还有大部分的本地提醒类通知都不会希望显示圆点的，用这个方法正好
7. NotificationCompat.Builder.setNumber 方法可以设置桌面图标的红点数量
8. 通过 NotificationCompat.DecoratedCustomViewStyle 样式可以给内容区域创建自定义布局。样式就是通知展示图标在左，我们自定义的布局在右，不过这个感觉就没啥用了。
9. 自定义布局的通知也可以给内部的 view 添加点击跳转事件，实现方法如下代码：

 val remoteViews = RemoteViews(context.packageName, R.layout.item_notification)

        val intent = Intent(context,OnlyShowActivity::class.java)

        val pendingIntent = PendingIntent.getActivity(context,0,intent,0)

        remoteViews.setOnClickPendingIntent(R.id.iv_pendingintent_click,pendingIntent)

 

正文

进行组件化开发有一段时间了，不久后就要开始一个新项目了，为此整理了目前项目中使用的组件化开发规范，方便在下一个项目上使用。本文的重点是介绍规范和项目架构，仅提供示例代码举例，目前不打算提供示例Demo。如果你还不了解什么是组件化以及如何进行组件化开发的话，建议请先看下面这个文章。

定义

组件是 Android 项目中一个相对独立的功能模块，是一个抽象的概念，module 是 Android 项目中一个相对独立的代码模块。

在组件化开发的早期，一个组件就只有一个 module，导致很多代码和资源都会下沉到 common 中，导致 common 会变得很臃肿。有的文章说，专门建立一个 module 来存放通用资源，我感觉这样是治标不治本，直到后面看到微信Android模块化架构重构实践这篇文章，里面的"模块的一般组织方式"一节提到一个模块应该有多个工程，然后开始在项目对 module 进行拆分。

一般情况下，一个组件有两个 module，一个轻量级的 module 提供外部组件需要和本组件进行交互的接口方法及一些外部组件需要的资源，另一个重量级的 module 完成组件实际的功能和实现轻量级 module 定义的接口方法。

module 的命名规范请参考module名，在下文中使用 module-api 代表轻量级的 module，使用 module-impl 代表重量级的 module。

common组件

common 是一个特殊的组件，不区分轻量级和重量级，它是项目中最底层的组件，基本上所有的其他组件都会依赖 common 组件，common 中放项目中所有弱业务逻辑的代码和解决循环依赖的代码和资源。

一个完整的项目的架构如下：

弱业务逻辑代码

何为弱业务逻辑代码？简单来说，就是有一定的业务逻辑，但是这个业务逻辑对于项目中其他组件来说通用的。

比如在 common 组件集成网络请求库，创建一个 HttpTool 工具类，负责初始化网络请求框架，定义网络请求方法，实现组装通用请求参数以及处理全局通用错误等，对于其他组件直接通过这个工具类进行网络请求就可以了。

比如定义界面基类，处理一些通用业务逻辑，比如接入统计分析框架。

解决循环依赖的代码和资源

何为解决循环依赖的代码和资源？比如说 module-a-api 有一个类 C，module-b-api 中有一个类 D，在 module-a-api 中需要使用 D，在 module-b-api 中需要使用 C，这样就会造成 module-a-api 需要依赖 module-b-api，而 module-b-api 也会依赖 module-a-api，这就造成了循环依赖，在 Android Studio 中会编译失败。

解决循环依赖的方案就是将 C 和 D 其中的一个，或者两个都下沉到 common 组件中，因为 module-a-api 和 module-b-api 都依赖了 common 组件，至于具体下沉几个，这个根据具体的情况而定，但是原则是下沉到 common 组件的东西越少越好。

上面的举的例子是代码，资源文件同样也可能会有这个问题。

module代码结构

一个组件通常含有一个或多个功能点，比如对于用户组件，它有关于界面、意见反馈、修改账户密码等功能点，在 module 中为每一个功能点创建一个路径，里面放实现该功能的代码，比如 Activity、Dialog 、Adapter 等。除此之外，为了集中管理组件内部资源和统一编码习惯，特地将一部分的通用功能路径固定下来。这些路径包括 api、provider、tool 等。

一般情况下 module 的代码架构如下图：

api

该路径下放 module 内部使用到的所有网络请求路径和方法，一般使用一个类就够了，比如：UserApi：

object UserApi {



    /**

     * 获取个人中心数据

     */

    fun getPersonCenterData(): GetRequest {

        return HttpTool.get(ApiVersion.v1_0_0 + "authUser/myCenter")

    }

}



复制代码

ApiVersion 全局管理目前项目中使用的所有 api 版本，应当定义在 common 组件的 api 路径下：

object ApiVersion {

    const val v1_0_0 = "v1/"

    const val v1_1_0 = "v1_1/"

    const val v1_2_2 = "v1_2_2/"

}



复制代码

entity

该路径下放 module 内部使用到的所有实体类（网络请求返回的数据类）。

对于所有从服务器获取的字段，全部定义在构造函数中，且实体类应当实现 Parcelable ，并使用 @Parcelize 注解。对于客户端使用而自己定义的字段，基本上定义为普通成员字段，并使用 @IgnoredOnParcel 注解，如果需要在界面间传递客户端定义的字段，可以将该字段定义在构造函数中，但是必须注明是客户端定义的字段。

示例如下：

@Parcelize

class ProductEntity(

    // 产品名称

    var name: String = "",



    // 产品图标

    var icon: String = "",



    // 产品数量（客户端定义字段）

    var count: Int = 0

) : Parcelable {

    // 用户是否选择本产品

    @IgnoredOnParcel

    var isSelected = false

}



复制代码

其中 name 和 icon 是从服务器获取的字段，而 count 和 isSelected 是客户端自己定义的字段。

event

该路径下放 module 内部使用的事件相关类。对于使用了 EventBus 及类似框架的项目，放事件类，对于使用了 LiveEventBus 的项目，里面只需要放一个类就好，比如：UserEvent：

object UserEvent {



    /**

     * 更新用户信息成功事件

     */

    val updateUserInfoSuccessEvent: LiveEventBus.Event<Unit>

        get() = LiveEventBus.get("user_update_user_info_success")

}



复制代码

注意：对于使用 LiveEventBus 的项目，事件的命名必须用组件名作为前缀，防止事件名重复。

route

该路径下放 module 内部所使用到的界面路径和跳转方法，一般使用一个类就够了，比如：UserRoute：

object UserRoute {

    // 关于界面

    const val ABOUT = "/user/about"

    // 常见问题（H5）

    private const val FAQ = "FAQ/"



    /**

     * 跳转至关于界面

     */

    fun toAbout(): RouteNavigation {

        return RouteNavigation(ABOUT)

    }



    /**

     * 跳转至常见问题（H5）

     */

    fun toFAQ(): RouteNavigation? {

        return RouteUtil.getServiceProvider(IH5Service::class.java)

            ?.toH5Activity(FAQ)

    }

}



复制代码

注意：对于组件内部会跳转的H5界面链接也应当写在路由类中。

provider

该路径下放对外部 module 提供的服务，一般使用一个类就够了。在 module-api 中是一个接口类，在 module-impl 中是该接口类的实现类。

目前采用 ARouter 作为组件化的框架，为了解耦，对其进行了封装，封装示例代码如下：

typealias Route = com.alibaba.android.arouter.facade.annotation.Route



object RouteUtil {



    fun <T> getServiceProvider(service: Class<out T>): T? {

        return ARouter.getInstance().navigation(service)

    }

}



class RouteNavigation(path: String) {



    private val postcard = ARouter.getInstance().build(path)



    fun param(key: String, value: Int): RouteNavigation {

        postcard.withInt(key, value)

        return this

    }

    ...

}



复制代码

示例

这里介绍如何在外部 module 和 user-impl 跳转至用户组件中的关于界面。

准备工作

在 user-impl 中创建路由类，编写关于界面的路由和服务路由及跳转至关于界面方法：

object UserRoute {

    // 关于界面

    const val ABOUT = "/user/about"

    // 用户组件服务

    const val USER_SERVICE = "/user/service"



    /**

     * 跳转至关于界面

     */

    fun toAbout(): RouteNavigation {

        return RouteNavigation(ABOUT)

    }

}



复制代码

在关于界面使用路由：

@Route(path = UserRoute.ABOUT)

class AboutActivity : MyBaseActivity() {

    ...

}



复制代码

在 user-api 中定义跳转界面方法：

interface IUserService : IServiceProvider {



    /**

     * 跳转至关于界面

     */

    fun toAbout(): RouteNavigation

}



复制代码

在 user-impl 中实现跳转界面方法：

@Route(path = UserRoute.USER_SERVICE)

class UserServiceImpl : IUserService {



    override fun toAbout(): RouteNavigation {

        return UserRoute.toAbout()

    }

}



复制代码

界面跳转

在 user-impl 中可以直接跳转到关于界面：

UserRoute.toAbout().navigation(this)



复制代码

假设 module-a 需要跳转到关于界面，那么先在 module-a 中配置依赖：

dependencies {

    ...

    implementation project(':user-api')

}



复制代码

在 module-a 中使用 provider 跳转到关于界面：

RouteUtil.getServiceProvider(IUserService::class.java)

    ?.toAbout()

    ?.navigation(this)



复制代码

module依赖关系

此时各个 module 的依赖关系如下：

common：基础库、第三方库

user-api：common

user-impl：common、user-api

module-a：common、user-api

App壳：common、user-api、user-impl、module-a、...



复制代码

tool

该路径下放 module 内部使用的工具方法，一般一个类就够了，比如：UserTool：

object UserTool {



    /**

     * 该用户是否是会员

     * @param gradeId 会员等级id

     */

    fun isMembership(gradeId: Int): Boolean {

        return gradeId > 0

    }

}



复制代码

cache

该路径下放 module 使用的缓存方法，一般一个类就够了，比如：UserCache：

object UserCache {



    // 搜索历史记录列表

    var searchHistoryList: ArrayList<String>

        get() {

            val cacheStr = CacheTool.userCache.getString(SEARCH_HISTORY_LIST)

            return if (cacheStr == null) {

                ArrayList()

            } else {

                JsonUtil.parseArray(cacheStr, String::class.java) ?: ArrayList()

            }

        }

        set(value) {

            CacheTool.userCache.put(SEARCH_HISTORY_LIST, JsonUtil.toJson(value))

        }



    // 搜索历史记录列表

    private const val SEARCH_HISTORY_LIST = "user_search_history_list"

}



复制代码

注意：

1. 缓存Key的命名必须用组件名作为前缀，防止缓存Key重复。
2. CacheTool.userCache 并不是指用户组件的缓存，而是用户的缓存，即当前登录账号的缓存，每个账号会单独存一份数据，相互之间没有干扰。与之对应的是 CacheTool.globalCache，全局缓存，所有的账号会共用一份数据。

两种module的区别

module-api 中放的都是外部组件需要的，或者说外部组件和 module-impl 都需要的，其他的都应当放在 module-impl 中，对于外部组件需要的但是能通过 provider 方式提供的，都应当把具体的实现放在 module-impl 中，module-api 中只是放一个接口方法。

下表列举项目开发中哪些东西能否放 module-api 中：

注意：如果仅在 module-impl 中存在工具类，则该工具类命名为 xxTool。如果 module-api 和 module-impl 都存在工具类，则 module-api 中的命名为 xxTool，module-impl 中的命名为 xxTool2。

组件单独调试

在开发过程中，为了查看运行效果，需要运行整个App，比较麻烦，而且可能依赖的其他组件也在开发中，App可能运行不到当前开发的组件。为此可以采用组件单独调试的模式进行开发，减少其他组件的干扰，等开发完成后再切换回 library 的模式。

在组件单独调试模式下，可以增加一些额外的代码来方便开发和调试，比如新增一个入口 Actvity，作为组件单独运行时的第一个界面。

示例

这里介绍在 user-impl 中进行组件单独调试。

在项目根目录下的 gradle.properties 文件中新增变量 isDebugModule，通过该变量控制是否进行组件单独调试：

# 组件单独调试开关，为ture时进行组件单独调试

isDebugModule = false



复制代码

在 user-impl 的 build.gradle 的顶部增加以下代码来控制 user-impl 在 Applicaton 和 Library 之间进行切换：

if (isDebugModule.toBoolean()) {

    apply plugin: 'com.android.application'

} else {

    apply plugin: 'com.android.library'

}



复制代码

在 user-impl 的 src/main 的目录下创建两个文件夹 release 和 debug，release 中放 library 模式下的 AndroidManifest.xml，debug 放 application 模式下的 AndroidManifest.xml、代码和资源，如下图所示：

在 user-impl 的 build.gradle 中配置上面的创建的代码和资源路径：

android {

    ...

    sourceSets {

        if (isDebugModule.toBoolean()) {

            main.manifest.srcFile 'src/main/debug/AndroidManifest.xml'

            main.java.srcDirs += 'src/main/debug'

            main.res.srcDirs += 'src/main/debug'

        } else {

            main.manifest.srcFile 'src/main/release/AndroidManifest.xml'

        }

    }

}



复制代码

注意：完成上述配置后，在 library 模式下，debug 中的代码和资源不会合并到项目中。

最后在 user-impl 的 build.gradle 中配置 applicationId：

android {

    defaultConfig {

        if (isDebugModule.toBoolean()) {

            applicationId "cc.tarylorzhang.demo"

        }

        ...

    }

}



复制代码

注意：如果碰到65536的问题，在 user-impl 的 build.gradle 中新增以下配置：

android {

    defaultConfig {

        ...

        if (isDebugModule.toBoolean()) {

            multiDexEnabled true

        }

    }

}



复制代码

以上工作都完成后，将 isDebugModule 的值改为 true，则可以开始单独调试用户组件。

命名规范

module名

组件名如果是单个单词的，直接使用该单词 + api 或 impl 的后缀作为 module 名，如果是多个单词的，多个单词小写使用 - 字符作为连接符，然后在其基础上加 api 或 impl 的后缀作为 module 名。

示例

用户组件(User)，它的 module 名为 user-api 和 user-impl；会员卡组件(MembershipCard)，它的 module 名为 membership-card-api 和 membership-card-impl。

包名

在应用的 applicationId 的基础上增加组件名后缀作为组件基础包名。

在代码中的包名 module-api 和 module-impl 都直接使用基础包名即可，但是在 Android 中项目 AndroidManifest.xml 文件中的 package 不能重复，否则编译不通过。所以 module-impl 中的 package 使用基础包名，而 module-impl 中的 package 使用基础包名 + api 后缀。

package 重复的时候，会报 Type package.BuildConfig is defined multiple times 的错误。

示例

应用的 applicationId 为 cc.taylorzhang.demo，对于用户组件(user)，组件基础包名为 cc.taylorzhang.demo.user，则实际包名如下表：

对于多单词的会员卡组件(MembershipCard)，其组件基础包名为 cc.taylorzhang.demo.membershipcard。

资源文件和资源变量

所有的资源文件：布局文件、图片等全部要增加组件名作为前缀，所有的资源变量：字符串、颜色等也全部要增加组件名作为前缀，防止资源名重复。

示例

• 用户组件(User)，关于界面布局文件命名为：user_activity_about.xml；
• 用户组件(User)，关于界面标题字符串命名为：user_about_title；
• 会员卡组件(MembershipCard)，会员卡详情界面布局文件，文件名为：membership_card_activity_detail；
• 会员卡组件(MembershipCard)，会员卡详情界面标题字符串，文件名为：membership_card_detail_title；

类名

对于类名没必要增加前缀，比如 UserAboutActivity，因为对资源文件和资源变量增加前缀主要是为了避免重复定义资源导致资源被覆盖的问题，而上面的包名命名规范已经避免了类重复的问题，直接命名 AboutActivity 即可。

全局管理App环境

App 环境一般分为开发、测试和生产环境，不同环境下使用的网络请求地址大概率是不一样的，甚至一些UI都不一样，在打包的时候手动修改很容易有遗漏，产生不必要的 BUG。应当使用 buildConfigField 在打包的时候将当前环境写入 App 中，在代码中根据读取环境变量，根据不同的环境执行不同的操作。

示例

准备工作

在 App 壳 的 build.gradle 中给每个buildType 都配置 APP_ENV：

android {

    ...

    buildTypes {

        debug {

            buildConfigField "String", "APP_ENV", '\"dev\"'

            ...

        }

        release {

            buildConfigField "String", "APP_ENV", '\"release\"'

            ...

        }

        ctest {

            initWith release



            buildConfigField "String", "APP_ENV", '\"test\"'

            matchingFallbacks = ['release']

        }

    }

}



复制代码

注意：测试环境的 buildType 不能使用 test 作为名字，Android Studio 会报 ERROR: BuildType names cannot start with 'test'，这里在 test 前增加了一个 c。

在 common 的 tool 路径下创建一个App环境工具类：

object AppEnvTool {



    /** 开发环境 */

    const val APP_ENV_DEV = "dev"

    /** 测试环境 */

    const val APP_ENV_TEST = "test"

    /** 生产环境 */

    const val APP_ENV_RELEASE = "release"



    /** 当前App环境，默认为开发环境 */

    private var curAppEnv = APP_ENV_DEV



    fun init(env: String) {

        curAppEnv = env

    }



    /** 当前是否处于开发环境 */

    val isDev: Boolean

        get() = curAppEnv == APP_ENV_DEV



    /** 当前是否处于测试环境 */

    val isTest: Boolean

        get() = curAppEnv == APP_ENV_TEST



    /** 当前是否处于生产环境 */

    val isRelease: Boolean

        get() = curAppEnv == APP_ENV_RELEASE



}



复制代码

在 Application 中初始化App环境工具类：

class DemoApplication : Application() {



    override fun onCreate() {

        super.onCreate()



        // 初始化App环境工具类

        AppEnvTool.init(BuildConfig.APP_ENV)

        ...

    }

}



复制代码

使用App环境工具类

这里介绍根据App环境使用不同的网络请求地址：

object CommonApi {



    // api开发环境地址

    private const val API_DEV_URL = "https://demodev.taylorzhang.cc/api/"

    // api测试环境地址

    private const val API_TEST_URL = "https://demotest.taylorzhang.cc/api/"

    // api生产环境地址

    private const val API_RELEASE_URL = "https://demo.taylorzhang.cc/api/"

    // api地址

    val API_URL = getUrlByEnv(API_DEV_URL, API_TEST_URL, API_RELEASE_URL)



    // H5开发环境地址

    private const val H5_DEV_URL = "https://demodev.taylorzhang.cc/m/"

    // H5测试环境地址

    private const val H5_TEST_URL = "https://demotest.taylorzhang.cc/m/"

    // H5生产环境地址

    private const val H5_RELEASE_URL = "https://demo.taylorzhang.cc/m/"

    // H5地址

    val H5_URL = getUrlByEnv(H5_DEV_URL, H5_TEST_URL, H5_RELEASE_URL)



    private fun getUrlByEnv(devUrl: String, testUrl: String, releaseUrl: String): String {

        return when {

            AppEnvTool.isDev -> devUrl

            AppEnvTool.isTest -> testUrl

            else -> releaseUrl

        }

    }

}



复制代码

打包

通过不同的命令打包，打出对应的App环境包：

# 打开发环境包

./gradlew clean assembleDebug



# 打测试环境包

./gradlew clean assembleCtest



# 打生产环境包

./gradlew clean assembleRelease



复制代码

全局管理版本信息

项目中的 module 变多之后，如果要修改第三方库和App使用的SDK版本是一件很蛋疼的事情。应当建立一个配置文件进行管理，其他地方使用配置文件中设置的版本。

示例

在项目根目录下创建一个配置文件 config.gradle，里面放版本信息：

ext {

    compile_sdk_version = 28

    min_sdk_version = 17

    target_sdk_version = 28



    arouter_compiler_version = '1.2.2'

}



复制代码

在项目根目录下的 build.gradle 文件中的最上方使用以下代码引入配置文件：

apply from: "config.gradle"



复制代码

创建 module 后，修改该 module 中的 build.gradle 文件，将 SDK 版本默认值换成配置文件中的变量，按需添加第三方依赖，并使用 $ + 配置文件中的变量作为第三方库的版本：

android {

    ...

    compileSdkVersion compile_sdk_version



    defaultConfig {

        ...

        minSdkVersion min_sdk_version

        targetSdkVersion target_sdk_version

    }

}



dependencies {

    ...

    kapt "com.alibaba:arouter-compiler:$arouter_compiler_version"

}



复制代码

混淆

混淆文件不应该在 App 壳中集中定义，应当在每个 module 中各自定义自己的混淆。

示例

这里介绍配置 user-impl 的混淆，先在 user-impl 的 build.gradle 中配置消费者混淆文件：

android {

    defaultConfig {

        ...

        consumerProguardFiles 'proguard-rules.pro'

    }

}



复制代码

在 proguard-rules.pro 文件中写入该 module 的混淆：

# 实体类

-keepclassmembers class cc.taylorzhang.demo.user.entity.** { *; }



复制代码

总结

组件化开发应当遵守"高内聚，低耦合"的原则，尽量少的对外暴露细节。如果用一句话来总结的话，就是代码和资源能放 module-impl 里面的就都放在 module-impl，因为代码隔离问题实在不能放 module-impl 里面的才放 module-api，最后因为涉及到循环依赖问题的才往 common 中放。

本案例是我本人遇到的真实案例，因查找原因的过程一度让我崩溃，我相信不少人也遇到过相同的问题，故将其记录下来，希望对大家有帮助，本案例使用RxHttp 2.6.4 + OkHttp 4.9.1版本，当然，如果你使用Retrofit等其它基于OkHttp封装的框架，且用到监听上传进度功能，那么很大概率你也会遇到这个问题，请耐心看完，如果你想直接看到结果，划到文章末尾即可。

2、问题描述

事情是这样的，有一段文件上传的代码，如下：

fun uploadFiles(fileList: List<File>) {

    RxHttp.postForm("/server/...")     

        .add("key", "value")           

        .addFiles("files", fileList)   

        .upload {                       

            //上传进度回调                   

        }                              

        .asString()                    

        .subscribe({                    

            //成功回调                     

        }, {                            

            //失败回调                     

        })                             

}                                                                                  

 

这段代码在写完后很长一段时间内都是ok的，突然有一天，执行这段代码居然报错了，日志如下：

 这个异常是100%出现的，很熟悉的异常，具体原因就是，数据流被关闭了，但依然往里面写数据，来看看最后抛异常的地方，如下：

 可以看到，方法里面第一行代码就判断数据流是否已关闭，是的话，抛出异常。

注：如果你是RxHttp使用者，正在尝试这段代码，发现没问题，也不要惊讶，因为这需要在Android Studio特定场景下执行才会出现，而且是相对高频使用的场景，请待我一步步揭晓答案

3、一探究竟

本着出现问题，先定位到自己代码的原则，打开ProgressRequestBody类76行看看，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    private BufferedSink bufferedSink;

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        if (bufferedSink == null) {

            bufferedSink = Okio.buffer(sink(sink));

        }

        requestBody.writeTo(bufferedSink);   //这里是76行

        bufferedSink.flush();

    }

}

 

ProgressRequestBody继承了okhttp3.RequestBody类，作用是监听上传进度；显然最后执行到这里时，数据流已经被关闭了，从日志里可以看到，最后一次调用ProgressRequestBody#writeTo(BufferedSink)方法的地方在CallServerInterceptor拦截器的59行，打开看看

class CallServerInterceptor(private val forWebSocket: Boolean) : Interceptor {



    //省略相关代码 

    @Throws(IOException::class)

    override fun intercept(chain: Interceptor.Chain): Response {

        //省略相关代码

        if (responseBuilder == null) {

            if (requestBody.isDuplex()) {

              exchange.flushRequest()

              val bufferedRequestBody = exchange.createRequestBody(request, true).buffer()

              requestBody.writeTo(bufferedRequestBody)

            } else {

              val bufferedRequestBody = exchange.createRequestBody(request, false).buffer()

              requestBody.writeTo(bufferedRequestBody)  //这里是59行

              bufferedRequestBody.close()         //数据写完，将数据流关闭

            }

        }

    }

}

 

熟悉OkHttp原理的同学应该知道，CallServerInterceptor拦截器是okhttp拦截器链的最后一个拦截器，将客户端数据写出到服务端，就是在这里实现的，也就是59行，那问题就来了，数据都还没写出去，数据流怎么就关闭了呢？这令我百思不得其解，毫无头绪。

于是乎，我做了很多无用功，如：重新检查代码，看看是否有手动关闭数据流的地方，显然没有找到；接着，实在没有办法，代码回滚，回滚到最初写这段代码的版本，我满怀期待的以为，这下应该没问题了，可尝试过后，依旧报java.lang.IllegalStateException: closed，成年人的崩溃就在这一瞬间，我陷入了绝境，已经消耗5个小时在这个问题上，此时已晚上23：30，看来又是一个不眠夜。

习惯告诉我，一个问题很久没查出来，可以先放弃，好吧，拔手机关电脑，洗澡睡觉。

半小时后，我躺在床上，很难受，于是我拿出手机，打开app，再试了试上传功能，惊奇的发现，可以了，上传成功了，这。。。。一脸懵逼，我找谁说理去，虽然没问题了，但问题没找到，作为一名初级程序员，这我无法接受。

精神的力量把我从床上扶了起来，再次打开电脑，连上手机，这次，果然有了新的收获，也一下子刷新了我的世界观；当我再次打开app，尝试上传文件时，一样的错误出现在我眼前，What??? 刚才还好好的，连上电脑就不行了？

ok，我彻底没脾气了，拔掉手机，重启app，再试，没问题了，再次连上电脑，再试，问题又出来了。。

此时，我的心态有了些许的好转，毕竟有了新的调查方向，我再次查看错误日志，发现了一个很奇怪的地方，如下：

com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor是从哪冒出来的？在我的认知里，OkHttp3是没有这个拦截器的，为了验证我的认知，再次查看okhttp3源码，如下：

确定是没有添加这个拦截器的，仔细看日志发现，OkHttp3Interceptor在CallServerInterceptor、ConnectInterceptor之间执行的，那就只有一个解释，OkHttp3Interceptor是通过addNetworkInterceptor方法添加，现在就好办了，全局搜索addNetworkInterceptor就知道是谁添加的，哪里添加的，很可惜，未找到调用此方法的源码，似乎又陷入了绝境。

那就只能开启调试，看看OkHttp3Interceptor是否在OkHttpClient对象的networkInterceptors网络拦截器列表里，一调试，果然有发现，如下：

 调试点击下一步，神奇的事情就发生了，如下：

这怎么解释？networkInterceptors.size始终是0，interceptors.size是如何加1变为5的？再来看看，加的1是什么，如下：

很熟悉，就是我们之前提到的OkHttp3Interceptor，这是如何做到的？只有一个解释，OkHttpClient#networkInterceptors()方法被字节码插桩技术插入了新的代码，为了验证我的想法，我做了以下实验：

可以看到，我直接new了一个OkHttpClient对象，啥也没配置，调用networkInterceptors()方法，就获取了OkHttp3Interceptor拦截器，但OkHttpClient对象里的networkInterceptors列表中是没有这个拦截器的，这就证实了我的想法。

那现在的问题就是，OkHttp3Interceptor是谁注入的？跟文件上传失败是否有直接的关系？

OkHttp3Interceptor是谁注入的？

先来探索第一个问题，通过OkHttp3Interceptor类的包名class com.android.tools.profiler.agent.okhttp，我有以下3点猜测

• 包名有com.android.tools,应该跟 Android 官方有关系

• 包名有agent,又是拦截器，应该跟网络代理，也就是网络监控有关

• 最后一点，也是最重要的，包名有profiler，这让我联想到了Android Studio(以下简称AS)里Profiler网络分析器

果然，在Google的源码中，真找到了OkHttp3Interceptor类，看看相关代码：

public final class OkHttp3Interceptor implements Interceptor {



    //省略相关代码

    @Override

    public Response intercept(Interceptor.Chain chain) throws IOException {

        Request request = chain.request();

        HttpConnectionTracker tracker = null;

        try {

            tracker = trackRequest(request);  //1、追踪请求体

        } catch (Exception ex) {

            StudioLog.e("Could not track an OkHttp3 request", ex);

        }

        Response response;

        try {

            response = chain.proceed(request);

        } catch (IOException ex) {

            

        }

        try {

            if (tracker != null) {

                response = trackResponse(tracker, response);  //2、追踪响应体

            }

        } catch (Exception ex) {

            StudioLog.e("Could not track an OkHttp3 response", ex);

        } 

        return response;

    }

 

可以确定它就是一个网络监控器，但它是不是AS的网络监听器，我却还持怀疑态度，因为我这个项目没开启Profiler分析器，但我最近在开发room数据库相关功能，开启了数据分析器Database Inspector，难道跟这个有关？我尝试关掉Database Inspector，并且重启app，再次尝试文件上传，居然成功了，是真的成功了，你能信？我也不信，于是，再次开启Database Inspector，再次尝试文件上传，失败了，异常跟之前的一模一样；接着，我关闭Database Inspector，并且打开Profiler分析器，再次尝试文件上传，一样失败了。

我想到这里，基本可以认定OkHttp3Interceptor就是Profiler里面的网络监控器，但也好像缺乏直接证据，于是，我尝试改了下ProgressRequestBody类，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    private BufferedSink bufferedSink;

    

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        //如果调用方是OkHttp3Interceptor，不写请求体，直接返回

        if (sink.toString().contains(

            "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker"))

            return;

        if (bufferedSink == null) {

            bufferedSink = Okio.buffer(sink(sink));

        }

        requestBody.writeTo(bufferedSink);  

        bufferedSink.flush();

    }

}

 

以上代码，仅仅加了一句if语句，这条语句可以判断当前调用方是不是OkHttp3Interceptor，是的话，不写请求体，直接返回；如果OkHttp3Interceptor就是Profiler里的网络监控器，那么此时Profiler里应该是看不到请求体的，也就是看不到请求参数，如下：

可以看到，Profiler里的网络监控器，没有监控到请求参数。

这就证实了OkHttp3Interceptor的确是Profiler里的网络监控器，也就是AS动态注入的。

OkHttp3Interceptor 与文件上传是否有直接的关系？

通过上面的案例分析，显然是有直接关系的，当你未打开Database Inspector、Profiler时，文件上传一切正常。

OkHttp3Interceptor是如何影响文件上传的？

回到正题，OkHttp3Interceptor是如何影响文件上传的？这个就需要继续分析OkHttp3Interceptor的源码，来看看追踪请求体的代码：

public final class OkHttp3Interceptor implements Interceptor {



    private HttpConnectionTracker trackRequest(Request request) throws IOException {

        StackTraceElement[] callstack =

                OkHttpUtils.getCallstack(request.getClass().getPackage().getName());

        HttpConnectionTracker tracker =

                HttpTracker.trackConnection(request.url().toString(), callstack);

        tracker.trackRequest(request.method(), toMultimap(request.headers()));

        if (request.body() != null) {

            OutputStream outputStream =

                    tracker.trackRequestBody(OkHttpUtils.createNullOutputStream());

            BufferedSink bufferedSink = Okio.buffer(Okio.sink(outputStream));

            request.body().writeTo(bufferedSink);  // 1、将请求体写入到BufferedSink中

            bufferedSink.close();                  // 2、关闭BufferedSink

        }

        return tracker;

    }



}

 

想到这里问题就很清楚了，上面备注的第一代码中request.body()，拿到的就是ProgressRequestBody对象，随后调用其writeTo(BufferedSink)方法，传入BufferedSink对象，方法执行完，就将BufferedSink对象关闭了，然而，ProgressRequestBody里却将BufferedSink声明为成员变量，并且为空时才会赋值，这就导致后续CallServerInterceptor调用其writeTo(BufferedSink)方法时，使用的还是上一个已关闭的BufferedSink对象，此时再往里面写数据，自然就java.lang.IllegalStateException: closed异常了。

4、如何解决

知道了具体的原因，就好解决，将ProgressRequestBody里面的BufferedSink对象改为局部变量即可，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        BufferedSink bufferedSink = Okio.buffer(sink(sink));

        requestBody.writeTo(bufferedSink);  

        bufferedSink.colse();

    }

}

 

改完后，开启Profiler里的网络监控器，再次尝试文件上传，ok成功了，但又有一个新的问题，ProgressRequestBody是用于监听上传进度的，OkHttp3Interceptor、CallServerInterceptor先后调用了其writeTo(BufferedSink)方法，这就会导致请求体写两次，也就是进度监听会收到两遍，而我们真正需要的是CallServerInterceptor调用的那次，咋整？好办，我们前面就判断过调用方是否OkHttp3Interceptor

于是，做出如下更改：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是OkHttp3Interceptor，直接写请求体，不再通过包装类来处理请求进度

        if (sink.toString().contains(

        "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker")) {

            requestBody.writeTo(bufferedSink);  

        } else {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        }

    }

}

 

你以为这样就完了？相信很多人都会用到com.squareup.okhttp3:logging-interceptor日志拦截器，当你添加该日志拦截器后，再次上传文件，会发现，进度回调又执行了两遍，为啥？因为该日志拦截器，也会调用ProgressRequestBody#writeTo(BufferedSink)方法，看看代码：

//省略部分代码

class HttpLoggingInterceptor @JvmOverloads constructor(

  private val logger: Logger = Logger.DEFAULT

) : Interceptor {



  @Throws(IOException::class)

  override fun intercept(chain: Interceptor.Chain): Response {

    val request = chain.request()

    val requestBody = request.body



    if (logHeaders) {

      if (!logBody || requestBody == null) {

        logger.log("--> END ${request.method}")

      } else if (bodyHasUnknownEncoding(request.headers)) {

        logger.log("--> END ${request.method} (encoded body omitted)")

      } else if (requestBody.isDuplex()) {

        logger.log("--> END ${request.method} (duplex request body omitted)")

      } else if (requestBody.isOneShot()) {

        logger.log("--> END ${request.method} (one-shot body omitted)")

      } else {

        val buffer = Buffer()

        //1、这里调用了RequestBody的writeTo方法，并传入了Buffer对象

        requestBody.writeTo(buffer)  

      }

    }



    val response: Response

    try {

      response = chain.proceed(request)

    } catch (e: Exception) {

      throw e

    }

    return response

  }



}

 

可以看到，HttpLoggingInterceptor内部也会调用RequestBody#writeTo方法，并传入Buffer对象，到这，我们就好办了，在ProgressRequestBody类增加一个Buffer的判断逻辑即可，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是OkHttp3Interceptor，或者传入的是Buffer对象，直接写请求体，不再通过包装类来处理请求进度

        if (sink instanceof Buffer

            || sink.toString().contains(

            "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker")) {

            requestBody.writeTo(bufferedSink);  

        } else {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        }

    }

}

 

这样就完了？也不见得，如果后续又遇到什么拦截器调用其writeTo方法，还是会出现进度回调执行两遍的情况，只能在遇到这种情况时，加入对应的判断逻辑

到这，也许有人会问，为啥不直接判断调用方是不是CallServerInterceptor，是的话监听进度回调，否则，直接写入请求体。想法很好，也是可行的，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是CallServerInterceptor，监听上传进度

        if (sink.toString().contains("RequestBodySink(okhttp3.internal")) {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        } else {

            requestBody.writeTo(bufferedSink);  

        }

    }

}

 

但是该方案有个致命的缺陷，如果okhttp未来版本更改了目录结构，ProgressRequestBody类就完全失效。

两个方案就由大家自己去选择，这里给出ProgressRequestBody完整源码，需要自取

5、小结

本案例上传失败的直接原因就是在AS开启了Database Inspector数据库分析器或Profiler网络监控器时，AS就会通过字节码插桩技术，对OkHttpClient#networkInterceptors()方法注入新的字节码，使其多返回一个com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor拦截器(用于监听网络)，该拦截器会调用ProgressRequestBody#writeTo(BufferedSink)方法，并传入BufferedSink对象，writeTo方法执行完毕后，立即将BufferedSink对象关闭，在随后的CallServerInterceptor拦截又调用ProgressRequestBody#writeTo(BufferedSink)方法往已关闭的BufferedSink对象写数据，最终导致java.lang.IllegalStateException: closed异常。

二、logos语法

logos语法分为3类。

2.1、Block level

这一类型的指令会开辟一个代码块，以%end结束。

%group

用来将代码分组。开发中hook代码会很多，这样方便管理Logos代码。所有的group都必须初始化，否则编译报错。

#import <UIKit/UIKit.h>



%group group1



%hook RichTextView



- (_Bool)setPrefixContent:(id)arg1 TargetContent:(NSString *)arg2 TargetParserString:(id)arg3 SuffixContent:(id)arg4 {

    //hook后要处理的方式1

    return %orig;

}



%end



%end





%group group2



%hook RichTextView



- (_Bool)setPrefixContent:(id)arg1 TargetContent:(NSString *)arg2 TargetParserString:(id)arg3 SuffixContent:(id)arg4 {

    //hook后要处理的方式2

    return %orig;

}



%end



%end



%group group3



%hook RichTextView



- (_Bool)setPrefixContent:(id)arg1 TargetContent:(NSString *)arg2 TargetParserString:(id)arg3 SuffixContent:(id)arg4 {

    //hook后要处理的方式3

    return %orig;

}



%end



%end



//使用group要配合ctor

%ctor {

    //[[UIDevice currentDevice] systemVersion].doubleValue 可以用来判断版本或其它逻辑。

    if ([[UIDevice currentDevice] systemVersion].doubleValue >= 11.0) {

        //这里group3会覆盖group1，不会执行group1逻辑。

        %init(group1)%init(group3);

    } else {

        %init(group2);

    }

}

%subclass

%subclass Classname: Superclass <Protocol list>

运行时创建子类，只能包含方法或者关联属性，不能包含属性。可以通过%c创建类实例。

#import <UIKit/UIKit.h>



@interface MyObject



- (void)setSomeValue:(id)value;



@end



%subclass MyObject : NSObject



- (id)init {

    self = %orig;

    [self setSomeValue:@"value"];

    return self;

}



%new

- (id)someValue {

    return objc_getAssociatedObject(self, @selector(someValue));

}



%new

- (void)setSomeValue:(id)value {

    objc_setAssociatedObject(self, @selector(someValue), value, OBJC_ASSOCIATION_RETAIN_NONATOMIC);

}



%end

%property

%property (nonatomic|assign|retain|copy|weak|strong|getter|setter) Type name;

为subclass或者hook的类添加属性。必须在 %subclass 或%hook中。

%property(nonatomic,assign) NSInteger age;

%end

与其它命令配对出现。

2.2、Top level

TopLevel指令不放在BlockLevel中。

%config

%config(Key=Value);

为logos设置标记。

Configuration Flags

%config(generator=internal);

%config(warnings=error);

%config(dump=yaml);

%hookf(rtype, symbolName, args...) { … }

FILE *fopen(const char *path, const char *mode);

%hookf(FILE *, fopen, const char *path, const char *mode) {

    NSLog(@"Hey, we're hooking fopen to deny relative paths!");

    if (path[0] != '/') {

        return NULL;

    }

    return %orig;

}

%class Class;

//只是为了声明编译通过

@interface MainViewController



+ (void)HP_classMethod;



@end

 

 

%hook MainViewController



%new

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {

    //方式一

//    [self.class HP_classMethod];

    //方式二

//    [NSClassFromString(@"MainViewController") HP_classMethod];

    //方式三

    [%c(MainViewController) HP_classMethod];

}



%new

+ (void)HP_classMethod {

    NSLog(@"HP_classMethod");

}



%end

%hook RichTextView



- (_Bool)setPrefixContent:(id)arg1 TargetContent:(NSString *)arg2 TargetParserString:(id)arg3 SuffixContent:(id)arg4 {

    //传递参数&接收返回值。

    BOOL result1 = %orig(arg1,arg2,arg3,arg4);

    BOOL result2 = %orig;

    return %orig;

}



%end

%hook RichTextView



- (_Bool)setPrefixContent:(id)arg1 TargetContent:(NSString *)arg2 TargetParserString:(id)arg3 SuffixContent:(id)arg4 {

    %log;

    return %orig;

}



%end

 WeChat[11309:6708938] -[<RichTextView: 0x15c4c9720> setPrefixContent:(null) TargetContent:钱已经借给你了。 TargetParserString:<contentMD5>0399062cd62208dad884224feae2aa30</contentMD5><fontsize>20.287109</fontsize><fwidth>240.000000</fwidth><parser><type>1</type><range>{0, 8}</range><info><![CDATA[<style><range>{0, 8}</range><rect>{{0, 0}, {135, 21}}</rect></style>]]></info></parser> SuffixContent:(null)]

能够输出详细的日志信息，包含类、方法、参数、以及控件信息等详细信息。

1.1 SSH

SSH是一种网络协议，用于计算机之间的加密登录。
1995年，芬兰学者Tatu Ylonen设计了SSH协议，将登录信息全部加密，成为互联网安全的一个基本解决方案，迅速在全世界获得推广，目前已经成为Linux系统的标准配置。

1.2 OpenSSH

OpenSSH 是 SSH （Secure SHell） 协议的免费开源实现。它是一款软件，应用非常广泛。SSH协议可以用来进行远程控制， 或在计算机之间传送文件。

1.2.1 OpenSSH插件安装

通过OpenSSH插件可以连接手机，进行远程控制， 或者传送文件。以cydia为例，需要在软件源中添加源：

这两个源比较有名，推荐添加。

• 软件源可以理解为服务器，存放了插件安装包。

然后在搜索中搜索OpenSSH，认准来自apt.bingner.com。当然直接添加这个源也可以。

1.3 SSH登录过程

1. 电脑（客户端）请求连接手机(ip:22)。
2. 手机（服务端）将公钥发送给mac电脑。

1.4 中间人攻击(Man-in-the-middle attack)

上面的登录方式存在一种隐患。如果有人 冒充服务器 将生成的 虚假公钥 发给客户端，那么它将获得客户端连接服务器的 密码。