多模块中application的初始化方式

碎碎念

项目在多模块的过程中，出现一个比较烦躁的问题。那就是模块内，需要在application中初始化后，调用自己模块的一些代码。可能这样解释会比较抽象。举个例子吧~

现在的项目结构是这样的

image.png

假设需要在Applicaion的onCreate方法被调用后，调用ShopModule中的一些初始化方法。这样我们就面临着一些问题

1. 如何通知ShopModule模块Application的onCreate被调用了
2. 如何收集各个模块中的特定对象然后进行操作。
3. 能否控制优先级别。 比如一些模块可能需要早点初始化
4. 能否集中管理线程。 有一些模块可能需要异步初始化

BootStrap 使用方式

1. 导入相关依赖

    implementation 'com.balala.bootstrap:bootstrap-core:1.0.3'
    annotationProcessor 'com.balala.bootstrap:bootstrap-compiler:1.0.3'

2. 编写相关逻辑代码

@BootStrapApp(priority = 100, name = "RouterBootStrap",isMainThread = true)
public class RouterBootStrap extends BootStrapProxy {
    @Override
    public void onCreate(Application application) {
        if (application instanceof CommonApplication) {
            CommonApplication commonApplication = (CommonApplication) application;
            if (commonApplication.enableDebug()) {
                ARouter.openLog();
                ARouter.openDebug();
                ARouter.printStackTrace();
            }
        }
        ARouter.init(application);
    }
}

这样的话，你所编写的RouterBootStrap就会在APP启动的时候就会自动调用了onCreate方法。可以看到这里还可以配置运行的优先级和是否在主线程运行。

1. 优先级配置的越大，越早运行。
2. 线程默认是在主线程中运行。

BootStrap 背后的故事

很多时候，并不想造轮子。只是有一些处理方式，在尝试后感觉处理方式不是特别的好。然后在慢慢的尝试的过程中，发现自己对处理这类问题也有了一些心得。所以就尝试的来用自己的方式，去处理问题。

下面是我们的几种尝试：

1. ARouter 的处理方式

我们项目中使用的是阿里的ARouter的路由框架，在使用的过程中，我们发现了一个对象，可以当做模块之间的通信方式（IProvider），我们借助这个对象来完成上述的需求。

首先是对IProvider进行封装，因为项目中不仅仅使用这个来进行初始化，而且使用他用来模块之间的通讯

//异步模块同步的方式
public interface MProviderSyn extends IProvider {


    /**
     * 模块之前交互通过的接口
     *
     * @param context 上下文对象
     * @param param 需要传递到模块间的参数
     * @return 模块需要返回的参数
     */
    public Map<String, String> doExecute(Context context, Map<String, String> param);


}

然后我们就可以在需要初始化的模块来实现这个接口。

@Route(path = "/user/init")
public class UserModuleProvider implements MProviderSyn {
    @Override
    public Map<String, String> doExecute(Context context, Map<String, String> param) {
        return null;
    }

    @Override
    public void init(Context context) {
        Toast.makeText(context, "userInit", Toast.LENGTH_LONG).show();
    }
}

这样的话，我们就可以在Application初始化的时候，来初始化UserModuleProvider这个对象，从而达到上面的需求。

  MProviderManager.getProvider("/user/init");

在项目的使用过程中会慢慢的发现，这样的方式还会存在有一些问题

1. Application 还是会对一些模块具有感知。 因为还是需要在Application中的onCreate的方法，来初始化一些模块对象。而这些模块对象是可变的（当删除一个初始化对象，就需要进行更改），所以Application里面的方法会经常改动。
2. 因为借助路由框架，这样就造成了一些组件库（不依赖于路由框架）不能使用这种模式。

就这样，我们开始尝试的去寻找其他方式。

2. ContentProvider 的处理方式

ContentProvider 的方式，是无意间想知道AndroidUtilsCode在什么时候，保存application对象所知道的。

    public static final class FileProvider4UtilCode extends FileProvider {

        @Override
        public boolean onCreate() {
            Utils.init(getContext());
            return true;
        }
    }

可以知道，当应用一启动的时候，ContentProvider的onCreate的方法就会被调用。但是它会比Application的onCreate的调用时机晚。这个时候已经可以获取到Context对象了。而一些模块仅仅需要获取到上下文对象。所以在这个时候调用可以满足大部分模块的需求。而且可以解决上述ARouter存在的问题。

public class PermissionProvider extends ContentProvider {
    @Override
    public boolean onCreate() {
        Application application = (Application) Objects.requireNonNull(getContext()).getApplicationContext();
        SoulPermission.init(application);
        return false;
    }

    @Nullable
    @Override
    public Cursor query(@NonNull Uri uri, @Nullable String[] projection, @Nullable String selection, @Nullable String[] selectionArgs, @Nullable String sortOrder) {
        return null;
    }

    @Nullable
    @Override
    public String getType(@NonNull Uri uri) {
        return null;
    }

    @Nullable
    @Override
    public Uri insert(@NonNull Uri uri, @Nullable ContentValues values) {
        return null;
    }

    @Override
    public int delete(@NonNull Uri uri, @Nullable String selection, @Nullable String[] selectionArgs) {
        return 0;
    }

    @Override
    public int update(@NonNull Uri uri, @Nullable ContentValues values, @Nullable String selection, @Nullable String[] selectionArgs) {
        return 0;
    }
}

我们开始尝试着新的写法一段时间后，又发现了几个问题。

1. 需要操作的步骤太多了，而且需要配置AndroidManifest.xml
2. 不能控制优先级别。 比如一些模块可能需要早点初始化
3. 不能集中管理线程。 有一些模块可能需要异步初始化。

于是，我们开始尝试整合上述的问题和解决方案，尝试着开发出一套新的解决方案。

BootStrap 创建

BootStrap 创建的初衷就是为了处理多模块间Application初始化比较繁琐。那么如何收集每个模块需要初始化的对象呢？我们这里使用的是APT。使用APT将各个模块需要初始化的对象整合在一起。

image.png

上图是一个规划图，我们希望每个模块可以使用特定注解(BootStrapApp)，然后将带有特定注解(BootStrapApp)的类收集在一起，最后可以在Application初始化的地方。将我们收集的各个模块的类的信息。通过反射进行统一的调用。

1. 需要处理的问题

在收集各个模块带有注解的类的时候，发现各个模块之间会生成相同包名和类名的java文件。这样就无法收集各个模块中带有特定注解(BootStrapApp)。我们开始尝试查看ARouter是如何处理这样的问题。发现它在初始化话的过程中会去扫描dex文件，然后去获取特定的类文件（APT生成的文件，都实现一个特定的接口，然后根据这个接口，查找实现类）。

在获知这种实现方式的时候，我们并不是特别赞同这种方式

1. 扫描dex非常耗时。
2. 存在有ClassLoader的加载时机的问题。
3. 一些手机厂商认为对dex文件扫描是一种不安全的操作。
4. 加固的问题

之后，我们又发现了一个处理方式，那就是使用gradle插件。在Transform的时候，对特定的java文件进行整合。但是这样的话，会增加插件的配置成本。而且插件开发并不是我们所熟悉的领域

最后，我们尝试着不让apt生成java文件，而是直接生成一个json文件。然后将json文件放到assets目录中，这样也完成了对特定类的收集。打包完成后的assets文件夹

image.png

2. BootStrap 的使用

当我们处理完APT的问题后，我们来尝试的解决上述存在的问题：

1. 模块之间的耦合性很大
2. 不能控制优先级别。 比如一些模块可能需要早点初始化
3. 不能集中管理线程。 有一些模块可能需要异步初始化。
4. 需要操作的步骤太多了，而且需要配置AndroidManifest.xml

在处理问题2,3的时候，我们在注解上多加了一些属性，来标记它的运行特征

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface BootStrapApp {


    /**
     * 默认名称
     *
     * @return 相关名称
     */
    String name() default "";

    /**
     * 组信息
     *
     * @return 配置组信息
     */
    String group() default "application";


    /**
     * 初始化顺序，优先级越高，越早初始化
     *
     * @return 优先级
     */
    int priority() default -1;


    /***
     * 是否在主线程中运行
     * @return 默认运行在主线程中
     */
    boolean isMainThread() default true;

}

当我们增加了一些特定的属性，意味着我们可以在逻辑代码中，根据注解的属性。运行相应的逻辑。（比如说是否运行在主线程，又或者优先级）。

    //执行方法,主函数
    for (BootStrapAppModel model : mainThreadExecute) {
        executeMethod(model.bootstrapWrapApplication, args);
    }
    
    //执行方法，异步函数
    new AppExecutors().diskIO().execute(() -> {
        for (BootStrapAppModel model : runnableExecute) {
            executeMethod(model.bootstrapWrapApplication, args);
        }
    });

在处理完问题2,3的时候，让我们处理问题
1. 模块之间的耦合性很大
4. 需要操作的步骤太多了，而且需要配置AndroidManifest.xml

因为使用APT来收集特定类的信息，然后统一对特定的类进行处理。这就意味着模块之间的耦合程度就大大的减少了。那像问题1的问题就不存在了。而问题4是因为之前没有统一管理。现在我们只要定义出模块内部的ContentProvider。这样就可以初始换applicaiton方法了。而这部分逻辑已经在模块内部实现。对于开发者完全透明的。开发者只需要编写相关实现即可。

public class BootStrapProvider extends ContentProvider {
    @Override
    public boolean onCreate() {
        Application application = (Application) Objects.requireNonNull(getContext()).getApplicationContext();
        BootStrapUtils.init(application);
        BootStrapApplicationCore.invokeApplicaitonOnCreate(application);
        return false;
    }


    @Override
    public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
        return null;
    }


    @Override
    public String getType(Uri uri) {
        return null;
    }


    @Override
    public Uri insert(Uri uri, ContentValues values) {
        return null;
    }

    @Override
    public int delete(Uri uri, String selection, String[] selectionArgs) {
        return 0;
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
        return 0;
    }
}

3. BootStrap 中组的概念

在编写APT插件的时候，我们会解析group字段来作为索引的标识，并且将它缓存到内存中。BootStrap内部会维护相关组的信息和实例。

image.png

只用当你手动调用

    BootStrap.invokeGroupMethod("exit", this);
    BootStrap.findListForGroupMain("exit");

这些有关组的操作的时候，这些组的实例才会被创建。而当我们使用BootStrapApp注解的时候，并不需要去指定特定的组信息。因为BootStrapApp默认的组就是application，而且会在APP启动的时候，自动初始化application这个组的相关实例，并且调用方法。

那么为什么我们需要知道组的概念吗？假设我们在APP退出的时候，需要告诉其他模块进行一些退出操作，这个时候，组的概念就非常有必要了。我们可以在其他模块中完成退出所需要的逻辑，然后将它们归类为exit的组。在真正的退出模块中，只需要调用

 BootStrap.invokeGroupMethod("exit", this);

这样框架内部，就会帮你去寻找该组下的所以实例，然后调用其方法。

相关链接

1. https://github.com/BelongsH/BootStrap
2. https://juejin.im/post/5dd3bbf0f265da0c03540672 （APT相关学习）