Я разобрала статью:
(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 может быть расширен с помощью подхода, основанного на вытеснении. Этот подход может быть применен и к другим вычислительным средам, где есть строгие требования ко времени отклика.
В заключение:
В статье рассмотрена проблема инверсии приоритетов ввода-вывода
Представлена схема управления вводом-выводом с учетом приложений на переднем плане - FastTrack.
В качестве основных причин большинства инверсий приоритетов ввода-вывода выделяют страничный кэш и устройство хранения данных.
Результаты экспериментов на реальных смартфонах показывают, что FastTrack улучшает опыт пользователей, предотвращая инверсию приоритетов ввода-вывода между приложениями переднего плана и фоновыми приложениями на смартфонах Android.
namikiri
Насколько я помню, iOS именно так и делает. Даже как-то проводил тест — открывал страницу в браузере и, не давая ей догрузиться, начинал елозить пальцем по интерфейсу. Такие действия значительно замедляли загрузку страницы, но при этом недогруженные куски перемещались по экрану максимально плавно.