Android打包的那些事

時間  2019-11-06
標籤 android 打包 那些 欄目 Android 简体版
原文   原文鏈接

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

1. 替換AndroidManifest中的佔位符

我想把其中的${app_label}替換爲@string/app_nameandroid

android{
    defaultConfig{
        manifestPlaceholders = [app_label:"@string/app_name"]
    }
}

若是隻想替換debug版本：ios

android{
    buildTypes {
        debug {
              manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
        }
    }
}

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

android{
    productFlavors {
        // 把dev產品型號的apk的AndroidManifest中的channel替換dev
        "dev"{
            manifestPlaceholders = [channel:"dev"]
        }
    }
}

2. 獨立配置簽名信息

對於簽名相關的信息,直接寫在gradle固然很差,特別是一些開源項目，能夠添加到local.properties:github

RELEASE_KEY_PASSWORD=xxxx
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks

而後在build.gradle中引用便可：app

android {
    signingConfigs {
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }
}

爲了更省事，小規模團隊可考慮添加到gradle.properties或者另外再創建一個單獨的properties，而後提交到版本庫中，方便你們共享。ide

3. 多渠道打包

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

android {
    productFlavors {
        dev{
            manifestPlaceholders = [channel:"dev"]
        }
        official{
            manifestPlaceholders = [channel:"official"]
        }
        // ... ...
        wandoujia{
            manifestPlaceholders = [channel:"wandoujia"]
        }
        xiaomi{
            manifestPlaceholders = [channel:"xiaomi"]
        }
        "360"{
            manifestPlaceholders = [channel:"360"]
        }
}

注意一點，這裏的flavor名若是是數字開頭，必須用引號引發來。
構建一下，就能生成一系列的Build Variant了:學習

devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release

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

4. 自定義Build Type

前面說到默認的build type有兩種debug和release，區別以下：

// release版本生成的BuildConfig特性信息
public final class BuildConfig {
  public static final boolean DEBUG = false;
  public static final String BUILD_TYPE = "release";
}
// debug版本生成的BuildConfig特性信息
public final class BuildConfig {
  public static final boolean DEBUG = true;
  public static final String BUILD_TYPE = "debug";
}

如今有一種需求，增長一種build type，介於debug和release之間，就是和release版本同樣，可是要保留debug狀態（若是作過rom開發的話，相似於user debug版本），咱們稱爲preview版本吧。
其實很簡單：

android {
    signingConfigs {
        debug {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        preview {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }

    buildTypes {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
        }
    }
}

另外，build type還有一個好處，若是想要一次性生成全部的preview版本，執行assemblePreview便可，debug和releae版本同理。

5. build type中的定製參數

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

android {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
            applicationIdSuffix ".debug"
            minifyEnabled false
            signingConfig signingConfigs.debug
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
            applicationIdSuffix ".preview"
            debuggable true // 保留debug信息
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.preview
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

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

// minifyEnabled 混淆處理
// shrinkResources 去除無用資源
// signingConfig 簽名
// proguardFiles 混淆配置
// applicationIdSuffix 增長APP ID的後綴
// debuggable 是否保留調試信息
// ... ...

6. 多工程全局配置

隨着產品渠道的鋪開，每每一套代碼須要支持多個產品形態，這就須要抽象出主要代碼到一個Library，而後基於Library擴展幾個App Module。
相信每一個module的build.gradle都會有這個代碼：

android {
    compileSdkVersion 22
    buildToolsVersion "23.0.1"

    defaultConfig {
        minSdkVersion 10
        targetSdkVersion 22
        versionCode 34
        versionName "v2.6.1"
    }
}

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

ext {
    compileSdkVersion = 22
    buildToolsVersion = "23.0.1"
    minSdkVersion = 10
    targetSdkVersion = 22
    versionCode = 34
    versionName = "v2.6.1"
}

而後在各module的build.gradle中引用以下：

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion

    defaultConfig {
        applicationId "com.xxx.xxx"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode rootProject.ext.versionCode
        versionName rootProject.ext.versionName
    }
}

而後每次修改project級別的build.gradle便可實現全局統一配置。

7. 自定義導出的APK名稱

默認android studio生成的apk名稱爲app-debug.apk或者app-release.apk，當有多個渠道的時候，須要同時編出50個渠道包的時候，就麻煩了，不知道誰是誰了。
這個時候，就須要自定義導出的APK名稱了，不一樣的渠道編出的APK的文件名應該是不同的。

android {
    // rename the apk with the version name
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent,
                    "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

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

android {
    // rename the apk with the version name
    // add output file sub folder by build type
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent + "/${variant.buildType.name}",
                    "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

如今生成了相似於ganchai-dev-preview-v2.4.0.0.apk這樣格式的包了，preview的包天然就放在preview的文件夾下，清晰明瞭。

8. 混淆技巧

混淆能讓反編譯的代碼可讀性變的不好，並且還能顯著的減小APK包的大小。

1). 第一個技巧

相信不少朋友對混淆都以爲麻煩，甚至說，很是亂。由於添加混淆規則須要查詢官方說明文檔，甚至有的官方文檔還沒說明。當你引用了太多庫後，添加混淆規則將使一場噩夢。
這裏介紹一個技巧，不用查官方文檔，不用逐個庫考慮添加規則。
首先，除了默認的混淆配置(android-sdk/tools/proguard/proguard-android.txt), 本身的代碼確定是要本身配置的：

## 位於module下的proguard-rules.pro
#####################################
######### 主程序不能混淆的代碼 #########
#####################################

-dontwarn xxx.model.**
-keep class xxx.model.** { *; }

## 等等，本身的代碼本身清楚

#####################################
########### 不優化泛型和反射 ##########
#####################################

-keepattributes Signature

接下來是麻煩的第三方庫，通常來講，若是是極光推的話，它的包名是cn.jpush, 添加以下代碼便可：

-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }

其餘的第三庫也是如此，一個一個添加，太累！其實能夠用第三方反編譯工具（好比jadx：https://github.com/skylot/jadx ），打開apk後，一眼就能看到引用的全部第三方庫的包名，把全部不想混淆或者不肯定能不能混淆的，直接都添加又有何不可：

#####################################
######### 第三方庫或者jar包 ###########
#####################################

-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }

-dontwarn com.squareup.**
-keep class com.squareup.** { *; }

-dontwarn com.octo.**
-keep class com.octo.** { *; }

-dontwarn de.**
-keep class de.** { *; }

-dontwarn javax.**
-keep class javax.** { *; }

-dontwarn org.**
-keep class org.** { *; }

-dontwarn u.aly.**
-keep class u.aly.** { *; }

-dontwarn uk.**
-keep class uk.** { *; }

-dontwarn com.baidu.**
-keep class com.baidu.** { *; }

-dontwarn com.facebook.**
-keep class com.facebook.** { *; }

-dontwarn com.google.**
-keep class com.google.** { *; }

## ... ...

2). 第二個技巧

通常release版本混淆以後，像友盟這樣的統計系統若是有崩潰異常，會記錄以下：

java.lang.NullPointerException: java.lang.NullPointerException
    at com.xxx.TabMessageFragment$7.run(Unknown Source)

這個Unknown Source是很要命的，排除錯誤沒法定位到具體行了，大大下降調試效率。
固然，友盟支持上傳Mapping文件，可幫助定位，mapping文件的位置在：

project > module
        > build > outputs > {flavor name} > {build type} > mapping.txt

若是版本一多，mapping.txt每次都要從新生成，還要上傳，終歸仍是麻煩。
其實，在proguard-rules.pro中添加以下代碼便可：

-keepattributes SourceFile,LineNumberTable

固然apk包會大那麼一點點（我這裏6M的包，大個200k吧），可是不再用mapping.txt也能定位到行了，爲了這種解脫，這個代價我我的以爲是值的，並且超值！

9. 動態設置一些額外信息

假如想把當前的編譯時間、編譯的機器、最新的commit版本添加到apk，而這些信息又很差寫在代碼裏，強大的gradle給了我創造可能的自信：

android {
    defaultConfig {
        resValue "string", "build_time", buildTime()
        resValue "string", "build_host", hostName()
        resValue "string", "build_revision", revision()
    }
}

def buildTime() {
    return new Date().format("yyyy-MM-dd HH:mm:ss")
}
def hostName() {
    return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
}
def revision() {
    def code = new ByteArrayOutputStream()
    exec {
        commandLine 'git', 'rev-parse', '--short', 'HEAD'
        standardOutput = code
    }
    return code.toString()
}

上述代碼實現了動態的添加了3個字符串資源: build_time、build_host、build_revision, 而後在其餘地方可像如引用字符串同樣使用以下：

// 在Activity裏調用
getString(R.string.build_time)  // 輸出2015-11-07 17:01
getString(R.string.build_host)  // 輸出jay@deepin，這是個人電腦的用戶名和PC名
getString(R.string.build_revision) // 輸出3dd5823, 這是最後一次commit的sha值

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

10. 給本身留個"後門": 點七下

爲了調試方便，咱們每每會在debug版本留一個顯示咱們想看的界面（記得以前微博的一個iOS版本就泄露了一個調試界面），如何進入到一個界面，咱們能夠仿照android開發者選項的方式，點七下才顯示，咱們來實現一個：

private int clickCount = 0;
private long clickTime = 0;

sevenClickView.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {

        if (clickTime == 0) {
            clickTime = System.currentTimeMillis();
        }
        if (System.currentTimeMillis() - clickTime > 500) {
            clickCount = 0;
        } else {
            clickCount++;
        }
        clickTime = System.currentTimeMillis();

        if (clickCount > 6) {
            // 點七下條件達到，跳到debug界面
        }
    }
});

release版本確定是不能暴露這個界面的，也不能讓人用am在命令行調起，如何防止呢，能夠在release版本把這個debug界面的exported設爲false。

11. 自動化構建

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

12. 小結

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

同步首發：http://www.jayfeng.com/2015/11/07/Android%E6%89%93%E5%8C%85%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B/

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程