Android教程網
設為首頁|加入收藏
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> Android打包的那些事，Android打包那些事

Android打包的那些事，Android打包那些事

編輯：關於android開發

Android打包的那些事，Android打包那些事


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

1. 替換AndroidManifest中的占位符

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

1
2
3
4
5
android{
    defaultConfig{
        manifestPlaceholders = [app_label:"@string/app_name"]
    }
}

 

如果只想替換debug版本：

1
2
3
4
5
6
7
8
9
android{
    buildTypes {
        debug {
	          manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
        }
    }
}

 

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

1
2
3
4
5
6
7
8
android{
    productFlavors {
        // 把dev產品型號的apk的AndroidManifest中的channel替換dev
        "dev"{
            manifestPlaceholders = [channel:"dev"]
        }
    }
}

 

2. 獨立配置簽名信息

對於簽名相關的信息,直接寫在gradle當然不好,特別是一些開源項目，可以添加到local.properties:

1
2
3
4
RELEASE_KEY_PASSWORD=xxxx
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks

 

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

1
2
3
4
5
6
7
8
9
10
android {
    signingConfigs {
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }
}

 

為了更省事，小規模團隊可考慮添加到gradle.properties或者另外再建立一個單獨的properties，然後提交到版本庫中，方便大家共享。

3. 多渠道打包

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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了:

1
2
3
4
5
6
7
8
9
10
devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release

 

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

4. 自定義Build Type

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

1
2
3
4
5
6
7
8
9
10
// 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版本吧。
其實很簡單：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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的版本。
除此之外，可能還可以配置一些參數，我這裡列幾個我在工作中用到的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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'
        }
    }
}

 

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

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

 

6. 多工程全局配置

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

1
2
3
4
5
6
7
8
9
10
11
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全局變量:

1
2
3
4
5
6
7
8
ext {
    compileSdkVersion = 22
    buildToolsVersion = "23.0.1"
    minSdkVersion = 10
    targetSdkVersion = 22
    versionCode = 34
    versionName = "v2.6.1"
}

 

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

1
2
3
4
5
6
7
8
9
10
11
12
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的文件名應該是不一樣的。

1
2
3
4
5
6
7
8
9
10
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版本全混在一起沒法看，必須分類），簡單：

1
2
3
4
5
6
7
8
9
10
11
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), 自己的代碼肯定是要自己配置的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
## 位於module下的proguard-rules.pro
#####################################
######### 主程序不能混淆的代碼 #########
#####################################

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

## 等等，自己的代碼自己清楚

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

-keepattributes Signature

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

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

 

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#####################################
######### 第三方庫或者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版本混淆之後，像友盟這樣的統計系統如果有崩潰異常，會記錄如下：

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

 

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

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

 

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

1
-keepattributes SourceFile,LineNumberTable

 

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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, 然後在其他地方可像如引用字符串一樣使用如下：

1
2
3
4
// 在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開發者選項的方式，點七下才顯示，我們來實現一個：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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語言的強大，變的強大的同時必然也變的復雜，今天把我經歷的這些門道拿出來說道一下，做一個小小的總結，後續有更新我還會添加。

全能程序員交流QQ群290551701，聚集很多互聯網精英,技術總監,架構師,項目經理!開源技術研究,歡迎業內人士,大牛及新手有志於從事IT行業人員進入!

  1. 上一頁:
  2. 下一頁:
關於android開發
開發入門初級開發中級開發高級開發關於android開發
相關文章
熱門文章
Linux動態鏈接庫加載失敗一例 Building Apps with Over 65K Methods（解決APP引用方法總數超過65536），appsapp Android應用開發教程之二十二：內存洩漏調試學習與總結 Android開發2：事件處理及實現簡單的對話框，android開發 Android MVP開發模式詳解(十九) 位圖索引(Bitmap Index)與數據DML LOCK場景問題解析
Android防微信首頁左右滑動切換，android防微

Android防微信首頁左右滑動切換，android防微大家看到微信首頁
Intent(一.顯示使用intent)，顯示使用intent

Intent(一.顯示使用intent)，顯示使用intent 
Form and Control KeyEvent

Form and Control KeyEvent一、Form的KeyE
FFmpeg使用手冊 - FFmpeg 的常用命令

FFmpeg使用手冊 - FFmpeg 的常用命令ffmpeg在做音視頻
閱讀排行版
Copyright © Android教程網 All Rights Reserved