R8: ano ito, mga kakayahan at paghahambing sa ProGuard

Ano ang R8?

R8 ay isang programa sa pagproseso at pagbabago ng bytecode, na binuo ng Google bilang kapalit ng ProGuard sa Android ecosystem. Hindi tulad ng ProGuard na gumagana bilang isang hiwalay na tool sa yugto ng mga class file, ang R8 ay direktang isinama sa DEX compiler (D8/R8). Ito ay nagpapahintulot sa R8 na magsagawa ng pagsusuri at pag-optimize sa mas malalim na antas, hindi naa-access ng mga panlabas na tool.

Arkitektura ng R8

R8 ay tumatanggap ng Java bytecode sa format ng class file o JAR archives at ginagawa itong optimized na DEX code sa isang pass. Ang built-in optimizer ng R8 ay nagsasagawa ng higit sa 50 iba't ibang uri ng pagbabago — mula sa simple (inline ng mga constant) hanggang sa kumplikado (pagsusuri ng reachability ng mga uri na may katumpakan hanggang sa indibidwal na field). Ayon sa Google, ang arkitektura ng R8 ay espesyal na dinisenyo para gumana sa multi-threaded mode, na tinitiyak ang mataas na bilis ng build.

Kasaysayan ng pag-unlad

R8 ay inanunsyo sa Google I/O 2018 at unang isinama sa Android Gradle Plugin 3.4 (2019) bilang opsyonal na kapalit ng ProGuard. Sa AGP 7.0, naging default tool ang R8 para sa lahat ng proyekto, at sa AGP 8.0 (2023) ang suporta para sa ProGuard ay ganap na tinanggal mula sa plugin. Hanggang 2025, ang R8 ay ang tanging opisyal na tool ng obfuscation at optimization para sa Android na inirerekomenda ng Google.

Mga pangunahing kakayahan ng R8

R8 ay nagbibigay sa mga developer ng isang hanay ng mga malakas na kakayahan na makabuluhang lumalampas sa ProGuard sa mga tuntunin ng kahusayan. Tingnan natin ang mga pangunahing.

Minification at compression ng code

R8 ay nagsasagawa ng global na pagsusuri ng code ng app at lahat ng dependencies nito, na tinutukoy ang mga naaabot na klase at pamamaraan sa pamamagitan ng call graph mula sa mga entry point. Ang pagsusuri ng R8 ay mas tumpak kaysa sa ProGuard dahil sa access sa DEX na representasyon ng code. Maaaring alisin ng R8 hindi lamang ang buong klase at pamamaraan, kundi pati na rin ang mga indibidwal na field na hindi kailanman ginagamit. Ayon sa mga pagsubok ng Google, ang R8 ay nag-aalis ng average na 15% higit pang code kaysa sa ProGuard sa parehong mga proyekto.

Desugaring ng Java 8+

Built-in na desugaring — isang natatanging kakayahan ng R8 na wala sa ProGuard. Awtomatikong kino-convert ng R8 ang mga lambda expression, method reference, interface na may default na pamamaraan at try-with-resources ng Java 8+ sa backward compatible na code na gumagana sa lahat ng antas ng Android API. Ito ay nagpapalaya sa developer mula sa pangangailangan na magkonekta ng hiwalay na desugar_jdk_libs library at manu-manong i-configure ang desugaring.

Pag-optimize sa antas ng DEX

Dahil nakikita ng R8 ang final DEX format, maaari itong magsagawa ng mga optimization na imposible para sa ProGuard. Pinagsasama ng R8 ang magkaparehong string constants, nag-aalis ng hindi ginagamit na exceptions, nag-o-optimize ng switch constructions at nagsasagawa ng agresibong inlining na may pag-rewrite ng call graph. Ang mga optimization na ito ay hindi lamang nagpapababa ng laki ng APK, kundi pinapabuti din ang performance ng pag-execute ng code sa ART.

// build.gradle tahasang pag-activate ng R8 (opsyonal sa AGP 8.0+)
android {
    compileSdk 34
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt'
            ), 'proguard-rules.pro'
        }
    }
}

// gradle.properties — pilit na i-activate ang R8
android.enableR8.fullMode=true

Paghahambing ng R8 at ProGuard

Ang pagpili sa pagitan ng R8 at ProGuard ay may kaugnayan lamang para sa mga proyektong gumagamit ng AGP na mas luma sa 8.0. Para maunawaan ang mga pagkakaiba sa arkitektura, tingnan natin ang paghahambing batay sa mga pangunahing parameter.

Sukat ng huling APK

Ang mga pagsubok ng Google sa sample ng 100 sikat na Play Store apps ay nagpakita na ang R8 ay nagpapababa ng laki ng APK ng average na 18% kumpara sa ProGuard. Sa ilang proyekto na may aktibong paggamit ng Java 8+ syntax at third-party libraries, ang pagkakaiba ay umabot sa 28%. Para sa isang app na may sukat na 40 MB, ito ay nangangahulugan ng pagtitipid na 5 hanggang 11 MB, na kritikal para sa mga user na may limitadong trapiko.

Pagkakatugma sa Kotlin

Ang parehong tool ay wastong nagpoproseso ng Kotlin code, ngunit ang R8 ay mas mahusay na nag-o-optimize ng Kotlin-specific na mga konstruksyon: lambda, inline function, coroutine, at null-safe na mga uri. Nauunawaan ng R8 ang semantika ng Kotlin metadata at maaaring ligtas na alisin ang mga labis na null check at mag-embed ng inline function. Para sa mga proyekto sa Kotlin, ang R8 ay ang inirerekomendang tool ng Google.

Pag-configure ng R8 sa Android project

Ang pag-configure ng R8 ay nangangailangan ng minimal na pagbabago sa configuration ng build, dahil sa AGP 8.0+ ang tool ay ginagamit bilang default. Tingnan natin ang mga pangunahing aspeto ng configuration.

Buong mode ng R8

Buong mode ng R8 (android.enableR8.fullMode=true) ay nag-a-activate ng mas agresibong optimization na nagbibigay ng karagdagang pagbawas sa laki ng APK na 5-10%. Sa mode na ito, ang R8 ay nagsasagawa ng mas malalim na pagsusuri ng code, nag-aalis ng mga klase at pamamaraan na ituturing ng ProGuard na maaabot. Ang buong mode ay maaaring mangailangan ng karagdagang -keep na mga patakaran para sa mga library na gumagamit ng reflection.

# gradle.properties — pag-activate ng buong mode ng R8
android.enableR8.fullMode=true

# Karagdagang patakaran para sa full mode
-keep class com.example.reflection.** { *; }
-keep class * implements android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
}

Pag-debug ng mga problema sa R8

Sa kaso ng mga error sa release build gamit ang R8, inirerekomenda ng Google: suriin ang mapping file para sa deobfuscation ng stacktrace, pansamantalang huwag paganahin ang fullMode para ihiwalay ang problema, magdagdag ng -whyareyoukeeping para maunawaan kung bakit hindi tinanggal ang isang klase, at gamitin ang --info flag ng Gradle para makakuha ng detalyadong log ng R8 processing.

Integrasyon sa CI/CD

Para sa automation ng build gamit ang R8 sa CI/CD, mahalagang itago ang mga mapping file bilang build artifacts. Ang bawat mapping file ay dapat naka-link sa numero ng bersyon at variant ng build. Inirerekomenda ng Google ang pag-archive ng build/outputs/mapping/ kasama ng APK/AAB sa isang sistema ng pamamahala ng artifact. Ito ay titiyak sa posibilidad ng deobfuscation ng mga crash mula sa anumang bersyon ng app.

Pinakamahusay na kasanayan sa paggamit ng R8

Ang maraming taon ng karanasan sa paggamit ng R8 sa Android community ay nakabuo ng isang hanay ng mga napatunayang kasanayan na tumutulong upang maiwasan ang mga tipikal na problema at makuha ang maximum na benepisyo mula sa tool.

Unti-unting implementasyon

Sa paglipat mula sa ProGuard patungong R8 inirerekomenda na magsimula sa AGP 7.x, kung saan ang R8 ay naka-activate bilang default ngunit ang fullMode ay naka-deactivate. Pagkatapos ng beripikasyon ng stability ng build sa kumpletong hanay ng mga device at senaryo, maaaring i-activate ang fullMode. Ang bawat yugto ay nangangailangan ng pagsubok ng release build sa pisikal na mga device na may iba't ibang bersyon ng Android.

Pagmonitor ng mga mapping file

Ang mga mapping file ng R8 ay may parehong format ng ProGuard, ngunit naglalaman ng mas maraming impormasyon dahil sa mas detalyadong pagsusuri. Inirerekomenda ng Google: itago ang mga mapping file nang walang katapusan — kailangan ang mga ito para sa deobfuscation ng mga crash ng lumang bersyon; isama ang mga mapping file sa Firebase Crashlytics sa pamamagitan ng awtomatikong pag-upload; regular na suriin na ang deobfuscation sa Firebase console ay wastong nagpapanumbalik ng mga pangalan ng klase.

Pagsubok gamit ang R8 full mode

Ang buong mode ng R8 ay maaaring mag-alis ng code na itinuturing na maaabot sa standard mode. Mga kritikal na lugar para sa pagsubok: mga screen na may WebView (maaaring alisin ng R8 ang mga bridge interface class), mga app na may plugin sa pamamagitan ng classLoader, mga library ng analytics at crash reporting, at custom na view sa layout file na ginawa sa pamamagitan ng inflate.

Pagmonitor ng laki ng build

Inirerekomenda ng Google ang pagsubaybay sa laki ng APK pagkatapos ilapat ang R8 sa bawat build. Gamitin ang APK Analyzer sa Android Studio para ihambing ang laki ng mga indibidwal na component: classes.dex, resources.arsc at native code library. Ang R8 ay maaaring makaapekto sa laki ng DEX file nang hindi linear — minsan ang agresibong optimization ay humahantong sa pagtaas ng laki dahil sa inlining. Ang regular na pagmonitor ay tumutulong upang matukoy ang mga anomalya sa tamang oras at itama ang mga patakaran ng obfuscation.

// Halimbawa ng klase na pinanatili para sa Firebase Crashlytics
@Keep
class CrashLogger {
    fun logException(e: Throwable) {
        FirebaseCrashlytics.getInstance().recordException(e)
    }
}

// rules.pro — panatilihin ang lahat ng klase na may @Keep
// -keep @androidx.annotation.Keep class * { *; }