Atlas框架源码简要分析(上)--框架的初始化

Atlas框架源码简要分析(上)–框架的初始化

内容根据阿里发布到github官网上的源码整理，版本号：v5.0.7.55，官方源码github地址https://github.com/alibaba/atlas；官方文档地址：https://alibaba.github.io/atlas/

一、关于Atlas应该大致知道的

1.1.这个框架都能做到什么？

1.1.1、首先这是一个组件化的框架其实现和插件化还是有一定区别的，这个也可能是设计之初定位的原因，毕竟综合考虑稳定性和常见开发及迭代的需求来看，砍掉插件化所能带来的好处也是能够接受的。

1.1.2、这个框架能够让在开发过程中各个业务模块单独开发，当然也能解决方法数爆炸的问题，这个也是最实用的

1.1.3、这个框架能够让把不常用的业务模块放在云端等需要的时候再加载，从而减小安装包的大小

1.1.4、能够动态的下发补丁，修复业务中的bug

1.2.这个框架不能做什么？

他不是一个定位于插件化开发的框架，所以不支持动态的部署一开始没有预订的业务，简单的说，不能动态的新增一个之前旧包中没有的Activity，只能更新里面的逻辑

1.3、这个框架所需要的基础或者说准备工作有哪些？

首先该框架是需要配合gradle插件，一块工作的该框架其在编译打包过程中做了很多工作，因此需要配合专门的gradle插件才能工作

1.3.1、在主工程中，需要为每个依赖的bundle的资源ID前缀提前配置相应不重复的值

1.3.2、主工程构建时，每个依赖的bundle都会按照配置好的资源Id前缀进行替换，保证各bundle资源ID前缀不会重复

1.3.3、构建过程中会合并各bundle的Manifest文件到主bundle中

这个是关键，整个框架的实现都是基于所有的Bundle中的四大组件信息会统一在主工程的Manifest中声明，简单的说，就是子Bundle中的组件不再需要特殊的处理，已经是合法的了,这样相对来说就会少Hack相当一部分系统的实现保证了稳定性，当然也牺牲了类似插件化框架的那种能够动态添加新的Activity的能力

1.3.4、构建过程中会把主工程中的manifest中声明的application会替换为框架中的AtlasBridgeApplication，而该Application是框架初始化的起点

反编译后可见实际的manifest文件中除了会合并所有子bundle的manifest之外还替换了之前声明的application的name

<application android:allowBackup="false" 
android:debuggable="true" 
android:icon="@drawable/launch_icon" 
android:label="@string/app_name"
android:name="android.taobao.atlas.startup.AtlasBridgeApplication" //打包过程中，该处的name已经被替换为了AtlasBridgeApplication
android:supportsRtl="false" 
android:theme="@style/xxxxAppTheme">

1.3.5、构建过程中在主工程的manifest中添加了

<meta-data android:name="REAL_APPLICATION" android:value="com.xxxx.xxxx.xxxxApplication"/>//其中xxxxApplication即正常编码中写的自己的Application

其中xxxxApplication即正常编码中写的自己的Application,以下都直接使用RealAppliaction代替自己声明的Application

1.3.6、构建过程中会根据build文件中配置的multidex_enable在主工程的Manifest中添加

 <meta-data android:name="multidex_enable" android:value="true"/>

1.3.7、在编译过程中还回收集各bundle中的Activity，BroadcastReceiver，Server，ContentProvider等信息，并把这些信息写入FrameworkProperties类中的bundleInfo字段,同时会在该类中插入的信息还有该bundle的package信息，当前bundle的Application等，具体反编译之后就可以看到。并且该类在框架启动中会把该字段值取出来转化为一个BundInfo的List

反编译之后的FrameworkProperties对应的信息如下，bundleInfo字段记录了所有子bundle的信息

package android.taobao.atlas.framework;

public class FrameworkProperties
{
  public static String autoStartBundles = "com.android.autostartbundle";//
  public static String bundleInfo = "[{\"activities\":[\"com.xxxx.update.lightapk.storagespace.xxxxActivity\",\"com.----------.update.lightapk.BundleNotFoundActivity\",\"com.xxxx.test.xxxxxActivity\"],\"applicationName\":\"com.xxxx.update.UpdateApplication\",\"contentProviders\":[],\"dependency\":[],\"isInternal\":true,\"pkgName\":\"com.android.update\",\"receivers\":[\"com.xxxx.atlas.update.AwoPatchReceiver\",\"com.xxxx.update.bundle.BundleInstalledExitAppReceiver\",\"com.xxxx.update.test.DynamicTestReceiver\",\"com.xxxx.update.test.MutiDynamicTestReceiver\",\"com.xxxx.update.test.AndFixTestReceiver\",\"com.xxxx.update.test.ApkTestReceiver\"],\"services\":[\"com.xxxx.atlas.dexmerge.DexMergeService\",\"com.xxxx.update.test.DynamicTestService\"],\"unique_tag\":\"d48a03f8a4f81ac00e9184c0f69961e2\",\"version\":\"[email protected]\"}{...}]";
  public static String group = "xxxxxxx";
  public static String outApp = "false";
  private String version = "0.0.0.1";

  public String getVersion()
  {
    return this.version;
  }
}

ps:对于APK的字节码及资源的反编译可以参考：https://www.jianshu.com/p/792a08d5452c

二、框架是怎么启动起来的

上面已经看到，实际生成的Apk中的Application已经被替换成了AtlasBridgeApplication，而App的启动是从Application开始的，现在就从这个AtlasBridgeApplication开始，一步一步走下去

下面是简要大概的时序图:

在下面的代码分析中的小节没有严格按照时序进行排序，而是为了方便把对应一个代码块中的逻辑分为一个小节，而对于具体的个别函数的展开会另起一个小节，此处给出以下面的小节标号为参照的时序：

• 1.对应AtlasBridgeApplication中的attachBaseContext()的逻辑涉及2.1到2.4，时序为：2.1(顺序执行)->2.2->2.2.1->2.2.2->2.2.3->2.2.4->2.2.5->2.2.6->2.2.7->2.2.8(对应函数Atlas.getInstance().init())->2.3顺序执行->2.2.9->至此attachBaseContext()执行完毕。

• 2.对应AtlasBridgeApplication.onCreate()的逻辑涉及2.4-2.8，时序如下：调用如下从2.4的onCreate()开始，2.4(顺序执行)->2.5->2.5.1->2.5.2->2.5.3->2.5.4->2.5.5->2.5.6(对应Atlas.getInstance().startup())->2.6->2.7->2.8->2.5.7

2.1、因为apk打包过程中Manifest中声明的application已经被替换为了AtlasBridgeApplication，现在就看一下，最先被调用的AtlasBridgeApplication中的attachBaseContext()，此处略去在线更新(update)的逻辑，大致逻辑及代码如下：

2.1.1 KernalConstants 主要用来记录一些全局的初始化的变量值，在后面hack过程中，会相应替换为其当前的相应值

2.1.2 初始化更新安装包有关的逻辑

2.1.3 实例化BridgeApplicationDelegate，所有操作都是转嫁到该类中实现的，会在当前的application中反射调用其相应的方法，使其和Application同步

2.1.4 调用BridgeApplicationDelegate中的attachBaseContext（）

    @AtlasBridgeApplication.java
    @Override
    protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    if (!isApplicationNormalCreate(base)) {
        android.os.Process.killProcess(android.os.Process.myPid());
    }
    System.setProperty("BOOT_TIME",System.currentTimeMillis()+"");
    // *0 checkload kernalpatch
    boolean isUpdated = isUpdated(getBaseContext());

    //----------2.1.1、KernalConstants 主要用来记录一些全局的初始化的变量值，在后面hack过程中，会相应替换为其当前的相应值
    KernalConstants.baseContext = getBaseContext();//记录当前的系统生成的Context
    KernalConstants.APK_PATH = getBaseContext().getApplicationInfo().sourceDir;//记录APK的安装路径
    KernalConstants.RAW_APPLICATION_NAME = getClass().getName();//记录当前Application的类名，即AtlasBridgeApplication的全路径类名
    DexLoadBooster dexBooster = new DexLoadBooster();//该类是启动前的一些准备工作初始化
    dexBooster.init(getBaseContext());
    KernalConstants.dexBooster = dexBooster;//记录
    boolean hasKernalPatched  = false;
    boolean isMainProcess = getBaseContext().getPackageName().equals(KernalConstants.PROCESS);//判定是否是当前主进程
    if(isUpdated){//-------------2.1.2、此