ps:如果您看過atlas的官方介紹，本片文章可以略過，期待我們追溯源碼的過程中有你的參與

摘要：Atlas是古希臘神話中的天神，是波士頓動(dòng)力公司的機(jī)器人，借助搜索引擎，得以發(fā)現(xiàn)這個(gè)名詞背后許許多多的含義。在手機(jī)淘寶，Atlas是一個(gè)扎根于Android客戶端的一個(gè)組件化容器框架，相比神話中用手和頭支撐起蒼天的泰坦神族，Atlas在手淘默默無聞地承載著手淘上豐富業(yè)務(wù)的運(yùn)行，伴隨著數(shù)不清的功能在...

Android方向的大牛們都已經(jīng)深入了解了插件化所帶來的巨大的便利，一直也沒時(shí)間去搞一套詳細(xì)的記憶，在這里，僅以源碼分析的形式進(jìn)行插件化框架的鞏固，文集中會(huì)具體分析源碼，框架結(jié)構(gòu)，運(yùn)行原理等方面，除了加深記憶，也讓我們一起進(jìn)步
本片為引導(dǎo)篇，請(qǐng)注意后續(xù)更新。

淘技術(shù)團(tuán)隊(duì)宣布正式開源它們的容器框架Atlas，項(xiàng)目地址：
https://github.com/alibaba/atlas
同時(shí)他們還推出了項(xiàng)目官網(wǎng)，上線了技術(shù)文檔：
http://atlas.taobao.org/docs/

容器框架結(jié)構(gòu)圖

2013年，手淘航母戰(zhàn)略的制定，帶來了業(yè)務(wù)和開發(fā)人員的翻倍膨脹。從不到100人猛增四五倍，同時(shí)業(yè)務(wù)數(shù)量大增，整個(gè)客戶端的架構(gòu)和發(fā)版節(jié)奏受到極大挑戰(zhàn)，Atlas作為之前手淘客戶端的基礎(chǔ)框架，進(jìn)行了一次大的重構(gòu)，形成了今天的Atlas。

Atlas是一個(gè)Android客戶端容器化框架，主要提供了組件化、動(dòng)態(tài)性、解耦化的支持。支持工程師在工程編碼期、Apk運(yùn)行期以及后續(xù)運(yùn)維修復(fù)期的各種問題。

• 在工程期，實(shí)現(xiàn)工程獨(dú)立開發(fā)，調(diào)試的功能，工程模塊獨(dú)立。
• 在運(yùn)行期，實(shí)現(xiàn)完整的組件生命周期的映射，類隔離等機(jī)制。
• 在運(yùn)維期，提供快速增量的更新修復(fù)能力，快速升級(jí)。
  Atlas是工程期和運(yùn)行期共同起作用的框架，它的特點(diǎn)是盡量將一些工作放到工程期，這樣來保證運(yùn)行期的簡單，穩(wěn)定。

Atlas首先要解決的問題是大規(guī)模團(tuán)隊(duì)的協(xié)作問題，訴求包括并行開發(fā)、快速迭代、工程解耦，然后解決的問題是客戶端動(dòng)態(tài)更新的問題。

Atlas組件化實(shí)現(xiàn)

組件化，業(yè)界稱為插件化，不過這里Atlas的組件化和現(xiàn)在的插件化有一些不一樣的地方。組件化是需要去知道組件的功能，設(shè)計(jì)更規(guī)范。

手淘APK包目錄結(jié)構(gòu)

這是一個(gè)手機(jī)淘寶的APK包，第一層目錄上與標(biāo)準(zhǔn)的APK是完全一樣的，在APP會(huì)有很多的so文件，如果解開來看的話，它的結(jié)構(gòu)類似于完整的APK，但本身并不能獨(dú)立運(yùn)行，它跟很多插件化的差別是在運(yùn)行期，它是運(yùn)行在整個(gè)容器里的，每一個(gè)組件都是獨(dú)立的Bundle。

模塊話劃分

從模塊來劃分，手淘APK可以分為兩層，上層是經(jīng)過拆分的業(yè)務(wù)Bundle，掃碼、評(píng)價(jià)、詳情，各個(gè)業(yè)務(wù)之間可以進(jìn)行功能的調(diào)用，可以通過路由調(diào)度到其他業(yè)務(wù)方。下層是共享的底層中間件，向業(yè)務(wù)方開放各種能力，如網(wǎng)絡(luò)庫、圖片庫等，會(huì)在容器里進(jìn)行統(tǒng)一地把控，這樣做的好處是包做到盡可能小，第二是性能佳。

整體設(shè)計(jì)

這一塊是Atlas的整體設(shè)計(jì)，分為五層：

• 第一層我們稱之為Hack層，包括OS Hack toolkit & verifier，這里我們對(duì)系統(tǒng)能力做一些擴(kuò)展，然后做一些安全校驗(yàn)。

• 第二層是Bundle Framework，就是我們的容器基礎(chǔ)框架，提供Bundle管理、加載、生命周期、安全等一些最基本的能力。

• 第三層是運(yùn)行期管理層，包括清單，我們會(huì)把所有的Bundle和它們的能力列在一個(gè)清單上，在調(diào)用時(shí)方便查找；另外是版本管理，會(huì)對(duì)所有Bundle的版本進(jìn)行管理；再就是代理，這里就是和業(yè)界一些插件化框架機(jī)制類似的地方，我們會(huì)代理系統(tǒng)的運(yùn)行環(huán)境，讓Bundle運(yùn)行在我們的容器框架上；然后還有調(diào)試和監(jiān)控工具，是為了方便工程期開發(fā)調(diào)試。

• 第四層是業(yè)務(wù)層了，這里我們向業(yè)務(wù)方暴露了一些接口，如框架生命周期、配置文件、工具庫等等。

• 第五層,最上面一層是應(yīng)用接入層，就是我們的業(yè)務(wù)代碼了。

所以Atlas作為一個(gè)框架提供了相對(duì)完整的能力，業(yè)務(wù)層的開發(fā)可以在框架生命周期的各個(gè)環(huán)節(jié)做一些自定義的動(dòng)作，也可以自由的調(diào)用系統(tǒng)、框架，乃至其它組件釋放的能力。

組件化技術(shù)細(xì)節(jié)

前面講的是容器層面的比較概要的東西，下面我們會(huì)講一些具體的細(xì)節(jié)。

關(guān)于Bundle的生命周期會(huì)提供細(xì)粒度的節(jié)點(diǎn)，比如下面是一個(gè)Bundle從加載到運(yùn)行的周期：

• startInstall：開始加載。這個(gè)時(shí)候框架會(huì)做一些拷貝文件、釋放lib、加載Bundle的事情；
• Installed：加載完畢。這時(shí)框架會(huì)注入資源路徑，創(chuàng)建class loader；
• resolved：解析完畢，框架會(huì)檢查組件配置是否合法，是否能被解析；
• active：運(yùn)行組件，即開始運(yùn)行組件Bundle；
• started：運(yùn)行成功。

組件化涉及到的

• 第一個(gè)問題是Manifest處理，一個(gè)是因?yàn)閬碓春芏?，有宿主Manifest、Aar Manifest以及組件Manifest，另外不同組件的Manifest經(jīng)常發(fā)生變化，要求我們靈活地去處理。這里的做法是在工程期將所有的Manifest進(jìn)行Merge操作，這里需要注意的是Bundle的依賴單獨(dú)Merge，因?yàn)檫@里涉及到依賴仲裁的問題。最后解析各個(gè)Bundle的Merge Manifest，得到整包的BundleInfoList，就是上面我們提到的Bundle信息清單。

類加載

• 第二個(gè)是類加載，這里利用Delegate ClassLoader來動(dòng)態(tài)加載組件的類。Delegate ClassLoader先查找宿主Bundle的PathClassLoader，然后根據(jù)前面的BundleList找到對(duì)應(yīng)的BundleClassLoader.

資源管理

• 第三個(gè)是資源，我們會(huì)用自己的DelegeteResources替換掉系統(tǒng)的resource，Bundle的資源會(huì)逐個(gè)在安裝的時(shí)候添加到AssertPath，由于添加Bundle的順序非固定，不分區(qū)會(huì)導(dǎo)致資源查找錯(cuò)亂。

另外，Dalvik和ART上的資源查找過程順序是不一樣的，加上小米等系統(tǒng)會(huì)重寫自己的resources，所以我們會(huì)適配不同的機(jī)型，往后追加AssetsPath或者往前追加，系統(tǒng)AssetManager是個(gè)單例，默認(rèn)往后追加，如果往前追加，則需要重新創(chuàng)建AssetsManager對(duì)象，同樣主dex動(dòng)態(tài)部署的時(shí)候要達(dá)到替換原有resource的目的，必須保證插入順序與查找順序一致。

還有需要注意的是，每次更新resourceTable的時(shí)候，必須保證apkresource，runtime的系統(tǒng)resource，例如webview，bundle resource都已經(jīng)添加成功，而且唯一，順序正確。

不同Bundle的資源可能發(fā)生命名沖突，我們是用了一種相對(duì)來說簡單的方法，將各自的Bundle分配成不同的ID，保證所有的業(yè)務(wù)資源不會(huì)產(chǎn)生沖突，盡量將問題放到工程期解決。在很多代碼里，通過反射來調(diào)用整個(gè)資源，在5.0以上的系統(tǒng)是沒有問題的，它只找第一個(gè)，對(duì)業(yè)務(wù)代碼而言，原來是怎么寫的，今天還是怎么去寫。

關(guān)于組件化性能這一部分，我們引入了按需加載，因?yàn)槭痔訟PK有70多個(gè)Bundle，每個(gè)用戶真正用的時(shí)候只需要5或10個(gè)，所以不需要加載所有的Bundle。Bundle之間進(jìn)行隔離，通過Android四大原生組件進(jìn)行交互，這樣Bundle之間可以比較好的解耦。我們所有調(diào)用的入口都是基于BundleInfolist去做的，根據(jù)這個(gè)清單信息，得到組件所在Bundle，如果需要加載，我們就進(jìn)行install、dexopt等操作。

另外，對(duì)于解決組件依賴問題，定義了兩種新的組件格式Awb（業(yè)務(wù)Bundle）和solib（so庫），前者與AAR一致，不過不添加本地lib，在構(gòu)建的時(shí)候做依賴仲裁區(qū)分，后者是Native so庫的依賴。Awb其實(shí)就是AAR，只是后綴修改了，如果你的包放在宿主Bundle就用AAR，如果是組件Bundle就用Awb。

對(duì)于業(yè)務(wù)Bundle的依賴，我們?cè)跇?gòu)建期會(huì)將宿主Bundle和業(yè)務(wù)Bundle及其依賴分別打包，然后按照最短路徑、第一聲明原則進(jìn)行樹狀仲裁，得到每個(gè)Bundle需要的依賴，在打包的時(shí)候會(huì)將依賴庫放到各自的Bundle里去。

apk構(gòu)建

最后是APK構(gòu)建，我們對(duì)它做了比較大的調(diào)整。上面的圖中，其實(shí)左邊這一部分是一個(gè)標(biāo)準(zhǔn)的APK的構(gòu)建過程，包括處理，編譯，到簽名的過程。我們這個(gè)不同的地方是多了Awb需要特殊處理，其中Awb的資源根據(jù)宿主的resource.ap_和包內(nèi)資源構(gòu)建，R文件由Bundle R資源和宿主R資源合并而來，然后我們對(duì)Aapt進(jìn)行了修改，對(duì)每個(gè)awb分配不同的packageId，然后進(jìn)行統(tǒng)一混淆，生產(chǎn)各個(gè)AWB的Dex，打包為APK，簽名之后復(fù)制到libs，改名為so文件，然后合并到taobao APK. 這就是我們組件化的整個(gè)過程。

Atlas動(dòng)態(tài)化

在一個(gè)容器框架內(nèi)，組件化和動(dòng)態(tài)化是相輔相成的，組件只是解決了解耦的問題，但我們?nèi)绻胍S時(shí)發(fā)包，就必須讓容器框架具備動(dòng)態(tài)化能力。我們?cè)谕瓿闪薃tlas的組件化之后，做了動(dòng)態(tài)化的支持。動(dòng)態(tài)化的好處一個(gè)是包的大小縮減，我們可以將一些包在運(yùn)行后下載到應(yīng)用中，另一個(gè)是具備動(dòng)態(tài)發(fā)版和修復(fù)能力。

增量動(dòng)態(tài)化方案

Atlas提供了動(dòng)態(tài)部署的能力，主要目標(biāo)是動(dòng)態(tài)業(yè)務(wù)發(fā)布，以及問題修復(fù)。它基于手淘自研差量算法，主Bundle基于ClassLoader機(jī)制，業(yè)務(wù)Bundle基于差量merge，支持全業(yè)務(wù)類型。

另外，Atlas也支持Andfix作為插件使用，目標(biāo)是快速故障修復(fù)，它的原理基于Native hook，主要做方法的修改，在實(shí)際中可以兩個(gè)一起用。在工程構(gòu)建期適配之后，可以做到一套代碼兩套方案通用。

動(dòng)態(tài)部署

自研動(dòng)態(tài)部署功能實(shí)現(xiàn)原理，首先，對(duì)于Dex Patch的生成，我們通過修改Dex的字節(jié)碼實(shí)現(xiàn)，將Dex文件轉(zhuǎn)為Smali，對(duì)其中的ClassDef和ClassDataMethod結(jié)構(gòu)體進(jìn)行分析，可以實(shí)現(xiàn)刪除、新增、修改類，然后通過Diff處理得到差量文件，再通過Merge處理即生成補(bǔ)丁。

其次是整個(gè)資源Patch的生成，分為兩塊，一個(gè)是業(yè)務(wù)Bundle，本來是一個(gè)不斷加載的過程，它實(shí)現(xiàn)起來會(huì)比較簡單，通過Md5 diff/BSDiff即可得到。對(duì)于主Bundle，因?yàn)榘沧勘旧碛幸粋€(gè)限制，所有的資源必須得在base包里，新增一個(gè)資源是不生效的。所以一個(gè)做法是在打包的時(shí)候預(yù)留很多空資源。另外更新已有的資源則通過資源覆蓋來完成。

最后，如果新加業(yè)務(wù)的話，會(huì)新加Activity，我們的做法首先在Manifest預(yù)埋一個(gè)StubActivity，然后在Instrumentation.execStartActivity()階段進(jìn)行替換，同時(shí)配合Intent setFlag模擬Activity launch mode并繼續(xù)startActivity，接著System_server進(jìn)程進(jìn)行處理，更新ActivityStack，創(chuàng)建binder，并通知ActivityThread進(jìn)行實(shí)例創(chuàng)建，最后我們?cè)贏ctivityThread的handler里面進(jìn)行攔截，更新ActivityInfo等信息，創(chuàng)建目標(biāo)Activity。

另外在工程實(shí)踐上，因?yàn)檠a(bǔ)丁的生成會(huì)涉及到Dex和資源的基線，我們會(huì)在部署的時(shí)候，每次發(fā)布APK包同步發(fā)布AP（基線包）到Maven，AP基線包里是所有影響基線的文件，第一是安卓APK，第二是Mapping.txt，最后是Dependency.txt，這樣的話整個(gè)構(gòu)建的速度會(huì)非常的快。

所以我們這種方式，版本的升級(jí)是不同的方式。比如今天手淘的詳情要更新，會(huì)發(fā)布版本，這個(gè)版本可能不是到應(yīng)用市場的版本，而是一個(gè)Patch包。業(yè)務(wù)版本的動(dòng)態(tài)部署，是同步的，這樣一個(gè)好處是只要容器版本沒有升級(jí)，只要有需求，patch就可以一直升級(jí)，而且是無感知的差量升級(jí)。

上述了atlas很多的優(yōu)點(diǎn)，但是也有缺點(diǎn)所在，大家應(yīng)該看到，宿主工程和插件工程之間的相互調(diào)用是基于反射方式，而一般情況下發(fā)版的release包都要進(jìn)行代碼混淆，這里的atlas就相當(dāng)于赤裸裸的暴露在了外界，對(duì)于逆向調(diào)試來說簡直是豐盛的。atlas還有很多的弊端，當(dāng)然，好處是數(shù)不勝數(shù)的

期待我們下次的見面

關(guān)注微信公眾號(hào)

Android歷練記

或掃一掃二維碼：
讓我們一起來搞事情。

Android歷練記