Android Lint Performance Tips
Android BroadcastЭта статья является переводом обсуждения лучших практик по оптимизации скорости выполнения проверок кода с помощью Android Lint из обсуждения Lint Performance Tips в Google Groups.

Android Lint (далее просто Lint) - это замечательный анализатор кода, который определяет специфичные для Android баги и потенциальные проблемы. Проблемой в работе этой утилиты является её скорость - она невысокая и становиться все хуже с каждым релизом. Это связано с тем, что количество проверок становится все больше и больше (в Android Studio 3.4 их количество уже около 350).
Создатель Lint Tom Norbye из Google начал собирать советы по оптимизации скорости выполнения анализа, давайте разберем их.
Используйте Gradle Lint таск, который проверяет только один buildVariant
Например, если вы запустите таск lint, то у вас выполнится анализ всех buildVariant в проекте (обычно их как минимум два: debug и release). Аналогично, если вы выполните lintDebug у вас будут выполнены проверки всех для всех buildVariant у которых buildType = Debug, а это все productFlavor вашего приложения из каждой группы, которых может много. Поэкому, как рекомендуется запускать анализ одного buildVariant, например.

Это не являлось бы проблемой если бы Lint был инкрементным, но увы сейчас он не такой 😪
Анализируйте только модуль с приложением в вашем проекте, вместо анализа каждого модуля независимо
Если ваш проект разделен на модули, например библиотеки или вы используйте разделения кодовой базы с помощь Gradle модулей, тогда вместо анализа каждого модуля в отдельности лучше используйте включите анализ зависимостей в Lint

И вместо при запуске анализа явно указывайте модуль, который надо проверять

Также анализ зависимостей из модуля приложений выставляет minSdk, targetSdk и прочие параметры из приложения, что позволяет сделать результаты более актуальными для вашего приложения.
Не анализируйте исходники тестов
Тут все просто - меньше кода, быстрее скорость анализа + качество кода в тестах частенько не волнует разработчиков. Для ускорения отключаем анализ тестов в Gradle DSL:

Для тех кто тесты не пишет рекомендация значительной пользы не принесет, но улучшение в пару секунд можно получить
Не используйте checkAllWarnings
Lint имеет опцию `checkAllWarnings`, которая включает все проверки, даже те которые отключены по умолчанию. Это опция по умолчанию выключена, но некоторые разработчики включают ее, так как хотят все все все возможные проверки. С ней надо быть осторожным, так как она имеет проверки, которые очень медленные (например `WrongThreadInterprocedural`).
Используйте последнюю версию
Используйте последнюю версию Lint для анализа вашего исходного кода, и не бойтесь брать Canary версию. Lint очень хорошо покрыта тестами и регрессии случаются крайне редко. Для Production билдов все также используйте последний стабильный релиз.
Выделите Android Lint больше памяти
У Lint очень большой аппетит в плане RAM, поэтому рекомендуется попробовать увеличить/уменшить размер памяти Gradle Daemon и посмотреть какой эффект это принесёт вашему приложению.
Запускайте полный анализ проекта с помощью Lint периодически
Этот совет высказывал Том, когда ему на Android Dev Summit высказывал. Идея заключается в том, что для больших проектов полный анализ может быть долгим и проще его выполнять когда активность в репозитории минимальна - ночью. Естественно анализ должен выполняться на CI.
Разделить полный анализ проекта и критических проверок
Идея заключается в том чтобы для pull request-ов ускорить проверку и убрать низкоприоритетные проверки, а их выполнять только на ежедненвых сборках. Корректно развести конфигурации с помощью lint.xml в рамках одного Gradle модуля я способа не нашел, но вот сделать это можно через Gradle в коде у меня получилось:


Заключение
Android Lint - очень мощная утилита и советы из этой статьи должны вам помочь ускорить ее выполнение, хотя и сами авторы утилиты стараются улучшать ее скорость и делать более качественные проверки.
