ProGuard — ano ito, mga kakayahan at configuration ng obfuscation

Ano ang ProGuard?

ProGuard — isang malayang ipinamamahagi na tool para sa pagproseso ng Java bytecode, na binuo ng kumpanyang Guardsquare. Ito ay naka-embed sa Android SDK at gumaganap ng tatlong pangunahing function: compression (shrinking), optimization (optimization) at obfuscation (obfuscation) ng code. Sinusuri ng ProGuard ang lahat ng bytecode ng application at mga dependency nito, tinutukoy ang mga hindi ginagamit na klase at metodo, inaalis ang mga ito, at pagkatapos ay itinatago ang natitirang code.

Kasaysayan at Pagpoposisyon

ProGuard ay nilikha ni Éric Lafourge noong 2000 bilang isang optimization tool para sa mga Java application. Sa pagdating ng Android noong 2008, ang ProGuard ay isinama sa Android SDK at naging pamantayang tool para sa pagprotekta ng mga application. Ayon sa estadistika ng Guardsquare (2024), ang ProGuard ay ginagamit sa higit sa 80% ng mga application sa Google Play, kabilang ang mga application ng pinakamalaking bangko at kumpanya ng teknolohiya.

Paano Nagproseso ng Code ang ProGuard

ProGuard ay nagsasagawa ng pagproseso sa apat na yugto. Sa unang yugto (shrink) sinusuri ng tool ang mga entry point ng application at tinutukoy kung aling mga klase, metodo at field ang maaabot sa panahon ng pagpapatupad. Sa ikalawang yugto (optimize) binabago ng ProGuard ang bytecode para pahusayin ang performance. Ang ikatlong yugto (obfuscate) ay nagpapalit ng pangalan ng mga identifier. Sa huling yugto ang preverify ay nagdaragdag ng metadata na kinakailangan para sa pag-verify ng bytecode sa virtual machine.

Mga Pangunahing Kakayahan ng ProGuard

Tingnan natin nang detalyado ang bawat isa sa tatlong pangunahing function ng ProGuard: compression, optimization at obfuscation. Ang pag-unawa sa bawat mekanismo ay makakatulong upang i-configure ang tool sa pinakamainam na paraan.

Compression ng Code (Shrinking)

ProGuard ay sumusuri sa call graph mula sa mga entry point (main method, Activity, BroadcastReceiver) at nag-aalis ng hindi ginagamit na code. Sa isang tipikal na Android project na may mga library tulad ng Retrofit, OkHttp at Gson, ang compression ay maaaring mag-alis ng hanggang 40% ng bytecode, kabilang ang mga hindi ginagamit na metodo ng mga library, debug code at test class. Ito ay direktang nagpapaliit ng laki ng APK at nagpapaikli sa oras ng pag-load ng application.

Optimization (Optimization)

Sa yugto ng optimization, ang ProGuard ay nagsasagawa ng higit sa 20 iba't ibang pagbabago ng bytecode: inlining ng maiikling metodo, pag-alis ng hindi ginagamit na parameter, pagpapasimple ng logical expression, pagsasama ng magkaparehong code block. Halimbawa, ang maiikling getter at setter ay maaaring palitan ng direktang access sa field. Ang optimization ay maaaring pabilisin ang pagpapatupad ng code ng 5-15% depende sa istraktura ng application.

Obfuscation (Obfuscation)

Obfuscation sa ProGuard ay gumagana sa pamamagitan ng pagpapalit ng pangalan ng mga klase, metodo at field sa maiikling pagkakasunod-sunod ng character: a, b, c, a.a, a.b at iba pa. Lahat ng reference sa pinalitan ng pangalan na mga elemento ay awtomatikong ina-update sa buong code. Mahalagang tandaan na ang obfuscation ay hindi nagbabago ng pag-uugali ng programa, pinapahirapan lamang nito ang pag-unawa sa decompiled code. Ang mga library at pampublikong API ay dapat na ibukod mula sa obfuscation sa pamamagitan ng keep rules.

// Bago ang obfuscation ng ProGuard
public class LoginManager {
    public User authenticateUser(String username, String password) {
        // lohika ng pagpapatotoo
    }
}

// Pagkatapos ng obfuscation ng ProGuard
public class a {
    public Object a(String b, String c) {
        // parehong lohika na may pinalitan ng pangalan na identifier
    }
}

Configuration ng ProGuard sa Android Project

Configuration ng ProGuard — isang kritikal na yugto ng pag-setup ng build ng Android application. Ang maling mga panuntunan ay maaaring humantong sa pag-alis ng mga kinakailangang klase at, bilang resulta, sa crash sa release version.

Basic Configuration sa build.gradle

Pag-activate ng ProGuard sa Android project ay kinabibilangan ng pagtatakda ng flag na minifyEnabled sa true para sa release build type. Ang mga standard na panuntunan ng ProGuard ay kasama ng Android SDK sa file na proguard-android-optimize.txt. Ang mga custom na panuntunan ay idinaragdag sa isang hiwalay na file na proguard-rules.pro. Sa build, unang inilalapat ng ProGuard ang standard na panuntunan, pagkatapos ang custom na panuntunan, na nagpapahintulot sa pag-override ng basic configuration.

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

File na proguard-rules.pro

Ang custom na file ng panuntunan ay naglalaman ng mga direktiba na tiyak sa isang partikular na proyekto. Ang mga tipikal na panuntunan ay kinabibilangan ng pagpapanatili ng mga klase na ginagamit sa pamamagitan ng reflection, mga modelo ng data para sa serialization ng Gson/Moshi, callback interface ng mga library at mga klase na may annotation na may partikular na annotation. Bawat direktiba ay nagsisimula sa keyword na -keep, -dontwarn o -keepclassmembers at tumutukoy ng pattern ng klase na hindi dapat baguhin ng ProGuard.

# Panatilihin ang mga modelo ng data para sa Gson
-keep class com.example.data.model.** { *; }

# Panatilihin ang mga klase na ginagamit sa pamamagitan ng reflection
-keep class * implements com.google.gson.TypeAdapterFactory

# Huwag pansinin ang mga babala ng library
-dontwarn okhttp3.internal.**
-dontwarn retrofit2.**

# Panatilihin ang mga enum (tampok ng ProGuard)
-keep class * extends java.lang.Enum { *; }

Mga Panuntunan ng ProGuard: keep, dontwarn at iba pa

Ang gramatika ng configuration ng ProGuard ay may kasamang ilang kategorya ng mga direktiba, na ang bawat isa ay kumokontrol sa isang partikular na aspeto ng pagproseso. Tingnan natin ang mga pangunahing, na kinakailangan para sa tamang configuration.

Reflection at Dynamic na Pag-load

ProGuard ay hindi maaaring static na suriin ang code na na-load sa pamamagitan ng reflection (Class.forName()), ServiceLoader o dynamic na pag-load ng mga DEX file. Kung ang isang klase ay nilikha sa pamamagitan ng string name, hindi alam ng ProGuard ang pag-iral nito at maaaring alisin ito bilang hindi ginagamit. Lahat ng naturang klase ay dapat na tahasang panatilihin sa pamamagitan ng -keep. Ito ang pinakakaraniwang sanhi ng crash sa mga release build pagkatapos i-enable ang ProGuard.

Mga Library at AAR Dependency

Ang mga library ay madalas na may kasamang sariling ProGuard rules, na awtomatikong idinaragdag sa build sa pamamagitan ng consumer-rules.pro, na naka-embed sa AAR file. Awtomatikong inilalapat ng Android Gradle Plugin ang mga panuntunang ito sa build. Kailangan lamang tiyakin ng developer na ang lahat ng ginamit na library ay nagbibigay ng tamang panuntunan, at kung kinakailangan, dagdagan ang mga ito sa proyekto.

Pag-debug ng mga Problema sa ProGuard

Kapag may mga error pagkatapos i-enable ang ProGuard, gamitin ang mapping file para sa deobfuscation ng stack trace. Para sa diagnosis, ginagamit ang key na -whyareyoukeeping, na nagpapakita ng dahilan ng pagpapanatili ng klase sa final build. Ang pansamantalang pag-disable ng -optimizationpasses at -obfuscation ay nagbibigay-daan sa lokalisasyon ng problema. Ayon sa Guardsquare, 80% ng mga problema sa ProGuard ay naaayos sa pamamagitan ng pagdaragdag ng -keep rules para sa mga reflection class.

ProGuard at R8: paghahambing at migrasyon

Sa paglabas ng Android Gradle Plugin 3.4 (2019), ipinakilala ng Google ang R8 — ang kahalili ng ProGuard, na direktang isinama sa D8/R8 compiler. Pagsapit ng 2023, ganap na pinalitan ng R8 ang ProGuard sa AGP 8.0, ngunit ang pag-unawa sa mga pagkakaiba sa arkitektura ay mahalaga para sa migrasyon ng mga proyekto.

Mga Pagkakaiba sa Arkitektura

ProGuard ay gumagana bilang isang hiwalay na tool, na nagpoproseso ng Java bytecode (.class file) bago ang conversion sa DEX. Ang R8 ay isinama sa DEX compiler at nagpoproseso ng code sa mas mababang antas, na nagbibigay-daan sa optimization na hindi available sa ProGuard. Sinusuportahan din ng R8 ang desugaring — conversion ng syntactic sugar ng Java 8+ sa backward-compatible code para sa lumang Android API level.

Mga Bentahe ng R8

Ayon sa Google Android Performance Team (2025), ang R8 ay nagbibigay ng 10-15% na mas mahusay na compression ng code kumpara sa ProGuard na may parehong panuntunan. Ang R8 ay mas mabilis — ang build time ay nababawasan ng 20-30%. Bukod pa rito, nag-aalis ang R8 ng mas maraming patay na code dahil sa pagsusuri sa antas ng DEX, hindi class file. Ang R8 ay ganap na compatible sa syntax ng ProGuard rules, na ginagawang transparent ang migrasyon para sa developer.

Proseso ng Migrasyon

Ang paglipat mula sa ProGuard patungo sa R8 ay simple: sa AGP 8.0+ ang R8 ay ginagamit bilang default. Para sa mga lumang proyekto, kailangang alisin ang ProGuard mula sa classpath at i-update ang gradle.properties: android.enableR8=true. Ang ProGuard rules ay compatible sa R8 nang walang pagbabago sa karamihan ng kaso. Inirerekomenda na subukan ang release build sa lahat ng target na device pagkatapos ng paglipat, dahil maaaring alisin ng R8 ang code na pinanatili ng ProGuard.