11 декабря 2018

GDG DevFest 2018

GDG DevFest 2018 Noveo

Уже третий год подряд сообщество Google Developer Groups радует сибирских разработчиков, менеджеров, тестировщиков, дизайнеров и всех, кто вовлечен в мир IT-индустрии. В ноябре на площадке Технопарка прошла IT-конференция GDG DevFest Siberia, которая в этом году была расширена дополнительным днем воркшопов, где можно было попробовать на практике новые технологии. Как и в предыдущие годы, компания Noveo выступила одним из участников спонсорского пакета, и, конечно, была только рада поддержать сотрудников, выразивших желание посетить DevFest. Среди более чем полутора десятка участников-новеовчан — Android-разработчики Таня и Варя, которых мы попросили поделиться впечатлениями о том, что заинтересовало их больше всего.

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

Секция Mobile для Android-разработчиков в этом году была самой концентрированной и яркой за все три года. Основной фокус докладов по Android начал смещаться на визуальную красоту и производительность приложений, что говорит о росте скиллов сообщества. Ведь если вспомнить историю, на заре эпохи во времена GingerBread разработчиков волновало в основном, как не падать по Out of memory exception. С развитием Android-платформы основная масса подобных проблем разрешилась, и разработчики переключились на задачи следующего уровня:

  • Как сделать код поддерживаемым и гибким для изменений?
  • Как при добавлении следующей фичи не упереться в рефакторинг, который нельзя обойти? И как этот рефакторинг сделать?
  • Как адаптировать разработку под команду и не ломать своими изменениями код коллег?

В течение последних лет не утихали разговоры об архитектуре, подходах и инструментах разработки. Эти дискуссии не прошли даром: сейчас мы можем свободно говорить на одном языке. Появились Best Practices, лучшие библиотеки превратились в стандарт индустрии, были созданы проекты Open Source, которые могут служить образцами. Кроме того, нельзя недооценивать также развитие инструментов: взять хотя бы недавний переход на Kotlin как на основной язык разработки. Поддерживаемость и структуризация кода не перестали быть важными, но сейчас у людей, которые пишут код, появилось время подумать ещё и о визуальном аспекте приложений. Так же, как в своё время с решением базовых проблем появилось время задуматься об архитектуре.

Говоря о визуальных аспектах приложений, стоит отметить, что в Android уже существует большое количество способов добавить любые анимации в приложение, даже из самых смелых фантазий дизайнера: Drawable animations, View Animations, Property Animations, Layout animations, Transitions framework, Shared Objects — и это далеко не полный список. На далеком Google I/O ‘15 были представлены ViewGroup, которые упростили разработку экранов с стандартными collapse/expand анимациями, отвечающими Material Design: AppbarLayout, CollapsingToolbarLayout и CoordinatorLayout. После выхода этих ViewGroup потребовалось определенное время на их отладку, не все смогли сразу внедрить их в продакшн, но сейчас Google Play содержит массу приложений, которые их используют. Однако это было лишь начало, и компания Google пошла дальше в стремлении сделать анимации простыми для разработки. В этом году на Google I/O ‘18 был анонсирован новый MotionLayout — ViewGroup, который позволит настроить практически любые анимации для всех View, которые он содержит. Главный плюс использования MotionLayout — все анимации останутся в файлах разметки, и ваши Activity или Fragments не будут содержать ни строчки кода для анимаций или смены состояний для View из связанного файла разметки. Кроме того, Google разрабатывает MotionLayout tooling, и скоро анимации можно будет отлаживать без запуска приложения, подобно тому, как мы отлаживаем View, смотря в Preview. Константин Цховребов был впечатлен анонсированными возможностями MotionLayout и решил реализовать понравившуюся ему анимацию с сайта Dribbble.com. В своем докладе «MotionLayout на практике» он рассказал о проблемах и их решениях при реализации, с какими ограничениями он столкнулся, а главное — можно ли уже применять новинку в продакшн-коде. Пример анимаций, который он выбрал, был достаточно сложным и однозначно потребовал бы контроля над анимациями в коде Activity. Однако с использованием MotionLayout Activity осталась пустой, все анимации остались в файлах xml — и это действительно здорово, это еще один шаг к разделению ответственности в коде. Google есть что еще доработать в MotionLayout, но он уже способен на многое, пора применять его в своих проектах. Этот доклад вдохновил многих скорее попробовать реализовать что-то с MotionLayout.

В докладе «Как мы ускоряем Яндекс под Android» Артур Василов из компании Яндекс поделился подходами к ускорению работы приложений под Android. Всем известно, что компания Яндекс всегда делала упор на повышение скорости работы своих приложений, что не удивительно, ведь показатели производительности — это продуктовые показатели, напрямую определяющие качество вашего приложения. Артур рассказывал, как схитрить и где подумать в, казалось бы, стандартных кейсах, которые встречаются в практически каждом приложении: запуск приложения, выполнение сетевых запросов, отображение списков. Редко кто из разработчиков задумывается, что можно оптимизировать получение данных из сети, ведь сетевой запрос напрямую зависит от скорости сетевого соединения, на которую программно никак не повлиять. Но Артур напомнил, что отправка сетевого запроса — это составная операция, которую можно попробовать ускорить на каждом ее шаге:

  • инициализация запроса,
  • получение ответа от сервера,
  • парсинг json,
  • маппинг данных в представление (UI).

Главная идея, на чем можно выиграть по скорости: каждый шаг можно начинать раньше, чтобы раньше его закончить. В частности, инициализировать запрос нужно как можно раньше, выбирая самые первые методы лайфсайкла активити или фрагментов. Потом не нужно ждать, пока придут данные для отображения, можно начать подготовку View. Отрисовка View — это относительно долгий процесс, состоящий из нескольких этапов, но, пока View не добавлена к иерархии на экране, можно начать ее настраивать даже в отдельном потоке. Конечно, это нарушает привычные правила работы с View (операции над вьюшками должны выполняться в главном потоке), но можно получить заметное ускорение, если, например, создать пул View для списка RecyclerView заранее. Наконец, при получении данных от сервера можно сразу начать читать данные из потока на скачивание, не прибегая к стандартным парсерам, при чтении данные можно сразу отправлять для отображения, тем более, что View уже готова и ожидает данных. В итоге можно создать эффект «мгновенной пагинации».

Для решения проблемы скорости запуска приложения нужно оптимизировать загрузку классов — именно этот этап при запуске часто самый долгий. Поэтому стоит ограничить использование в проекте популярных библиотек, которые прибегают к кодогенерации. Например, для dependency injection (DI) часто используют Dagger, прибегающий к неудержимой кодогенерации. Кроме того, нужно уметь грамотно выделять компоненты и стоит ознакомиться с опциями, доступными для оптимизации Dagger в Gradle. Есть и более сложные подходы — можно указать последовательность классов в dex-файле, что может дать хорошее ускорение времени запуска приложения.

GDG DevFest 2018 Noveo

Федор Цыбал в презентации «Project Treble. Технический долг длиною в жизнь» поделился своим опытом и взглядом инсайдера:

  • что Google сделал (или чего Google не сделал в самом начале)?
  • Каким был переход на Android Oreo для производителей девайсов?
  • Каким будет переход на следующие версии системы Android?
  • Почему с выходом новой версии не все девайсы могут сразу обновиться, а многие не могут вообще, что заставляет пользователей покупать новые девайсы?

В основном разработчики мобильных приложений не задумываются, какие изменения происходят «под капотом» с выходом новой системы Android, для них важно лишь отладить свой код, чтобы поддерживать нововведения или ограничения. Поэтому многим было интересно услышать презентацию Федора, где он рассказал, что переход на новую версию ОС всегда требовал, чтобы производители чипов и производители девайсов также выпустили апдейт, чтобы поддерживать изменения от Google, а это в итоге сдерживает выход новой системы на конечный продукт — мобильные девайсы. Project Treble — это глобальный архитектурный рефакторинг, который был нацелен на решение этих проблем интеграции новых ОС на мобильные девайсы и полностью лег на плечи компании Google. Благодаря Project Treble после Android Oreo переход на новые системы должен быть облегчен для производителей устройств под Android. В августе этого года вышла топовая на данный момент версия Android 9 Pie, многие девайсы сразу получили апдейт на beta версию, и, казалось, замысел Google удался, но если посмотреть статистику сейчас, то только два производителя, Google и Essential, выпустили девайсы с Android Pie, что покрывает меньше 0.1 процента рынка. Еще рано судить, получилось ли у них, производители устройств кастомизируют свои прошивки, из-за чего им все равно нужны будут доработки с выходом новых версий ОС. Однако явно наблюдается единая стратегия компании Google: с одной стороны, вендоры устройств должны двигаться к новым прошивкам, с другой — разработчики приложений должны таргетировать последние версии API.

GDG DevFest 2018 Noveo

Сохраняется повышенное внимание к мультиплатформенной разработке, и становится все больше первопроходцев, пробующих сделать такой проект с использованием Kotlin под главные мобильные платформы: iOS и Android. Андрей Мищенко из Сингапура рассказал, что сейчас их команда разрабатывает музыкальный редактор — мультиплатформенное приложение, которое ещё не на Kotlin. Именно поэтому он начал изучать эту тему и поделился своим обзором возможностей Kotlin Multiplatform в презентации «Мультиплатформенная мобильная разработка на Kotlin». Разработка начинается с разделения проекта на модули: платформозависимые модули и модуль Common с чистым Kotlin-кодом, где нет возможности использовать какие-то методы, специфичные для платформ. Этот модуль не может быть скомпилирован сам по себе — только под конкретную платформу. Однако в каждом реальном приложении в модуле Common потребуется платформенный код — без этого не разработать даже библиотеку. Как написать такую функцию, которую можно использовать в общем модуле? Тут на помощь приходит поддержка в языке: Kotlin позволяет использовать декларации функций, вместо их платформозависимых реализаций, с помощью ключевых слов: expect и actual. Функцию Expect можно свободно использовать в общем коде, а реальная имплементация такой функции будет проверена на этапе компиляции. В этом и есть сила языка Kotlin применительно к мультиплатформенной разработке. Проблема, как шарить UI в таком проекте, ещё не решена, и есть серьезные причины, почему сейчас это невозможно (да и не нужно): сильная зависимость от платформы и желание иметь нативный UI. Но можно свободно шарить слой Data и слой бизнес-логики, и теперь не получится, не подумав, нарушить архитектуру проекта: все методы UI останутся в платформозависимых модулях, и вы просто обязаны абстрагировать логику. Андрей пришел к выводу, что, хотя примеров еще немного и сейчас есть всего два мультиплатформенных приложения (и это приложения, разработанные для конференций), Kotlin Multiplatform уже можно использовать. Мы не так часто начинаем новые проекты, но это не значит, что мы не можем попробовать собраться с коллегами и решить: давайте напишем что-то один раз?

Разработчики эволюционируют вместе с технологиями, и, очевидно, запас роста сохраняется бесконечным. По данным исследований Google, Flurry, Yandex и многих других компаний время, которое пользователи проводят в мобильных приложениях, увеличилось и аналитика имеет положительный тренд, а это значит, что у IT-сообщества впереди много работы: пользователям нужно больше интересных и полезных решений, поэтому очень важно сотрудничать друг с другом и делиться идеями, чтобы вместе делать мир IT больше и сильнее. GDG DevFest — это «must attend»-конференция, где можно узнать о разработках зарубежных коллег, а взамен рассказать много нового для них с нашей стороны.

GDG DevFest 2018 Noveo

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: