Все Android-разработчики хотят одного: чтобы интерфейс их приложения был плавным и отзывчивым, а переходы экранов — быстрыми. Уверенность в плавности и чёткости интерфейса дают замеры метрик. Но как измерить ту самую плавность, как оценить гладкость анимаций? У кого-нибудь есть плавнометр или транзишинометр?

Google даёт нам Macrobenchmark и JunkStats — инструменты для оценки общей отзывчивости и стабильности интерфейса. Но их недостаточно, чтобы понять, быстро ли у нас открываются экраны.

В этой статье мы поговорим о том, как получить полную картину по метрикам UI-перформанса. Как замерить плавность и отзывчивость интерфейса, и как оценить время открытия экрана — одно из самых частых действий для пользователя. Напишем собственный транзишинометр и замерим рендер экрана до первого onDraw и до последнего, причём и во Fragments, и в Compose.

Jetpack Compose постоянно развивается, открывая перед разработчиками новые горизонты для оптимизации. С момента нашего последнего обзора, мы добились значительного прогресса, сократив задержки при скролле с 5-7% до нуля. В этом материале мы поделимся свежими находками и передовыми практиками в оптимизации Compose. Чтобы максимально углубиться в тему, рекомендуем ознакомиться с первой частью.

Jetpack Compose может работать медленнее системы View из-за своей архитектуры и дизайна. Но при этом он гораздо более гибкий.

Дело в том, что Jetpack Compose — это unbundled-библиотека. В этой статье я расскажу о том, что это значит и почему оно влияет на производительность, на примере нашего переезда на Compose.

Мы вместе ужаснёмся тормозам UI, вызванным переездом на Compose, и порадуемся возможности писать Compose-код, не оглядываясь на версию Андроида! Но это всё спойлеры. Давайте расскажу подробнее!

Привет, хабр! Меня зовут Алексей, я ведущий разработчик платформенной команды и по совместительству лид архитектурной компетенции в проекте Альфа-Бизнес. Сегодня я расскажу, как можно автоматизировать повторяющуюся работу в андроид-разработке при помощи плагина для Android Studio.

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

Также мы привыкли автоматизировать свою собственную работу. Инструменты CI/CD позволяют быстрее доставлять ценность клиентам, чем ручное развертывание, линты помогают уменьшить время, которое мы тратим на прохождение задачи код ревью. 

В процессе написания кода тоже встречается много рутинной работы. Это может быть какой-то шаблонный код для написания тестов, например, создание моков и прокидывание в конструктор при создании экземпляра тестируемого класса или добавление нового экрана. Если вы используете подход MVI, что очень актуально для андроид-разработки, вы сталкивались с тем, что для каждого экрана приходится создавать множество отдельно файлов с шаблонным кодом, для редьюсера, экзекутора, стейта, экшены, сами файлы экрана, и это тоже хотелось бы делать «в один клик».

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

Настроек для пайплайна Gitlab очень много. В этой статье, не вдаваясь в недра тюнинга, поговорим о том, как выглядит скрипт пайплайна, из каких блоков он состоит и что может содержать.

Jetpack Compose — относительно молодая технология написания декларативного UI. Множество разработчиков даже не предполагают, что пишут неоптимальный код в такой критически важной части, и впоследствии это приводит к неожиданной низкой производительности и проседании метрик.

Наша команда Ozon Seller также столкнулась с этой проблемой. Мы решили собрать воедино все советы и наработки по написанию оптимизированного Compose-кода. Активное применение этих советов при оптимизации существующих экранов и написании новых существенно улучшило наши метрики: длительность лага по отношению к длительности скролла (hitch rate; чем меньше, тем лучше) экранов со списками упала в среднем с 15-19 % до 5-7 % (на 90-м перцентиле). Все эти советы и наработки мы описали в этой статье. Она будет полезна и начинающим, и опытным разработчикам, в ней подробно описаны оптимизации и механизмы Compose, а также рассказано про слабо задокументированных особенности и исправления ошибок, которые есть в других статьях. Давайте же начнём.

Реализация нашей дизайн-системы на Jetpack Compose не всегда проходила гладко. Большинство компонентов мы переписали без проблем, но с некоторыми пришлось повозиться. Одним из таких компонентов стал аналог старого доброго CollapsingToolbarLayout из View-мира. В статье разберем тонкости его реализации на Compose: погрузимся в особенности работы кастомного лейаутинга в Compose, систему вложенного скролла и посмотрим в исходники библиотеки androidx.compose.material3.

Материал может быть полезен всем, кто собирается делать сложные кастомные виджеты или просто интересуется внутренними деталями работы Compose-компонентов. 

Всем привет! Меня зовут Алишер, Android-разработчик уже как 1,5 года. За это время у меня появился шаблонный (Boilerplate) проект в котором у нас базовая архитектура приложений которую мы будем разбирать. В этой статье я расскажу, и покажу как я ел Single Activity Architecture с Fragment'ами и Navigation Component.

Всем привет! Меня зовут Павел, я Android-разработчик в Delivery Club. Моя команда разрабатывает функциональность доставки продуктов из магазинов. Я расскажу о подходе к написанию кода, подразумевающем, что любые долгие операции могут быть отменены. На примере корутин рассмотрим сферы применения такого подхода.

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

В этой статье я хочу поделиться опытом работы со скроллом в приложении, написанном на Jetpack Compose.

Какое-то время назад я решил, что надо попробовать Compose в деле и начал делать pet project приложение Хотелки, суть которого в записи своих желаний и возможности делиться списком желаний с помощью любого мессенджера.

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

Привет! Меня зовут Алексей Дёмин, я Android-разработчик в Prequel - мобильном редакторе для фото и видео. Сегодня я бы хотел детально разобрать реализацию поведения Pinch-to-zoom. Такое поведение широко распространено в приложениях и выглядит привычным и естественным для большинства пользователей. Поэтому, на первый взгляд, его реализация на основе предоставляемого системой api не должна вызывать трудностей. Однако при попытке разработать решение, применимое в большинстве кейсов, возникают интересные нюансы, которые я постараюсь осветить в данной статье.

Два года назад на Google I/O Android-разработчикам представили новое решение для навигации в приложениях — библиотеку Jetpack Navigation Component. Про маленькие приложения уже было сказано достаточно, а вот о том, с какими проблемами можно столкнуться при переводе большого приложения на Navigation Component, информации практически нет.

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

Dagger и Koin, без сомнения, являются двумя самыми популярными фреймворками для внедрения зависимостей на Android. Обе эти библиотеки служат одной цели и кажутся очень похожими, но работают они по-разному.

А при чем здесь Hilt? Hilt — это библиотека, которая использует Dagger под капотом и просто упрощает работу с ним, поэтому все, что я говорю здесь о Dagger, применимо и к Hilt.

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

Каждое большое приложение содержит множество способов навигации между экранами. А хорошая библиотека навигации должна помогать разработчику их реализовывать. Именно с такой мыслью я подошёл к исследованию кейсов со вложенными графами навигации.

Это вторая из трёх статей про реализацию кейсов навигации при помощи Navigation Component-а.

1. Краткое описание шаблона MVI, постановка задачи и создание общего модуля с использованием Kotlin Multiplatform.
2. Интеграция общего модуля в iOS- и Android-приложения.
3. Модульное и интеграционное тестирование.