Android ProGuard: самые агрессивные оптимизации

Официальная официальная показывает две основные оптимизации:

установите minifyEnabled в true
использовать proguard-android-optimize.txt вместо proguard-android.txt

Являются ли эти две наиболее агрессивными возможными настройками?

Я пишу андроидную библиотеку и должен убедиться, что когда люди используют мою библиотеку, мой код не сломается. (Я знаю, что есть правила, которые я могу поместить в свою библиотеку, чтобы противостоять конфигурации конфигурации proguard в приложении, использующем библиотеку, но я не хочу этого делать, если мне это не нужно.)

Ответ 1

Помните, что лучшая конфигурация ProGuard - это конфигурация с минимальным количеством исключений. За исключениями я понимаю:

 -keepclassmembers class * extends android.content.Context {
    public void *(android.view.View);
    public void *(android.view.MenuItem);
 }

Пройдите через proguard-android-optimize.txt и посмотрите варианты оптимизации/обфускации.

Для подробного описания опций ProGuard я использую this

-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/* Этот - список возможной оптимизации,! означает отрицание, поэтому эта оптимизация не используется

-optimizationpasses 5 Определяет количество проходов оптимизации, которые необходимо выполнить. По умолчанию выполняется один проход. Многократные пропуски могут привести к дальнейшим улучшениям. Если после прохождения оптимизации не обнаружены улучшения, оптимизация завершается. Применимо только при оптимизации.
Использование: ОК, и выглядит так, что по умолчанию достаточно 5 проходов

-allowaccessmodification Указывает, что модификаторы доступа классов и членов класса могут быть расширены во время обработки. Это может улучшить результаты этапа оптимизации.
Использование: ОК, да выглядит улучшенная оптимизация

-dontpreverify При настройке на Android, preverifing не требуется, поэтому dontpreverify отключает его, чтобы немного сократить время обработки. Но этот параметр не влияет на нерушимость кода.
Использование: ОК, просто немного времени на обработку данных

-dontusemixedcaseclassnames Указывает не генерировать имена классов смешанного класса при запутывании. По умолчанию обфусканные имена классов могут содержать сочетание символов верхнего регистра и строчных символов. Это создает совершенно приемлемые и пригодные для использования банки.
Использование: QUESTIONABLE, я не могу найти точную причину, почему эта опция добавлена, но выглядит как имя класса изменения от abcdef до AbSdEf не делает код нерушимым

-dontskipnonpubliclibraryclasses Указывает не игнорировать классы непубличной библиотеки. Начиная с версии 4.5, это значение по умолчанию.
Использование: Хорошо, очень полезно

Следующие параметры не включают в proguard-android-optimize.txt:

-mergeinterfacesaggressively Указывает, что интерфейсы могут быть объединены, даже если их классы реализации не реализуют всех методов интерфейса... установка этого параметра может снизить производительность обработанного кода на некоторых JVM

Использование: BAD, выглядит опасно для Android, не включается в конфигурацию, сводка запрета класса/слияния/в оптимизации

-overloadaggressively Указывает на применение агрессивной перегрузки при запутывании. Несколько полей и методов могут затем получать одинаковые имена, если их аргументы и типы возвращаемых данных различаются, как требуется байт-кодом Java (а не только их аргументы, как того требует язык Java)
Использование: BAD, Google Dalvik VM не может обрабатывать перегруженные статические поля.

-repackageclasses '' Указывает переупаковать все файлы классов, которые переименованы, переместив их в один заданный пакет. Без аргумента или с пустой строкой ('') пакет полностью удаляется. Этот параметр переопределяет параметр -flattenpackagehierarchy.
Использование: OK, Используется Google, так что, по крайней мере, мы нашли вариант, который мы можем добавить в нашу конфигурацию

Поэтому я знаю только один полезный для обфускации и не опасный вариант:
-repackageclasses ''

Также обратите внимание на декодирование стеков стека. ProGuard также удаляет имя файла и номера строк из stacktrace. Это затрудняет обнаружение ошибок. Вы можете сохранить номера строк, добавив следующий код в свой конфиг:

-renamesourcefileattribute SourceFile 
-keepattributes SourceFile,LineNumberTable

Это сохранит номера строк, но заменит имя файла в stacktrace на "SourceFile".

Также не забывайте, что ProGuard выглядит уязвимым, потому что он не шифрует строковые ресурсы, поэтому подумайте об использовании DexGuard или зашифруйте важные строки (например, маркеры, URL-адреса).

Ответ 2

В соответствии с комментарием файла оптимизации оптимизация приводит к определенным рискам и, если используется, приложение должно быть тщательно протестировано. Согласно моему опыту, необходимо отключить код/упрощение/расширенный, поскольку он вызвал конечные локальные переменные, которые были инициализированы вне лямбда, которые были NULL внутри лямбда. Было очень сложно отлаживать и находить. Поэтому мои настройки оптимизации следующие:

-оптимизации код/упрощение/литье, код/упрощение/расширенный,! поле /*,! класс/слияние/*,! метод/удаление/параметр,! метод/распространение/параметр

Обратите внимание, что код/упрощение/арифметика также должны быть отключены, если вы настроите Android 2.0 и ниже (что очень маловероятно). Кроме того, мне также пришлось отключить метод/удаление/параметр и метод/распространение/параметр, поскольку они неявно включают код/упрощение/расширенный (см. Руководство ProGuard для получения дополнительной информации).