Windows 10 uwp что это

Почему Windows 10 UWP это будущее. Или зачем он нужен.

Чтобы программы могли корректно взаимодействовать с операционной системой, для этих программ нужна SDK, по которой они будут работать. UWP решает эту задачу, а также решает множество других проблем Windows.

Что сейчас в Windows?

В Windows сейчас хаос. Приложения можно писать на нескольких фреймворках:

По сути Win32Api не является фреймворком, а приложения написаны на «неуправляемом» коде, с максимально близким доступом к ОС. Win32Api это лишь набор функций + обертка для точки входа в приложение.

UWP приложения пошли дальше. Кроме расширенного SDK, с доступом к магазину Windows, такие приложения теоретически могут работать на всех платформах Windows и на архитектурах, как x86, так и ARM.

Что хотят в Microsoft?

По моему мнению, Microsoft проспала момент с продажей и рекламой приложений через интернет, но конкуренты в лице Apple и Google не дремлют. У macOS есть удобный магазин, такой же магазин есть и у Google Android. Представьте, если бы вам пришлось приложения для смартфона искать по разным сайтам. Удобно ли это? Вряд ли.

Microsoft хотят сделать тоже самое. Дать возможность людям скачивать приложения прямо из магазина Windows.

Но почему бы не сделать это для всех старых приложений? Я не знаю. Я думаю, все эти приложения не поддаются какому-либо контролю, имеют сотни инсталляторов и пишут свои файлы во все места ОС. С UWP все эти проблемы решаются. Хотя они могли бы попытаться это сделать. Тогда была бы полная победа Windows.

Правда Microsoft делают это крайне медленно. Даже в Windows 10 большая часть приложений не являются UWP. А те приложения, которые являются UWP, выглядят немного чужеродно. Все знают про две панели управления, два калькулятора и так далее.

Microsoft своими вялыми действиями не подталкивают серьезных разработчиков к созданию UWP приложений или портированию уже существующих. Результаты бездействия мы можем наблюдать в магазине:

В магазине Windows 10 в основном представлен один «шлак». Серьезные компании не стремятся переводить свои продукты на UWP.

Почему текущий подход к написанию приложений должен умереть?

1) Неконтролируемый доступ к железу.

UWP частично решает эту проблему, разграничивая права пользователей. Этот подход был полностью скопирован с Google Android и macOS/iPhone.

Если система может ограничивать доступ приложения к определенным компонентам железа или операционной системы, то мы можем увидеть список разрешений:

Тут я побуду адвокатом Windows 10, которую часто обвиняют в шпионаже. Как мне кажется, Windows 10 наоборот, пытается защитить ваши данные, разграничивая права приложений. Хотя тут можно сказать, что они просто не хотят с этими данными делиться 🙂

И если вы установили приложение, а оно начнет рассылать СМСки, то уж сами виноваты. Магазин вас предупредил. Сейчас мы устанавливаем любое приложение Windows на свой страх и риск. Оно может собирать любые данные с компьютера, а мы даже не узнаем об этом. Но здесь Microsoft наступила на грабли, сделав пункт: разрешить полный доступ ко всем компонентам Windows. И разработчики ставят этот пункт, особо не разбираясь, что к чему. Например, этим страдает Telegram.

2) Приложения написаны с использованием разных технологий.

В нормальной системе приложения написаны с помощью единых инструментов. К примеру, для Android это Java + Android SDK. Нет, есть конечно ненормальные, которые пишут приложения на Qt / C# / HTML5 приложения для Android, но внутри они всё равно используют Android SDK. Без него никуда.

Что даст переход на UWP?

Переход на UWP даст более тесную интеграцию с системой, можно будет использовать уведомления на полную мощность, обмениваться данными между приложениями. Писать приложения под все платформы, при этом ядро приложения будет единым.

Источник

Подробно о Windows 10X: контейнеры, работа UWP и Win32 приложений

11 февраля на конференции для разработчиков Microsoft 365 Developer Day компания Microsoft поделилась некоторыми деталями о работе новой операционной системы Windows 10X. Также был представлен эмулятор для разработчиков, позволяющий оптимизировать приложения для устройств с двумя экранами.

Главная особенность Windows 10X заключается в том, что приложения запускаются в контейнерах. Подробнее остановимся на данной технологии и рассмотрим, какие типы приложений можно будет запустить на устройствах под управлением Windows 10X, таких как Surface Neo.

Три типа контейнеров для максимальной совместимости

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

В Windows 10X абсолютно все приложения выполняются в контейнерах, которые являются частью архитектуры ОС. Разработчикам не нужно реализовывать какие-либо дополнительные изменения на высоком уровне для запуска приложений в Windows 10X.

Разработчики самостоятельно могут выбирать архитектуру своих продуктов: Win32, прогрессивные веб-приложения или UWP. По понятным причинам UWP-приложения лучше всего оптимизированы для Windows 10X, но Microsoft приложила много усилий, чтобы классические настольные приложения корректно работали в новой системе.

Контейнеры позволяют оптимизировать энергопотребление и производительность

UWP-платформа имеет наилучшую оптимизацию для Windows 10X. Это вполне логично, ведь UWP-приложения первоначально разрабатывались с учетом мобильной платформы Windows Phone (Windows Mobile). Такие приложения повышают безопасность и производительность, снижают энергопотребление и соблюдают меры энергосбережения операционной системы (переход и выход из спящего режима).

Приложения Win32 создавались преимущественно для настольных компьютеров. Им недостает мобильной оптимизации, как у UWP. Классические приложения, как правило, являются более функциональными, чем UWP, но хуже влияют на время автономной работы и скорость работы системы. В любом случае, даже в 2020 году приложения Win32 играют важную роль в современных компьютерных вычислениях.

Microsoft решила «исправить слабые стороны» приложений Win32 (и MSIX) с помощью контейнеризации:

В свернутом состоянии приложения Win32 и MSIX не будут работать в фоновом режиме. Данная мера позволяет экономить системные ресурсы и заряд аккумулятора. И наоборот, когда приложения Win32 активно используется, они выделяют больше ресурсов для высокой производительности.

Существует два последствия такого поведения. Во-первых, классические приложения Win32 не смогут выполнять фоновые задачи. По крайней мере длительные задачи до приостановки контейнера. Во-вторых, приложения Win32 не смогут автоматически запускаться в Windows 10X. В Windows 10X нет системного трея, поэтому классические приложения не смогут непрерывно работать в фоновом режиме.

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

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

Все будет работать корректно

Интересно, что контейнеризация приложений Win32 не скажется на их функциональных возможностях. Microsoft заявляет, что эти классические приложения получат полный доступ к следующим компонентам:

Это означает, что старая модель «Plug and Play» сохранится, и на Surface Neo можно будет использовать все, что вы к нему подключите, включая внешние мониторы и периферийные устройства.

Так как в Windows 10 отсутствует системный трей, то классические приложения не смогут его использовать, что, тем не менее, не должно привести к проблемам стабильности. Microsoft сообщает, что Win32 приложения cмогут работать «как есть» (то есть без изменений в реестре), но из-за контейнеризации программные вызовы никогда не коснутся ОС. Компания заявляет, что ограничения, наложенных контейнером Win32, не должны приводить к сбоям.

Два Проводника

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

Однако, при вызове диалогового окна работы с файлами в UWP-приложениях или в самой системе Windows 10X откроется «современный» Проводник Windows (Modern File Explorer), который ограничен необходимыми библиотеками, такими как Видео, Музыка, Избранное, Документы, Изображения и др.

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

Приложения запускаются в развернутом режиме

Корпоративный вице-президент Microsoft Developer Platform, Кевин Галло (Kevin Gallo) рассказал, что в настоящее время все приложения в Windows 10X работают в полноэкранном режиме (т.е. развернуты на весь экран). Это похоже на то, как приложения запускаются в Windows 8 или в планшетном режиме в Windows 10.

Причиной такого выбора является размер экрана: чем меньше дисплей, тем больше «плотность» отображаемой информации. Запуск пяти приложений с маленькими окнами на одном 9-дюймовом дисплее вряд ли будет популярным сценарием.

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

Итог: Windows 10X является технически сложной системой, но простой для пользователя

Microsoft спроектировала Windows 10X таким образом, чтобы она была нейтральной для приложений, независимо от архитектуры: Electron, UWP, Win32, WinForms, WPF. Все эти приложения уверенно запустятся на Windows 10X без существенных изменений в коде.

По сравнению с обычной Windows 10 Microsoft изменила не только дизайн, но и основный приоритет:

Конечно, это условная классификация, но Windows 10X построена так, чтобы быть быстрой, гибкой, мобильной и безопасной. Уже известно, что обновление ОС должно занимать не более 90 секунд. Данное преимущество связано с тем, что Windows 10X построена на замкнутой и ограниченной природе UWP, как и HoloLens.

В любом случае, владельцы Surface Neo смогут устанавливать любое приложение по желанию, и ожидаемое поведение будет соблюдено. У разработчиков также не нужно вносить существенные изменения в свои продукты.

Галло подчеркивает, что приложения, оптимизированные для работы с двумя экранами, также должны обеспечивать лучшее взаимодействие с настольными системами Windows 10. Это яркий пример преемственности Windows 10X и Windows 10.

Как все будет работать на практике, пока неизвестно. Microsoft утверждает, что разница в производительности между приложениями Win32 и UWP в Windows 10X не должна быть заметна для пользователей. Мы вступаем в новую эру мобильных ПК, где пользователям не придется идти на компромиссы.

Примечание: Большая часть данной информации основана на демонстрационном видео «How Windows 10X runs UWP and Win32 apps» показанном на Microsoft 365 Developer Day.

Источник

Что такое приложение UWP?

UWP — это один из многих способов создания клиентских приложений для Windows. Приложения UWP используют API WinRT для предоставления мощных пользовательских интерфейсов и расширенных асинхронных функций, которые идеально подходят для устройств, подключенных к Интернету.

Чтобы скачать средства, требуемые для создания приложений UWP, ознакомьтесь со сведениями о подготовке, а затем напишите свое первое приложение.

Какое место принадлежит UWP в истории разработки Майкрософт?

История разработки Майкрософт получила логическое развитие с реализацией UWP — мощного средства для создания клиентских приложений, используемого наряду с такими инициативами, как WinUI, MSIX и Project Reunion.

Возможности приложения UWP

Основные достоинства приложения UWP.

Рассмотрим все это более подробно.

Безопасность

В манифестах приложений UWP объявляются возможности устройства, необходимые приложению, — например, доступ к микрофону, геоданным, веб-камере, USB-устройствам, файлам и т. д. Прежде чем приложение получит доступ к возможности, пользователь должен подтвердить и разрешить такой доступ.

Общая поверхность API для всех устройств

В Windows 10 впервые появилась универсальная платформа Windows (UWP), которая предоставляет общую платформу приложений на любом устройстве, работающем под управлением Windows 10. Основные API UWP одинаковы на всех устройствах Windows. Если ваше приложение использует только основные API, оно будет работать на любом устройстве под управлением Windows 10, независимо от того, под какое устройство оно разрабатывалось — ПК, Xbox, гарнитуру смешанной реальности и т. п.

Приложение UWP, написанное на C++ /WinRT или C++ /CX, имеет доступ к API-интерфейсам Win32, которые входят в состав UWP. Эти API Win32 реализуются всеми устройствами с Windows 10.

Пакеты SDK расширений предоставляют уникальные возможности для конкретных типов устройств

Если вы разрабатываете приложение для универсальных API, такое приложение сможет работать на всех устройствах под управлением Windows 10. Но если вы хотите, чтобы ваше приложение UWP могло пользоваться преимуществами API конкретных устройств, это также возможно.

Пакеты SDK расширений позволяют вызывать специализированные API для различных устройств. Например, если ваше приложение UWP предназначено для устройства Интернета вещей, вы можете добавить в свой проект пакет SDK расширения для Интернета вещей, чтобы реализовать функции, характерные для устройств Интернета вещей. См. сведения в разделе Пакеты SDK расширений статьи Программирование с помощью пакетов SDK расширений.

Вы можете написать приложение так, чтобы оно было предназначено для запуска только на устройствах определенного типа, а затем ограничить его распространение в Microsoft Store только этим типом устройств. Или же вы можете реализовать условную проверку на наличие того или иного API во время выполнения и соответствующим образом адаптировать поведение своего приложения. См. сведения в разделе Написание кода статьи Программирование с помощью пакетов SDK расширений.

Следующее видео представляет собой краткий обзор семейств устройств и написания адаптивного кода:

Адаптивные элементы управления и ввод

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

Windows позволяет ориентировать пользовательский интерфейс на множество устройств с помощью следующих функций:

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

Один магазин для всех устройств.

Благодаря единому магазину ваше приложение будет доступно на различных устройствах с Windows 10 — ПК, планшетах, HoloLens, Surface Hub, а также устройствах для Интернета вещей. Вы можете отправить приложение в магазин и сделать его доступным для всех типов устройств или только некоторых из них. Вы отправляете все свои приложения для устройств с ОС Windows и управляете ими централизованно. У вас есть классическое приложение на C++, которое вы хотите модернизировать за счет возможностей UWP и продавать в Microsoft Store? Это тоже возможно.

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

Приложения UWP можно упаковывать с использованием MSIX и распространять через Microsoft Store или другими способами. MSIX позволяет обновлять приложения независимо от способа их распространения (см. статью Обновление пакетов приложений, опубликованных не в Store, из кода).

Монетизация приложения

Вы можете выбрать способ монетизации своего приложения. Существует целый ряд способов заработать на своем приложении. Вам нужно только выбрать наиболее подходящий (примеры способов приведены ниже).

Актуальная информация в реальном времени, которая побуждает пользователей вновь и вновь обращаться к приложению

Есть множество способов поддерживать интерес пользователей к приложению UWP.

Использование уже знакомого языка

Приложения UWP могут использовать среду выполнения Windows, то есть собственный API, встроенный в операционную систему. Этот API реализован на языке C++ и поддерживается в C#, Visual Basic, C++ и JavaScript. Некоторые из языков и технологий, пригодных для написания приложений UWP:

Ссылки, которые помогут вам приступить к работе

Подготовка

Скачайте средства, необходимые для создания приложений, на странице Get set up (Подготовка), а затем создайте свое первое приложение.

Проектирование приложения

Корпорация Майкрософт предоставляет систему проектирования под названием Fluent. Fluent Design — это набор функций UWP в сочетании с рекомендациями по созданию приложений, которые будут прекрасно смотреться на всех типах устройств под управлением Windows. Разработанные с помощью Fluent приложения адаптируются к самым разным устройствам — от планшетов и ноутбуков до ПК и телевизоров, и даже к устройствам виртуальной реальности — и выглядят на них совершенно естественно. Вводные сведения о системе Fluent см. в статье The Fluent Design System for Windows app creators (Система проектирования Fluent для разработчиков приложений Windows).

Хорошее проектирование подразумевает принятие решений о том, как пользователи будут взаимодействовать с приложением, а также как оно будет выглядеть и функционировать. Взаимодействие с пользователем очень сильно повлияет на то, насколько люди будут довольны вашим приложением, так что не пренебрегайте этим шагом. Из статьи Проектирование и разработка приложений для Windows вы узнаете, с чего начинать проектирование универсального приложения для Windows. Сведения о проектировании приложений UWP, которыми будут довольны все пользователи, см. в руководстве по приложениям универсальной платформы Windows (UWP) для разработчиков. Прежде чем приступить к написанию кода, изучите вводную информацию об устройствах. Это поможет вам продумать взаимодействие с пользователем в приложении на устройствах любых форм-факторов, на которые вы ориентируетесь.

Помимо взаимодействия на разных устройствах, проектируйте приложение так, чтобы использовать все преимущества работы на разных устройствах. Например:

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

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

Добавление служб

Отправьте приложение в Store.

Центр партнеров позволяет централизованно управлять всеми приложениями и держать в одном месте все приложения для устройств Windows. См. статью Публикация приложений и игр для Windows, чтобы узнать, как отправлять приложения в Microsoft Store для публикации.

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

Подробные вводные сведения см. в статье Windows 10 — An Introduction to Building Windows Apps for Windows 10 Devices (Вводные сведения о создании приложений для Windows для устройств с Windows 10).

Более сложные темы

Сопоставление универсальной платформы Windows (UWP) и API времени выполнения Windows

Если вы разрабатываете приложение для универсальной платформы Windows (UWP), вам будет намного проще и удобнее считать термины «Универсальная платформа Windows» и «Среда выполнения Windows (WinRT)» почти синонимами. Но у вас есть возможность заглянуть «под капот» этих технологий и определить различия между концепциями. Если вам это интересно, то этот последний раздел написан именно для вас.

И, само собой, API-интерфейсы WinRT можно вызвать из приложения UWP. Модель приложения UWP создана на основе среды выполнения Windows. С технической точки зрения модель приложения UWP основана на CoreApplication, но некоторые подробности могут быть недоступны в зависимости от выбора языка программирования. Как описано в этом разделе, с точки зрения ценности платформа UWP предназначена для создания единого двоичного файла, который вы сможете при желании опубликовать в Microsoft Store и запустить на любых устройствах самых разных форм-факторов. Охват устройств для приложений UWP зависит от API среды выполнения Windows, которые может вызывать приложение или которые вы можете вызывать условно.

Мы надеемся, что смогли описать в этом разделе разницу между базовыми технологиями API среды выполнения Windows и механизмом и ценностью универсальной платформы Windows.

Источник

Жизненный цикл приложения универсальной платформы Windows (UWP) для Windows 10

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

Немного истории

В Windows 8 была представлена новая модель приложений — приложения UWP. На высоком уровне было добавлено новое приостановленное состояние. Приложение UWP приостанавливается вскоре после того, как пользователь свернет его или переключится на другое приложение. Это означает, что потоки приложения будут остановлены, а приложение останется в памяти, если операционной системе не потребуется освободить ресурсы. Когда пользователь вернется к этому приложению, его работу можно будет быстро восстановить.

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

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

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

В Windows 10 версии 1607 представлены два дополнительных состояния модели приложения: Работает на переднем плане и Работает в фоновом режиме. Мы также рассмотрим эти новые состояния в следующих разделах.

Состояние выполнения приложения

На рисунке показаны возможные состояния модели приложений начиная с Windows 10 версии 1607. Изучим стандартный жизненный цикл приложения UWP.

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

Хотя термины «запущен» и «активирован» кажутся похожими, они отражают различные способы запуска приложения операционной системой. Сначала рассмотрим запуск приложения.

Запуск приложения

При запуске приложения вызывается метод OnLaunched. Ему передается параметр LaunchActivatedEventArgs, который, помимо прочего, предоставляет аргументы, переданные приложению, идентификатор плитки, которая запустила приложение, и его предыдущее состояние.

Получить предыдущее состояние приложения можно с помощью функции LaunchActivatedEventArgs.PreviousExecutionState, которая возвращает объект ApplicationExecutionState. Далее описаны его значения и соответствующие действия.

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

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

В связи с предварительным запуском метод Onlaunchd () приложения может быть инициирован системой, а не пользователем. Поскольку приложение предварительно запущено в фоновом режиме, может потребоваться другое действие в OnLaunched (). Например, если приложение начинает воспроизводить музыку после запуска, будет неизвестно, откуда она берется, поскольку приложение было предварительно запущено в фоновом режиме. Как только приложение будет предварительно запущено в фоновом режиме, последует вызов Application.Suspending. Затем, когда пользователь запускает приложение, вызывается событие возобновления, а также метод OnLaunched(). Дополнительные сведения о работе с предварительным запуском см. в разделе Обработка предварительного запуска приложения. Предварительно запускаются только приложения, которые явно разрешили эту функцию.

При запуске приложения Windows отображает его экран-заставку. Подробнее о настройке экрана-заставки см. в статье Добавление экрана-заставки.

После завершения запуска приложение переходит в состояние Running, и экран-заставка исчезает, а все соответствующие ресурсы и объекты удаляются.

Активация приложений

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

Класс Windows.UI.Xaml.Application определяет методы, которые можно переопределить для обработки различных типов активации приложения. Метод OnActivated используется для обработки всех возможных типов активации. Однако более часто используются другие методы обработки наиболее распространенных типов активации, и метод OnActivated используется как резервный для менее распространенных типов активации. Существуют другие методы для конкретных активаций:

Примечание. Если вы войдете в систему с учетной записью администратора, то не сможете активировать приложения UWP.

Выполнение в фоновом режиме

Начиная с Windows 10 версии 1607 приложения могут выполнять фоновые задачи в том же процессе, в котором работает само приложение. Подробнее об этом см. в статье Модель фонового действия с одним процессом. В этой статье мы не рассматриваем фоновую обработку с одним процессом, но следует отметить, что в жизненный цикл приложения добавлены два новых события, связанные с фоновым выполнением приложения. Это события EnteredBackground и LeavingBackground.

Они также отражают, может ли пользователь видеть интерфейс приложения.

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

Выполнение на переднем плане

Пользовательский интерфейс приложения, которое выполняется на переднем плане, виден.

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

Ранее лучшим местом для загрузки ресурсов интерфейса были обработчики событий Activated и Resuming. Теперь же обработчик события LeavingBackground — лучший способ проверить готовность вашего интерфейса.

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

Когда пользователь переключается на другую задачу, ваше приложение снова переходит в фоновое состояние.

Повторный переход в фоновое состояние

Событие EnteredBackground указывает, что приложение больше не отображается на переднем плане. На настольном компьютере событие EnteredBackground срабатывает, когда приложение свертывается, на телефоне — при переключении на начальный экран или другое приложение.

Уменьшение объема памяти, которое потребляет приложение

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

Если вы планируете выполнять какие-то задачи в фоновом режиме, здесь можно к этому подготовиться. Лучше всего проверить свойство MemoryManager.AppMemoryUsageLevel и, если требуется, уменьшить объем памяти, который использует ваше приложение, работающее в фоновом режиме, чтобы система не закрыла его, чтобы освободить ресурсы.

Сохранение состояния

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

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

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

Помните, что если приложение выполняет фоновые задачи, оно может перейти из фонового состояния в состояние выполнения на переднем плане, минуя приостановленное состояние.

Асинхронные работа и отсрочки

Если вы используете асинхронный вызов в обработчике, контроль после его завершения возвращается немедленно. Это означает, что обработчик событий вернет управление приложению, которое сможет перейти в следующее состояние, даже если асинхронный вызов еще не завершен. Используйте метод GetDeferral объекта EnteredBackgroundEventArgs, который передается обработчику события, чтобы задержать приостановку после вызова метода Complete возвращенного объекта Windows.Foundation.Deferral.

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

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

Приостановка приложения

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

Если приложение приостановлено, оно вызывает событие Application.Suspending. шаблоны проектов UWP Visual Studio предоставляют обработчик для этого события с именем onsuspendd в App. xaml. cs. До Windows 10 версии 1607 код для сохранения состояния здесь размещался здесь. Теперь рекомендуется сохранять состояние при входе в фоновый режим, как описано выше.

Вам также нужно освободить монопольные ресурсы и дескрипторы файлов, чтобы другие приложения могли получать к ним доступ, пока приложение приостановлено. К примерам монопольных ресурсов относятся камеры, устройства ввода-вывода, внешние устройства и сетевые ресурсы. Явное освобождение монопольных ресурсов и дескрипторов файлов обеспечивает доступ к ним других приложений на то время, пока приложение приостановлено. Когда приложение возобновляется, оно должно повторно получать монопольные ресурсы и дескрипторы файлов.

Помните о крайнем сроке

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

Как и в случае с EnteredBackground, если используется асинхронный вызов из обработчика, управление немедленно возвращается после его завершения. Это означает, что обработчик событий вернет управление приложению, которое сможет перейти в приостановленное состояние, даже если асинхронный вызов еще не завершен. Используйте метод GetDeferral объекта SuspendingOperation (доступного через аргументы события), чтобы отложить переход в приостановленное состояние до момента, когда будет вызван метод Complete возвращенного объекта SuspendingDeferral.

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

Завершение работы приложения

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

примечание об отладке с помощью Visual Studio: Visual Studio не позволяет Windows приостанавливать приложение, подключенное к отладчику. Это позволяет пользователю видеть пользовательский интерфейс отладчика Visual Studio во время выполнения приложения. При отладке программы с помощью Visual Studio вы можете отправить ей событие приостановки. Убедитесь, что отображается панель инструментов Место отладки, а затем щелкните значок Приостановить.

Возобновление работы приложения

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

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

Приложение может быть приостановлено на несколько часов или дней. Если ваше приложение работает с содержимым или сетевыми подключениями, которые могут устареть за это время, оно должно обновить их после возобновления работы. Если приложение зарегистрировало обработчик события Application.Resuming, то он будет вызываться при возобновлении работы приложения после выхода из состояния Suspended. С помощью этого обработчика событий вы можете обновлять содержимое и данные приложения.

Если приостановленное приложение активировано для участия в контракте приложений или расширении, оно получает сначала событие Resuming, а затем — событие Activated.

Если работа приостановленное приложения была завершена, событие Resuming не срабатывает, а вызывается метод OnLaunched(), при этом параметру ApplicationExecutionState присвоено значение Terminated. Поскольку вы сохранили состояние во время приостановки приложения, вы можете восстановить его в методе OnLaunched (), чтобы приложение выглядело так же, как и до приостановки.

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

Закрытие приложений

Обычно пользователям не нужно закрывать приложения. Они могут разрешить Windows управлять ими. Но пользователь может закрыть приложение с помощью соответствующего жеста, нажав клавиши ALT+F4 или воспользовавшись диспетчером задач в Windows Phone.

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

Поведение закрыто по пользователям: если приложению нужно сделать что-то другое, когда оно закрывается пользователем, чем оно закрывается Windows, можно использовать обработчик событий активации, чтобы определить, было ли приложение завершено пользователем или Windows. Описания состояний ClosedByUser и Terminated приведены в справочных документах по перечислению ApplicationExecutionState.

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

Сбой приложения

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

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

Когда пользователь активирует приложение после сбоя, его обработчик событий активации получает параметр ApplicationExecutionState со значением NotRunning и должен просто отобразить его начальный пользовательский интерфейс и данные. После сбоя не используйте данные приложения, которые вы бы использовали для события Resuming из состояния Suspended, поскольку эти данные могут быть повреждены; см. раздел Рекомендации по приостановке и возобновлению приложений.

Удаление приложений

Когда пользователь удаляет приложение, вместе с ним удаляются все локальные данные этого приложения. При удалении приложения не затрагиваются данные пользователей, сохраненные в стандартных расположениях, таких как файлы в библиотеках «Документы» или «Изображения».

Жизненный цикл приложения и шаблоны проектов Visual Studio

Базовый код, который соответствует жизненному циклу приложения, содержится в шаблонах проектов Visual Studio. Базовое приложение обрабатывает активацию запуска, предоставляет место для восстановления данных приложения и отображает основной пользовательский интерфейс еще до того как, вы добавите собственный код. Дополнительные сведения см. в статье Шаблоны проектов на C#, VB и C++ для приложений.

Источник