Оптимизация времени приостановки и возобновления работы

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

Launch

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

Во время активации всегда проверка значение PreviousExecutionState параметра args (например, для запущенных активаций проверка LaunchActivatedEventArgs.PreviousExecutionState). Если значение имеет значение ClosedByUser или NotRunning, не тратьте время на восстановление ранее сохраненного состояния. В этом случае правильно, чтобы обеспечить свежий опыт - и это приведет к более быстрому запуску.

Вместо того, чтобы с нетерпением восстановить ранее сохраненное состояние, рассмотрите возможность отслеживания этого состояния и только восстановления по требованию. Например, рассмотрим ситуацию, когда приложение было приостановлено, сохранено состояние на 3 страницы и затем было завершено. При повторном запуске, если вы решите вернуть пользователя на 3-ю страницу, не восстанавливайте состояние для первых 2 страниц. Вместо этого удерживайте на этом состоянии и используйте его только после того, как вы знаете, что вам нужно.

Во время выполнения

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

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

Не используйте события "Активировано" или "Видимость" для выбора состояния сохранения. Когда пользователь переключается с вашего приложения, окно деактивируется, но система ожидает короткое время (около 10 секунд) перед приостановкой приложения. Это позволяет повысить скорость реагирования, если пользователь быстро переключается на приложение. Дождитесь события приостановки перед выполнением логики приостановки.

Приостановить

Во время приостановки уменьшите объем памяти приложения. Если приложение использует меньше памяти во время приостановки, общая система будет более адаптивной и меньше приостановленных приложений (включая ваши) будет прекращена. Однако сбалансируйте это с необходимостью возобновления snappy: не сокращайте объем памяти, что возобновление значительно замедляется, пока ваше приложение перезагрузит много данных в память.

Для управляемых приложений система будет выполнять передачу сборки мусора после завершения обработчиков приостановки приложения. Не забудьте воспользоваться этим путем выпуска ссылок на объекты, которые помогут уменьшить объем памяти приложения во время приостановки.

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

Возобновить

Большинство приложений не должны делать ничего особенного при возобновлении, поэтому обычно вы не будете обрабатывать это событие. Некоторые приложения используют возобновление для восстановления подключений, которые были закрыты во время приостановки, или для обновления данных, которые могут быть устаревшими. Вместо того, чтобы выполнять эту работу с нетерпением, создайте приложение, чтобы инициировать эти действия по требованию. Это приведет к более быстрому работе, когда пользователь переключается на приостановленное приложение и гарантирует, что вы выполняете только работу, которую пользователь действительно нуждается.

Избегайте ненужного завершения

Система времени существования процесса UWP может приостановить или завершить приложение по различным причинам. Этот процесс предназначен для быстрого возвращения приложения в состояние, в которое оно было выполнено до приостановки или завершения работы. Когда все готово, пользователь не будет знать, что приложение когда-либо остановлено. Ниже приведены некоторые рекомендации, которые приложение UWP может использовать для упрощения системных переходов в течение всего времени существования приложения.

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

Сериализация только при необходимости

Многие приложения сериализуют все свои данные при приостановке. Если вам нужно хранить только небольшой объем данных параметров приложения, то вместо сериализации данных следует использовать локальное хранилище Параметры вместо сериализации данных. Используйте сериализацию для больших объемов данных и для данных, отличных от параметров.

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

Сериализация данных в C# и Visual Basic

Доступные варианты технологии сериализации для приложений .NET: классы System.Xml.Serialization.XmlSerializer, System.Runtime.Serialization.DataContractSerializer и System.Runtime.Serialization.Json.DataContractJsonSerializer.

С точки зрения производительности рекомендуется использовать класс XmlSerializer. XmlSerializer имеет наименьшее время сериализации и десериализации и поддерживает низкое объем памяти. XmlSerializer имеет несколько зависимостей от платформы .NET. Это означает, что по сравнению с другими технологиями сериализации меньше модулей необходимо загрузить в приложение для использования XmlSerializer.

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

Уменьшение объема памяти

Система пытается сохранить максимальное количество приостановленных приложений в памяти, чтобы пользователи могли быстро и надежно переключаться между ними. Когда приложение приостановлено и остается в памяти системы, оно может быстро быть доставлено на передний план для взаимодействия пользователя без необходимости отображать экран-заставку или выполнять длинную операцию загрузки. Если недостаточно ресурсов для хранения приложения в памяти, приложение завершается. Это делает управление памятью важной по двум причинам:

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

Выпуск ресурсов

Некоторые объекты, такие как файлы и устройства, занимают большое количество памяти. Мы рекомендуем во время приостановки обрабатывать выпуск приложения для этих объектов и повторно создавать их при необходимости. Это также хорошее время для очистки любых кэшей, которые не будут допустимыми при возобновлении работы приложения. Дополнительный шаг платформы XAML выполняется от вашего имени для приложений C# и Visual Basic — сборка мусора, если это необходимо. Это гарантирует, что все объекты больше не ссылаются в коде приложения.

Быстрое возобновление

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

Большинству приложений не нужно обрабатывать событие возобновления . Когда приложение возобновляется, переменные и объекты имеют точно то же состояние, что и при приостановке приложения. Обработка события возобновления только в том случае, если необходимо обновить данные или объекты, которые могли бы измениться между временем приостановки приложения, и когда оно было возобновлено, например содержимое (например, данные канала обновления), сетевые подключения, которые могли устареть, или если необходимо повторно получить доступ к устройству (например, веб-камера).