Всем привет! Меня зовут Тимур, я Android-разработчик в KTS.
Состоялась конференция Google I/O, и наша команда решила выпустить обзор докладов. В этой статье — про интеграцию передового генеративного ИИ в Android-приложения, который предлагает идеальные ответы или даже делает сводку по вашей аудио записи. Также спецы из Google дали практические советы по оптимизации фоновой работы приложения для увеличения времени работы от аккумулятора.
Оглавление
Генеративный ИИ на Android под капотом
Почему выбранный трек интересен?
На этом Google I/O большое внимание уделили развитию искусственного интеллекта, и Android не остался в стороне. Генеративный ИИ на Android интересен, поскольку демонстрирует значительный технологический прорыв в интеграции ИИ на мобильных устройствах. Для разработчиков это открывает новые возможности создания инновационных приложений. В целом, данный трек отражает будущее мобильных технологий, делая устройства умнее и функциональнее.
Преимущества выполнения на устройстве
Встроенный в телефоны ИИ может обрабатывать запросы непосредственно на вашем смартфоне, планшете или компьютере без каких либо обращений к серверу. Это дает такие преимущества как:
Конфиденциальность — пользовательские данные обрабатываются локально на устройстве
Работа без доступа к Wi-Fi — модель обладает полной функциональностью без подключения к сети
Снижение задержки — потенциально снижает задержку и обеспечивает оперативность реагирования в режиме реального времени
Нет дополнительных денежных затрат, потому что все работает на пользовательском оборудовании
Но локальная обработка имеет и ряд ограничений. Устройства как правило обладают меньшей вычислительной мощностью чем облачные серверы, поэтому модели предназначенные для работы на устройствах меньше по размеру и следовательно результаты могут иметь более низкое разрешение (от 2 до 3 млрд. параметров, что на порядок меньше чем в облачных аналогах).
Поэтому можно сделать вывод, что точная настройка имеет решающее значение для достижения качества продукции. Точность таких моделей намного ниже чем у более крупных моделей к которым мы привыкли. Так же это означает, что модель не будет превосходно работать во всех вариантах использования, например, это не так эффективно для чат-ботов или генерации кода.
В чем заключаются хорошие варианты использования ИИ на устройствах?
Распространенные варианты использования встроенных на устройствах ИИ это:
Предоставление краткого обзора текста
Помощь в создании контента — например создания предложений или перефразирования ответов, чтобы изменить тон или стиль сообщения.
Классификация контента — например определение настроения в разговорах или любом другом тексте.
Сегодня есть несколько способов получить доступ к возможностям ИИ на устройствах. Один из таких способов — это Gemini Nano. Это модель для создания приложений Android с искусственным интеллектом на устройстве. Gemini Nano интегрирована через AlCore в ОС Android начиная с API 34 и выше (Android 14 +).
Разработчики могу получить доступ к сервису AICore с помощью API-интерфейса, который предоставляет Google Al Edge SDK.
Сейчас все это доступно на Pixel 8 Pro и Samsung S24 Series, но ожидается появление и на других флагманских устройствах.
В декабре 2023 года Gemini Nano был доступен ограниченному кругу партнеров разработчиков в рамках программы раннего доступа.
Gemini Nano предназначены не только для сторонних разработчиков, он уже работает в некоторых приложениях от Google. Такие приложения как Messages, Recorder и GBoard уже успешно интегрировались с Gemini Nano. Например, в Messages появилась возможность отредактировать ваше сообщение и даже предлагает готовые к отправке варианты ответов. Благодаря тому, что все процессы выполняются на устройстве, весь функционал полностью конфиденциальный.
Благодаря Gemini Nano приложение Recorder научилось создавать обзор записи в текстовом виде с помощью расшифровки голоса (пока работает только на английском языке).
Техническое погружение в AICore
Когда разработчики выводят свои приложения в продакшен, то сталкиваются с такими препятствиями как развертывание, производительность, объем памяти и размер диска. В этой секции рассказывается как решаются эти проблемы, а также объясняются некоторые технические детали AICore.
Как уже упоминалось ранее, AICore это системный сервис Android разработанный для оптимизации использования базовых моделей. Он решает проблемы с развертыванием больших моделей ИИ путем централизации времени выполнения, доставки и важнейших компонентов безопасности.
AICore был создан потому что модели ИИ несмотря на свою мощь, огромны и требуют большой производительности, что делает их не практичными для объединения в отдельных приложениях. Предоставляя эти модели в качестве общего системного ресурса AICore позволяет использовать возможности Gemini Nano без головной боли связанной с развертыванием.
AICore обрабатывает все взаимодействия с Gemini Nano моделью и аппаратными ускорителями от имени каждого приложения. В результате приложению нужно вызывать только SDK, чтобы запустить свои рабочии нагрузки на основе машинного обучения. При этом разработчикам не нужно заботиться об обслуживании собственных моделей.
Еще одним удобным аспектом запроса ИИ является то, что он распространяется как системный сервис. Его версия уже присутствует в системном образе для подходящих устройств, так что пользователям не нужно загружать его вручную.
AICore постоянно обновляется через Google Play до тех пор пока пользователи не отключили автоматические обновления.
На картинке нижи показана схема AICore и как приложения могут взаимодействовать с ним.
В APK файле AICore наиболее важным блоком является модель Gemini Nano.
AICore также включает в себя уровень тонкой настройки, который называется низко ранговой адаптацией (LoRA). Это позволяет разработчикам приложений настраивать модель для выполнения конкретных задач. Приложения могут обучать свои собственные специализированные блоки тонкой настройки для оптимизации производительности модели Gemini Nano.
По сравнению со стационарными компьютерами и серверами мобильные устройства имеют гораздо более ограниченные вычислительные мощности. На картинке ниже можно увидеть таблицу на которой видна разница в размере памяти пропускной способности, вычислениях и мощности. Разница составляет по меньшей мере один или два порядка.
Мобильные устройства также должны обеспечивать повседневную функциональность для пользователей, например отправка сообщений друзьям. Развертывание большой базовой модели в рамках ограничений мобильных устройств было непростой задачей. Успех с Gemini Nano был основан на тесном сотрудничестве с многочисленными командами Google включая DeepMind, Android и Tensor Flow Lite. Вот что для этого потребовалось:
Четырех квантовое квантование с учетом обучения значительно уменьшило влияние Gemini Nano на окружающую среду.
Тесное сотрудничество с крупными поставщиками позволяет Gemini Nano использовать выделенные ускорители ИИ повышая скорость и эффективность.
Параметрическая эффективная сменная поддержка LoRA позволяет нескольким приложениям настраивать Gemini Nano для конкретных задач, сохраняя при этом возможность совместного использования базовой модели в памяти и на диске.
Также были разработаны инструменты помогающие преобразовывать модели и оптимизировать целевые ускорители.
AICore был разработано с учетом конфиденциальности и безопасности пользователей. Прежде чем возвращать результат клиентскому приложения он проходит через фильтр безопасности.
AICore соответствует концепции частного вычислительного ядра, который был представлен в Google I/O 2021 года. Например AICore не не имеет прямого доступа в интернет и не может связываться с большинством пакетов за исключением ограниченного набора системных пакетов.
Тонкая настройка
Как уже упоминалось ранее, тонкая настройка позволяет приложению или службе настраивать веса модели для выполнения конкретных задач. LoRA это эффективный параметр используемый при тонкой настройке, которая не требует изменения весов базовой модели.
Также LoRA позволяет оптимизировать Gemini Nano для различных вариантов использования в приложениях, при этом сохраняя одну копию модели на устройстве для обслуживании всех приложений которые ее используют. До сих пор все приложения которые интегрировали Gemini Nano использовали LoRA для повышения производительности.
Так почему же тонкая настройка так важна для моделей на устройстве, когда облачные модели могут решать многие варианты использования из коробки с помощью простых prompt-ов?
Ответ заключается в ограничениях с которыми сталкиваются модели на устройствах, о которых говорилось ранее (одно из ограничений — размер моделей). Работы с prompt-ми не достаточно для этих моделей на устройстве. Тонкая настройка с помощью LoRA позволяет небольшой модели Gemini Nano преуспеть в конкретных вариантах использования таких как умный ответ.
Поскольку обучение с помощью LoRA настраивает веса модели для выполнения конкретной задачи. Вам нужен четкий вариант использования и не слишком большие различия в ваших обучающих данных. Проще говоря у вас должно быть не менее 100 обучающих данных.
Индивидуальная модель становится еще более надежной если у вас есть хотя бы одна запись в обучающих данных. При обучении нет правильных и неправильных ответов, нужно эксперементировать с вашими обучающими данными и понять какие данные дают наилучшие результаты. Нужно иметь ввиду, что вы также можете использовать более крупные модели такие как Gemini Pro или Ultra, чтобы помочь сгенерировать обучающие образцы.
Посмотрим демонстрацию влияния тонкой настройки, на конкретном примере. Ниже на картинке можно увидеть пример генерации сообщения в заданном виде, после обучения с помощью LoRA.
Пример предоставила команда Messages. В качестве входных данных была задана фраза: “Давай сходим погулять”, модели было предложено перефразировать это сообщение в лирическом тоне. Free Prompting Gemini Nano ответил: “Давай прогуляемся, давай исследуем мир, давай создадим воспоминания, давай насладимся видом”.
Звучит очень неплохо, однако после тонкой настройки Gemini Nano ответил: “Давай побродим и дадим волю своим сердцам. По лугам и полям, мы всегда будем кружиться. Прогулка, полная радости, исцелит наши души. В объятиях природы мы позволим нашей воле возобладать.” Звучит намного лучше, Gemini Nano даже сделал так, чтобы строки рифмовались.
Открытые модели на Android
Популярность открытых больших языковых моделей довольно возросла в последнее время и хотя они не подходят для продакшена из-за проблем с производительностью, с некоторыми из них не получится поиграть на устройствах Android.
Недавно исследовательские группы Google выпустили API вывода больших языковых моделей под названием MediaPipe. Это новое экспериментальное API, которое позволяет запускать модели преобразования текста в текст непосредственно на устройстве.
В настоящее время MediaPipe LLM inference API поддерживает следующие модели:
Falcon 1B — параметрическая каузальная модель декодера с 1,3 млрд. параметров, обученная на наборе данных RefindWeb.
Phi-2 — модель трансформатора с 2,7 млрд. параметров, наилучшим образом подходящая для ответов на вопросы, чатов и кодовых задач.
Stable LM 3B — модель с 2,8 млрд. параметров, обученная по наборам данных английского языка и кода.
Gemma 2B — открытая модель Google с 2,5 млрд. параметров, которая подходит для широкого спектра задач, таких как ответы на вопросы, обобщение и рассуждение.
После выбора модели, нужно преобразовать ее в формат MediaPipe с помощью библиотеки genai.converter. Затем нужно загрузить модель на устройство. Ожидается что размер файла составит что-то около гигабайта, с которым можно поэкспериментировать, но это делает его непрактичным для продакшена.
Чтобы узнать больше об API MediaPipe посетите ее документацию.
Выводы
В этой части мы погрузились в захватывающий мир генеративного ИИ на Android.
Такие преимущества как локальная обработка, сокращение задержки и автономный режим открывают ряд крутых возможностей для функций генеративного ИИ на Android.
Однако ограничения ресурсов требует некоторых корректировок для ИИ по сравнения с серверными решениями. Методы тонкой настройки и тщательные prompt-ы позволяют адаптироваться к ограничениям на мобильных устройствах.
Обладая уникальными преимуществами, такими как интеграция в Android через системный сервис AlCore, а также проверенный путь производства с приложениями от Google, такими как Messages и Recorder, Gemini Nano, это базовая модель, которую выбирают разработчики Android для создания продакшн сценариев использования.
Повышение эффективности фоновой работы от аккумулятора на Android
Представьте себе такую ситуацию. Боб проводит день с друзьями и начинает его с полностью заряженным устройством. В течение всего дня он редко пользуется своим устройством. Однако в конце дня, когда он начинает искать дорогу домой, телефон оказывается почти разряженным. Куда делась батарея?
Сегодня мы попробуем понять, как происходит разрядка батареи в фоновом режиме, чтобы вы могли предотвратить неожиданный разряд вашего приложения, как в случае с Бобом. Повышение эффективности работы вашего приложения от батареи также предотвратит удаление вашего приложения пользователями вроде Боба.
В этом части статьи мы рассмотрим следующие темы:
Как связаны фоновая работа и энергопотребление.
Какие API следует использовать и каковы лучшие практики при выполнении фоновой работы.
Как повысить уровень своих навыков, проверяя энергопотребление и использование сети вашим приложением.
Вы можете задаться вопросом: разве разрядка аккумулятора не происходит в основном, когда устройство не спит? Это действительно так. Однако, согласно результатам внутренних исследований и испытаний, основной причиной плохой работы устройства от батареи является разрядка батареи при выключенном экране. Наши внутренние показатели показывают, что больше всего батарею расходуют следующие аппаратные компоненты - сотовый модем, процессор, Wi-Fi и Bluetooth
Позже мы обсудим, как анализировать энергопотребление этих аппаратных компонентов.
Другой вопрос, о котором вы, возможно, думаете — разве система Android не должна отвечать за оптимизацию использования? Да. Исторически сложилось так, что Android оптимизирует потребление следующим образом
Doze и Deep Doze
App Standby buckets
App Cached State
Foreground Service Usage Restrictions
и многое другое.
Несмотря на большое количество оптимизаций и API, которые мы внедрили, они эффективны только в том случае, если вы используете правильный инструмент в своем наборе инструментов. Именно об этом и пойдет речь в этой статье. Такие разработчики, как вы, оказывают большое влияние на то, насколько успешно устройство управляет энергопотреблением. Давайте узнаем, как это сделать.
Начиная свой путь к повышению эффективности работы приложения от батареи, первый вопрос, который следует задать себе — выбрал ли я правильный инструмент, наиболее оптимальный API для работы моей функции в фоновом режиме? API, доступные для выполнения работы после того, как приложение перестает быть видимым, можно разделить на следующие четыре категории представленные на картинке ниже.
Вот блок-схема, которую нужно задать себе, чтобы понять, какую категорию следует использовать.
Должно ли устройство продолжать работу после того, как приложение перешло в фоновый режим? Например, если вы начинаете получать ленту новостей для своего приложения, то завершение этой работы после того, как пользователь покинет приложение, не принесет ему пользы. Для отмены работы после выхода пользователя из приложения следует использовать асинхронные API, а также компоненты, учитывающие жизненный цикл.
Знает ли пользователь об этой фоновой задаче? Если пользователь инициирует действие или требуется немедленная обратная связь с пользователем, могут подойти фоновые службы. Например, если пользователь играет музыку и хочет, чтобы она продолжала играть после того, как приложение перейдет в фоновый режим, можно использовать службу Foreground Service с типом «media playback». Для коротких критических задач, таких как завершение платежа, можно использовать службу Foreground Service с типом «short service».
Если пользователь не знает о работе или ему не требуется обратная связь, вместо этого следует использовать оптимизированные API‑интерфейсы планирования. Например, периодическое резервное копирование локального содержимого на сервер не требует осведомленности пользователя.
Если пользователь не знает о работе или ему не требуется обратная связь, вместо этого следует использовать оптимизированные API‑интерфейсы планирования. Например, периодическое резервное копирование локального содержимого на сервер не требует осведомленности пользователя.
Прежде чем принять решение об использовании службы Foreground Service, следует узнать, есть ли альтернативный API для вашего случая использования? В документации по типу Foreground Service вы можете найти альтернативные API, которые помогут вам управлять жизненным циклом выполнения или запускать работу более оптимальными для батареи способами
Альтернативные API также обеспечивают преимущества в зависимости от конкретного случая использования. Наиболее распространенными сценариями использования альтернативных API являются использование инициируемой пользователем передачи данных для выполнения больших загрузок или выгрузок вместо создания синхронизированной с данными службы переднего плана. Этот API имеет возможность повторить попытку, если передача не удалась, и будет выполняться только во время доступности сети.
Кроме того, используйте companion device manager для сопряжения Bluetooth и передачи данных вместо использования фоновой службы подключенного устройства. Выбор правильного инструмента — это первый шаг на пути к повышению эффективности использования батареи. Шаг 2 — убедиться, что вы правильно используете этот инструмент. Давайте рассмотрим лучшие практики использования двух наиболее распространенных вариантов.
Использование Scheduling API и использование Foreground Service. Ниже приведены три лучших способа использования оптимизированных Scheduling API, которые повышают эффективность использования батареи. Эти советы применимы как к WorkManager, так и к JobScheduler.
Когда вы ложитесь спать, хотите ли вы, чтобы вас будили 16 раз, каждые 30 минут, или лучше проснуться один раз и сделать все за один раз? Устройство подобно пользователю: чем больше раз оно просыпается, тем больше энергии потребляет.
Вы должны объявить ограничения, чтобы обеспечить выполнение задачи в более оптимальных сценариях и, когда это возможно, объединить работу в пакет. Установка ограничений, например, выполнение во время зарядки или выполнение в сети без оплаты, поможет обеспечить выполнение задачи в менее затратные периоды времени. Ограничение на зарядку особенно рекомендуется для носимых устройств, чтобы минимизировать разряд батареи.
По умолчанию система сама выбирает время выполнения задачи, когда оно будет наиболее эффективным. Она может не выполняться немедленно, если вы запланировали задачу и приложение не находится в видимом состоянии. Вы можете исключить эту оптимизацию, используя флаг ускоренного выполнения. Однако делать это следует только в том случае, если задача очень важна по времени. Существуют квоты на время выполнения ускоренных задач, поскольку ускоренные задачи потребляют больше энергии, чем задачи, выполняемые по умолчанию.
Правильный сценарий, в котором вы можете использовать флаг expedited — это задача, которая должна быть выполнена в результате высокоприоритетного FCM. Недопустимым сценарием является отмена системных оптимизаций. Задача по умолчанию будет выполняться в оптимальное для системы время после выполнения заданных ограничений.
Используйте метод getStopReason, чтобы узнать, как была остановлена ваша задача. Например, если ваша задача часто получает таймаут stop_reason_timeout, это может означать, что в ней есть крайний случай, который должен быть отменен и требует дальнейшей отладки. Мы рекомендуем вам отслеживать эти данные через ваш механизм аналитики, чтобы помочь вам определить, как часто ваша задача останавливается системой. Кроме того, если ваша задача завершается слишком часто, система может перевести ваше приложение в ограниченное состояние.
Вот три лучших способа использования служб переднего плана, которые повышают эффективность работы от батареи. Избегайте излишнего использования wakelocks, особенно из службы Foreground Service. Блокировки Wakelocks — это способ предотвратить переход процессора в спящий режим при выключенном экране. Однако они могут быть сложными в управлении и при неэффективном использовании могут расходовать батарею.
Вот несколько вопросов, которые следует рассмотреть при использовании wakelock. Используете ли вы уже API, который является альтернативой для получения wakelock? Например, если вы используете WorkManager, JobScheduler или ExoPlayer, вам не нужно приобретать wakelock.
Требуется ли от устройства выполнять действия, даже когда экран выключен? Если вам нужно делать что‑то только периодически, пока устройство бодрствует, блокировка wakelock не нужна, например, если вы используете службу Foreground Service для периодического обмена данными с внешним устройством, и для пользователя нет никакой пользы от этого обмена данными, пока экран выключен.
Службы переднего плана должны использоваться только на время выполнения действия пользователя. Как только действие приостановлено или завершено, службу Foreground Service следует остановить. Работа службы дольше, чем длится действие пользователя, может привести к тому, что другие не связанные с ней асинхронные работы будут продолжаться и неожиданно расходовать заряд батареи.
Например, если вы используете службу Media Playback Foreground Service для воспроизведения музыки в фоновом режиме, как только пользователь приостановит воспроизведение музыки, вы должны немедленно остановить службу Foreground Service. Убедиться в том, что служба Foreground Service остановлена, можно в диспетчере задач, доступном на устройствах под управлением Android 13 и выше.
Службы переднего плана предназначены для продолжения действий, инициированных пользователем. Используете ли вы фоновое исключение для запуска службы, когда приложение не видно? Например, вы можете использовать BroadcastReceiver BOOT_COMPLETED для запуска службы переднего плана сразу после перезапуска устройства.
Мы настоятельно рекомендуем подождать, пока пользователь не сообщит о намерении перезапустить действие, чтобы снова использовать эту фоновую службу. Мы также добавляем ограничения на то, какие Foreground Services могут запускаться из BOOT_COMPLETED, когда речь идет об Android 15. Если вам интересно узнать больше о лучших практиках для оптимизированных API планирования или Foreground Service, вы можете обратиться к документации для разработчиков.
Выводы
Мы узнали, как связаны фоновая работа и энергопотребление. Одним из основных факторов, способствующих плохой работе от аккумулятора, на самом деле является отключение экрана. Разработчики не должны полагаться только на системные оптимизации для улучшения времени автономной работы.
Мы узнали о том, как выбрать наиболее оптимальные API для выполнения работы в фоновом режиме, используя эту блок-схему, а также о лучших практиках использования оптимизированных API планирования и Foreground Services.
Android будет продолжать оптимизировать и создавать API, которые побудят разработчиков переключить энергию с невидимых сценариев использования на видимые для клиентов сценарии использования, которые обеспечивают измеримую ценность. Помните Боба? Благодаря всем вашим усилиям его устройство расходует гораздо меньше батареи, и он смог добраться до дома.
Заключение
Оптимизация фоновой работы и использование мощных ИИ-моделей позволяют создавать инновационные и энергоэффективные приложения, которые обеспечивают пользователям высококачественный опыт. С появлением ИИ на мобильных устройствах будут появляться новые фичи или крутые идеи для приложений. Скоро мы не сможем представить наши приложения без искусственного интеллекта!
Делитесь впечатлениями от прошедшего Google I/O в комментариях!!! Какая тема из представленных вам понравилась больше всего?
Другие статьи по Android-разработке для начинающих:
Статья про OAuth, из которой узнаете, на какие моменты стоит обратить внимание, какие способы реализации выбрать
Но это (не)точно: чего ждать мобильным разработчикам в 2023-м году
Другие статьи по Android-разработке для продвинутых:
Этапы работы во фреймворке Jetpack Compose, который упрощает написание и обновление визуального интерфейса приложения
