С релизом Android 12 приложения, где новая версия операционки будет указана в targetSdkVersion, получат запрет на запуск foreground-сервисов в бэкграунде. В качестве альтернативы Google предлагает WorkManager, который с появлением expedited jobs станет предпочтительным вариантом для запуска высокоприоритетных фоновых задач. 

О нём и пойдёт речь в статье — под катом обсудим новые возможности инструмента, подключим его к приложению и реализуем миграцию с foreground-сервиса.

Алоха, Хабр! Тестирование рекламных интеграций — довольно трудоёмкий процесс, который сложно автоматизировать, так как мы работаем со сторонними SDK и практически не можем их контролировать. Но для сокращения времени мы разработали и внедрили рекламную дебаг-панель, о плюсах и минусах которой расскажу в этой статье.

По мере развития приложения стоит проводить её аудит для выявления неявных деградаций в производительности. Недавно я проводил аудит раздела комментариев iFunny и написал собственный профайлер. Он не заменит имеющиеся на рынке инструменты Android Profile из Android Studio, Battery Historian и Systrace, но обладает рядом плюсов:

1. Негативное влияние профилировщика на производительность приложения сводится к минимуму.
2. Документация итераций оптимизации работы приложения.
3. Гибкость в сборе метрик.

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

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

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

Тестировать рекламные механики не так просто, как может показаться. Главные действующие лица здесь — сторонние SDK, которые не особо подконтрольны команде разработки. А так как рекламные интеграции — важная часть наших мобильных приложений, то ниже вместе с @maiscourt и @santypa расскажем, как мы это делаем.

Под катом список инструментов с описаниями, задачи тестирования и некоторые внутренние гайдлайны.

Большинство статей про алгоритмы, используемые для решения задачи многорукого бандита, очень академичны. Они пестрят формулами, графиками и статистическими таблицами. При этом как будто подразумевается, что у нас есть неизменяемый набор ручек для дёргания и n→∞ попыток. В этой статье я постараюсь рассказать об этих алгоритмах с колокольни обычного разработчика применительно к реальным условиям, в которых работает наш продукт (но графики будут — с ними красивее).

Дисклеймер: эта статья написана обычным разработчиком, не дата-саентистом или аналитиком. Не стоит рассматривать её в качестве серьёзного научного труда и искать неточности, неполноту и крайности. Она не про это.

Так как это статья про конкретное практическое применение, то и термины буду использовать из нашего домена:

• просмотр(n) = попытка;
• смайл(s) = победа;
• смайлрейт(w, от worth) = количество смайлов/количество просмотров;
• контент = то, у чего есть эти самые просмотры и смайлы.

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

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

Задание полностью отличалось от того, чем мы привыкли заниматься, разрабатывая мобильные приложения — нужно было научить машинку на основе Raspberry Pi 4.0 с камерой объезжать препятствия, искать врага определённого цвета и идти на таран. Кто показал в среднем лучший результат — тот и выиграл.

Задание опубликовали в день старта, выделили пару полноценных дней на разработку и провели финал в офисе с онлайн-трансляцией. Под катом — подробное описание задачи и решения команд. Гифки с хайлайтами прилагаются.