Сегодня расскажу одну интересную историю. Нужно было добавить небольшую зависимость в проект, я посмотрел описание и оценил задачку в пару SP. Прописать dependency в build.gradle - задачка с которой справится и стажер.
Но не тут то было. У нас есть мониторинг, который вычисляет разницу релизной APK до и после изменений. Оказалось, что после добавления этой библиотеки размер проекта увеличился почти на 10%. Как следствие pipeline на CI/CD упал с отчетом, что такое увеличение не допустимо. После тщательного изучения проблемы, оказалось, библиотека притащила агрессивные Proguard-правила, которые отключили оптимизацию для всего приложения.
⚠️Как работают Proguard-правила в Android-проекте:
1. Основные правила проекта – находятся в файле proguard-rules.
2. Правила из зависимостей (библиотек) – могут поставляться внутри AAR/JAR-файлов как proguard.txt.
Что происходит при сборке:
Если библиотека предоставляет свои Proguard-правила, они объединяются с правилами основного проекта.
Порядок применения зависит от порядка зависимостей, но обычно:
- Сначала применяются правила библиотек.
- Затем – правила основного проекта ( proguard-rules).
В моем кейсе были следующие проблемные правила:
1. -keepclassmembernames class * { public protected <methods>; }
- Действует на все классы приложения (из-за *), отключая оптимизацию методов. В коде SDK нужно уточнить правило, чтобы оно затрагивало только классы SDK.
2. -keep public class **.BuildConfig { *; }
- Сохраняет все BuildConfig в проекте, хотя нужно только свои.
3. -keep class ru.example. ** { *; }
- Полностью отключает оптимизацию всего SDK, хотя можно ограничиться только моделями (например, сериализуемыми классами).
Вывод:
Обязательно добавьте проверки на CI/CD, чтобы мониторить изменения в вашем приложении. Если вы разрабатываете SDK или библиотеку - обязательно проверяйте настройки proguard, чтобы не влиять на проекты, которые будут внедрять ваше решение. Свою обратную связь мы передали разработчикам и в следующей версии уже все поправили, так что все хорошо.
Правила должны быть:
📌 Конкретными (без дженериков, где возможно).
📌 Ограниченными только своим кодом (не затрагивать классы приложения).
📌 Проверки на CI/CD помогут вам оперативно выявить проблемы до релиза в прод.
А у вас есть проверки на CI/CD и как они вам помогают?