Android插件化进阶——Atlas 源码分析（一）

这两天项目上要做 MVVM 和 DataBinding 的重构，所以插件化的文章就停了几天，后面会分享一下关于 MVVM 架构封装相关的文章。这篇文章我准备作为我插件化系列文章的最终章，我将分析目前最成熟最强大的插件化框架 Atlas 的一些基本流程的源码，以后如果有机会作更深入的研究，再进行插件化系列的更新。

Atlas 是手淘以及一系列阿里系 App 的插件化方案，实际上它又和其他插件化框架有一些区别，说的严谨点应该是一个容器化框架或者动态组件化框架，为什么这样说，后面会讲到。

Atlas 功能非常强大，技术也非常成熟，背后有阿里的一支技术实力非常强劲的团队在维护，刚开始学习 Atlas 的时候，我发现它官方的文档写的不是特别详细，导致一些配置我花了很多时间也没有完全搞明白，所以开始的印象不是很好。但自从我看过了官方的 Gitbook 源码文档后，我对 Atlas 团队的印象就彻底改观了，可以说，Gitbook 文档写的非常详细，而且逻辑清晰，实际上大家完全可以通过研读官方的源码文档，就可以对 Atlas 的整体启动流程和插件加载流程比较清楚了。

具体 Atlas 功能范围以及和一些常用插件化框架的对比，可以看我之前的文章。

Gitbook 的地址

要看这个文档，需要先把 atlas 从 Githud clone 下来，然后进入atlas-docs目录，在终端输入

gitbook serve

最后在浏览器输入http://localhost:4000即可进入 Gitbook 观看文档，当然提前你得配置下 Gitbook，这个请读者自行查阅步骤。这边文章也是根据官网的分析流程进行修改优化所得。言归正传，我们先来看下 Atlas 的启动过程。

Atlas 的启动过程

这里先说一下，为什么 Atlas 不算是真正意义上的插件化框架，而是一个动态组件化框架，主要原因是两者的原理有区别。

插件化的核心思想实际上是一种埋坑机制和借尸还魂，它会在宿主的 manifest 中预留很多的组件坑，在运行时，进行一系列的填坑操作，将插件的四大组件通过「借尸还魂」的手段来加载运行。

而 Atlas 有着本质区别，在编译期，每个插件 bundle 的 manifest 就已经写入到 apk 中了，所以运行的时候，不需要进行一些特殊操作，bundle 的组件的使用就像正常宿主中声明的组件一样，无需再进行额外处理了。

阿里的 Atlas 沙龙视频中也非常明确的讲述了 Atlas 的设计灵感就是 Android 系统本身，我们可以把 Android 系统看成一个容器化框架，那么 Android 系统中的所有 App 实际上就是一种插件，Android 系统本身是没有这些插件的，而作为开发者，我们实际上开发 App 就是开发插件的过程，通过发布，容器加载了插件，从而可以使用。

Atlas 就是按照这样的思想，他们试图将 Atlas 设计成这样的组件，我们所有的 bundle 就是插件。这是从一个特殊的角度来看待 Atlas 框架实现的一个效果。我们下面来看一张时序图，时序图能够帮我们更好的理清源码的调用逻辑和思路。

时序图

这张图描述了集成了 Atlas 框架后，整个 App 的启动流程，图来源于官网。通过一些技术手段，我们绕过了一些系统的步骤，达到我们期望的目的。

本文只关注步骤 1-5。

1. 入口

app 的入口是application，这每一个 Android 开发者都了解，我们来看一下集成了 Atlas 后 application 是什么。代码来源于atlas-demo。

看起来，入口就应该是DemoApplication，但我们看一下反编译 apk 后拿到的 manifest

很奇怪，实际的入口却是AtlasBridgeApplication，原来，Atlas 在编译期就已经偷偷的替换了入口 application，但实际上，运行期依然会调用你自己写的 DemoApplication 的相关方法。我们来看下AtlasBridgeApplication的源码。根据常规的启动流程，我们跟进方法attachBaseContext。

protected void attachBaseContext(Context base){
    super.attachBaseContext(base);
    //一些逻辑

    //1.构造 BridgeApplicationDelegate 对象
    Class BridgeApplicationDelegateClazz =getBaseContext().getClassLoader.loadClass("android.taobao.atlas.bridge.BridgeApplicationDelegate");
    Constructor con = BridgeApplciationDelegateClazz.getConstructor(parTypes);
    mBridgeApplicationDelegate = con.newInstance(this,getProcessName(...));

    //2.执行 BridgeApplicationDelegate 的 attachBaseContext 方法
    Method method = BridgeApplicationDelegateClazz.getDeclaredMethod("attachBaseContext");
    method.invoke(mBridgeApplicationDelegate);
}

如果大家是看源码，这段代码还是比较复杂也比较长，但实际上我们抽取关键部分发现，它实际上就做了两件事：

1. 反射构造 BridgeApplicationDelegate 实例
2. 执行 BridgeApplicationDelegate 的 attachBaseContext 方法

这时候我们就要保持耐心，进入 BridgeApplicationDelegate 类，先看它的构造方法：

public BridgeApplicationDelegate(Application rawApplication ...){
    mRawApplication = rawApplication;
    PackageManagerDelegate.delegatepackageManager(
        rawApplication.getBaseContext()
    );
}

跟进方法delegatepackageManager:

public static void delegatepackageManager(Context context){
    mBaseContext = context;
    1.反射pm
    PackageManager manager = mBaseContext.getPackageManager();
    Class ApplicationPackageManager = Class.forName("android.app.ApplicationPackageManager");
    Field field = ApplicationPackageManager.getDeclaredField("mPM");
    field.setAccessible(true);
    Object rawPm = field.get(manager);
    2.动态代理
    Class IPackageManagerClass = Class.forName("android.content.pm.IPackageManager");
    mPackageManagerProxyhandler = new PackageManagerProxyhandler(rawPm);
    mProxyPm = Proxy.newProxyInstance(mBaseContext.getClassLoader,new Class[]{IPackageManagerClass},mPackageManagerProxyhandler);
    3.替换pm

这段代码，注释写的比较清楚了，核心思想就是把系统的 pm 替换为我们实现的动态代理PackageManagerProxyhandler，具体该动态代理的实现我们先不细讲，动态代理不熟悉的同学可以自己去查阅下资料，网上很多，我们现在继续看BridgeApplicationDelegate中attachBaseContext的实现。

2. BridgeApplicationDelegate.attachBaseContext

public void attachBaseContext(){
    //2.1 hook 之前要准备的工作
    AtlasHacks.defineAndVerify();
    
    //2.2 回调预留接口
    launcher.initBeforeAtlas(mRawApplication.getBaseContext());

    //2.3 初始化 atlas
    Atlas.getInstance().init(mRawApplication,mIsUpdated);

    //2.4 处理 provider
    AtlasHacks.ActivityThread$AppBindData_providers.set(mBoundApplication,null);
}

通过注释我们可以看到，方法被分成了四个部分，我们将一个个来看这四个步骤，需要提醒的是，大家需要记住现在的代码位置，对应好文章开头的时序图，理清我们整体的代码逻辑。

3. AtlasHacks.defineAndVerify

我们知道，Android 上所有的动态加载方案，有三个关键的地方是必须要处理的：

• 动态加载 class
• 动态加载资源
• 处理四大组件

为了实现这三个目标，我们需要在系统关键调用处进行 Hook，例如我们会通过对 ClassLoader 做一些手脚来进行动态加载 Class，四大组件的处理比较特殊，这在之前我们也提到了。

回到正题，我们来看看 Atlas 为了实现上述的要求做了什么。我们先看下AtlasHacks这个类，这个类是用来定义 Atlas 需要 Hook 的类、方法、属性等字段。这段代码的静态成员变量的代码风格特别棒，大家可以学习一下，通过设置 AS 可以做到这样的效果。

//AtlasHacks.java

     // Classes
    public static HackedClass