工欲善其事必先利其器。
我们在学习一门新语言或者新框架之前总喜欢干一件事情。‘Hello World’。一般情况下我们都希望输出一个简单的demo以证明我们通过了某项内容的基本环境搭建。没错，程序员是一种可以创超世界的生物，正如我们所写的hello world一般，因为 we are our god!!
Android环境配置:
- Android Studio 2.3.1
- gradle 3.3
- gradle plugin atlas插件自适用
- jdk1.8
compileSdkVersion 25
buildToolsVersion "25.0.0"
defaultConfig {
applicationId "com.atlas.analysis"
minSdkVersion 15
targetSdkVersion 25
versionCode 1
versionName "1.0"
}
其余配置详情请查看demo
前两天适用 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的依赖关系如下图所示：
image.png
从上图也可以看出基于Atlas构建后大致工程的结构：
- 首先有个构建整体APK工程Apk_builder,里面管理着所有的依赖（包括atlas）及其版本，Apk_builder本身可能不包含任何代码，只负责构建使用
- host内部包含独立的中间件，以及一个Base的工程，里面可能包含应用的Application，应用icon等基础性内容（如果足够独立，application也可以直接放在apk_builder内）；
- 业务层基本上以bundle为边界自上而下与host发生调用，同时bundle之间允许存在依赖关系；相对业务独立的bundle如果存在接口耦合建议封装成aidl service的方式保证自身封装性；同时某些中间件如果只存在若干bundle使用的也可以封装bundle的方式提供出来，以保证host内容精简
- 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.应用plugin
apply 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 {
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
}
}
}
}
atlasEnable字段需要指定为true才能开启打包阶段的基于容器扩展的task
后续两个设置用语动态部署打包时的开关设置，其余字段参考配置列表中的使用方式
基本上配置到这里项目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作者提供的依赖关系图解释如下：
strutor.md
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文件夹下，我们的工程目录如下
工程中包含主app和插件firstbundle
我们打出的包中lib中的内容为（原谅我没有mac。。。不能输出详情图，各位有心的可以去验证）：
支持，我们要分析atlas的环境搭建已经没问题了。
demo 奉上:https://github.com/AnyMarvel/AnalysisAtlas
设一个小目标。下面我们会搭建一些小的功能并进行功能分析，期待你的参与
网友评论