我们在学习一门新语言或者新框架之前总喜欢干一件事情。‘Hello World’。一般情况下我们都希望输出一个简单的demo以证明我们通过了某项内容的基本环境搭建。没错，程序员是一种可以创超世界的生物，正如我们所写的hello world一般，因为 we are our god!!

Android环境配置:

1. Android Studio 2.3.1

2. gradle 3.3

3. gradle plugin atlas插件自适用

4. jdk1.8

 compileSdkVersion 25
 buildToolsVersion "25.0.0"
    defaultConfig {
        applicationId "com.atlas.analysis"
        minSdkVersion 15
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
    }

前两天适用 Android studio 3.0.1做atlas的demo可整蒙逼了，后续我们改造gradle再说遇到的种种坑。mabye到时间atlas官方已经适配。不太理解atlas结构和打包流程的可以参考官网：

https://alibaba.github.io/atlas/

在开始前我们需要了解下基本的结构概念：

Bundle: 类似OSGI规范里面bundle（组件）的概念，每个bundle有自己的classloader，与其他bundle相隔离，同时Atlas框架下bundle有自身的资源段（PackageID，打包时AAPT指定）；另外与原有OSGI所定义的service格式不同之处是Atlas里面Bundle透出所有定义在Manifest里面的component，随着service，activity的触发执行bundle的安装，运行。

awb： android wireless bundle的缩写，实际上同AAR类似，是最终构建整包前的中间产物。每个awb最终会打成一个bundle。awb与aar的唯一不同之处是awb与之对应有个packageId的定义。

host: 宿主的概念，所有的bundle可以直接调用host内的代码和资源，所以host常常集合了公共的中间件，UI资源等。host和bundle的依赖关系如下图所示：

从上图也可以看出基于Atlas构建后大致工程的结构：

1. 首先有个构建整体APK工程Apk_builder,里面管理着所有的依赖（包括atlas）及其版本，Apk_builder本身可能不包含任何代码，只负责构建使用

2. host内部包含独立的中间件，以及一个Base的工程，里面可能包含应用的Application，应用icon等基础性内容（如果足够独立，application也可以直接放在apk_builder内）；

3. 业务层基本上以bundle为边界自上而下与host发生调用，同时bundle之间允许存在依赖关系；相对业务独立的bundle如果存在接口耦合建议封装成aidl service的方式保证自身封装性；同时某些中间件如果只存在若干bundle使用的也可以封装bundle的方式提供出来，以保证host内容精简

4. remote bundle： 远程bundle，远程bundle只是apk构建时并未打到apk内部，而是单独放在了云端；同时远程bundle的限制条件是第一次被触发的前提是bundle内的Activity需要被start，此时基于Atlas内的ClassNotFoundInterceptorCallback可以进行跳转的重定向，提示用户下载具体bundle，待用户确定后进行异步下载同时完成后再跳转到目标bundle

主工程容器接入Atlas开源的代码内容主要包括以下几个模块：

• 基于gradle的构建插件（包括修改过的aapt内容）；

• android端测容器运行库atlas_core；

• 基于容器提供更新能力的库atlas_update;

我的首要任务也是引入以下几个内容：

1. 引用插件及依赖仓库

内容有删减，只贴比较关键的位置

buildscript {
    repositories {
        mavenLocal()
        jcenter()
        maven {
            //           url "http://mvnrepo.alibaba-inc.com/mvn/repository"
            url "http://maven.aliyun.com/nexus/content/groups/public"
        }

    }
    dependencies {
        classpath "com.taobao.android:atlasplugin:2.3.3.rc41"

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

注意：尽量不要指定 classpath "com.android.tools.build:gradle"的版本，Altas有默认使用

2.应用pluginapply plugin: 'com.taobao.atlas'//依赖atlas-pulgin组件

3.添加运行库依赖 

 compile “com.taobao.android:atlas_core:5.0.7.55@aar”//依赖atlas-core引擎代码组件
 compile “com.taobao.android:atlasupdate:1.1.4.14@aar”//依赖atlas-update更新代码组件

4.开启atlas容器功能atlas 

atlasEnable字段需要指定为true才能开启打包阶段的基于容器扩展的task

atlas {

    atlasEnabled true
    tBuildConfig {
        autoStartBundles = ['com.taobao.firstbundle'] //自启动bundle配置
    }
    patchConfigs {
        debug {
            createTPatch true
        }
    }
    manifestOptions {
        addAtlasProxyComponents true
    }
    buildTypes {
        debug {
            if (apVersion) {
                baseApDependency "com.taobao.android.atlasdemo:AP-debug:${apVersion}@ap"
                patchConfig patchConfigs.debug
            }
        }
    }
}

后续两个设置用语动态部署打包时的开关设置，其余字段参考配置列表中的使用方式

基本上配置到这里项目gradle和主app gradle已经配置的差不多了。接下来是bundle的gradle配置，也就是插件的gradle配置，添加如下内容即可将lib工程的Model配置为插件

apply plugin: 'com.taobao.atlas'
atlas {
    bundleConfig {
        awbBundle true
    }
    buildTypes {
        debug {
            baseApFile project.rootProject.file('app/build/outputs/apk/app-debug.ap')
        }
    }
}

以上说了这么多其实是想完成atlas组件化框架输出的apk包的基本机构。那么我们来看下官方的

Atlas Demo作者也在structor.md里面列出了demo的依赖关系，其中mainDex指的是会被编译进主dex的依赖；awbs指的是各个bundle，它们将以so文件的形式放在APK的lib文件夹下（这些个so文件其实就是各个业务bundle的独立APK，只不过这个APK可能要依赖容器里面的中间件代码才能运行，只是后缀改成了so而已），从awbs中也可以看出secondbundlelibrary只被secondbundle依赖。

如上所示我们可以知道，我们所要验证的结果是主站app咱mainDex中，而插件都是以so的形式存储在APK的lib文件夹下，我们的工程目录如下

我们打出的包中lib中的内容为（原谅我没有mac。。。不能输出详情图，各位有心的可以去验证）：

支持，我们要分析atlas的环境搭建已经没问题了。