Тренды Android-разработки

Продолжаем разговор с Андреем Белоусом (@tzkt1 в Телеграм) о том, куда движется Android и мобильная разработка.

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

Стек будет очень сильно зависеть от продукта и целей бизнеса, количества человек в команде, наличия дедлайнов. Например, если цель быстро сделать MVP (Minimum Viable Product) и проверить гипотезу, то стек будет один. Если же это какой-то критически важный продукт для бизнеса, например, банковское приложение, то стек должен быть соответствующий.

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

• Язык. Kotlin, это стандарт разработки для Android последние лет 5–6, он хорошо поддерживается, Java уже уходит в прошлое (для Android), поэтому Kotlin это точно выбор номер один.
• UI. Новый проект имеет смысл начать сразу же с использованием Jetpack Compose — декларативного UI-фреймворка для Android, который разрабатывается и поддерживается Google. Google очень много вкладывает в PR и продвижение, и Jetpack Compose де-факто станет стандартом разработки. Уже сейчас многие приложения Compose first.
• Презентационный слой. Я бы выбирал между MVVM и MVI, т.к. оба этих подхода хорошо работают совместно с Jetpack Compose. Выбор конкретного зависит от приложения. Если приложение более сложное, например, чат со сложной функциональностью, я бы выбрал MVI, т.к. он лучше вписывается в парадигму Compose и лучше решает проблему разработки сложных экранов. Но никто не мешает комбинировать эти 2 подхода, для каких то экранов использовать MVVM, а для каких то MVI.
• Многопоточность. Если лет 5 назад стандартом была RxJava, то теперь это Kotlin Coroutines, не сказал бы, что вижу много преимуществ одного перед другим, но на большинстве собеседований спрашивают корутины, и во многих компаниях их используют. RxJava также уходит в прошлое. Новые разработчики в основном так же знают корутины лучше, чем RxJava, поэтому я бы выбрал корутины.
• Архитектура. Стоит стремиться к разделению кода на слои для повышения тестируемости и чтобы теоретически можно было переиспользовать domain слой, например, в iOS приложении Но тут главное подойти без фанатизма и не плодить абстракций больше, чем нужно.
• DI.  Тут хотелось бы compile time safety и проверенное решение, поэтому если проект будет большим, я бы выбрал Dagger 2 или вовсе сделал бы ручной DI.
• Сетевой слой.  В зависимости от типа приложения тут могут быть очень разные подходы. Если это условно стандартное приложение, которое делает CRUD подобные операции, то я тоже выбрал бы что-то проверенное и известное — Retrofit + OkHttp.
• Local Storage. В зависимости от типа информации, которую надо кешировать, можно рассмотреть разные подходы. Если данных много, у них сложный формат и много зависимостей, нужен быстрый доступ и, например, поиск, то, конечно, нужна реляционная база данных. Использовать ли ORM, вроде Room, вопрос интересный. Я не вижу больших преимуществ в использовании Room, но добавляя его появляется еще одна зависимость и порог входа увеличивается. Поэтому, для реляционной БД, я бы взял чистый SQLite, и уже потом рассмотрел возможность внедрения Room-like решений. Если же данные для кеширования вписываются в формат document like, то точно стоит рассмотреть использование нереляционных баз данных, например, Realm. С ними будет легче делать миграции на новый формат данных — чего в новом приложении точно будет много, и это потенциально спасёт от некоторых проблем.

Как может меняться такой стек?

Стек может меняться по разным причинам.

С ростом приложения и команды.

Когда команда растет, некоторые инструменты перестают быть удобными. Например, может стать неудобным использование REST like архитектуры, потому что не удобно управлять моделями данных на всех клиентах или есть потребность уменьшить количество данных, передающихся по сети. Тогда команда может рассмотреть переход на gRPC и protobuf для автоматической генерации кода и уменьшения трафика.

Также с ростом команды могут понадобиться end to end тесты, а это значит, что нужно будет внедрить какой-то фреймворк для этого (Appium, UI Automator). В большой команде так же хотелось бы видеть инструменты автоматического анализа кода, чтобы все разработчики писали плюс минус по одним правилам.

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

Со временем.

Выходят новые фреймворки, подходы, библиотеки. Если пять лет назад реактивное программирование было стандартом, и на каждой конференции было несколько докладов про это, то теперь в Android есть корутины. Относительно недавно появился Jetpack Compose и многие приложения теперь Compose First. Поэтому я бы так-же ожидал чего-то нового в будущем.

Куда в целом движется Android-разработка?

Android-разработка движется в сторону упрощения и стандартизации. Когда Android-разработка только зарождалась, не было единых подходов к разработке, все писали приложения как умеют. Использовали разные инструменты, не было единого подхода к архитектуре, и не было “золотых” стандартов от Google.

Сейчас же есть набор Jetpack библиотек,лучшие практики от Google. Есть удобные и легкие для освоения решения для многопоточности, написания UI, баз данных, DI, навигации.

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

Куда тогда движется вся мобильная разработка?

Платформы (iOS, Android) всё больше сближаются. Как с точки зрения пользователя, так и с точки зрения разработчика. Многие команды постепенно пробуют кроссплатформенные решения. И на нескольких последних конференциях было намного больше докладов про кроссплатформу.

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

Какие навыки будут востребованы в ближайшие 3-5 лет?

3-5 лет для мобильной разработки довольно средний срок, не думаю, что что-то поменяется принципиально. Скорее всего, всё больше приложений будут использовать Jetpack Compose, корутины, Kotlin и Google Jetpack Libraries (Room, Navigation, ViewModel etc).

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

Отдельно я бы выделил навык прохождения интервью. Если есть желание попасть в крупную FAANG like компанию, то очень большая вероятность, что собеседование там более менее стандартное. Это значит, что для повышения шансов прохождения интервью нужно решить 200 медиум задач на leetcode.com и научиться проектировать мобильные приложения.

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

Тогда куда вкладывать свои силы в разрезе обучения?

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

После этого можно так же выбрать идею и реализовать ее без использования (ну или с минимальным использованием) библиотек. Это поможет разобраться, как всё работает изнутри.

Несколько идей приложений, которые кажутся мне хорошими для обучения:

• Реализовать простой клиент IMDB.com на их API с поддержкой оффлайн режима
• Приложение по показу погоды + виджет, отслеживающие геолокацию пользователя в фоне
• Приложение, которое транслирует написанный текст в азбуку морзе фонариком
• Тетрис на Jetpack Compose

Какое будущее у ИИ в разработке?

В зависимости от темпов развития ИИ, варианты могут быть разные. Уже сейчас ИИ может помогать в разработке как опытным разработчикам, так и начинающим. Существуют проекты — ИИ-конструкторы приложений. Но не сказал бы, что они могут составить конкуренцию разработчикам. ИИ может очень хорошо работать в таких сценариях:

• Написание документации
• “Продвинутый” поисковик
• Консультант по языку/технологии с которой ты не знаком
• Написание очень простых проектов

В реальных же рабочих задачах по написанию кода помощь довольно слабая (пока что).

Еще непонятно где мы находимся в цикле развития технологии. Это уже близко к максимуму? Если нет и мы предполагаем хотя бы 1% инкрементальное улучшение каждый год, то через какое то время ИИ должен сравняться с разработчиками. Плюс, компании должны внедрить его в свои процессы, решить проблемы безопасности, контроля качества. Поэтому, я думаю, что этого не случится в ближайшие лет 10.

Ну и напоследок, будет ли вменяемый кроссплатформенный движок (наприме, KMM) для приложений?

Уже сейчас KMM это довольно хороший и зрелый инструмент для кроссплатформенной разработки. Уже существуют кроссплатформенные архитектурные решения, а Jetpack Compose multiplatform в альфа версии для iOS. Поэтому думаю, что полное решение всех существующих проблем это лишь вопрос времени.

Понятно, что вряд-ли получится унифицировать разработку на две платформы на 100%, но, думаю, что получится подойти к этому максимально близко.