我們在學習一門新語言或者新框架之前總喜歡干一件事情。‘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的環境搭建已經沒問題了。