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

Отправка сообщения, тем не менее - это сложная операция, которая требует проделать большой объем работы. Самая существенная её часть - это работа с локальной базой данных. eXpress спроектирован как offline-first, и много данных хранит локально. У одного пользователя могут быть тысячи активных чатов, и десятки/сотни тысяч сообщений, и работа со всеми ними должна оставаться быстрой.

Меня зовут Воронская Дарья, я работаю в Android Core команде eXpress и занимаюсь оптимизацией работы приложения. Я расскажу про подходы, которые мы использовали, чтобы довести скорость отправки и рендера сообщения до того самого идеального результата. 

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

Наш стек: Kotlin, Room, Coroutines, WebSocket, OkHttp.

Размер приложения часто играет важную роль в восприятии его пользователями и принятии ими решения о скачивании. Исследования показывают, что чем меньше размер APK, тем выше вероятность его установки и тем реже оно оказывается в списке на удаление. Конечно же, это важно для команды Яндекс Go, так как наше приложение непрерывно развивается.

Для внедрения одной из SDK, основанной на Flutter, мы прибегли к механизму Dynamic Feature Delivery (DFD). Но оказалось, что в русскоязычном сегменте информации о DFD крайне мало, поэтому я решил поделиться нашим опытом работы с этим механизмом на Android с Google Play Feature Delivery Library.

Сегодня мы подробно разберём, как интегрировать механизм DFD в современную архитектуру Android‑приложения с использованием корутинов, а также протестируем загрузку и установку динамического модуля, использующего Flutter.

Начиная с 12 марта 2024 года регистрация на OSSRH портале теперь недоступна. Большинство существующих туториалов в интернете описывает как раз опыт публикации через OSSRH на Maven Central. Из-за чего после марта 2024 года эти туториалы стали не актуальны для публикации проектов новых авторов.

Вероятнее всего у вас спрашивали на собесе «как работают корутины под капотом?», вы не долго думая выбрасывали что‑то в стиле «там под капотом стейт‑машина, она определяет какая suspend функция будет выполняться», но понимали ли вы на самом деле всё о чем говорили? Возможно, только вам это известно, но если честно я очень плохо понимал собственные ответы на такие вопросы как бы это парадоксально не звучало и даже после десятка пройденных собесов у меня не было полноценной картины как работает внутрянка этой поистине невероятной библиотеки «сладкой асинхронщины».

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

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

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

В этой серии статей я расскажу о внутреннем устройстве Android  —  о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Привет! Я Даниэль Халиулин, технический менеджер продукта в Тинькофф. Отвечаю за надежность и производительность нашего основного приложения — мобильного банка. Руковожу двумя одноименными командами, которые занимаются производительностью и надежностью. Расскажу про направления SRE и Observability в мобильных приложениях.

В компании ИВИ, ведущем онлайн-кинотеатре, наша команда разработчиков занимается созданием приложения для платформы Android. Недавно мы успешно выпустили версию для Android TV, используя инновационный инструмент — Jetpack Compose. Несмотря на то, что библиотека Compose для ТВ еще находится в альфа-версии, мы хотим поделиться своим опытом, рассказать о трудностях, с которыми столкнулись, и обратиться к вопросу: стоит ли использовать Jetpack Compose, особенно для ТВ-приложений?

Небольшое предисловие от команды ОК: Последний пост на Хабре от Одноклассников был написан ещё в декабре прошлого года. Мы пропали отсюда на 8 месяцев, но это не означает, что за это время с Одноклассниками ничего не происходило. Нами по-прежнему пользуется несколько десятков миллионов человек ежемесячно, мы по-прежнему один из самых высоконагруженных сервисов на Java в мире. Мы обновили позиционирование, отсняли десятки эпизодов собственных шоу, отказались от оценок под фото :)

Мы решили вернуться на Хабр после долгого отсутствия и сразу с рассказом о своем проекте, который назвали Tracer. О том, что это, рассказывает руководитель направления Android-разработки в проекте ОК Кирилл Попов.

Ошибки и сбои в работе мобильного приложения — беда для любого разработчика, которая непременно тянет за собой ворох проблем в виде ухудшения UI, потери лояльности и оттока аудитории, а также смещения фокуса с написания продуктового кода на исправление багов. Вместе с тем, часто полностью исключить проблемы невозможно. Поэтому, чтобы обеспечить предсказуемую работу прода и свести ущерб от сбоев к минимуму, важно своевременно проводить аналитику ошибок. Но есть кейсы, когда классических решений со стектрейсами ошибок не достаточно, чтобы понять что и, главное, почему идет не так. В таких и многих других сценариях поможет Tracer — модульный инструмент для аналитики ошибок в мобильных приложениях от OK.Tech, технической команды ОК, который можно настроить под определенную задачу и который может решать конкретные проблемы.

 Что надо знать, чтобы успешно применять-реализовать многопоточность (Multithreading) в своей программе? Мне кажется есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются не раскрытыми или вообще пропускаются.

Мне хочется предложить на суд читателей мое собственное понимание таких неудобных аспектов, связанных с применением многопоточности для практического программирования, которое накопилось у меня за пару десятилетий успешного применения этой самой многопоточности на всех уровнях разработки от Embedded и аппаратно-ориентированных уровней до C#, WPF, Java высокоуровневых фронт-ендов.

Те, кто работал над крупным Android-проектом с множеством модулей, не понаслышке знают, что такие проекты могут долго собираться. Неважно, что мы делаем — исправляем баг или разрабатываем фичу, нам нужно собрать проект, чтобы увидеть, как изменения повлияли на приложение. Мы тратим время на ожидание сборки проекта, и это влияет на продуктивность. 

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

Меня зовут Олег Шелякин, я ведущий Android-разработчик в мобильном банке Тинькофф. Статья будет интересна тем, кто работает над многомодульным проектом, где количество модулей перевалило за сотню, время синхронизации измеряется в минутах, а время сборки — в десятках минут.

Привет, меня зовут Андрей Богомолов, я Android-разработчик в команде Платформа приложения Ozon Seller.

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

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

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

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

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

У нас в проекте с незапамятных времён для DI используется Dagger. И в целом он нас всем устраивает. Ну, разве что кроме одного маленького пунктика — скорость сборки с kapt. Он прилично увеличивает время сборки. Казалось бы, смирись, страдай, прими ситуацию. Но относительно недавно Yandex представили библиотеку для Dependency Injection. Имя ей Yatagan. У неё есть две важных особенности — она спроектирована быть похожей на Dagger по API, и одна из её целей — меньше влиять на время сборки. Меньшее время сборки — это всегда хорошо, а значит, стоит её как минимум попробовать. 

На Google I/O 2021 продемонстрировали фичу, которая позволяет динамически менять цветовую схему приложения в зависимости от его контента. Но ни в документации, ни в официальных примерах не оказалось использования этого подхода или API, которое делало бы это на уровне отдельного экрана или элемента.

Ведущего android-разработчика red_mad_robot Рому Чорыева это не устроило, и он для этой цели решил разработать собственное простое решение, — а теперь рассказывает об этом в статье.

Привет! Я Максим Коробов, руководитель отдела разработки мобильного приложения Тинькофф. В статье расскажу о том, как проходит отбор кандидатов на вакансии разработчиков iOS и Android, что спрашивают на первичном и техническом интервью и какие задачи предлагают решать во время практической секции. 

Материал будет полезен разработчикам, которые ищут точки роста, интересуются проектами в крупных компаниях или хотят работать именно в Тинькофф. Если это про вас, не переключайтесь.