О чём говорили на Google I-O 2019: Android 10, AR-приложения и многое другое

В этой статье я расскажу о своих впечатлениях от конференции Google I/O 2019, на которой мы с коллегами побывали на днях (и даже “засветились” с нашим приложением в одной из презентаций). Она поможет вам проникнуться атмосферой и, возможно, побудит посмотреть несколько докладов, выложенных на  канале Google Developers ^[1].

Разработчики Badoo на Google I/O 2019

День 0. Предисловие

Чтобы попасть на конференцию, нужно выиграть в лотерее, которая стартует в феврале на сайте Google I/O ^[2] (обычно об этом становится известно из новостей). Но победа не предусматривает получение билета, а лишь даёт возможность выкупить его за 1150 долларов. Есть и другие программы, которые позволяют получить билет с большой скидкой или бесплатно, например Code Jam ^[3]. Студенты и работники вузов могут купить билет значительно дешевле — за 375 долларов.

Перед конференцией IT-компании устраивали вечеринки для участников. Я узнал о них из чата в Telegram, в котором собралось более 150 русскоговорящих пользователей. Обычно в подобные чаты можно попасть по приглашениям из профильных Android-сообществ в Telegram. Такие вечеринки — хорошая возможность познакомиться с другими участниками конференции в неформальной обстановке. Например, мы встретили там организатора Mobius и команду разработчиков, которые делают приложение для авиапутешественников App in the Air.

Конференция проходила под лозунгом «No parking». Google организовала бесплатные автобусы от и до самых популярных отелей в окрестностях, а также выделила промокоды на сервис такси Lyft (американский конкурент Uber).

Из Badoo нас было пять разработчиков. Поехали все, кто выиграл возможность купить билет. Доклады шли в шесть—десять потоков, и часто мы разделялись, чтобы охватить больше интересных тем.

День 1

Первый день конференции открывают так называемые keynotes — общие презентации. Первая — для всех, вторая — для разработчиков.

Перед keynote человек-DJ и AI-DJ работают вместе

Главные новости

На первой keynote презентации рассказывали о разных проектах Google. Вот некоторые новости:

• компания продолжает развивать Google Duplex — робота-ассистента, который может позвонить и забронировать время в парикмахерской / столик в ресторане;
• Google Lens умеет анализировать чеки и разделять сумму счёта с суммой  чаевых (популярная задача в США);
• Google Assistant будет работать офлайн и заметно уменьшится в размерах, а аудиосообщения в мессенджерах и звонки можно будет увидеть в виде текста на экране с помощью Live Relay.

В Android 10 появятся:

• больше родительского контроля;
• тёмная тема;
• улучшенная поддержка складывающихся устройств;
• новая навигация жестами;
• улучшенный sharing;
• новая группировка уведомлений по приоритету.

На презентации для разработчиков объявили, что Kotlin теперь является основным языком программирования для Android-разработки. Google представила новую библиотеку для камеры Camera X, новый декларативный UI Jetpack Compose (судя по всему, он ещё достаточно сырой, но очень многообещающий), новые возможности для обновления приложения: разработчик сможет запрашивать обновление самостоятельно в интерфейсе приложения.

Во время каждого доклада субтитры генерируются в режиме реального времени

Советы Google, касающиеся складывающихся устройств

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

Представители Google заверили, что если следовать лучшим практикам, например правильно обрабатывать переворот экрана, то всё будет работать «из коробки». Для поддержки складывающихся устройств используется тот же механизм, что и для мультиоконности на планшетах и Chrome OS. В дополнение к уже существующему android:maxAspectRatio появится android:minAspectRatio, призванный добавить ограничения на соотношения поддерживаемых сторон в приложении. Google уверяет, что 2 дюйма (5,08 см) станет минимальной шириной экрана Android-устройств начиная с Android Q.

Несколько вещей, которые стоит проверить, если вы реализуете поддержку складывающихся устройств у себя в приложении, при сгибании и разгибании устройства:

• приложение должно восстанавливать то же состояние;
• позиция скролла должна сохраняться;
• фокус клавиатуры должен оставаться таким же.

Если вы не хотите, чтобы Activity изменяла размер, то флаг android:resizeableActivity=false не всегда может помочь в этом, так как система всё равно может изменить размер Activity или поместить его в режим совместимости:

Режим совместимости

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

О плюсах и минусах многомодульности

На конференции много внимания уделялось модульности. Основные плюсы многомодульности:

• тесты можно запускать только для тех модулей, на которые как-то повлияли изменения в текущей ветке;
• можно изолировать тестирование различных функций приложения; например, у нас в Badoo есть приложение-галерея, в котором собраны все UI-элементы, при их разработке можно собирать это приложение достаточно быстро, так как оно имеет ограниченное количество зависимостей (подробнее об этом мои коллеги рассказывали в докладе на MBLT DEV ^[4]);
• возможность добавления динамических фич: по словам докладчика, 80% пользователей используют 20% функций приложения, поэтому большинство функций можно вынести в dynamic module и загружать позднее; хорошими кандидатами являются, например, функции для пользователей-экспертов, функции, за которые нужно платить, экран «О приложении»; при этом Onboarding не стоит делать динамической функцией, так как он будет показан всем пользователям приложения.

Также многомодульность хорошо масштабируется под большое количество разработчиков, что является существенным преимуществом для больших и быстрорастущих команд.
У многомодульности есть и проблемы. Например, непонятно, как создавать базу данных. Есть три подхода:

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

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

У нас в приложении Badoo более 170 модулей, мы пока не используем dynamic feature, но получаем другие преимущества и недостатки многомодульности.

День 2

Второй день конференции был самым насыщенным. Первый доклад начался в 8:30, а последний закончился в 20:00. В общей сложности было представлено 90 докладов.

Такая аудитория полностью наполняется людьми примерно за десять минут

Новый декларативный UI

Системе Android уже десять лет, текущий UI морально устарел. Старый UI достаточно сложно поддерживать. Например, класс View имеет 29 188 строк кода, включая комментарии, AppCompat-версия обросла множеством хаков для разных версий Android. Посмотрев на эту картину, разработчики Google решили сделать UI-фреймворк, который будет поставляться вместе с приложением и станет полностью отвязанным от Android. Рабочее название фреймворка — Jetpack Compose.

Flutter, React, Litho и Vue.js служили источниками вдохновения для разработчиков, поэтому новый фреймворк многим покажется знакомым. Основная идея в обеспечении реагирования UI на изменения модели, при этом логики в UI нет.

Иерархия View представляется в виде функций, помеченных аннотацией @Composable. Фреймворк использует Compiler Plugin для перехвата вызовов к composable функциям.
Команда Google обещает поддержку нового фреймворка в старых иерархиях View (с помощью аннотаций @GenerateView), а также предпросмотр прямо в Android Studio и поддержку анимаций.
Jetpack Compose пока ещё достаточно сырой и не готов к использованию в реальных приложениях, но изучить принципы его работы стоит уже сейчас, чтобы понимать, куда движется Android-разработка.

Проектирование приложений дополненной реальности

Google подготовила советы по проектированию AR-приложений.

• Все элементы интерфейса должны быть на AR-сцене, а не в устройстве, так как пользователи не обращают внимания на устройство, когда увлечены AR.
• Избегать моментов, когда пользователю необходимо отходить назад, так как это может привести к травмам.
• Если AR-опыт строится в городе, не забывать о его опасностях. Например, стоит предупреждать пользователя о приближении к пешеходных переходам и просить опустить устройство.
• На AR-сцене объекты должны взаимодействовать с реальным светом, то есть тени должны меняться при изменении освещения. ARCore предоставляет данные об освещении для того, чтобы стало возможным подсветить виртуальные объекты.
• Объекты в AR должны обладать теми свойствами, которыми они обладают в реальности. Например, мяч должен отскакивать от пола.
• Когда пользователь далеко перемещает объект, нужно увеличивать зону касания объекта, чтобы сохранялась возможность удобно им управлять.
• Разработчику нужно чётко объяснить пользователю, что для работы AR-приложению требуется доступ к камере устройства.

Более подробную информацию о том, как проектировать AR-элементы в приложении, можно найти в видео с конференции ^[5].

Лучшие практики использования текста при разработке Андроид приложений

В этом докладе говорится о лучших практиках работы с текстом и о некоторых изменениях в новой версии Android.

• В Android Q будет отключён перенос слов по умолчанию (hyphenation).
• PrecomputedTextCompat поможет рассчитать размеры текста перед отрисовкой. Следует заметить, что менять шрифт и другие параметры TextView после передачи параметров в PrecomputedTextCompat, будет невозможно.
• Стили, которые применяются к тексту (от наиболее приоритетного к наименее приоритетному):
• В Android можно будет устанавливать фолбеки для шрифтов с помощью Typeface.CustomFallbackBuilder. Например, если какой-то шрифт приложения не поддерживается в одном из языков, то можно задать другой в качестве альтернативы, также можно задавать шрифты для эмоджи. Наше приложение переведено на более чем 40 языков, поэтому нам важно понимать, как оно будет выглядеть, если основной шрифт не поддерживается в одном из них.
• Используйте android:imeOptions=«flagNoPersonalizedLearning» в EditText, чтобы запретить запоминание введённых слов (например, при вводе промокода).
• Если вам нужно использовать в приложении два языка, то можно использовать setImeHintLocales, чтобы сигнализировать клавиатуре о том, что вам требуется другой язык. Это может быть полезно для приложений словарей или обучающих сервисов.

И еще одна небольшая новость. В докладе GIFs and More: Integrating Expression Search in Your App ^[6] Google презентовали свой API для работы с GIF — Tenor ^[7], альтернативу давно известному Giphy. Мы одни из первых стали использовать его в своём приложении Badoo, благодаря чему попали на слайд к спикеру — в качестве примера использования. Мелочь, а приятно!

Наше приложение “засветилось” в презентации Tenor

Концерт

В конце второго дня Google устроила концерт, на котором выступала группа The Flaming Lips. Если честно, раньше я о ней не слышал, но, судя по всему, в США она довольно популярна. В интернете доступен небольшой фрагмент выступления ^[8].

Перед концертом

День 3

Третий день был коротким. Уже к 16:30 все доклады были представлены, а с окончанием докладов закончилась и конференция. В основном в этот день я общался с другими участниками, но расскажу о паре докладов, на которые стоит обратить внимание.

На конференции есть зоны для общения, где не рекомендуется использовать технику

Принципы анимирования

В своём докладе Nik Butcher ^[9] рассказал о том, как в эру реактивности реализовывать анимации для улучшения пользовательского опыта. Проблема заключается в том, что в реактивном приложении объекты View не имеют состояния, а анимации, напротив, обладают состоянием.

Хорошие анимации должны отвечать трём критериям:

• перезапускаемость (reentrant): анимация может быть отменена и запущена снова;
• непрерывность (continuous): анимация не должна перепрыгивать из одного состояния в другое;
• плавность (smooth): анимация должна менять скорость / направление движения постепенно.

Как этого добиться:

• при старте анимации выставляйте только конечное значение (где она должна закончиться); при заданном начальном значении анимация может прыгать из одного состояния в другое, такое может случиться, если она запускается по нажатию на кнопку и пользователь нажимает на неё несколько раз;
• отменяйте старую анимацию перед началом новой (иногда это уже реализовано внутри Android SDK; например, ViewPropertyAnimator, получаемый из View#animate, отменяет предыдущую анимацию для анимируемого свойства);
• используйте Spring Animation ^[10]; такие анимации двигаются с учетом законов физики, а значит, плавность и непрерывность достигаются легче, то есть если объект движется из точки A в точку B и поступает команда двигаться в точку C, то в случае использования Spring Animation объект плавно изменит направление движения;
• используйте <animated-selector> ^[11] для добавления анимации в Drawable; чтобы избежать реализации переходов между всеми возможными состояниями, можно ввести промежуточное состояние (например, состояние загрузки) и переходить через него.

Но лучше один раз увидеть, чем сто раз услышать прочитать, поэтому вот видео ^[12] с докладом.

Тестирование производительности

Библиотека для измерения производительности приложения сейчас находится в состоянии альфа-версии в составе Jetpack. Она позволяет делать замеры производительности кода и избегает множества ошибок замеров, также есть интеграция с Android Studio.

О чём стоит помнить при написании и запуске тестов производительности с помощью Jetpack Benchmark Library ^[13]:

• на эмуляторе собирать измерения ненадёжно, об этом любезно подскажет предупреждение при запуске;
• ProGuard/R8 должен быть включён, чтобы замерять производительность корректно;
• на устройстве должен быть достаточный уровень заряда аккумулятора, чтобы низкий уровень заряда не повлиял на результаты измерений;
• модуль, в котором написаны тесты производительности, должен быть с параметром «debuggable=false»;
• не стоит сравнивать результаты измерений на разных устройствах, они могут сильно отличаться.

Заключение

Команда Badoo и разработчик Google

Google I/O посетить определённо стоит. В такой атмосфере за чашкой чая можно услышать много интересных историй и узнать об интересных инженерных решениях. Например, о том, как ребята из ВКонтакте придумали сделать тёмную тему и раскатить её на пользователей, которые спрашивали: «Где тёмная тема?», как на другом конце Земли разработчики из Tinder борются со спамом и порноконтентом и как команда App in the Air реализовывала авторегистрацию на авиаперелёты. Также можно поймать представителей Google, создающих инструменты, которыми мы пользуемся, и задать интересующие вопросы.

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

Автор: Link20

Источник ^[14]