從上面兩張圖可以看出：經(jīng)過混淆處理之后，我們的 APK 中包名、類名、成員名等都被替換為隨機(jī)、無意義的名稱，增加了代碼閱讀和理解的困難程度，提高了反編譯的成本。細(xì)心的小伙伴可能又會注意到：混淆前后 APK 的體積竟然從 2.7M 減小到了 1.4M，體積縮減了近一倍！真的有這么神奇嗎？哈哈，確實(shí)是這么神奇，讓我們慢慢來揭開它的神秘面紗吧。

在 Android 中，我們平常所說的"混淆"其實(shí)有兩層意思，一個是 JAVA

代碼的混淆

資源的壓縮

啟用混淆

......android { buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } }}

以上就是開啟混淆的基本操作了，通過

minifyEnabled

shrinkResources

proguard-android.txt

proguard-rules.pro

代碼混淆

其實(shí)，Java 平臺為我們提供了

Proguard

壓縮

優(yōu)化

混淆

校驗(yàn)

資源壓縮

Android 中，編譯器為我們提供了另外一項(xiàng)強(qiáng)大的功能：

資源的壓縮

切記要先開啟代碼混淆

ERROR: Removing unused resources requires unused code shrinking to be turned on. See http://d.android.com/r/tools/shrink-resources.html for more information.Affected Modules: app

自定義要保留的資源

當(dāng)我們開啟了資源壓縮之后，系統(tǒng)會默認(rèn)替我們移除所有未使用的資源，假如我們需要保留某些特定的資源，可以在我們項(xiàng)目中創(chuàng)建一個被 標(biāo)記的 XML 文件（如 res/raw/keep.xml），并在 tools:keep 屬性中指定每個要保留的資源，在 tools:discard 屬性中指定每個要舍棄的資源。這兩個屬性都接受逗號分隔的資源名稱列表。同樣，我們可以使用字符

*

<?xml version="1.0" encoding="utf-8"?>

啟用嚴(yán)格檢查模式

正常情況下，資源壓縮器可準(zhǔn)確判定系統(tǒng)是否使用了資源。不過，如果您的代碼（包含庫）調(diào)用 Resources.getIdentifier()，這就表示您的代碼將根據(jù)動態(tài)生成的字符串查詢資源名稱。這時，資源壓縮器會采取防御性行為，將所有具有匹配名稱格式的資源標(biāo)記為可能已使用，無法移除。例如，以下代碼會使所有帶 img_ 前綴的資源標(biāo)記為已使用：

String name = String.format("img_%1d", angle + 1);res = getResources().getIdentifier(name, "drawable", getPackageName());

這時，我可以開啟資源的嚴(yán)格審查模式，只會保留確定已使用的資源。

移除備用資源

Gradle 資源壓縮器只會移除未被應(yīng)用引用的資源，這意味著它不會移除用于不同設(shè)備配置的備用資源。必要時，我們可以使用 Android Gradle 插件的 resConfigs 屬性來移除您的應(yīng)用不需要的備用資源文件（常見的有用于國際化支持的 strings.xml，適配用的 layout.xml 等）：

android { defaultConfig { ... //保留中文和英文國際化支持 resConfigs "en", "zh" }}自定義混淆規(guī)則

品嘗完了以上"配菜"，下面讓我們來品味一下本文的"主菜"：

自定義混淆規(guī)則

keep 命令

這里說的

keep

-keep

-keep

# 保留包：com.moos.media.entity 下面的類以及類成員-keep public class com.moos.media.entity.**# 保留類：NumberProgressBar-keep public class com.moos.media.widget.NumberProgressBar {*;}

-keepclassmembers

# 保留類的成員：MediaUtils類中的特定成員方法-keepclassmembers class com.moos.media.MediaUtils { public static *** getLocalVideos(android.content.Context); public static *** getLocalPictures(android.content.Context);}

-keepclasseswithmembers

# 保留類：BaseMediaEntity 的子類-keepclasseswithmembers public class * extends com.moos.media.entity.BaseMediaEntity{*;}# 保留類：OnProgressBarListener接口的實(shí)現(xiàn)類-keep public class * implements com.moos.media.widget.OnProgressBarListener {*;}

@Keep

@Keep

@Keepdata class CloudMusicBean(var createDate: String, var id: Long, var name: String, var url: String, val imgUrl: String)同樣地，我們也可以讓 @Keep 來修飾方法或者字段進(jìn)而保留它們。其他命令

dontwarn

-keep class twitter4j.** { *; }-dontwarn twitter4j.**其他的命令用法可參考 Android 系統(tǒng)提供的默認(rèn)混淆規(guī)則：

#混淆時不生成大小寫混合的類名-dontusemixedcaseclassnames#不跳過非公共的庫的類-dontskipnonpubliclibraryclasses#混淆過程中記錄日志-verbose#關(guān)閉預(yù)校驗(yàn)-dontpreverify#關(guān)閉優(yōu)化-dontoptimize#保留注解-keepattributes *Annotation*#保留所有擁有本地方法的類名及本地方法名-keepclasseswithmembernames class * { native ;}#保留自定義View的get和set方法-keepclassmembers public class * extends android.view.View { void set*(***); *** get*();}#保留Activity中View及其子類入?yún)⒌姆椒ǎ? onClick(android.view.View)-keepclassmembers class * extends android.app.Activity { public void *(android.view.View);}#保留枚舉-keepclassmembers enum * { **[] $VALUES; public *;}#保留序列化的類-keepclassmembers class * implements android.os.Parcelable { public static final android.os.Parcelable$Creator CREATOR;}#保留R文件的靜態(tài)成員-keepclassmembers class **.R$* { public static ;}-dontwarn android.support.**-keep class android.support.annotation.Keep-keep @android.support.annotation.Keep class * {*;}-keepclasseswithmembers class * { @android.support.annotation.Keep ;}-keepclasseswithmembers class * { @android.support.annotation.Keep ;}-keepclasseswithmembers class * { @android.support.annotation.Keep (...);}混淆"黑名單"

我們在了解了混淆的基本命令之后，很多人應(yīng)該還是一頭霧水：到底哪些內(nèi)容該混淆？其實(shí)，我們在使用代碼混淆時，

ProGuard

哪些元素不應(yīng)該被混淆

枚舉

項(xiàng)目中難免可能會用到枚舉類型，然而它不能參與到混淆當(dāng)中去。原因是：枚舉類內(nèi)部存在 values 方法，混淆后該方法會被重新命名，并拋出

NoSuchMethodException

被反射的元素

被反射使用的類、變量、方法、包名等不應(yīng)該被混淆處理。原因在于：代碼混淆過程中，被反射使用的元素會被重命名，然而反射依舊是按照先前的名稱去尋找元素，所以會經(jīng)常發(fā)生

NoSuchMethodException

NoSuchFiledException

實(shí)體類

實(shí)體類即我們常說的"數(shù)據(jù)類"，當(dāng)然經(jīng)常伴隨著

序列化

反序列化

反射

四大組件

Android 中的四大組件同樣不應(yīng)該被混淆。原因在于：

AndroidManifest.xml

JNI 調(diào)用的Java 方法

當(dāng) JNI 調(diào)用的 Java 方法被混淆后，方法名會變成無意義的名稱，這就與 C++ 中原本的 Java 方法名不匹配，因而會無法找到所調(diào)用的方法。

其他不應(yīng)該被混淆的

代碼經(jīng)過 ProGuard 混淆處理后，想要讀取

StackTrace

混淆輸出結(jié)果

混淆構(gòu)建完成之后，會在

/build/outputs/mapping/release/

dump.txt

mapping.txt

seeds.txt

usage.txt

恢復(fù)堆棧跟蹤

了解完混淆構(gòu)建完畢后輸出的內(nèi)容之后，我們現(xiàn)在就來看一下之前的問題：混淆處理后，StackTrace 定位困難。如何來恢復(fù) StackTrace 的定位能力呢？系統(tǒng)為我們提供了

retrace

mapping.txt

崩潰堆棧追蹤信息

StackTrace

java.lang.RuntimeException: Unable to start activity Caused by: kotlin.KotlinNullPointerException at com.moos.media.ui.ImageSelectActivity.k(ImageSelectActivity.kt:71) at com.moos.media.ui.ImageSelectActivity.onCreate(ImageSelectActivity.kt:58) at android.app.Activity.performCreate(Activity.java:6237) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1107)通過 retrace 腳本工具首先我們要進(jìn)入到 Android SDK 路徑的

/tools/proguard/bin