Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.

Несмотря на шутку в адрес многомодульности, это действительно полезный подход, но для большого проекта с богатой историей модуляризация может быть очень сложным процессом. Поэтому пока давайте посмотрим, что можно сделать без больших болей на уровне Gradle и AGP.

Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.

Пассивный DPI

Привет, Хабр! 

Меня зовут Василий Материкин, я — Android-разработчик в QIWI. В этом посте я расскажу о применении фича-флагов в QIWI Кошельке.

Внедрение Trunk-Based Development и Feature Flags

В процессе работы над большими приложениями, в которых много фич и над которыми трудится большая команда разработчиков, часто приходится сталкиваться с такой проблемой как конфигурация приложения помощью фича-флагов. Мы в QIWI столкнулись с этим два года назад, когда в QIWI Кошельке было создано несколько feature-команд. Выяснилось, что разрабатывать новые фичи с помощью стандартных feature-веток не так удобно, потому что когда над одним проектом работает несколько feature-команд, ветки становятся достаточно объёмными. Потом смержить их в мастер становится довольно непростой задачей, появляются постоянные конфликты. 

Поэтому мы решили перейти на Trunk-Based Development (TBD). TBD предлагает работать в небольших ветках и, желательно, чтобы они как можно быстрее были влиты основную ветку. Для этого, конечно же, реализацию нового функционала нужно оформлять небольшими пулл-реквестами, чтобы они быстро проходили ревью и были влиты в основную ветку. Это, в свою очередь, создает другую проблему — когда в главной ветке может появиться код, который ещё не готов к релизу, но при этом нам нужно как-то релизить с этим кодом приложение. Мы же релизы выпускаем достаточно часто. И для этого TBD предлагает пользоваться такими подходами, как Branch by Abstraction (BBA) и Feature Flags (FF).

BBA позволяет выделить какой-либо функционал в отдельную абстракцию. Для этого создается интерфейс, который описывает контракт для работы с этим функционалом. Сразу же можно создать его текущую реализацию, просто скопировав код, который сейчас в продакшене. Также создается другая реализация (уже с новым функционалом) и с ней уже начинается работа. То есть обычно первый пулл-реквест при работе с фичей — это выделение кода, создается две реализации, эти изменения вливаются в главную ветку и далее продолжаем работать уже над новой реализацией. При этом в проекте (в продакшене) используется всё ещё старая реализация, пока мы не закончим работать над фичей.

Привет, Хабр!

Меня зовут Юрий Шабалин, я один из основателей компании "Стингрей Технолоджиз" (входит в группу компаний Swordfish Security), мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.

По долгу службы мы подписаны на большое количество ресурсов и прорабатываем все статьи и материалы, которые относятся к теме мобильной безопасности. Результаты этого анализа я хочу представить в рамках этой статьи. Материал будет полезен всем, кто следит за появлением новой информации о способах поиска уязвимостей, разработкой новых инструментов и в целом заинтересован в безопасности мобильных приложений.

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

Однажды вы проснулись и поняли, что не хотите идти на работу. Поездка в офис — как поход на войну. И так уже было какое-то время, но вы не замечали. Спустя несколько недель к вам пришло состояние тотальной беспомощности и бессмысленности происходящего. Думая, что проблема в проекте, вы поменяли состав команды, саму работу, но ничего не помогло. Вы автоматически выполняли операционные задачи, а попытки отвлечься от работы заканчивались многочасовым созерцанием потолка. Потом появились проблемы со здоровьем.

Вы не одни. В сегодняшней статье Юлия Белозерова, которая выгорала уже полтора раза, решила поделиться своим опытом. Последние 10 лет она занималась управлением проектами в аутсорсинге, в продуктовых компаниях (ex-Yandex, ex-Epam, ex-Booking.com). Юля не врач, не терапевт, не психолог и не профессионал по выгоранию. Это взгляд выжившего.

Система сборки проектов Gradle стала значительной вехой в эволюции инструментов подготовки артефактов и заменила во многих проектах ранее популярный Maven (который ранее стал заменой для make и ant). Де-факто Gradle является стандартом для сборки проектов для Android, но в действительности он может использоваться и для других целевых платформ и технологий разработки, отличных от JVM. Подобно maven в gradle используются устанавливаемые дополнения, которые могут добавлять свои цели и элементы конфигурации, а также встраиваться в существующие цели и добавлять операции как и исходными текстами (например, форматирование), так и с вспомогательными объектами (как пример можно привести кодогенерацию), а также вызов внешних команд или объектов классов (например, компилятора kotlin или инструментов сборки ресурсов для android).

В этой статье мы пошагово создадим и протестируем простой plugin трансформации текстовых файлов для gradle (при разработке будем в основном использовать API, который поддерживается версиями 6.0+, но отдельно отметим, какие функции поддерживаются только в Gradle 7.0 и более новых).

Сначала начнем с определения контекста. Сборка любого проекта состоит из последовательности действий (actions), которые в конечном счете приводят к появлению целевого состояния (task). Конфигурация сборки описывается в виде gradle-сценария, который может взаимодействовать с методами, импортированными из plugin'ов или входящих в gradle-core, либо с версии Gradle 4.0 с использованием Kotlin Scripting (.kts) с возможностью использования объектов стандартной библиотеки Kotlin и импортируемых библиотек.

Если вы мобильный разработчик, знаете ли вы, каково пользоваться вашим приложением незрячим людям? В каких именно местах они могут столкнуться с главными сложностями? Как вообще будет происходить взаимодействие с приложением?

На нашей конференции Mobius Виктор Вихров (Яндекс Go) рассказал о том, как сделать Android-приложение более подходящим для использования «вслепую». А эксперт в сфере цифровой доступности Анатолий Попко помог ему, прокомментировав представленные решения с точки зрения такого пользователя. Мы считаем, что такой контент нужен и на Хабре — поэтому сделали текстовую расшифровку доклада.

Подбираем эффективную конфигурацию под ваши нужды

Всем привет! Меня зовут Иван Левиков, я старший инженер по тестированию.

ВКонтакте развиваю и ускоряю автотесты, анализирую и улучшаю инфраструктуру, создаю новые решения.

При проектировании инфраструктуры для автотестов на Android приходится искать ответы на вопросы о том, где можно их запускать и где лучше это делать. 

Рассмотрим самые популярные места для запуска автотестов: 
• облачные решения;
• решения на физических девайсах. 

Disclaimer. В статье рассмотрим конфигурацию, которую вы можете внедрить в свои проекты. При этом помните про несколько факторов:

• Результат может варьироваться, если используются разные серверные машины.
• Избыток ресурсов — это не всегда хорошо.
• Оптимизация железа должна идти бок о бок с оптимизацией тестов.

Проблема традиционных цветовых пространств

RGB

• градиент красного — это цвета #000, #100, #200, #FEE, #FFFи т.д.;
• градиент зеленого — это цвета #000, #010, #020и т.д.;
• градиент синего — это цвета #000, #001, #002и т.д.;
• градиент желтого — это цвета #000, #110, #220и т.д.;
• градиент голубого — это цвета #000, #011, #022и т.д.;
• градиент пурпурного — это цвета #000, #101, #202и т.д.

• Яркость цветов увеличивается неравномерно: чем оттенок ближе к белому цвету, тем изменение яркости меньше;
• Яркость разных цветов различается: синий намного темнее остальных;
• Насыщенность также неравномерна: синий и красный выглядят «ненасыщенными» в правой части градиента.

Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.

Корутины в Kotlin - одна из значимых фич языка, которая позволяет писать асинхронных код в синхронном стиле. Корутины прекрасны во всём, до тех пор пока не возникает необходимость их дебажить.

Когда я писал свой первый gradle-плагин, я проверял его работоспособность следующим образом:

1. Опубликовал версию n в plugins.gradle.org
2. Проверил опубликованный плагин вручную на тестовом проекте
3. Нашел ошибку/доработал, увеличил версию n=n+1, затем снова пункт 1

Такой вот PDD (Publish Driven Development). Сегодня поговорим о том, как писать эффективные тесты на собственные gradle плагины.

Эта статья является пересказом моего доклада на Java-конференции SnowOne 2021 года. LJV — проект, созданный в 2004 году как инструмент для преподавания языка Java студентам. Он позволяет визуализировать внутреннее устройство структур данных. В этом докладе я запускаю LJV на разных структурах (от String до ConcurrentSkipListMap) в разных версиях Java и разбираю, что там внутри, как оно менялось от версии к версии, и как это всё работает.