Android市場的渠道分散已不是什么新鮮事，但如何高效打包仍是令許多開發(fā)者頭疼的問題。本篇文章著重介紹了目前最新的三種打包方案，并且從安全方面對這三種方案進(jìn)行點(diǎn)評，相信會(huì)給開發(fā)者帶來新的助力。

一般需求的打包，一條行命令就出來了。復(fù)雜一些的話，也就是一個(gè)簡單的開源工具，或是一段小配置代碼就搞定了。既然如此，為什么我還要來寫Android打包相關(guān)內(nèi)容？主要有以下兩個(gè)方面的原因：

Android市場開放，渠道越來越多，幾千個(gè)渠道已經(jīng)是常態(tài)。所以，需要一個(gè)高效且安全的打包方式，來支持成千上萬的渠道打包重任。

現(xiàn)在Android應(yīng)用程序都會(huì)使用ProGuard或者DexGuard來進(jìn)行代碼混淆，在引入代碼混淆的前提下，需要針對某一個(gè)版本盡量只保留一份符號(hào)表（Android是mapping文件）。多份不同的符號(hào)表對應(yīng)到一個(gè)版本的程序，會(huì)給Crash修正等后期問題的追查造成很大困難。

所以，當(dāng)Android開發(fā)團(tuán)隊(duì)有一定規(guī)模時(shí)，需要一種優(yōu)雅并且高效安全的打包方式來銜接從代碼到應(yīng)用程序包的這個(gè)過程。

歷史回顧

大概在3-4年前，國內(nèi)的移動(dòng)開發(fā)者都會(huì)使用友盟來做Crash收集和一些用戶的行為數(shù)據(jù)收集。所以，友盟定義渠道的方式基本定義了數(shù)據(jù)收集工具的渠道定義方式。友盟默認(rèn)的渠道直接從AndroidManifest文件中的meta－data里面讀取。如以下代碼所示：

'' '' '' ''

在示例中，UMENG_APPKEY是賬戶的唯一標(biāo)示，UMENG_CHANNEL的內(nèi)容為wandoujia，即表示這時(shí)渠道是wandoujia。這里再多說一句渠道的概念，一般的渠道可能會(huì)表示具體是哪個(gè)應(yīng)用市場。比如上傳豌豆莢和上傳360手機(jī)助手的渠道標(biāo)示不一樣，當(dāng)然，如果有一些線下推廣的話，也需要區(qū)分渠道。隨著數(shù)據(jù)統(tǒng)計(jì)越來越細(xì)，渠道也會(huì)更加的層出不窮。現(xiàn)在一個(gè)日活在百萬的應(yīng)用，Android的渠道在幾千個(gè)是非常正常的現(xiàn)象。

在AndroidManifest定義渠道的年代，多渠道打包無非以下兩種方案：

方案一：完全的重新編譯，即在代碼重新編譯打包之前，在AndroidManifest中修改渠道標(biāo)示；

方案二：通過ApkTool進(jìn)行解包，然后修改AndroidManifest中修改渠道標(biāo)示，最后再通過ApkTool進(jìn)行打包、簽名。

現(xiàn)在看來，這兩種方式效率都不高。方案一基本上毫無效率可言，只能支持20個(gè)以內(nèi)的渠道規(guī)模。方案二效率高一些，如果再引入多線程驅(qū)動(dòng)來進(jìn)行打包，支持200以內(nèi)的渠道打包毫無壓力。但是隨著Android的版本升級(jí)，代碼混淆和加固工具的引入，這種方案已經(jīng)不能正常運(yùn)行了。所以，需要一種兼容性好并且高效的多渠道打包方式。

三種高效的多渠道打包方式

Android項(xiàng)目本身是開源的，大家都可以去研究任何實(shí)現(xiàn)，基于這個(gè)特性，一種叫做“Android黑科技”的學(xué)科迅速誕生。以下介紹的多渠道打包方式都應(yīng)該屬于其范疇。

添加comments多渠道打包

首先解釋什么是comments（注釋或評論）的打包方式？

Android應(yīng)用使用的APK文件就是一個(gè)帶簽名信息的zip文件，根據(jù)zip文件格式規(guī)范（請參見：https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT），每個(gè)文件的最后都必須有一個(gè)叫Central Directory Record（https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html）的部分，這個(gè)CDR的最后部分叫“End of Central Directory Record”，這一部分包含一些元數(shù)據(jù)，它的末尾是zip文件的注釋。注釋包含Comment Length和File Comment兩個(gè)字段。前者表示注釋的長度，后者是注釋的內(nèi)容，正確修改這一部分不會(huì)對zip文件造成破壞，利用這個(gè)字段，我們可以添加一些自定義數(shù)據(jù)。

簡單來說就是：我們利用的是zip文件“可以添加comment（摘要）”的數(shù)據(jù)結(jié)構(gòu)特點(diǎn)，在文件的末尾寫入任意數(shù)據(jù)，而不用重新解壓zip文件（apk文件就是zip文件格式）；所以該工具不需要對APK文件解壓縮和重新簽名即可完成多渠道自動(dòng)打包，可謂是高效、速度快，無兼容問題。

這種高效的方式是奇虎360的一位工程師公布的，他已經(jīng)把相關(guān)工具的代碼開放在GitHub上面了，地址為https://github.com/seven456/MultiChannelPackageTool。工具本身為命令行形式，一條命令即可生成一個(gè)多渠道包，并且非常高效。作者本人公布的性能數(shù)據(jù)是：5M的APK，1秒種能打300個(gè)。

就是因?yàn)樗俣确浅？?，現(xiàn)在一些廠商用這種方案來做安裝包的動(dòng)態(tài)生成。在用戶下載之前渠道是沒有添加進(jìn)去的，用戶選擇下載以后通過渠道來源判斷渠道標(biāo)示，并且寫入。過程瞬間完成，用戶下載時(shí)毫無感知。

當(dāng)然，利用工具把渠道寫入應(yīng)用程序包內(nèi)，還應(yīng)該提供一種在APK內(nèi)部讀取渠道的方式。讀取時(shí)方法也非常簡單，首先通過反射方法找到APK在手機(jī)中的位置，然后通過讀zip comment的方式獲取渠道內(nèi)容。讀取comment和找APK位置的代碼都能在這個(gè)急速添加渠道的工具中找到，在這里不再詳細(xì)介紹。需要注意的是，在Android中使用Java反射的性能非常差，需要做一些優(yōu)化處理。

如果你覺得這種方式的安全比較差，也可以自己重新實(shí)現(xiàn)一個(gè)小工具，并且對comment的內(nèi)容加密。當(dāng)然，加密使用的密鑰需要在APK代碼中體現(xiàn)，這種加密方案也只是提高了一點(diǎn)破譯的門檻而已。

美團(tuán)的Android多渠道打包

美團(tuán)點(diǎn)評技術(shù)團(tuán)隊(duì)（原美團(tuán)技術(shù)團(tuán)隊(duì)）有一個(gè)公開的博客，每篇文章都在領(lǐng)域內(nèi)有一定的影響。其中有一篇就是討論“如何高效地進(jìn)行Android多渠道打包？”，可參見：http://tech.meituan.com/mt-apk-packaging.html。

文章中首先提到了ApkTool的多渠道打包方式，然后講到美團(tuán)的業(yè)務(wù)發(fā)展已經(jīng)有900多個(gè)渠道，ApkTool的方式已經(jīng)不能支持這種規(guī)模的多渠道打包。所以，美團(tuán)點(diǎn)評技術(shù)團(tuán)隊(duì)開始探索一種更加高效的多渠道打包方式。

美團(tuán)的做法是把一個(gè)Android應(yīng)用包當(dāng)作zip文件包進(jìn)行解壓，然后發(fā)現(xiàn)在簽名生成的目錄下添加一個(gè)空文件不需要重新簽名。利用這個(gè)機(jī)制，該文件的文件名就是渠道名。這種方式不需要重新簽名等步驟，非常高效。

下面我們來詳細(xì)講解一下這個(gè)過程。首先把一個(gè)已經(jīng)簽名好的Android應(yīng)用程序包解壓縮，簽名文件的目錄為：META-INF，如圖1所示。

圖1 美團(tuán)Android多渠道打包壓縮文件目錄

圖中有兩個(gè)框選的部分，分別為：assets目錄和META－INF目錄。assets等下文介紹豌豆莢高效打包方式的時(shí)候再說。我們這里先來看看META－INF目錄。在META－INF目錄下的三個(gè)文件，就是一個(gè)Android應(yīng)用程序包被正確簽名之后的生成文件，當(dāng)這個(gè)程序包中的文件被修改以后，驗(yàn)證信息就需要重新生成，否則驗(yàn)證的簽名信息就不正確。這套簽名機(jī)制也是從Java的jar包方式繼承過來的。

美團(tuán)多渠道打包方式，正是利用簽名的驗(yàn)證方式，巧妙地放入了一個(gè)空文件，利用文件名來表示渠道方式的完成。如果放入了一個(gè)非空的文件，這時(shí)簽名驗(yàn)證的機(jī)制就會(huì)被破壞。美團(tuán)的具體做法是通過一段簡單的Python腳本來完成。代碼如下：

'' import zipfile

'' zipped = zipfile.ZipFile(your_apk, 'a', zipfile.ZIP_DEFLATED)

'' empty_channel_file = "META-INF/mtchannel_{channel}".format(channel=your_channel)

'' zipped.write(your_empty_file, empty_channel_file)

通過運(yùn)行Python腳本，Android應(yīng)用程序包中便會(huì)多出一個(gè)文件，如圖2所示。

圖2 通過運(yùn)行Python腳本，Android應(yīng)用程序包中多出來的一個(gè)文件

渠道添加成功后，可以參照美團(tuán)點(diǎn)評技術(shù)團(tuán)隊(duì)的博客，在Android程序中添加讀取渠道的代碼，即可擁有高效的多渠道打包方式。

當(dāng)然，這個(gè)技術(shù)實(shí)現(xiàn)本身可以有更加優(yōu)雅和高效的方式——添加渠道。原理不變，添加方式可以進(jìn)行改變。添加文件可以使用AAPT這個(gè)工具。AAPT本身是Android平臺(tái)自帶的一個(gè)命令行工具，可以實(shí)現(xiàn)從Android程序包中刪除和添加任意文件。當(dāng)然，如果添加文件破壞了簽名驗(yàn)證信息，則是另外一回事了。關(guān)于AAPT的使用和其在多渠道簽名打包時(shí)的用法，會(huì)在下文進(jìn)行講解。

如果現(xiàn)在想把美團(tuán)的渠道刪除，使用AAPT輸入一條簡單的命令行即可（能刪除就能添加，添加部分還是在豌豆莢多渠道打包方案中介紹吧）：

'' aapt remove? meituan.apk META-INF/mtchannel_meituan

豌豆莢Android多渠道打包

豌豆莢的多渠道打包方案和美團(tuán)的所用的方式一樣，都是添加一個(gè)文件，文件本身會(huì)帶入渠道消息。但不同點(diǎn)在于它添加的是一個(gè)不為空的文件。之前已經(jīng)提到過了，如果添加一個(gè)非空文件，就會(huì)破壞簽名校驗(yàn)，需要重新簽名。

從這個(gè)方案可以看出，豌豆莢多渠道打包和美團(tuán)多渠道打包正好是利用了一個(gè)特性的兩個(gè)方面。當(dāng)然，如果需要重新簽名，效率會(huì)差一些。在失去效率的同時(shí)，擁有了更加安全的渠道管理。下面具體講解，豌豆莢多渠道打包管理方案。

首先，如果把渠道文件還放在META－INF目錄下的話，重新簽名時(shí)渠道文件會(huì)被刪掉。所以，渠道文件需要重新找一個(gè)合理的地方存放。之前的文章也提到過，還有一個(gè)assets目錄。assets目錄和META－INF目錄一樣，可以隨便放入小文件。如果是空文件不需要重新簽名

加入渠道時(shí)主要有以下步驟。

首先需要準(zhǔn)備好渠道文件。在Android應(yīng)用程序包的同級(jí)目錄，新建一個(gè)assets目錄，并且在該目錄下放入一個(gè)channel.txt文件，文件內(nèi)容是渠道信息，可以是wandoujia或360等。

使用AAPT加入渠道文件：

'' aapt add wandoujia.apk asserts/channel.txt

在渠道加入后，重新簽名APK文件并且進(jìn)行對齊。

重新簽名相關(guān)的步驟就不再介紹了，如果感興趣的話，推薦看一下calabash-android這個(gè)開源項(xiàng)目的resign相關(guān)部分實(shí)現(xiàn)，calabash的重新簽名實(shí)現(xiàn)是我見過最嚴(yán)謹(jǐn)?shù)摹?/p>

圖3 豌豆莢打包方案處理一個(gè)包需要大約4秒

說完了豌豆莢多渠道打包的實(shí)現(xiàn)部分以后，需要來談一下效率。之前的兩種多渠道打包方案效率都很高，處理一個(gè)包都能在1秒之內(nèi)完成。但豌豆莢的多渠道打包方案由于必須重新簽名，會(huì)慢一些（但也沒有慢多少）。在屏蔽了一些關(guān)鍵信息之后，從圖3中可以看到，一次處理大概需要4秒的時(shí)間?，F(xiàn)在一臺(tái)一般配置的計(jì)算機(jī)，開8個(gè)線程處理，速度完全可以接受。

從安全的角度看多渠道打包方案

三種打包方案都是高效的實(shí)現(xiàn)，當(dāng)然也有各自的側(cè)重點(diǎn)。以下，從安全的角度來分析。

對于Android應(yīng)用包的安全問題來說，主要需要考慮渠道被惡意篡改的可能性和成本。如果一個(gè)渠道商，通過網(wǎng)絡(luò)劫持和篡改渠道的組合方式來獲取暴利，對于程序開發(fā)者來說可能會(huì)存在著巨大的經(jīng)濟(jì)損失。

在介紹篡改渠道之前，還是先簡單介紹AAPT這個(gè)工具的一般使用方法。AAPT是在AndroidSDK內(nèi)的一個(gè)命令行工具，具體位置在AndroidSDK目錄下的build-tools/19.0.0或者其他版本下，AAPT并不存在于每個(gè)發(fā)行版本中，所以一般使用的AAPT是19.0.0或19.0.1版本。

使用AAPT主要有以下4種場景：

查看Android開發(fā)包的基本信息，例如：包名、版本等。以微信的Android版本為例：

'' INPUT? apt dump badging weixin.apk

'' OUTPUT package: name='com.tencent.mm' versionCode='740' versionName='6.3.13.49_r4080b63'

'' uses-permission:'com.tencent.mm.plugin.permission.READ'

'' uses-permission:'com.tencent.mm.plugin.permission.WRITE'

'' uses-permission:'com.tencent.mm.permission.MM_MESSAGE'

''? uses-permission:'com.huawei.authentication.HW_ACCESS_AUTH_SERVICE'

'' sdkVersion:'15'

'' targetSdkVersion:'23'

'' uses-feature-not-required:'android.hardware.camera'

'' uses-feature-not-required:'android.hardware.camera.autofocus'

'' uses-feature-not-required:'android.hardware.bluetooth'

'' uses-feature-not-required:'android.hardware.location'

'' uses-feature-not-required:'android.hardware.location.gps'

'' uses-feature-not-required:'android.hardware.location.network'

'' uses-feature-not-required:'android.hardware.microphone'

'' uses-feature-not-required:'android.hardware.telephony'

'' uses-feature-not-required:'android.hardware.touchscreen'

'' uses-feature-not-required:'android.hardware.wifi'

'' uses-permission:'android.permission.ACCESS_NETWORK_STATE'

'' uses-permission:'android.permission.ACCESS_COARSE_LOCATION'

'' uses-permission:'android.permission.ACCESS_FINE_LOCATION'

'' uses-permission:'android.permission.CAMERA'

'' .....

從以上代碼可以看到這個(gè)微信的版本信息，并且知道了微信的包名是：com.tencent.mm，還能看到微信這個(gè)應(yīng)用使用到了哪些權(quán)限等信息（更多的信息還是交給讀者自己仔細(xì)研究吧）。

使用AAPT查看Android開發(fā)包的目錄結(jié)構(gòu)如下：

'' INPUT? aapt list? weixin.apk

'' OUTPUT META-INF/MANIFEST.MF

''? META-INF/COM_TENC.SF

''? META-INF/COM_TENC.RSA

''? assets/jsapi/wxjs.js

''? assets/avatar/default_nor_avatar.png

''? assets/avatar/default_meishiapp.png

''? assets/avatar/default_hd_avatar.png

''? assets/ipcall_country_code.txt

''? assets/merged_features.xml

''? assets/address

''? .....

又看到了META－INF目錄和assets目錄。一般在Android的應(yīng)用中assets都會(huì)放一些靜態(tài)的資源。

使用AAPT添加一個(gè)文件：

'' INPUT aapt add wandoujia.apk? assets/channel.txt

使用AAPT刪除一個(gè)文件

'' INPUT aapt remove wandoujia.apk assets/channel.txt

在掌握了以上簡單的四個(gè)命令行后，修改美團(tuán)的渠道就已經(jīng)非常簡單了。先通過list命令找到渠道文件，然后直接刪除文件，最后再加入自己的惡意渠道。但豌豆莢的渠道也可以通過相同的方式來進(jìn)行篡改，但篡改之后需要重新簽名。在沒有官方的簽名文件時(shí)，是沒有辦法完全偽造一個(gè)相同的簽名的。

添加comments多渠道打包方式中雖然渠道信息不是明文顯示，但也存在著被篡改的可能性。如果自己進(jìn)行一些簡單的加密可以杜絕大多數(shù)的惡意篡改，但由于不需要重新簽名，這種方法還是存在著被篡改的機(jī)率的。

具體選擇哪一種多渠道打包方式，還是由業(yè)務(wù)決定的。豌豆莢作為一個(gè)應(yīng)用商店，需要有自己的渠道，渠道的安全性會(huì)很不好。如果是一個(gè)普通的App，一般都是在一些應(yīng)用商店上發(fā)布新版本，應(yīng)用商店本身會(huì)給開發(fā)者提供相對安全的環(huán)境。所以這也就是美團(tuán)方案依然能夠使用的關(guān)鍵。

結(jié)束語

本文重點(diǎn)介紹了3種高效的多渠道打包方式。這三種方式都不會(huì)產(chǎn)生二次編譯，二次編譯會(huì)對一個(gè)版本的程序產(chǎn)生多個(gè)版本的符號(hào)表，在后期的問題追查中會(huì)有很多障礙。利用結(jié)束語簡單說說符號(hào)表的重要性吧。

當(dāng)程序正確打包發(fā)布以后，可以通過各種免費(fèi)、收費(fèi)或自己開發(fā)的工具來收集Crash等堆棧信息，查看錯(cuò)誤并進(jìn)行改正。你可能會(huì)得到一段這樣的異常堆棧：

'' ava.lang.RuntimeException: There is no view set with ViewPackage found in the log tree.

'' at o.λ.?(:64)

'' at o.λ.ˊ(:25)

'' at o.к$ˋ.run(:233)

'' at android.os.Handler.handleCallback(Handler.java:733)

'' at android.os.Handler.dispatchMessage(Handler.java:95)

'' at android.os.Looper.loop(Looper.java:136)

'' at android.os.HandlerThread.run(HandlerThread.java:61)

然后如果沒有一個(gè)符號(hào)表幫忙，你會(huì)陷入深深的沉思：這到底是什么問題？我的代碼在哪里？如果有了正確的符號(hào)表，一條命令行就可以就可以把相關(guān)的異常堆棧信息翻譯正確。符號(hào)表和編譯過程有著緊密的耦合，所以在選擇打包工具時(shí)，都應(yīng)該選擇不產(chǎn)生二次編譯的工具。在以上提到的三款工具中，添加多渠道都是基于已有APK進(jìn)行添加的，并不是基于源碼來添加渠道。所以都完全滿足條件。

考慮到文章的篇幅，有一些內(nèi)容沒有展開說，開發(fā)者如果遇到這方面的問題，歡迎與我交流。