UWP(유니버설 Windows 플랫폼) 앱 수명 주기

  • 아티클

이 토픽에서는 UWP(유니버설 Windows 플랫폼) 앱이 시작된 시점부터 닫힐 때까지의 수명 주기를 설명합니다.

짧은 역사

Windows 8 이전까지는 앱의 수명 주기가 단순했습니다. Win32 앱 및 .NET 앱은 실행되기도 하고 실행되지 않기도 합니다. 사용자가 이 앱들을 최소화하거나 다른 앱으로 전환해도 해당 앱들은 계속 실행됩니다. 휴대용 디바이스 및 전원 관리의 중요성이 점점 더 높아지기 전까지는 아무 문제가 없었습니다.

Windows 8에서는 UWP 앱을 사용하는 새 애플리케이션 모델이 도입되었습니다. 높은 수준에서 새로운 일시 중단 상태가 추가되었습니다. 사용자가 앱을 최소화하거나 다른 앱으로 전환하면 즉시 UWP 앱이 일시 중단됩니다. 다시 말해서, 운영 체제가 리소스를 회수할 필요가 없는 한 앱의 스레드가 중지되고 앱이 메모리에 남게 됩니다. 사용자가 앱으로 다시 전환하면 앱이 실행 중 상태로 신속하게 복원될 수 있습니다.

앱이 백그라운드에 있을 때 계속 실행되어야 하는 경우는 백그라운드 작업, 확장형 실행, 활동 후원형 실행(예: 앱이 백그라운드에서 미디어 재생을 계속할 수 있게 하는 BackgroundMediaEnabled 기능) 등으로 다양합니다. 게다가 앱이 일시 중단되었거나 종료된 경우에도 백그라운드 전송 작업이 계속될 수 있습니다. 자세한 내용은 파일 다운로드 방법을 참조하세요.

포그라운드에 없는 앱은 기본적으로 일시 중단됩니다. 이로 인해 전원이 절약되고 현재 포그라운드에 있는 앱에 사용할 수 있는 리소스가 늘어납니다.

운영 체제는 리소스를 확보하기 위해 일시 중단된 앱을 종료하기로 선택할 수 있습니다. 따라서 일시 중단 상태에서는 개발자인 사용자에게 새로운 요구 사항이 추가됩니다. 종료된 앱은 작업 표시줄에 계속 표시됩니다. 사용자는 앱을 클릭했을 때 시스템이 앱을 닫았다는 사실을 알지 못합니다. 따라서 앱이 종료되기 전의 상태로 앱을 복원해야 합니다. 앱은 다른 작업이 진행되는 동안 스스로가 백그라운드에서 대기 중이라고 판단하고, 작업이 중단되었던 때와 동일한 상태에 있을 것으로 예상합니다. 이 토픽에서는 이 과정을 달성하는 방법을 알아보겠습니다.

Windows 10 버전 1607에는 앱 모델 상태가 두 가지 더 도입되었는데, 바로 포그라운드에서 실행 중 및 백그라운드에서 실행 중입니다. 이 추가 상태들은 이후의 섹션에서 알아보겠습니다.

앱 실행 상태

이 그림은 Windows 10 버전 1607부터 발생 가능한 앱 모델 상태를 나타냅니다. UWP 앱의 일반적인 수명 주기를 살펴보겠습니다.

state diagram showing transitions between app execution states

앱은 열리거나 활성화될 때 백그라운드 상태로 실행되기 시작합니다. 포그라운드 앱이 실행되어 앱을 포그라운드로 이동해야 하는 경우 앱은 LeavingBackground 이벤트를 가져옵니다.

"실행됨"과 "활성화됨"은 비슷한 용어같지만 운영 체제에서 앱을 시작할 수 있는 다른 방식을 가리킵니다. 먼저 앱 시작 작업부터 살펴보겠습니다.

앱 시작

앱을 시작하면 OnLaunched 메서드가 호출됩니다. 무엇보다도 LaunchActivatedEventArgs 매개변수(앱에 전달되는 인수, 앱을 시작한 타일의 ID, 앱이 속해 있던 이전 상태를 제공함)가 전달됩니다.

LaunchActivatedEventArgs.PreviousExecutionState(ApplicationExecutionState를 반환함)로부터 앱의 이전 상태를 가져오세요. 해당 상태의 값 및 해당 상태 때문에 취해야 할 적절한 조치는 다음과 같습니다.

ApplicationExecutionState 설명 수행할 작업
실행 중 아님 앱은 사용자가 마지막으로 재부팅했거나 로그인한 이후에 아직 시작된 적이 없어서 이 상태에 있을 수 있습니다. 실행 중이었으나 충돌이 발생해서, 혹은 사용자가 이전에 앱을 닫아서 이 상태일 수도 있습니다. 현재의 사용자 세션에서 최초로 실행되는 것처럼 앱을 초기화하세요.
일시 중단됨 사용자가 앱을 최소화했거나 다른 앱으로 전환했으며 몇 초 내에 앱으로 돌아가지 않았습니다. 앱이 일시 중단되었을 때 앱의 상태가 메모리에서 유지되었습니다. 앱이 일시 중단되었을 때 배포한 파일 핸들 또는 기타 리소스를 다시 획득하기만 하면 됩니다.
종료됨 앱은 이전에 일시 중단되었지만, 시스템이 메모리를 회수해야 했기 때문에 이후 일정 시점에 종료되었습니다. 사용자가 다른 앱으로 전환했을 때의 앱 상태를 복원하세요.
ClosedByUser 사용자가 시스템 닫기 단추를 사용하거나 Alt+F4를 사용하여 앱을 닫았습니다. 사용자가 앱을 닫으면 앱이 먼저 일시 중단되었다가 종료됩니다. 앱은 기본적으로 종료됨 상태를 초래하는 동일한 단계를 거쳤기 때문에, 종료됨 상태와 동일한 방식으로 이 현상을 처리합니다.
실행 중 이 앱은 사용자가 다시 시작하려 했을 때 이미 열려 있었습니다. 아무 일도 일어나지 않습니다. 앱의 다른 인스턴스는 시작되지 않았습니다. 이미 실행 중인 인스턴스는 활성화되기만 했습니다.

참고 항목

현재 사용자 세션은 Windows 로그온을 기반으로 합니다. 현재 사용자가 Windows를 로그오프, 종료 또는 다시 시작하지 않은 한, 현재 사용자 세션은 잠금 화면 인증, 사용자 전환 등의 이벤트를 통틀어 지속됩니다.

알아둬야 할 한 가지 중요한 상황은 디바이스의 리소스가 충분한 경우, 운영 체제가 응답성을 최적화하기 위해 해당 동작을 옵트인한 적이 있는 자주 사용하는 앱을 미리 시작한다는 것입니다. 사전 시작된 앱은 백그라운드에서 시작되었다가 빠르게 일시 중단됩니다. 이 때문에 사용자가 해당 앱으로 전환하면 앱을 시작할 때보다 빠르게 다시 시작할 수 있습니다.

사전 실행 때문에 사용자가 아니라 시스템에서 앱의 OnLaunched() 메서드를 시작할 수 있습니다. 이 앱은 백그라운드에서 미리 시작되므로, 사용자가 OnLaunched()에서 다른 작업을 실행해야 할 수 있습니다. 그 예로 앱이 열렸을 때 음악 재생이 시작되면, 앱이 백그라운드에서 미리 시작되었기 때문에 앱의 출처가 어디인지 알 수 없게 됩니다. 앱이 백그라운드에서 미리 시작되면 이후에 Application.Suspending을 호출합니다. 그런 다음 사용자가 앱을 시작하면 OnLaunched() 메서드는 물론 재개 이벤트도 호출됩니다. 사전 시작 시나리오를 처리하는 방법에 대한 자세한 내용은 앱 사전 시작 처리하기를 참조하세요. 옵트인하는 앱만이 미리 시작됩니다.

앱이 시작되면 Windows에 앱의 시작 화면이 나타납니다. 시작 화면을 구성하려면 시작 화면 추가하기를 참조하세요.

시작 화면이 나타나는 동안 앱으로 이벤트 처리기를 등록하고 첫 페이지에 필요한 사용자 지정 UI를 설정해야 합니다. OnLaunched() 및 애플리케이션의 생성자에서 실행 중인 이러한 작업이 몇 초 내에 완료되도록 합니다. 완료되지 않으면 시스템에서 앱이 응답하지 않는다고 생각하고 종료할 수도 있습니다. 앱이 네트워크에 데이터를 요청해야 하거나 디스크에서 대량의 데이터를 검색해야 하는 경우, 이러한 활동은 시작 시와 다른 때에 완료되어야 합니다. 앱은 장기 작업이 완료될 때까지 기다리는 동안 자체적인 사용자 지정 로딩 UI 또는 확장형 시작 화면을 사용할 수 있습니다. 자세한 내용은 더 오랫동안 시작 화면 표시하기 및 시작 화면 샘플을 참조하세요.

앱 시작이 완료되고 나면 앱이 실행 중 상태가 되고, 시작 화면이 사라지면서 모든 시작 화면 리소스 및 개체가 지워집니다.

앱 활성화

사용자가 앱을 시작한 때와는 다르게 시스템에서 앱을 활성화할 수 있습니다. 앱은 공유 계약 등의 계약에 따라 활성화될 수 있습니다. 아니면 사용자 지정 URI 프로토콜 또는 앱이 처리하도록 등록된 확장자가 붙은 파일을 처리하도록 앱이 활성화될 수도 있습니다. 앱을 활성화할 수 있는 방법의 목록은 ActivationKind를 참조하세요.

Windows.UI.Xaml.Application 클래스는 앱을 활성화할 수 있는 다양한 방법을 처리하기 위해 재정의할 수 있는 메서드를 정의합니다. OnActivated는 가능한 모든 활성화 유형을 처리할 수 있습니다. 다만 특정 메서드를 사용하여 가장 일반적인 활성화 형식을 처리하고, 덜 일반적인 활성화 형식에 대해서는 대체 메서드로 OnActivated를 사용하는 것이 더 일반적입니다. 다음은 특정 활성화에 대한 추가 메서드입니다.

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivatedOnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

이 메서드들에 대한 이벤트 데이터에는 앞에서 설명한 것과 동일한 PreviousExecutionState 속성이 포함되어 있습니다. 이 속성은 활성화되기 전의 앱 상태를 알려줍니다. 상태 및 앞서 앱 시작 섹션에서 설명한 것과 동일한 방법으로 수행해야 하는 작업을 해석하세요.

참고 컴퓨터의 관리자 계정을 사용해서 로그온하면 UWP 앱을 활성화할 수 없습니다.

백그라운드에서 실행 중

Windows 10 버전 1607부터는 앱으로 앱 자체와 동일한 프로세스 내에서 백그라운드 작업을 실행할 수 있습니다. 이에 대한 자세한 내용은 단일 프로세스 모델을 이용한 백그라운드 활동에서 확인하세요. 이 문서에서는 In-process 백그라운드 처리를 진행하지 않습니다. 다만 이것이 앱 수명 주기에 영향을 미친다는 것은 앱이 백그라운드에 있는 시기와 관련된 두 개의 새 이벤트가 추가되었다는 뜻입니다. 이 이벤트들은 EnteredBackground와 LeavingBackground입니다.

이들 이벤트에는 사용자가 앱의 UI를 확인할 수 있는지 여부도 반영됩니다.

백그라운드에서 실행 중 상태는 애플리케이션이 시작되거나, 활성화되거나, 재개될 때의 기본 상태입니다. 이 상태에서는 애플리케이션 UI가 아직 눈에 보이지 않습니다.

포그라운드에서 실행 중

포그라운드에서 실행 중 상태는 앱의 UI가 눈에 보인다는 뜻입니다.

LeavingBackground 이벤트는 애플리케이션 UI가 표시되기 직전에, 그리고 포그라운드 상태로 실행이 시작되기 전에 발생합니다. 사용자가 앱으로 다시 전환하는 경우에도 발생합니다.

이전에는 UI 자산을 로드하기 가장 좋은 위치가 Activated(활성화됨) 이벤트 처리기 또는 Resuming(재개 중) 이벤트 처리기에 있었습니다. 이제 LeavingBackground는 UI가 준비되었는지 확인하기 가장 좋은 장소입니다.

이는 애플리케이션이 사용자에게 표시되기 전에 작업을 수행할 수 있는 마지막 기회입니다. 따라서 시각 자산이 이 시기까지 준비되었는지 확인하는 것이 중요합니다. 이 이벤트 처리기의 모든 UI 작업은 사용자가 경험하는 시작 및 재개 시간에 영향을 미치므로 신속하게 완료되어야 합니다. LeavingBackground는 UI의 첫 프레임이 준비되었는지 확인하는 시기입니다. 그런 다음 이벤트 처리기를 반환할 수 있도록 장기 실행 스토리지 호출 또는 네트워크 호출을 비동기적으로 처리해야 합니다.

사용자가 애플리케이션으로부터 멀리 전환하면 앱이 백그라운드 상태에서 다시 실행되기 시작합니다.

백그라운드 상태 다시 시작 중

EnteredBackground 이벤트는 앱이 더 이상 포그라운드에 표시되지 않는다는 것을 나타냅니다. EnteredBackground는 데스크톱에서 앱이 최소화되었을 때, 휴대폰에서 홈 화면 또는 다른 앱으로 전환할 때 발생합니다.

앱의 메모리 사용량 줄이기

앱이 더 이상 사용자에게 표시되지 않으므로, 가장 좋은 방법은 UI 렌더링 작업 및 애니메이션을 중지하는 것입니다. LeavingBackground를 사용하면 해당 작업을 다시 시작할 수 있습니다.

백그라운드에서 작업을 수행하려는 경우에는 이 시기에 작업을 준비하기 좋습니다. 앱이 리소스를 확보하기 위해 시스템에서 종료될 위험을 감수하지 않도록 MemoryManager.AppMemoryUsageLevel을 확인하고, 필요한 경우 백그라운드에서 실행 중일 때 앱에서 사용하는 메모리의 용량을 줄이는 것이 가장 좋은 방법입니다.

자세한 내용은 앱이 백그라운드 상태로 이동할 때 메모리 사용량 줄이기를 참조하세요.

상태 저장하기

suspending 이벤트 처리기가 앱 상태를 저장하기에 가장 적합합니다. 그러나 백그라운드에서 작업하는 경우(예: 확장된 실행 세션이나 in-proc 백그라운드 작업을 사용하여 오디오 재생) EnteredBackground 이벤트 처리기에서 비동기적으로 데이터를 저장하는 것도 좋은 방법입니다. 앱이 백그라운드에서 우선 순위가 더 낮은 경우 종료될 수 있기 때문입니다. 이 경우에는 앱이 일시 중단 상태를 거치지 않으므로 데이터가 손실됩니다.

백그라운드 작업이 시작되기 전에 EnteredBackground 이벤트 처리기에서 데이터를 저장하면 사용자가 앱을 다시 포그라운드로 전환할 때 적절한 사용자 환경을 제공할 수 있습니다. 애플리케이션 데이터 API를 사용하면 데이터 및 설정을 저장할 수 있습니다. 자세한 내용은 설정 및 기타 앱 데이터 저장/검색하기를 참조하세요.

데이터를 저장한 후 메모리 사용량 한도가 초과되면, 나중에 다시 로드할 수 있으므로 메모리에서 데이터를 내보내면 됩니다. 이렇게 하면 백그라운드 활동에 필요한 자산에서 사용할 수 있는 메모리가 확보됩니다.

앱에서 백그라운드 활동이 진행 중인 경우에는 일시 중단 상태에 도달한 적이 없어도 백그라운드에서 실행 중 상태에서 포그라운드에서 실행 중 상태로 이동할 수 있습니다.

참고 항목

사용자가 앱을 닫으면 EnteredBackground 이벤트 전에 OnSuspending 이벤트가 발생할 수 있습니다. 경우에 따라서는 앱이 종료되기 전에 EnteredBackground 이벤트가 발생하지 않을 수 있습니다. OnSuspending 이벤트 처리기에 데이터를 저장하는 것이 중요합니다.

비동기 작업 및 지연

처리기 내에서 비동기 호출을 하면 해당 비동기 호출에서 컨트롤이 즉시 반환됩니다. 즉 이 실행은 이벤트 처리기에서 반환될 수 있으며, 비동기 호출이 아직 완료되지 않은 경우에도 앱이 다음 상태로 이동합니다. 반환된 Windows.Foundation.Deferral 개체에서 Complete(완료) 메서드를 호출할 때까지 일시 중단을 지연시키려면 이벤트 처리기에 전달되는 EnteredBackgroundEventArgs 개체의 GetDeferral 메서드를 사용하세요.

지연을 실행하더라도 앱을 종료하기 전에 코드를 실행해야 하는 시간이 늘어나지는 않습니다. 지연의 Complete(완료) 메서드가 호출되거나 기한이 경과할(둘 중 먼저 도달하는 시기) 때까지만 종료가 지연됩니다.

상태를 저장하는 데 더 많은 시간이 필요한 경우, OnSuspending 이벤트 처리기에 저장할 시간이 적어지도록 앱이 백그라운드 상태가 되기 전에 상태를 단계별로 저장하는 방법을 알아보세요. 아니면 더 많은 시간을 얻기 위해 ExtendedExecutionSession을 요청할 수도 있습니다. 그러나 요청이 접수된다는 보장은 없으므로, 상태를 저장하는 데 필요한 시간을 최소화할 방법을 찾는 것이 가장 좋습니다.

앱 일시 중단

사용자가 앱을 최소화하면 Windows가 몇 초 동안 대기했다가 사용자가 해당 앱으로 다시 전환할지 여부를 확인합니다. 이 기간 내에 다시 전환하지 않고 확장형 실행, 백그라운드 작업 또는 활동 후원형 실행이 활성화되지 않으면 Windows가 앱을 일시 중단합니다. 확장형 실행 세션 등이 해당 앱에서 활성화되지 않는 한, 잠금 화면이 나타나면 앱도 일시 중단됩니다.

앱이 일시 중단되면 Application.Suspending 이벤트가 호출됩니다. Visual Studio의 UWP 프로젝트 템플릿은 App.xaml.cs에 OnSuspending이라는 이 이벤트의 처리기를 제공합니다. 여기에는 애플리케이션 상태를 저장할 코드를 넣어야 합니다.

앱이 일시 중단되어 있는 동안 다른 앱으로 액세스할 수 있도록 전용 리소스 및 파일 핸들을 해제해야 합니다. 전용 리소스의 예로는 카메라, I/O 디바이스, 외부 디바이스, 네트워크 리소스 등이 있습니다. 전용 리소스 및 파일 핸들을 명시적으로 해제하면 앱이 일시 중단되어 있는 동안 다른 앱으로 액세스할 수 있게 하는 데 도움이 됩니다. 앱이 재개되면 전용 리소스 및 파일 핸들을 다시 가져와야 합니다.

기한에 유의하세요.

디바이스의 빠른 속도와 응답성을 보장하기 위해 일시 중단 중인 이벤트 처리기에서 코드를 실행해야 하는 시간에는 제한이 있습니다. 이 시간 제한은 디바이스마다 다르며, 사용자는 SuspendingOperation 개체의 기한이라는 속성을 사용해서 시간 제한이 어떤지 확인할 수 있습니다.

EnteredBackground 이벤트 처리기와 마찬가지로, 원하는 처리기에서 비동기 호출을 하면 해당 비동기 호출에서 컨트롤이 즉시 반환됩니다. 즉 이 실행은 이벤트 처리기에서 반환될 수 있으며, 비동기 호출이 아직 완료되지 않은 경우에도 앱이 일시 중단 상태로 이동합니다. 반환된 SuspendingDeferral 개체에서 Complete(완료) 메서드를 호출할 때까지 일시 중단 상태의 시작을 지연시키려면 SuspendingOperation 개체(이벤트 인수로 사용 가능)의 GetDeferral 메서드를 사용하세요.

시간이 더 필요하다면 ExtendedExecutionSession을 요청할 수 있습니다. 그러나 요청이 접수된다는 보장은 없으므로, Suspended(일시 중단됨) 이벤트 처리기에 필요한 시간을 최소화할 방법을 찾는 것이 가장 좋습니다.

앱 종료

시스템에서는 앱이 일시 중단된 동안 해당 앱과 그 데이터를 메모리에 저장하려고 시도합니다. 단, 앱을 메모리에 저장할 리소스가 시스템에 없으면 시스템에서 앱이 종료됩니다. 앱은 종료된다는 알림을 수신하지 않습니다. 따라서 앱의 데이터를 저장할 수 있는 유일한 기회는 OnSuspending 이벤트 처리기에 있습니다.

앱이 종료 후 활성화되었다고 판단되면 앱이 종료 이전과 동일한 상태가 되도록 저장된 애플리케이션 데이터를 로드해야 합니다. 사용자가 종료된 일시 중단 앱으로 다시 전환하면 앱으로 OnLaunched 메서드에서 애플리케이션 데이터를 복원해야 합니다. 시스템은 종료 시기를 앱에 알리지 않습니다. 따라서 앱으로 애플리케이션 데이터를 저장하고, 앱이 일시 중단되기 전에 전용 리소스 및 파일 핸들을 해제했다가 종료 후 앱이 활성화되었을 때 해당 리소스 및 파일 핸들을 복원해야 합니다.

Visual Studio를 이용한 디버깅에 관한 참고 사항: Visual Studio는 Windows가 디버거에 연결된 앱을 일시 중단하지 못하게 합니다. 이는 앱이 실행되는 동안 사용자가 Visual Studio 디버그 UI를 볼 수 있게 하기 위한 조치입니다. 앱을 디버깅하려는 경우에는 Visual Studio를 사용해서 일시 중단 이벤트를 앱으로 전송할 수 있습니다. 디버그 위치 도구 모음이 표시되는지 확인한 다음 일시 중단 아이콘을 클릭하세요.

앱 재개

사용자가 해당 앱으로 전환하거나, 디바이스가 저전력 상태를 벗어났을 때 앱이 활성 상태가 되면 일시 중단된 앱이 재개됩니다.

일시 중단됨 상태에서 앱이 재개되면 백그라운드에서 실행 중 상태가 되며, 앱이 계속 실행 중인 것처럼 사용자에게 표시되도록 시스템이 앱을 중단된 위치에서 복원합니다. 메모리에 저장된 앱 데이터는 손실되지 않습니다. 따라서 대부분의 앱은 일시 중단되었을 때 해제된 파일 또는 디바이스 핸들을 다시 가져와야 하고, 앱이 일시 중단되었을 때는 명시적으로 해제된 상태를 복원해야 하는 반면, 재개되었을 때는 상태를 복원할 필요가 없습니다.

앱은 몇 시간 또는 며칠 동안 일시 중단될 수 있습니다. 앱에 오래되었을 수 있는 콘텐츠 또는 네트워크 연결이 있으면 앱이 재개될 때 해당 콘텐츠 또는 연결을 새로 고쳐야 합니다. 앱이 Application.Resuming 이벤트에 대한 이벤트 처리기를 등록한 경우, 해당 이벤트는 앱이 일시 중단 상태에서 재개될 때 호출됩니다. 이 이벤트 처리기에서는 앱 콘텐츠 및 데이터를 새로 고칠 수 있습니다.

일시 중단된 앱은 앱 계약 또는 확장에 참여하도록 활성화되면 먼저 재개 중 이벤트를 수신하고, 이어서 활성화됨 이벤트를 수신합니다.

일시 중단된 앱이 종료되면 재개 중 이벤트가 발생하지 않고, 대신 종료됨의 ApplicationExecutionState로 OnLaunched()를 호출합니다. 앱이 일시 중단되었을 때 상태를 저장했으므로, 앱이 다른 앱으로 전환되었을 때처럼 사용자에게 표시되도록 OnLaunched() 도중에 해당 상태를 복원할 수 있습니다.

앱이 일시 중단되어 있는 동안에는 수신하도록 등록된 네트워크 이벤트가 전혀 수신되지 않습니다. 이 네트워크 이벤트는 대기 상태가 되지 않으며 누락되기만 합니다. 따라서 앱이 재개되면 앱으로 네트워크 상태를 테스트해야 합니다.

참고재개 중 이벤트는 UI 스레드에서 발생하지 않습니다. 따라서 재개 처리기의 코드가 UI와 통신하면 발송자를 사용해야 합니다. 이 작업을 수행하는 방법에 대한 코드 예제는 백그라운드 스레드에서 UI 스레드 업데이트하기를 참조하세요.

전체 지침은 앱 일시 중단 및 재개 관련 지침을 참조하세요.

앱 닫기

사용자는 일반적으로 앱을 닫을 필요가 없으며 Windows로 앱을 관리할 수 있습니다. 다만 사용자는 닫기 제스처를 사용하거나, Alt+F4를 누르거나, Windows Phone의 작업 전환기를 사용해서 앱을 닫기로 선택할 수 있습니다.

사용자가 앱을 닫았다는 것을 나타내는 이벤트는 없습니다. 사용자가 앱을 닫으면 먼저 앱이 일시 중단되어 앱의 상태를 저장할 기회가 생깁니다. Windows 8.1 이상에서는 사용자가 앱을 닫은 후 해당 앱이 화면 및 전환 목록에서 제거되지만, 명시적으로 종료되지는 않습니다.

Closed-by-user behavior: 앱을 사용자가 닫을 때 Windows에서 닫을 때와 다른 작업을 수행해야 하는 경우 활성화 이벤트 처리기를 사용하여 앱을 종료한 주체가 사용자인지 Windows인지를 확인할 수 있습니다. ApplicationExecutionState 열거형 관련 참조에서 ClosedByUser 상태 및 Terminated 상태에 대한 설명을 참조하세요.

반드시 필요한 경우가 아니라면 앱이 스스로를 프로그래밍 방식으로 닫지 않는 것이 좋습니다. 그 예로 앱에서 메모리 누수가 감지되면, 사용자의 개인 데이터에 대한 보안을 보장하기 위해 앱이 스스로를 닫을 수 있습니다.

앱 충돌

시스템 충돌 환경은 사용자가 가능한 한 빨리 수행 중이던 작업으로 돌아갈 수 있도록 설계되었습니다. 사용자가 지연되므로 경고 대화 상자 또는 기타 알림을 제공해서는 안 됩니다.

앱이 충돌하거나, 응답을 중지하거나, 예외를 생성하면 사용자의 피드백 및 진단 설정에 따라 문제 보고서가 Microsoft로 전송됩니다. Microsoft는 앱을 개선하는 데 사용되도록 문제 보고서를 통해 오류 데이터의 하위 집합을 제공합니다. 이 데이터는 대시보드의 앱 품질 페이지에서 확인할 수 있습니다.

사용자가 충돌 이후 앱을 활성화하면 앱의 활성화 이벤트 처리기가 NotRunning의 ApplicationExecutionState 값을 수신하며, 초기 UI 및 데이터를 표시해야 합니다. 충돌 이후에는 데이터가 손상될 수 있으므로, 일시 중단과 함께 재개 중에 사용했을 만한 앱 데이터를 정기적으로 사용하지 마세요. 앱 일시 중단 및 재개 관련 지침을 참조하세요.

앱 제거

사용자가 앱을 삭제하면 해당 앱이 앱의 모든 로컬 데이터와 함께 제거됩니다. 앱을 제거해도 일반적인 위치(예: 문서 또는 그림 라이브러리)에 저장된 사용자의 데이터가 영향을 받지는 않습니다.

앱 수명 주기 및 Visual Studio 프로젝트 템플릿

앱 수명 주기와 관련 있는 기본 코드는 Visual Studio 프로젝트 템플릿에 수록됩니다. 기본 앱은 사용자가 본인만의 코드를 추가하기 전에 시작 활성화를 처리하고, 앱 데이터를 복원할 수 있는 장소를 제공하고, 기본 UI를 표시합니다. 자세한 내용은 앱용 C#, VB, C++ 프로젝트 템플릿을 참조하세요.

주요 애플리케이션 수명 주기 API