Я разобрала статью:

Hahn, S. S., Lee, S., Yee, I., Ryu, D., & Kim, J. (2018). FastTrack: Foreground App-Aware I/O Management for Improving User Experience of Android Smartphones. In 2018 Annual Technical Conference (USENIX 18) (pp. 15-28).

(FastTrack: Управление вводом/выводом с учетом приложений на переднем плане для улучшения пользовательского опыта смартфонов Android)

И хочу поделиться основными идеями по улучшению пользовательского опыта при взаимодействии со смартфонами Android.

Пользователям смартфонов важно, чтобы их устройства без задержек реагировали на действия пользователя. Инверсии приоритетов ввода-вывода в разделах кэша страниц (page cache) и хранилище (storage device) являются причинами увеличения времени отклика приложений переднего плана (FG, Foreground). Цель статьи - исследовать проблему инверсии приоритетов ввода-вывода на смартфонах Android, ее влияние на работу пользователя. Авторы статьи предлагают инструмент управления вводом-выводом FastTrack. Он вытесняет текущую фоновую активность на всех уровнях. 

По результатам тестирования инструмент ограничивает увеличение времени отклика на 27%, в дефолтной реализации Android еще на 2,319%. Когда шесть фоновых приложений (BG, Background) работают вместе, FastTrack может сократить время отклика приложения FG на 94% по сравнению с Android. Авторы изменили реализацию кэша страниц, планировщик ввода-вывода внутри хранилища. FastTrack улучшает взаимодействие пользователя со смартфонами, предотвращая инверсию приоритетов ввода-вывода.

Основные идеи из статьи

В смартфонах существуют приложения переднего плана (foreground, FG) и фоновые приложения (background, BG). Процесс FG - это любая программа, которую вы запускаете на телефоне и ждете ее завершения. Другими словами, все приложения, которые отображаются на экране смартфона. BG-приложения работают в фоновом режиме. К ним относятся, например, поиск обновлений или новых сообщений на почте.

Ввод/вывод (I/O) процессов из FG имеет более высокий приоритет по сравнению с вводом/выводом BG - процессов. При этом FG I/O-ы должны ждать завершения BG I/O-ов. То есть происходит инверсия приоритетов ввода-вывода. В статье авторы с разных сторон рассматривают проблему инверсии приоритетов ввода-вывода на смартфонах Android, включая ее влияние на работу пользователей, а также основные причины возникновения инверсии и как решать эту проблему.

Для того, чтобы оценить, действительно ли инверсия приоритетов происходит в реальном андроиде или нет, авторы реализовали простую утилиту ввода-вывода, основанную на инструменте мониторинга Linux strace. (Спойлер: Андроид это Линукс, если вы не знали.) Исследователи для тестирования выбрали пользователей, которые почти всегда носят с собой смартфоны. Участники использовали приложения браузер Chrome, сообщения, камеру, галерею и игры в качестве FG-приложений и Dropbox, OneDrive, автоматическое обновление приложений в качестве BG-приложений на 10 различных Android-смартфонах. Задержка загрузки (load latency) приложений измерялась в трех сценариях: запуск галереи, переключение на приложение камеры, загрузка игр. Для каждого смартфона собрали историю системных вызовов за месяц. Затем вычислили средние коэффициенты, которые представляют собой отношение количества системных вызовов I/O для FG к общему количеству I/O - вызовов.

Проведенное исследование подтверждает, что вызовы I/O для BG могут значительно ухудшить пользовательский опыт, когда BG конфликтуют с FG I/Os. Устройство хранения (storage device) данных считается самым медленным компонентом в иерархии стека ввода-вывода, поэтому оно является главным узким местом при отсутствии BG I/O.

Авторы статьи проанализировали стек ввода-вывода Android с помощью IOPro, инструмента профилирования ввода-вывода, разработанного также авторами статьи. IOPro измерял время выполнения запросов ввода-вывода на всех стеках ввода-вывода Android: в кэше страниц, на уровене блочного ввода-вывода и на устройстве хранения данных. Влияние блочного ввода-вывода на производительность оказалось довольно незначительным по сравнению с двумя другими уровнями. Поэтому авторы статьи сосредоточились на анализе внутренней активности ввода-вывода в кэше страниц и на устройстве хранения.

Найдены 3 основные причины снижения производительности FG приложений по сравнению с приложениями BG:

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

  • в кэше страниц создается много грязных страниц (dirty pages). Это такие страницы в оперативной памяти, которые были изменены по сравнению с той версией, которая сейчас хранится на диске. Они будут записаны на диск когда-нибудь (связано с механизмом своппинга).

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

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

В статье авторы предложили новую схему управления вводом/выводом для смартфонов Android, названную FastTrack. Ключевое отличие от существующих методов заключается в том, что FastTrack вытесняет текущую фоновую активность (BG процессы) на всех уровнях стека ввода-вывода. FastTrack останавливает текущую фоновую активность незамедлительно, как только поступают процессы FG ввода/вывода. Затем FastTrack отправляет запрос непосредственно на устройство хранения с минимальным вмешательством со стороны уровней стека ввода-вывода. Таким образом, FastTrack может быстро отреагировать на запрос ввода-вывода от приложения FG и обеспечить такой же уровень воспринимаемой пользователем отзывчивости, как и при отсутствии BG ввода-вывода. В FastTrack изменили политику отчистки кэша страниц, чтобы он был доступен для FG.

FastTrack был протестирован на смартфонах Android, таких как Nexus 5, Nexus 6, Galaxy S6 и Pixel. Выбраны два сценария фонового использования: обновление игры примерно на 1,5 Гб и резервное копирование 1 Гб файлов данных в облачное хранилище. В статье описывается, что изменение расписания запросов ввода-вывода на уровне планировщика оказалось менее эффективным, чем выполнение на более высоком уровне - в кэше страниц. Более высокая производительность также может быть достигнута, если устройство хранения данных способно обрабатывать запросы ввода-вывода с информацией о приоритетах на уровне приложений.

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

Затем провели следующий тест. Шесть приложений BG с интенсивным вводом-выводом были запущены вместе. На основе экспериментальных результатов FastTrack может обеспечить эквивалентный уровень отзывчивости приложений FG независимо от количества приложений BG. Также FastTrack может:

  • ограничить увеличение времени отклика приложения FG до 27%.

  • увеличить время отклика на 2 319% в стандартной реализации Android.

  • уменьшить время отклика приложения FG на 94% по сравнению с реализацией Android по умолчанию.

Хотя существующие методы все еще эффективны, они имеют фундаментальные ограничения по улучшению отзывчивости ввода/вывода по сравнению с FastTrack. Поэтому существующие методы не подходят для устройств, ориентированных на взаимодействие, таких как смартфоны.

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

В заключение:

  1. В статье рассмотрена проблема инверсии приоритетов ввода-вывода

  2. Представлена схема управления вводом-выводом с учетом приложений на переднем плане - FastTrack. 

  3. В качестве основных причин большинства инверсий приоритетов ввода-вывода выделяют страничный кэш и устройство хранения данных. 

  4. Результаты экспериментов на реальных смартфонах показывают, что FastTrack улучшает опыт пользователей, предотвращая инверсию приоритетов ввода-вывода между приложениями переднего плана и фоновыми приложениями на смартфонах Android.

Комментарии (1)


  1. namikiri
    07.02.2022 17:31

    Насколько я помню, iOS именно так и делает. Даже как-то проводил тест — открывал страницу в браузере и, не давая ей догрузиться, начинал елозить пальцем по интерфейсу. Такие действия значительно замедляли загрузку страницы, но при этом недогруженные куски перемещались по экрану максимально плавно.