19 июля 2018 на Reddit прошел раунд вопросов от сообщества разработчиков под Android и ответов от команды инженеров Android, посвященный последним нововведениям фреймворка (но не ограниченный этим списком):

• Android Jetpack
• Kotlin
• Notifications
• Power — app standby, app restrictions
• Display cutout
• Actions and Slices
• Compatibility and non-SDK interface restrictions
• Android P Beta devices, Project Treble

Среди участников Android команды, всего свыше 30 человек, в т.ч. засветились: Dianne Hackborn, Ian Lake, Jake Wharton, Romain Guy, Brian Carlstrom и другие.

Чувствуете уровень?

На заглавном фото — команда Android потеет над вопросами, источник.

Здесь перевод некоторых интересных вещей с переднего края разработки.

Navigation framework

Q. С новым Navigation framework, продвигающим идею single activity (или нескольких действий), каков план для Android планшетов? Я уверен, что внутри вас все хотят, чтобы планшеты ушли, но клиенты продолжают просить об этом, а разработка для планшетов стала серьезным препятствием. Есть ли планы сделать это проще? master/detail кажется простой, но когда приложение не является простым GitHubRepo (гм …), все выходит из-под контроля и быстро становится сложным. Отсутствие хорошего оборудования не помогает. По правде говоря, большинство приложений, которые я видел, имеют < 2% пользователей планшетов, это очень грустно.

A. Ian Lake, Software Engineer, Jetpack (Fragments, Navigation, Work Manager):

Навигация и планшеты на самом деле — это то, о чем я уже много говорил с группами Material и Chrome OS. Одним из факторов, который значительно повлиял на пространство дизайна для больших экранных устройств, стало введение многооконных режимов, в частности free-form windows, которые полностью изменяются по размеру, как вы можете найти на устройствах Chrome OS.

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

Одна вещь, которую я, вероятно, добавлю сейчас, это то, что вы можете и должны подумать над тем, чтобы сделать navigation chrome вашего приложения (bottom nav, navigation drawer, etc) адаптированным к размеру экрана — если вы загрузите код Navigation codelab, вы обратите внимание, что приложение переходит из navigation drawer, в multi-window режиме на телефонах (где пространство дорого) к bottom navigation bar на телефонах и всегда отображается видимая side nav на планшетах.

При этом мы хорошо знаем, что еще многое предстоит сделать.

Soft Keyboard

Q. Есть ли хоть какие-то планы по его переработке? Почему мы заботимся об IMM, почему мы заботимся о «фокусе», почему нам даже нужен контекст, чтобы делать что-либо ?

Я уверен, что большинство пользователей хотят просто: Я открываю Activity / Fragment / X, и есть три edit texts, я хочу, чтобы клавиатура вела себя так, как должна. Не появляться в середине моего transition, что приводит к пропуску кадров или запутыванию transition framework, потому что зафиксированные значения начала / конца изменились (потому что, например, у меня есть настройка adjustResize в моем манифесте, или, может быть, у меня есть настройка adjustPan, чтобы обойти это, но теперь у меня есть другие проблемы … это просто выглядит действительно уродливо, когда клавиатура появляется, когда вы не хотите, чтобы она появлялась. Я понимаю последствия для безопасности и «third-party kbd support», но я думаю, что большинство разработчиков Android офигеет, если вы анонсируете API, который выглядел бы так:
Keyboard.isVisible(); Keyboard.isHardware(); Keyboard.show (focusThisView, callbackWhenKBVisible); Keyboard.hide(callbackWhenKBGone);

A. Adam Powell. TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

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

Мы всегда были немного щепетильны в том, чтобы раскрыть запросы типа Keyboard.isVisible, поскольку большинство допущений, сделанных на их основе, ошибочны по крайней мере в одном реальном сценарии — «У меня меньше вертикального пространства, если возвращается true», «пользователь активно редактирует текст, если возвращается true, «у какого-то представления есть valid фокус», «пользователю не нужно видеть дополнительный интерфейс редактирования текста, когда возвращается false» и т. д.

Тем не менее, window insets не так хорошо работают, и мы знаем, что нам нужно предложить некоторые (многие) лучшие решения там. Есть также ряд других действий, которые люди пытаются эмулировать: «Скажите, отображается ли клавиатура, чтобы я мог накладывать ее на custom sticker/photo picker, который не передает UI» является одним из примеров использования который мы должны поддерживать лучше.

Reply из зала. Я просто не понимаю, как инженеры Google не видят этой проблемы с клавиатурой. Вот что они сказали вам: «В настоящее время у нас нет каких-либо значительных планов, хотя нам бы хотелось услышать об определенных проблемах / багах, которые разработчики приложений видят, чтобы мы могли их решать». Люди жаловались и хакали IMM API уже почти 10 лет … Да, вы владеете платформой. Хотите поддержать все IMM дерьмо? Идем дальше, но затем предоставляем API SOFT KEYBOARD для 98% разработчиков, которым просто нужно ПОКАЗАТЬ / СКРЫТЬ КЛАВИАТУРУ, и, может быть, только, возможно, надежно, под контролем, с точными обратными вызовами. Это не сложно, Android. iOS сделала это. И вы сможете.

RecyclerView

Q. Какие-либо планы по оказанию официальной поддержки headers и collapsing groups? Каждая неофициальная попытка в какой-то момент терпит неудачу, и стыдно, насколько легко она работает на iOS с 2008 года.

A. Adam Powell: TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

Голосуй, если хочешь этого. В основном это вопрос приоритетов, и, поскольку есть библиотеки от сообщества, мы не считаем это срочным.

Reply из зала. Пожалуйста, где я могу проголосовать! Я еще не нашел приложение, которым не нужен список вещей. Это было верно 10 лет назад. Теперь парадигма такова: мне еще предстоит найти список, который не нуждается в какой-то grouping/header/stickyness/material animation.

Themes

Q. В словах Баллмера вместо «developers developers…» подумайте о: Themes themes themes themes… Каковы планы для Themes/Styles/Attrs? Поскольку вопросы существуют, исследование того, как тема реализует, например, menu item color, представляет собой подвиг силы, проклятие и движуха на StackOverflow, что приводит к неправильным идеям повсюду. Планируете ли вы прикоснуться к этому, чтобы сделать … проще?

A. В ближайшей перспективе мы фокусируемся на обучаемости — возможность указать что-то на экране и понять, как было разрешено конкретное свойство без необходимости вручную выкапывать исходный код платформы, имея возможность настроить свойство view on-device, возможность экспериментировать, изменяя значение в теме или стиле и быстро видя, как это влияет на другие атрибуты. Сейчас это слишком black-box, и мы надеемся сначала разобраться в этом.

Fragments

Q. Почему бы не выставить API анимации напрямую, что позволило бы сделать animate(View previousView, View newView, ViewGroup container, int direction, AnimationCallback callback)? У Conductor есть это, и это самая простая вещь, которую можно придумать. Это же гораздо легче, чем setExitTransition или setCustomAnimations, особенно в отношении Z-order.

Почему вы, ребята, не дали Fragment’у метод onRetainNonConfigurationInstance? Вы можете retain сам фрагмент (что делает его non-backstack-friendly и не рекомендуется использовать, если он имеет view), но дать ему onRetainNonConfigurationInstance было бы намного проще, и тогда даже AAC ViewModel не понадобится ( хотя обратный вызов onCleared() хорош). Его можно сохранить вместе с состоянием FragmentManager как non-config! Почему нет?

Почему только операция REPLACE инициирует shared element transition, но не SHOW / HIDE, DETACH / ATTACH или ADD / REMOVE?

Почему views в child fragment уничтожаются до того, как они будут анимированы при использовании DETACH или REMOVE или REPLACE (вместо HIDE)?

A. Ian Lake:

Animation API — это то, о чем мы много думали, особенно учитывая такие вещи, как MotionLayout. FragmentManager определенно должен выполнять гораздо более сложные вещи, которые вам нужно будет сделать, только потому, что он пытается охватить все возможные сценарии.

ViewModels — рекомендуемый шаблон для сохранения данных через все configuration changes в фрагментах. Как вы указали, обратный вызов onCleared() является важной частью этого (вам абсолютно не нужна ваша собственная логика, чтобы определить, когда делать окончательную очистку), но разделение ownership и создания сравнения объекта, который вы предоставляете действительно важно для testability perspective.

В Fragments, как правило, слишком много возможных операций, которые делают разные вещи и обрабатываются по-разному. Мы смотрим более целостно на это, но, пожалуйста, сделайте file a bug, если найдете что-то особенное, что, по вашему мнению, должно работать, но этого не происходит.

Android Architecture Components

Q. Каков рекомендуемый способ обмена данными между несколькими фрагментами, но не делая его app-global через ActivityModel Activity?

Если я использую ViewModel Activity, как мне узнать, с помощью Navigation AAC, когда очистить этот кеш (соответствующие фрагменты, которые будут использовать эти данные, больше не будут существовать и могут быть удалены)?

A. Ian Lake:

Да, то, что вы действительно хотите, это некоторая область связанное между single destination/Fragment и всей областью активити. Одна естественная область видимости, которая существует в навигации, находится вокруг графа навигации (поскольку вы можете вкладывать навигационные графы для инкапсуляции login flow или checkout flow). Я создал feature request для этого — пожалуйста, поучаствуйте, если это та концепция, которую вы хотели бы нам представить более полно.

Direct Share APIs

Q. Почему share sheet UI настолько медленный? Обычно share sheet загружается в два этапа: во-первых, загружается основная нижняя часть, а затем вторая, опции «direct share» будут загружаться над всеми.

Часто доля «direct share» в этом пользовательском интерфейсе занимает очень много времени, даже на моем Pixel XL. Кроме того, пока пользователь ожидает, чтобы панель «direct share» загрузилась, нижний share sheet (который уже загружен!) не принимает сенсорные нажатия. Это слишком раздражает пользователя, потому что заставляет пользователя думать, что с телефоном что-то не так, когда на самом деле панель просто не принимает никакого сенсорного ввода. Кроме того, иногда панель «direct share» приводит к тому, что нижний share sheet перемещается, и поэтому пользователь случайно нажимает что-то непреднамеренное.

Вот статья, где освещены и другие проблемы Rita El Khoury had a wonderful article at Android Police.

(Прим. мое. Эта штука действительно бесит).

A. Adam Powell, TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

Потому что ваши приложения медленны! 🙂

(Прим. мое. Типа «сам дурак»).

Это моя ошибка, поскольку я добавил исходные Direct Share APIs. Он привязывается к сервисам из приложений с прямым доступом, поддерживающих Direct Share, и запрашивает у них своих лучших кандидатов на участие в рейтинге (ChooserTargetService).

Если приложение запускается медленно и медленно возвращает результаты, оно получает штраф в рейтинге. Это оказалось намного менее масштабируемым, чем указано в первоначальном тестировании, но Adam Cohen был достаточно вежлив, чтобы не говорить мне «Я же говорил» слишком часто.

Теперь мы получили сочетание отзывов пользователей перед выпуском и несколько ошибок. Людям не нравились direct share targets в несколько этапов, так как приложения каждый возвращали свои результаты, так как это приводило к неустойчивости пользовательского интерфейса, поэтому теперь он ждет самого медленного приложения, прежде чем показывать любые Direct Share targets. Люди беспокоились о том, чтобы не ошибиться, если пользовательский интерфейс изменился, пока они собирались нажать на свою цель, поэтому ничего не запускается, если вы нажмете во время анимации. Если вы подловите момент, прежде чем начнется анимация, то нажатие будет работать, но обычно ваш палец проигрывает эту гонку.

У нас были некоторые идеи для улучшения API в течение последних двух выпусков, которые не вписались в расписание. Эти идеи включали в себя изменение API, чтобы быть более похожими на launcher shortcuts, когда приложения пушат targets заранее, поэтому нам не нужно их запрашивать, изменяя верхнюю часть UI, чтобы присутствие или отсутствие поздних прибытий не было так разрушительно, и ряд других. Мы увидим, как далеко мы доберемся в будущих релизах, и сколько из них мы сможем включить в Jetpack API.

Material Components

Q. Короткий вопрос: Material Components для Android (на GitHub) — это постоянный беспорядок. Я всегда слышу, что все будет лучше, но все остается по прежнему. Что вы делаете для улучшения ситуации?

Подробности:

• Десятки неотвеченных проблем
• Отсутствие связи
• Закрытая разработка
• Большинство Pull Requests полностью игнорируются — некоторым из них много лет
• Документы также устарели и / или функций там нет. Также гиперссылки на material components docs на dev.android.com в основном не работают.

По сравнению с iOS Material Components:

• Действительно открытая разработка (2250 Pull Requests)
• общение с разрабами в Discord
• открыто для contributions
• разрабы отвечают на issues, ставят tag, помогают как могут.

A. Dave Carlsson:

Прежде всего, спасибо за ваш вопрос. Он привлекает нас к ответственности и облегчает нам понимание того, что мы можем сделать, чтобы лучше поддерживать наше сообщество с открытым исходным кодом. Мы очень много работаем над Material Components для Android и ценим терпение сообщества open source, в то время как мы продолжаем создавать нашу команду и лучше взаимодействовать с нашими пользователями.

Этот вопрос освещает основные исторические различия между тем, как наши Material engineers разрабатывают библиотеки для iOS и Android. Material Components для Android были впервые разработаны и выпущены как Design Lib в библиотеке поддержки. Это означало, что нашим внешним пользователям Material приходилось жить с более медленным циклом выпуска в составе библиотеки поддержки Android. Мы продолжаем тесно сотрудничать с Android Support Library, даже когда мы переходим к использованию Jetpack в рамках нашего release cycle. В этом релизе мы создаем артефакты для Maven, которые легко используются разработчиками с помощью Android Studio для создания красивых Material apps. Получение наилучшего кода в инструменты, используемые разработчиками Android, наш первый приоритет.

Предоставление свежей копии нашей библиотеки Android на GitHub становится все более важным, поскольку мы разрабатываем обновления для Material. Эти обновления означают, что мы быстрее тестируем и делаем больше изменений вMaterial. В течение года между открытием кода нашей библиотеки на Google I/O в 2017 году и анонсом Material Theming in 2018, наша команда плотно работает с нашей основной библиотекой. Мы также потратили этот год на развитие команды и научились масштабировать все большее число внутренних и внешних клиентов. Нам предстоит долгий путь и в настоящее время уделяем особое внимание стабильности, улучшениям в нашей существующей библиотеке и лучшему реагированию на потребности наших пользователей Google и open source пользователей.

Мы будем сообщать больше о Material в Google Design newsletter. Недавно мы создали public tracker для технических вопросов, специфичных для Material Component library for Android. Мы используем этот трекер вместо GitHub issues для лучшего согласования с нашими внутренними требованиями к проекту, чтобы мы могли быть более отзывчивыми и эффективными. Мы также делаем все возможное, чтобы поделиться нашей roadmap с сообществом, чтобы у наших пользователей было лучшее представление о том, над чем мы сейчас работаем, и что мы будем делать дальше.

Я знаю, что много написал, так что я собираюсь закончить. Я также не буду обещать волшебное превращение за одну ночь, потому что если делать все правильно, то это занимает много времени. Мы продолжим писать наш код внутри Google’s codebase, как и для многих наших продуктов. Я чрезвычайно горжусь тем огромным усилием, которое наша небольшая команда по Material Android заложила в прошлом году, и я тоже рад видеть, как команда растет. Мы работаем над более быстрыми версиями при поддержке команды Android, и я думаю, что мы уже улучшаем то, как мы планируем наши вехи и обновляем код на GitHub. Даже эта AMA — еще один шаг в правильном направлении, и я благодарен за то, что у меня есть шанс участвовать в этом.

ART

Q. Здравствуйте, я хотел бы получить дополнительную информацию об изменениях, внесенных в ART на android P, каковы эти изменения, как эти изменения повлияют на использование ram / storage и время выполнения? Я заметил, что размер приложений растет все больше и больше, и это будет продолжаться в будущем?

A. Brian Carlstrom. Director of Software Engineering, covering App Compatibility, ART, NDK, Auth, Autofill, “adb shell”, etc:

Мы работаем в Android N, O и P, чтобы продолжать уменьшать использование памяти и памяти при одновременном повышении производительности.
Например, в Android N мы отошли от компиляции с full ahead-of-time (AOT), чтобы использовать JIT + profile guided AOT для уменьшения объема storage и memory.

В Android O мы начали делать device layout из dex code, чтобы уменьшить использование памяти и увеличить (прим. наверное имелось в виду “уменьшить”) время запуска.

Мы также добавили непрерывную сборку мусора для приложений на переднем плане.

Мы также уменьшили накладные расходы для внутренних структур данных кэша, используемых для классов и полей в 8.0, и для методов в 8.1, делая их LRU вместо пропорционального размера файлам приложений dex.

Для Android P мы продолжили фокусироваться на сокращении использования storage и памяти с внедрением CompactDex, о котором мы немного поговорим в наших I/O talk.

В целом я считаю, что приоритетами команды ART являются:

1. корректность
2. память
3. производительность,

поэтому определенно у нас память в качестве приоритета в будущем.

Treble

Q. О телефонах Treble и Non-treble: смогут ли телефоны с нестандартными формами получать официальное или неофициальное обновление (Lineage и другие)?

(Прим. мое. Project Treble — это хитрый план Google, который поможет производителям упростить процесс обновления, чтобы сделать обновления более своевременными).

A. Brian Carlstrom:

Что касается телефонов Treble vs non-Treble, или можно обновить новые Android O до Android P, или для телефонов, которые имеют Google Play, нужно внедрить архитектуру Treble для начала. Поддержка custom ROMs, таких как Lineage OS, а также общий хакинг Android и эксперименты, теперь стали намного проще.

Generic System Image который построен из источников AOSP, является требованием совместимости. Это означает, что Treble-enabled devices будут работать с GSI по определению. Эта базовая гарантия позволяет создавать custom ROMs на основе GSI, используя эту стабильность.

Мы уже много знаем об этом с помощью различных сообщений на форумах XDA и связанных с ними сайтах, где люди могут более легко поддерживать Custom ROMs on Treble-enabled devices. В ближайшие месяцы мы опубликуем подробные инструкции по созданию Generic System Images, чтобы этот процесс стал еще проще.

Kotlin, JavaScript

Q. Что вы думаете о Kotlin Native, и видите ли вы какое-либо будущее в кросс-платформенной разработке с использованием Kotlin Native?

A. James Lau:

Да, мы считаем, что Kotlin Native очень интересен. Мы получаем много вопросов об этом от разработчиков, которые считают это очень перспективным направлением. В частности, одна из главных вещей, которую мы слышим от разработчиков, — это то, что обмен кодами для логики бизнес-процессов очень ценен. И что Kotlin Native был бы потрясающим решением по сравнению с этим на C ++ или JavaScript (как это делают большинство наших разработчиков сегодня). Мы тесно сотрудничаем с JetBrains, чтобы узнать, каким может быть его будущее в отношении разработки Android, включая встречу с разработчиками, которые пытаются это сделать, чтобы получить обратную связь и повторить попытку. KotlinNative все еще находится на ранней стадии, даже не Beta, но мы считаем, что перспектива довольно классная.

Q. Просто любопытно, как вы используете JavaScript на Android? В веб-приложении, прикрепленном к окну или какой-то безголовой JS-среде выполнения?

A. Jake Wharton:

V8, javascriptcore или duktape — это некоторые варианты движков, которые вы можете использовать для работы на Android.

Power management

Q. В поисках оптимизации батареи многие OEM-производители Android часто переусердствуют и в конечном итоге убивают приложения, даже если у них есть notifications переднего плана. Каждый OEM имеет свое собственное конкретное место, где пользователи могут отключить эти «оптимизации», и это становится кошмаром для управления всем этим. Существуют ли какие-либо планы по унификации battery optimizations, чтобы приложения на переднем плане были в безопасности ?

A. В P мы внедрили Background Restriction в качестве шага в этом направлении, и мы предоставляем руководство, направленное на обеспечение согласованности между OEM-производителями.

Разное

Q. Каковы некоторые из неочевидных вещей, которые вы хотите, чтобы сторонние разработчики перестали делать?

A. Не отправляйте ошибки платформы или библиотек для устройств, на которых запущены темы Xposed или RRO. Если вы ковыряетесь в кишках framework вне сферы действия CTS, вы сами по себе.

Q. Почему Android не поддерживает SVG напрямую? Насколько я понимаю, Vector Drawables реализует только часть функций SVG, и это ломает совместимость с остальным миром.

A. Chet Haase, Lead/Manager of the UI Toolkit team (views & widgets, text rendering, HWUI, support libraries):

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

Q. Почему компас настолько ненадежен? Это дико неточно даже на Pixel-телефонах.

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

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

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

Это обсуждение устарело, но затрагивает различные вопросы, о которых я говорил выше.