Код, боль и чипы: мой путь в мобильной разработке

Помню свой первый запуск приложения на Nokia Symbian. Это было в далеком 2007-м. Тогда мы писали код чуть ли не наугад, документация оставляла желать лучшего, а телефоны тормозили так, что казалось – вот-вот закипят. Сейчас мобильная разработка – это другая вселенная. Быстрая, мощная, местами даже слишком. Но некоторые вещи не меняются. Например, вечная дилемма: нативный код или кроссплатформенное решение?

Основа основ – понимание платформы. Не просто умение тыкать в Swift или Kotlin. А чувство того, как живет устройство. Как оно управляет памятью, как работает с сенсорным вводом, как ведет себя при нехватке ресурсов. Вот эту ошибку я у джунов вижу сплошь и рядом – пишут код, который идеально работает на эмуляторе с 16 гигами оперативки, а на реальном устройстве с 2 ГБ оно падает через пять минут. Лично терпеть не могу, когда менеджеры пытаются впихнуть в одно приложение все возможные фичи. Получается монстр, который жрет батарею как не в себя.

Был у меня проект – приложение для онлайн-трансляций. Заказчик хотел всё: HD-видео, чат, модерацию, стикеры, донаты. Сделали. На флагманах летало. А на средних телефонах – перегрев через десять минут. Стандартные методы оптимизации не работали. Пока не сели и не порезали функционал для разных устройств. Для слабых – упрощенная версия видео и базовый чат. Жестко? Зато работает. Иногда лучше сделать два простых приложения, чем одно сложное.

По поводу инструментов. Сейчас модно всё, что кроссплатформенное. React Native, Flutter, Kotlin Multiplatform. Они обещают писать один код для двух платформ. Быстро. Качественно. Дешево. Но по моему опыту, вопреки учебникам, нативный код под конкретную ОС часто дает лучшую производительность и меньше багов. Особенно для сложных интерфейсов или работы с железом. Кроссплатформенщина – это всегда компромисс. Иногда оправданный, иногда – нет.

Работа с памятью – это отдельная песня. В iOS со Swift и ARC всё более-менее предсказуемо. А в Android с его Java/Kotlin и Garbage Collector’ом бывают чудеса. Помню, одно приложение периодически вылетало без логов. Два дня дебагили. Оказалось, сборщик мусора срабатывал в самый неподходящий момент при скролле сложного списка. Добавили ручное управление памятью в критичном месте – проблема ушла. Такие вещи в учебниках не пишут.

Дизайнеры… Люблю их, но иногда хочется задушить. Приносят макет с анимациями, которые съедают 60% процессора. «Но это же красиво!» – говорят. А потом у пользователя батарея садится за три часа. Приходится объяснять, что каждый кадр – это деньги. Время работы. Ресурс. Находим компромисс. Упрощаем. Иногда – упрощаем до безобразия. Зато – работает.

Тестирование. Раньше тестировали на пяти-шести устройствах. Сейчас их сотни. Разные разрешения, версии ОС, производители. Физически все не охватишь. Поэтому юзаем облачные сервисы для тестов. Но и это не панацея. Баг, который проявится только на Sony Xperia с кастомной прошивкой от оператора – это классика.

Выкатка в сторе. App Store и Google Play – два разных мира. Apple любят всё проверять с пристрастием. Могут завернуть из-за одной не той иконки. Google – проще, но там свои тараканы. Особенно с политикой конфиденциальности. Можно месяц ждать апрува, а потом получить отказ из-за пункта, который никто не читал.

Это тема для отдельного разговора – как пережить ревью в App Store без потерь нервных клеток.

Сейчас всё упирается в монетизацию. Подписки, реклама, внутренные покупки. Пользователи ненавидят и то, и другое, и третье. Но с чего-то жить надо. Баланс между «заработать» и «не отпугнуть» – это искусство.

Верстка. Auto Layout в iOS, ConstraintLayout в Android. Казалось бы, решили все проблемы. Но нет. На каждом новом устройстве находится новый баг. Иногда кажется, что проще написать свою систему верстки, чем бороться с нативной. Шутка. Почти.

В итоге, что я могу сказать? Мобильная разработка – это бег с препятствиями. Постоянно меняющиеся правила, новые технологии, капризное железо. Но когда видишь, как твое приложение работает у миллионов людей – это того стоит. Стоит всех ночей с кофе и дебаггером.

Просто помните: нет ничего более постоянного, чем временные костыли в коде. И ни один проект не обходится без фразы «а давайте перепишем это на SwiftUI/Jetpack Compose через год». И ведь переписывают.

Автор статьи: Артем Каштанов, lead iOS-инженер в «Т-Банке» (2015-2023), участник запуска приложения «Госуслуги» на iOS в 2014-м, ментор в мобильном направлении «Яндекс.Практикума».