Android Broadcast: тренды Android-разработки 2022

Кирилл Розов, ведущий Android Broadcast, строит планы на 2022 год.

Jetpack Compose

Jetpack Compose — готов он продакшену, не готов, подожду еще годик после первого релиза, вот пофиксят все и тогда можно будет брать — столько всего я слышал про Compose.

На самом деле, его уже успешно интегрируют и я думаю его популяризация будет только расти. Ребята из Google не особо заинтересованы в том, чтобы развивать систему Android View. Они ее поддерживают, добавляют что-то, но, скорее всего, это актуализация планов, которые были раньше. Все-все новомодные фишки будут уходить именно в Compose, потому что он им развязывает руки. У них там много свободы и заниматься им намного интересней, чем старой системой, в которой надо будет обеспечивать для тех, кто написал кучу кода, какую-то обратную совместимость. Заниматься двумя направлениями сразу вряд ли у них получится.

Да, к сожалению, новое неизбежно все будет заменять старое, мы будем двигаться вперед и, конечно же, останутся проекты, в которых можно будет узнать Android View. Можно ли их не учить? Нет, знать их надо, потому что работать с ними придется везде. View это фундамент Android, без него никуда и есть места, в которых на Compose просто будет не перейти.

Будет ли Jetpack Compose активного набирать обороты? Тут даже нет сомнений. Все будет только больше, все будет активнее и много всякого интересного будет с ним происходить.

Я думаю, новые релизы будут привносить разный функционал, догоняющий существующую систему Android View, потому что на текущий момент Compose по возможностям отстаёт от нативной системы UI, которая уже существует давным-давно. Но Compose очень активно ее догоняет, а в каких то моментах даже перегоняет.

Яркий пример — как сделать анимации с Compose. Это уже стало на порядок проще чем то, что нам предлагается в системе View. Поэтому ждем улучшений и больше интеграций, больше примеров с ним.

RxJava, корутины и Flow

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

Но самое важное событие, которое случилось в многопоточке – RxJava. RxJava – один, наверно, из самых популярных сейчас подходов в Android-разработке для того, чтобы работать с потоками.

Хотя предназначался он для других вещей, но засел очень крепко и никуда уходить не хочет. Часть разработчиков его любит, не все готовы его менять на корутины, не все видят в корутинах особые плюсы, не все готовы переписывать код, не всё корутины могут делать, есть спорные моменты и прочее, прочее. Поэтому RxJava точно останется с нами.

Но, если несколько лет назад корутины просто были в отдельных проектах, и нужно было еще найти, где их интегрировать, то сейчас таких проектов становится все больше. Даже сама команда Android уже давно признала корутины Kotlin официально рекомендуемым подходом для организации асинхронного выполнения задач и многопоточности. Все  новые API и библиотеки Jetpack пишутся на Kotlin, и там они сразу пишутся с асинхронным подходом, с ключевым словом «suspend».

Фактически? вам будут все больше и больше навязывать корутины.

С RxJava, кстати, так не было, хотя всегда была библиотека для ее поддержки. Но вот именно корутины сейчас являются главным подходом.

Все это потому, что сейчас, естественно, разработка в Android строится вокруг UI. UI текущий современный — это Compose. Compose – это чистый Kotlin. Чистый Kotlin – соответственно, нужны библиотеки, или можно сразу обеспечивать асинхронность, потому что есть ключевые слова, которые позволяют все это делать, есть корутины, которые все это позволяют делать. Естественно, все это будет пропитываться и использоваться все больше и больше.

Архитектура: MVI, MVP, MVVM

А какую теперь архитектуру использовать? Ведь приходит Compose, вообще все меняется. Что у нас будет происходить с архитектурой? Давайте разбираться.

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

Что будет у нас с архитектурой презентационного слоя? Естественно, MVVM, который продвигает Google, будет актуальным. Google активно нас нацеливает на Compose, и там нужно использовать Unidirectional архитектуры. Фактически, когда у вас есть стрим событий с UI и обратное пробрасывание состояния в вашу View. Это может быть Compose, это может быть Android View, но главное – View-слой. Как раз MVVM ему соответствует.

MVI будет очень активно набирать популярность, потому что с декларативным UI всегда ассоциируют какой-то MVI-подход. Это удобно, но мне, например, MVI не заходит, поэтому для меня MVVM в таком чистом виде – довольно приятная штука.

Но если вы будете переходить на декларативный UI, то тут наступает смерть MVP, потому что MVP сделан так, что презентер должен контролировать View и не пробрасывать ее в ивент, а именно прямо вызывать, что у нее происходит.

И если вы у себя используете MVP, к сожалению, либо вы не сможете перейти на Compose или на какие-то другие виды декларативного UI, либо вам придется от него отказываться. Это нормально. MVP–подход себя изжил с событийными подходами, когда у вас есть именно потоки ивентов, без него будет жить намного проще.

Что у нас будет с DI? Естественно, у нас, как всегда, есть старый добрый Dagger – старый друг лучше новых двух. Но с ним есть пачка проблем. Естественно, он генерирует множество кода. Он не такой простой в освоении. И вообще множество вещей с ним делать сложно.

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

Hilt – ту затычку, которую предложил Google для упрощение, я не считаю хорошим эффективным решением для больших проектов, потому что сейчас с ним есть сложности в модульности и много всяких «но».

Если вы идете по стандартному Flow в небольшом проекте, у вас проблем не будет. Но как только у вас появляется какая-то кастомизация и прочее, к сожалению, с Hiltом нужно тоже писать много кода поверх, изучать не меньше, а может, даже больше, и сложнее все это впихивать, поэтому еще непонятно насколько все это проще. Поэтому, если у вас маленький проект, берите Hilt, но если вы понимаете, что он будет разрастаться и прочее, то лучше оставайтесь на Dagger.

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

Если мы говорим вообще уже про генерацию кода, большой сдвиг, который сейчас начинает происходить (к сожалению, потихоньку) — замена KAPT на KSP. Мы переходим с генерации  кода на основе Java-механизмов, на механизмы, которые лежат в Kotlin-компиляторе, то есть KSP.

И это очень классно, но, во-первых, KAPT полностью на KSP не заменить, потому что KAPT все-таки базируется на Java Annotation Processing, который не является полным аналогом KSP, то есть KSP – это такая урезанная версия. Не каждая библиотека может легко переехать. Сейчас поддержка KSP есть в Room, и то ограниченная, пока не все, и пока они еще в активной разработке находятся. Тот же Dagger, я не думаю, что быстро получится перевести на KSP, потому что с ним немножко все сложнее.

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

Kotlin и Multiplatform

Давайте поговорим про Kotlin. В Kotlin сейчас активно девелопят IR, новый компилятор Kotlin Intermediate Representation, который будет единый для всех поддерживаемых платформ. И он позволит значительно ускорить разработку новых фичей, он позволит ускорить работу Kotlin, и вообще много-много чего позитивного он должен принести. И пока идет его доработка, стопорнулось развитие каких-то новых функций. В принципе, сейчас команда Kotlin на этом сосредоточена.

Надеюсь, что в этом году мы уже увидим его финальную версию, и команда Kotlin продолжит дальше разрабатывать новые возможности, потому что они уже провели опросы по фичам, но пока все отложили.

Этой весной должно произойти важное событие для тех, кто любит мультиплатформу – KMM должен выйти в бете. И я надеюсь, что Kotlin Native с новой memory-моделью тоже будет выходить в фазу стабилизации, и мы, естественно, уже сможем в обозримом будущем получить новые вещи.

Но самое главное, что в этом году мы ждем мультиплатформенный Compose с очень важной поддержкой iOS. Сейчас классно, что Compose можно писать для десктопа, можно делать что-то в вэбе, но без iOS популярность KMM получить сложнее.

Да, Kotlin Multiplatform пилился в другой идеологии, что он для шаринга бизнес-логики и прочего, но бизнес хочет экономить много времени. А экономить много времени можно на шаринге UI. И как раз Compose для iOS даст большой толчок развитию KMM и Kotlin Multiplatform в целом. Это значимый шаг.

Инструменты

Помимо того, что мы разрабатываем какие-то фичи в языках и SDK, нам нужен хороший классный тулинг. Android Studio развивается, она сейчас перешла на новую модель,  они стабилизировали Gradle API, и много чего делают.

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

Это уже сейчас все идет в разработке. На Android Dev Summit 2021 года показали это. Когда это будет интегрировано, не сказали, но команда Android прекрасно понимает, чего от них ждут. И им нужно лишь время, чтобы реализовать эти затеи, поэтому давайте смотреть, давайте следить.

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

JetBrains сейчас делает много всяких инструментов. Совсем недавно на моем канале было интервью с Антоном Архиповым, где мы про это все поговорили – про удаленную разработку, про текущее состояние инструментария, про Fleet поговорили, про Remote Development, который, кстати, как Антон сказал, должен скоро появиться именно и в Android Studio.

Конечно же, Сode With Me – это плагин для IDEA Ultimate, где вы можете шарить что-то и, естественно, с другом своим или коллегой работать вместе над одним куском кода и общаться. Почему все это становится актуальным? Да все довольно просто. Мир уже принимает удаленку, формат работы вне офиса уже становится нормой, и нужно иметь эффективный пакет инструментов.

Насколько быстро те наработки, которые делает JetBrains, будут интегрироваться в Android Studio – очень интересный вопрос. Как мы знаем, обычно текущая версия тулинга отстает на два поколения от IDEA. Например, если сейчас уже выходит 2022.1 IDEA, то мы сидим в стабильной версии 2021. Вопрос – насколько Google заинтересован в том, чтобы интегрировать быстрее эти инструменты и дать возможность нам с ними работать. А еще, самое главное, если часть инструментов доступна только в Ultimate, получим ли мы их вообще каким-то образом в Android Studio? Вопрос на миллион.

Удаленная работа

Главный тренд, который у нас в 2022 году продолжается – это удаленка. Наверное, сначала она была шоком для всех компаний, потому что не все были готовы к переходу на нее. Те немногочисленные компании, которые еще до старта пандемии побыли во всем этом и, в принципе, работали и знали, им было все равно. Но многие компании, которые работали всегда в офисе и контролировали сотрудников, это был их принцип, были не очень довольны и ждали возвращения.

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

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

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

Да, какие-то компании с этим работают. Я слышал о Facebook – когда все это началось, они сделали хорошие бонусы сотрудникам, чтобы они обеспечили свои рабочие места. Но большинство компаний, о которых мне известно, из России, Беларуси и Украины этого делать не стали. Ну, а те, кто стали, я знаю, что это такая смешная сумма, что там себе даже стул нормальный не купишь.

Также будет все активнее развиваться тулинг. Да, я уже показывал на примере JetBrains, что они активно свой инструментарий развивают. Очень сейчас активно развиваются виртуальные рабочие столы. Это те же серверы через облачные инструменты. Я думаю, например, если вы смотрите русских блогеров, то вполне могли видеть рекламу Selectel, который активно рассказывает про свои инструменты.

Плохая ли это тенденция? Нет, довольно хорошая и актуальная для текущего времени. Посмотрите, как компании Google и Apple развивают свой тулинг. В Apple очень активно начали развивать, например, тот же свой Keynote для презентаций, который я просто обожаю как программу для того, чтобы делать все презентации. У них стало появляться все больше вещей для коллабораций. Например, режим презентации вдвоем. У них появилась возможность делать презентацию не на full screen, а в окне, то есть супер удобно, когда у тебя нет нескольких экранов.

Нужно уже привыкнуть к тому, что мир изменился. Даже если завтра вся пандемия закончится, люди почувствовали эти преимущества.