ProGuard — що це таке, можливості та налаштування обфускації

Що таке ProGuard?

ProGuard — інструмент, що вільно поширюється, для обробки Java-байткоду, розроблений компанією Guardsquare. Він вбудований в Android SDK і виконує три ключові функції: стиснення, оптимізацію та обфускацію коду. ProGuard аналізує весь байткод додатку та його залежностей, визначає невикористовувані класи та методи, видаляє їх, а потім заплутує решту коду.

Історія та позиціонування

ProGuard був створений Еріком Лафоржем у 2000 році як інструмент оптимізації Java-додатків. З появою Android у 2008 році ProGuard був інтегрований в Android SDK і став стандартним інструментом для захисту додатків. За даними статистики Guardsquare (2024), ProGuard використовується в більш ніж 80% додатків з Google Play, включаючи додатки найбільших банків та технологічних компаній.

Як ProGuard обробляє код

ProGuard виконує обробку в чотири етапи. На першому етапі (стиснення) інструмент аналізує точки входу в додаток і визначає, які класи, методи та поля досяжні під час виконання. На другому етапі (оптимізація) ProGuard перетворює байткод для підвищення продуктивності. Третій етап (обфускація) перейменовує ідентифікатори. На фінальному етапі preverify додає метадані, необхідні для верифікації байткоду на віртуальній машині.

Основні можливості ProGuard

Розглянемо детально кожну з трьох основних функцій ProGuard: стиснення, оптимізацію та обфускацію. Розуміння кожного механізму допоможе налаштувати інструмент оптимальним чином.

Стиснення коду

ProGuard аналізує граф викликів від точок входу (main-метод, Activity, BroadcastReceiver) і видаляє невикористовуваний код. У типовому Android-проєкті з бібліотеками на кшталт Retrofit, OkHttp та Gson стиснення може видалити до 40% байткоду, включаючи невикористовувані методи бібліотек, debug-код та тестові класи. Це безпосередньо зменшує розмір APK і скорочує час завантаження додатку.

Оптимізація

На етапі оптимізації ProGuard виконує понад 20 різних перетворень байткоду: вбудовування коротких методів, видалення невикористовуваних параметрів, спрощення логічних виразів, злиття однакових блоків коду. Наприклад, короткі геттери та сеттери можуть бути замінені на прямий доступ до поля. Оптимізація може прискорити виконання коду на 5-15% залежно від структури додатку.

Обфускація

Обфускація в ProGuard працює шляхом перейменування класів, методів та полів у короткі послідовності символів: a, b, c, a.a, a.b і так далі. Всі посилання на перейменовані елементи автоматично оновлюються по всьому коду. Важливо зазначити, що обфускація не змінює поведінку програми, а лише ускладнює розуміння декомпільованого коду. Бібліотеки та публічні API повинні бути виключені з обфускації через правила keep.

// До обфускації ProGuard
public class LoginManager {
    public User authenticateUser(String username, String password) {
        // логіка автентифікації
    }
}

// Після обфускації ProGuard
public class a {
    public Object a(String b, String c) {
        // та ж логіка з перейменованими ідентифікаторами
    }
}

Налаштування ProGuard в Android-проєкті

Конфігурація ProGuard — критичний етап налаштування збірки Android-додатку. Неправильні правила можуть призвести до видалення необхідних класів і, як наслідок, до помилок в релізній версії.

Базове налаштування в build.gradle

Активація ProGuard в Android-проєкті включає встановлення прапора minifyEnabled в true для релізного типу збірки. Стандартні правила ProGuard постачаються разом з Android SDK у файлі proguard-android-optimize.txt. Користувацькі правила додаються в окремий файл proguard-rules.pro. При збірці ProGuard застосовує спочатку стандартні правила, потім користувацькі, що дозволяє перевизначати базову конфігурацію.

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

Файл proguard-rules.pro

Користувацький файл правил містить директиви, специфічні для конкретного проєкту. Типові правила включають збереження класів, що використовуються через reflection, моделей даних для серіалізації Gson/Moshi, callback-інтерфейсів бібліотек та класів, анотованих специфічними анотаціями. Кожна директива починається з ключового слова -keep, -dontwarn або -keepclassmembers і визначає шаблон класу, який ProGuard не повинен змінювати.

# Зберегти моделі даних для Gson
-keep class com.example.data.model.** { *; }

# Зберегти класи, що використовуються через reflection
-keep class * implements com.google.gson.TypeAdapterFactory

# Ігнорувати попередження бібліотек
-dontwarn okhttp3.internal.**
-dontwarn retrofit2.**

# Зберегти enum-и (особливість ProGuard)
-keep class * extends java.lang.Enum { *; }

Правила ProGuard: keep, dontwarn та інші

Граматика конфігурації ProGuard включає кілька категорій директив, кожна з яких керує певним аспектом обробки. Розглянемо основні з них, необхідні для коректного налаштування.

Reflection та динамічне завантаження

ProGuard не може статично проаналізувати код, що завантажується через reflection (Class.forName()), ServiceLoader або динамічне завантаження DEX-файлів. Якщо клас створюється за рядковим іменем, ProGuard не знає про його існування і може видалити його як невикористовуваний. Всі такі класи потрібно явно зберігати через -keep. Це найчастіша причина помилок в релізних збірках після включення ProGuard.

Бібліотеки та AAR-залежності

Бібліотеки часто включають власні правила ProGuard, які автоматично додаються в збірку через consumer-rules.pro, вбудований в AAR-файл. Android Gradle Plugin автоматично застосовує ці правила при збірці. Розробнику потрібно лише переконатися, що всі використовувані бібліотеки надають коректні правила, і при необхідності доповнити їх у проєкті.

Налагодження проблем ProGuard

При виникненні помилок після включення ProGuard використовуйте mapping-файл для деобфускації стеку викликів. Для діагностики застосовується ключ -whyareyoukeeping, що показує причину збереження класу у вихідній збірці. Тимчасове вимкнення -optimizationpasses та -obfuscation дозволяє локалізувати проблему. За даними Guardsquare, 80% проблем з ProGuard вирішуються додаванням правил -keep для reflection-класів.

ProGuard та R8: порівняння та міграція

З виходом Android Gradle Plugin 3.4 (2019) Google представив R8 — наступника ProGuard, інтегрований безпосередньо в компілятор D8/R8. До 2023 року R8 повністю замінив ProGuard в AGP 8.0, але розуміння архітектурних відмінностей важливо для міграції проєктів.

Архітектурні відмінності

ProGuard працює як окремий інструмент, що обробляє Java-байткод (.class файли) до перетворення в DEX. R8 інтегрований в компілятор DEX і обробляє код на більш низькому рівні, що дозволяє виконувати оптимізації, недоступні ProGuard. R8 також підтримує дешугаринг — перетворення синтаксичного цукру Java 8+ у зворотно сумісний код для старих API-рівнів Android.

Переваги R8

За даними Google Android Performance Team (2025), R8 забезпечує на 10-15% краще стиснення коду порівняно з ProGuard при однакових правилах. R8 швидший — час збірки скорочується на 20-30%. Крім того, R8 видаляє більше мертвого коду завдяки аналізу на рівні DEX, а не class-файлів. R8 повністю сумісний з синтаксисом правил ProGuard, що робить міграцію прозорою для розробника.

Процес міграції

Перехід з ProGuard на R8 простий: в AGP 8.0+ R8 використовується за замовчуванням. Для старих проєктів потрібно видалити ProGuard з classpath та оновити gradle.properties: android.enableR8=true. Правила ProGuard сумісні з R8 без змін у більшості випадків. Рекомендується протестувати релізну збірку на всіх цільових пристроях після перемикання, оскільки R8 може видаляти код, який ProGuard залишав.