Android打包的那些事

使用gradle打包apk已經成為當前主流趨勢，我也在這個過程中經歷了各種需求，並不斷結合gradle新的支援，一一改進。在此，把這些相關的東西記錄，做一總結。

 

1. 替換AndroidManifest中的佔位符

我想把其中的${app_label}替換為@string/app_name

如果只想替換debug版本：

更多的需求是替換渠道編號：

 

2. 獨立配置簽名資訊

對於簽名相關的資訊,直接寫在gradle當然不好,特別是一些開源專案，可以新增到gradle.properties:

然後在build.gradle中引用即可：

如果不想提交到版本庫，可以新增到local.properties中，然後在build.gradle中讀取。

 

3. 多渠道打包

多渠道打包的關鍵之處在於，定義不同的product flavor, 並把AndroiManifest中的channel渠道編號替換為對應的flavor標識：

注意一點，這裡的flavor名如果是數字開頭，必須用引號引起來。
構建一下，就能生成一系列的Build Variant了:

其中debug, release是gradle預設自帶的兩個build type, 下一節還會繼續說明。
選擇一個，就能編譯出對應渠道的apk了。

 

4. 自定義Build Type

前面說到預設的build type有兩種debug和release，區別如下：

現在有一種需求，增加一種build type，介於debug和release之間，就是和release版本一樣，但是要保留debug狀態（如果做過rom開發的話，類似於user debug版本），我們稱為preview版本吧。
其實很簡單：

另外，build type還有一個好處，如果想要一次性生成所有的preview版本，執行assemblePreview即可，debug和releae版本同理。

 

5. build type中的定製引數

上面我們在不同的build type替換${app_label}為不同的字串，這樣安裝到手機上就能明顯的區分出不同build type的版本。
除此之外，可能還可以配置一些引數，我這裡列幾個我在工作中用到的：

這些都用的太多了，稍微解釋一下：

 

6. 多工程全域性配置

隨著產品渠道的鋪開，往往一套程式碼需要支援多個產品形態，這就需要抽象出主要程式碼到一個Library，然後基於Library擴充套件幾個App Module。
相信每個module的build.gradle都會有這個程式碼：

當升級sdk、build tool、target sdk等，幾個module都要更改，非常的麻煩。最重要的是，很容易忘記，最終導致app module之間的差異不統一，也不可控。
強大的gradle外掛在1.1.0支援全域性變數設定，一舉解決了這個問題。
先在project的根目錄下的build.gradle定義ext全域性變數:

然後在各module的build.gradle中引用如下：

然後每次修改project級別的build.gradle即可實現全域性統一配置。

 

7. 自定義匯出的APK名稱

預設android studio生成的apk名稱為app-debug.apk或者app-release.apk，當有多個渠道的時候，需要同時編出50個渠道包的時候，就麻煩了，不知道誰是誰了。
這個時候，就需要自定義匯出的APK名稱了，不同的渠道編出的APK的檔名應該是不一樣的。

當apk太多時，如果能把apk按debug，release，preview分一下類就更好了（事實上，對於我這樣經常發版的人，一編往往就要編四五十個版本的人，debug和release版本全混在一起沒法看，必須分類），簡單：

現在生成了類似於ganchai-dev-preview-v2.4.0.0.apk這樣格式的包了，preview的包自然就放在preview的資料夾下，清晰明瞭。

 

8. 混淆技巧

混淆能讓反編譯的程式碼可讀性變的很差，而且還能顯著的減少APK包的大小。

1). 第一個技巧

相信很多朋友對混淆都覺得麻煩，甚至說，非常亂。因為新增混淆規則需要查詢官方說明文件，甚至有的官方文件還沒說明。當你引用了太多庫後，新增混淆規則將使一場噩夢。
這裡介紹一個技巧，不用查官方文件，不用逐個庫考慮新增規則。
首先，除了預設的混淆配置(android-sdk/tools/proguard/proguard-android.txt), 自己的程式碼肯定是要自己配置的：

接下來是麻煩的第三方庫，一般來說，如果是極光推的話，它的包名是cn.jpush, 新增如下程式碼即可：

其他的第三庫也是如此，一個一個新增，太累！其實可以用第三方反編譯工具（比如jadx：https://github.com/skylot/jadx ），開啟apk後，一眼就能看到引用的所有第三方庫的包名，把所有不想混淆或者不確定能不能混淆的，直接都新增又有何不可：

2). 第二個技巧

一般release版本混淆之後，像友盟這樣的統計系統如果有崩潰異常，會記錄如下：

這個Unknown Source是很要命的，排除錯誤無法定位到具體行了，大大降低除錯效率。
當然，友盟支援上傳Mapping檔案，可幫助定位，mapping檔案的位置在：

如果版本一多，mapping.txt每次都要重新生成，還要上傳，終歸還是麻煩。
其實，在proguard-rules.pro中新增如下程式碼即可：

當然apk包會大那麼一點點（我這裡6M的包，大個200k吧），但是再也不用mapping.txt也能定位到行了，為了這種解脫，這個代價我個人覺得是值的，而且超值！

 

9. 動態設定一些額外資訊

假如想把當前的編譯時間、編譯的機器、最新的commit版本新增到apk，而這些資訊又不好寫在程式碼裡，強大的gradle給了我創造可能的自信：

上述程式碼實現了動態的新增了3個字串資源: build_time、build_host、build_revision, 然後在其他地方可像如引用字串一樣使用如下：

這個地方，如何從命令列讀取返回結果，很有意思。
其實這段程式碼來自我學習VLC原始碼時偶然看到，深受啟發，不敢獨享，特摘抄在此。
vlc原始碼及編譯地址：https://wiki.videolan.org/AndroidCompile， 有興趣可以過去一觀。

 

10. 給自己留個”後門”: 點七下

為了除錯方便，我們往往會在debug版本留一個顯示我們想看的介面（記得之前微博的一個iOS版本就洩露了一個除錯介面），如何進入到一個介面，我們可以仿照android開發者選項的方式，點七下才顯示，我們來實現一個：

release版本肯定是不能暴露這個介面的，也不能讓人用am在命令列調起，如何防止呢，可以在release版本把這個debug介面的exported設為false。

 

11. 自動化構建

如何使用jenkins打包android和ios，並上傳到蒲公英平臺，這個可以參考我的另外一篇文章專門介紹: 《使用jenkins自動化構建android和ios應用》，不過，這篇文章還沒寫完，實際上在公司裡已經一直在用了，哪天心情好了總會寫完的，這裡不再贅述。

 

12. 小結

android打包因為groovy語言的強大，變的強大的同時必然也變的複雜，今天把我經歷的這些門道拿出來說道一下，做一個小小的總結，後續有更新我還會新增。