Compartir a través de

Ciclo de vida de la aplicación Plataforma universal de Windows (UWP)

  • Artículo

En este tema se describe el ciclo de vida de una aplicación de Plataforma universal de Windows (UWP) desde el momento en que se inicia hasta que se cierra.

Un poco de historia

Antes de Windows 8, las aplicaciones tenían un ciclo de vida sencillo. Las aplicaciones Win32 y .NET se ejecutan o no se ejecutan. Cuando un usuario los minimiza o se aleja de ellos, continúa ejecutándose. Esto fue correcto hasta que los dispositivos portátiles y la administración de energía se volvieron cada vez más importantes.

Windows 8 introdujo un nuevo modelo de aplicación con aplicaciones para UWP. En un nivel alto, se agregó un nuevo estado suspendido. Una aplicación para UWP se suspende poco después de que el usuario la minimice o cambie a otra aplicación. Esto significa que los subprocesos de la aplicación se detienen y la aplicación se deja en memoria a menos que el sistema operativo necesite reclamar recursos. Cuando el usuario vuelve a la aplicación, se puede restaurar rápidamente a un estado en ejecución.

Hay varias maneras de seguir ejecutándose en las aplicaciones cuando se encuentran en segundo plano, como tareas en segundo plano, ejecución extendida y ejecución patrocinada por la actividad (por ejemplo, la funcionalidad BackgroundMediaEnabled que permite que una aplicación siga reproduciendo elementos multimedia en segundo plano). Además, las operaciones de transferencia en segundo plano pueden continuar incluso si la aplicación está suspendida o incluso finalizada. Para obtener más información, consulta Cómo descargar un archivo.

De forma predeterminada, las aplicaciones que no están en primer plano se suspenden. Esto da como resultado ahorro de energía y más recursos disponibles para la aplicación actualmente en primer plano.

El estado suspendido agrega nuevos requisitos para usted como desarrollador porque el sistema operativo puede optar por finalizar una aplicación suspendida para liberar recursos. La aplicación terminada seguirá apareciendo en la barra de tareas. Cuando el usuario hace clic en él, la aplicación debe restaurar el estado en el que estaba antes de finalizar porque el usuario no será consciente de que el sistema cerró la aplicación. Pensarán que ha estado esperando en segundo plano mientras estaban haciendo otras cosas y esperarán que esté en el mismo estado en que estaba en cuando lo dejaron. En este tema veremos cómo hacerlo.

Windows 10, versión 1607, introdujo dos estados de modelo de aplicación más: En ejecución en primer plano y En ejecución en segundo plano. Veremos estos estados adicionales en las secciones siguientes.

Estado de ejecución de la aplicación

Esta ilustración representa los posibles estados del modelo de aplicación a partir de Windows 10, versión 1607. Vamos a recorrer el ciclo de vida típico de una aplicación para UWP.

diagrama de estado que muestra las transiciones entre estados de ejecución de la aplicación

Las aplicaciones entran en estado en segundo plano cuando se inician o activan. Si la aplicación necesita pasar al primer plano debido a un inicio de la aplicación en primer plano, la aplicación obtiene el evento LeavingBackground.

Aunque "iniciado" y "activado" pueden parecer términos similares, hacen referencia a diferentes formas en que el sistema operativo puede iniciar la aplicación. Echemos un vistazo primero al inicio de una aplicación.

Inicio de la aplicación

Se llama al método OnLaunched cuando se inicia una aplicación. Se pasa un parámetro LaunchActivatedEventArgs que proporciona, entre otras cosas, los argumentos pasados a la aplicación, el identificador del icono que inició la aplicación y el estado anterior en el que estaba la aplicación.

Obtenga el estado anterior de la aplicación desde LaunchActivatedEventArgs.PreviousExecutionState, que devuelve applicationExecutionState. Sus valores y la acción adecuada que se debe realizar debido a ese estado son los siguientes:

ApplicationExecutionState Explicación Acción que realizar
NotRunning Una aplicación podría estar en este estado porque no se ha iniciado desde la última vez que el usuario ha reiniciado o iniciado sesión. También puede estar en este estado si se estaba ejecutando pero luego se bloqueó o porque el usuario lo cerró anteriormente. Inicialice la aplicación como si se estuviera ejecutando por primera vez en la sesión de usuario actual.
Suspendida El usuario ha minimizado o cambiado de la aplicación y no volvió a ella en unos segundos. Cuando se suspendió la aplicación, su estado permaneció en la memoria. Solo tiene que volver a adquirir los identificadores de archivo u otros recursos que liberó cuando se suspendió la aplicación.
Finalizado La aplicación se suspendió anteriormente, pero luego se desconectaba en algún momento porque el sistema necesitaba reclamar memoria. Restaure el estado en el que estaba la aplicación cuando el usuario se apartó de ella.
ClosedByUser El usuario cerró la aplicación con el botón cerrar del sistema o con Alt+F4. Cuando el usuario cierra la aplicación, primero se suspende y, a continuación, finaliza. Dado que la aplicación ha pasado básicamente por los mismos pasos que conducen al estado Terminado, controle esto de la misma manera que lo haría con el estado Terminado.
Ejecución La aplicación ya estaba abierta cuando el usuario intentó iniciarla de nuevo. Nada. Tenga en cuenta que no se inicia otra instancia de la aplicación. La instancia que ya se está ejecutando simplemente está activada.

Nota:

La sesión de usuario actual se basa en el inicio de sesión de Windows. Siempre que el usuario actual no haya cerrado, apagado o reiniciado Windows, la sesión del usuario actual persiste en eventos como la autenticación de la pantalla de bloqueo, el usuario del conmutador, etc.

Una circunstancia importante a tener en cuenta es que si el dispositivo tiene suficientes recursos, el sistema operativo iniciará previamente las aplicaciones usadas con frecuencia que han optado por ese comportamiento para optimizar la capacidad de respuesta. Las aplicaciones que se inician previamente se inician en segundo plano y, a continuación, se suspenden rápidamente para que cuando el usuario cambie a ellas, se puedan reanudar, lo que es más rápido que iniciar la aplicación.

Debido al inicio previo, el sistema puede iniciar el método OnLaunched() de la aplicación en lugar del usuario. Dado que la aplicación se inicia previamente en segundo plano, es posible que deba realizar diferentes acciones en OnLaunched(). Por ejemplo, si la aplicación comienza a reproducir música cuando se inicia, no sabrá de dónde procede porque la aplicación se inicia previamente en segundo plano. Una vez que la aplicación se inicia previamente en segundo plano, va seguida de una llamada a Application.Suspending. A continuación, cuando el usuario inicia la aplicación, se invoca el evento de reanudación, así como el método OnLaunched(). Consulte Control del inicio previo de la aplicación para obtener información adicional sobre cómo controlar el escenario de inicio previo. Solo se inician previamente las aplicaciones que participan.

Windows muestra una pantalla de presentación para la aplicación cuando se inicia. Para configurar la pantalla de presentación, consulte Agregar una pantalla de presentación.

Mientras se muestra la pantalla de presentación, la aplicación debe registrar controladores de eventos y configurar cualquier interfaz de usuario personalizada que necesite para la página inicial. Vea que estas tareas que se ejecutan en el constructor de la aplicación y OnLaunched() se completan en unos segundos o el sistema puede pensar que la aplicación no responde y finalizarla. Si una aplicación necesita solicitar datos de la red o necesita recuperar grandes cantidades de datos del disco, estas actividades deben completarse fuera del inicio. Una aplicación puede usar su propia interfaz de usuario de carga personalizada o una pantalla de presentación extendida mientras espera a que finalicen las operaciones de larga duración. Consulta Mostrar una pantalla de presentación para obtener más tiempo y el ejemplo de pantalla de presentación para obtener más información.

Una vez que la aplicación finaliza el inicio, entra en estado En ejecución y la pantalla de presentación desaparece y se borran todos los recursos y objetos de la pantalla de presentación.

Activación de la aplicación

A diferencia de ser iniciado por el usuario, el sistema puede activar una aplicación. Una aplicación puede activarse mediante un contrato como el contrato de recursos compartidos. O bien, se puede activar para controlar un protocolo de URI personalizado o un archivo con una extensión que la aplicación está registrada para controlar. Para obtener una lista de las formas en que se puede activar la aplicación, consulta ActivationKind.

La clase Windows.UI.Xaml.Application define métodos que puedes invalidar para controlar las distintas formas en que se puede activar la aplicación. OnActivated puede controlar todos los tipos de activación posibles. Sin embargo, es más común usar métodos específicos para controlar los tipos de activación más comunes y usar OnActivated como método de reserva para los tipos de activación menos comunes. Estos son los métodos adicionales para activaciones específicas:

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivated OnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

Los datos del evento de estos métodos incluyen la misma propiedad PreviousExecutionState que vimos anteriormente, lo que indica en qué estado estaba la aplicación antes de que se activara. Interprete el estado y lo que debe hacer de la misma manera que se describió anteriormente en la sección Inicio de la aplicación.

Nota Si inicias sesión con la cuenta de administrador del equipo, no puedes activar aplicaciones para UWP.

Ejecución en segundo plano

A partir de Windows 10, versión 1607, las aplicaciones pueden ejecutar tareas en segundo plano dentro del mismo proceso que la propia aplicación. Obtenga más información sobre ella en Actividad en segundo plano con el modelo de proceso único. No entraremos en el procesamiento en segundo plano en proceso en este artículo, pero cómo afecta al ciclo de vida de la aplicación es que se han agregado dos nuevos eventos relacionados con cuando la aplicación está en segundo plano. Son: EnteredBackground y LeavingBackground.

Estos eventos también reflejan si el usuario puede ver la interfaz de usuario de la aplicación.

La ejecución en segundo plano es el estado predeterminado en el que se inicia, activa o reanuda una aplicación. En este estado, la interfaz de usuario de la aplicación aún no está visible.

Ejecución en primer plano

La ejecución en primer plano significa que la interfaz de usuario de la aplicación está visible.

El evento LeavingBackground se desencadena justo antes de que la interfaz de usuario de la aplicación esté visible y antes de escribir la ejecución en estado en primer plano. También se activa cuando el usuario vuelve a la aplicación.

Anteriormente, la mejor ubicación para cargar los recursos de la interfaz de usuario estaba en los controladores de eventos Activados o Reanudando . Ahora LeavingBackground es el mejor lugar para comprobar que la interfaz de usuario está lista.

Es importante comprobar que los recursos visuales están listos en este momento porque esta es la última oportunidad de realizar el trabajo antes de que la aplicación sea visible para el usuario. Todo el trabajo de la interfaz de usuario en este controlador de eventos debe completarse rápidamente, ya que afecta al inicio y reanudación del tiempo que experimenta el usuario. LeavingBackground es el momento de asegurarse de que el primer fotograma de la interfaz de usuario está listo. A continuación, las llamadas de red o almacenamiento de larga duración deben controlarse de forma asincrónica para que el controlador de eventos pueda devolver.

Cuando el usuario se aleja de la aplicación, la aplicación vuelve a escribir el estado en ejecución en segundo plano.

Volver a escribir el estado en segundo plano

El evento EnteredBackground indica que la aplicación ya no está visible en primer plano. En el escritorio EnteredBackground se activa cuando la aplicación está minimizada; en el teléfono, al cambiar a la pantalla principal u otra aplicación.

Reducir el uso de memoria de la aplicación

Puesto que la aplicación ya no es visible para el usuario, este es el mejor lugar para detener el trabajo de representación de la interfaz de usuario y las animaciones. Puede usar LeavingBackground para iniciar ese trabajo de nuevo.

Si va a hacer trabajo en segundo plano, este es el lugar para prepararlo. Es mejor comprobar MemoryManager.AppMemoryUsageLevel y, si es necesario, reducir la cantidad de memoria que usa la aplicación cuando se ejecuta en segundo plano para que el sistema no ponga en riesgo la finalización del sistema para liberar recursos.

Consulta Reducir el uso de memoria cuando la aplicación se mueve al estado en segundo plano para obtener más detalles.

Guardar el estado

El controlador de eventos de suspensión es el mejor lugar para guardar el estado de la aplicación. Sin embargo, si está trabajando en segundo plano (por ejemplo, reproducción de audio, mediante una sesión de ejecución extendida o una tarea en segundo plano en proceso), también es recomendable guardar los datos de forma asincrónica desde el controlador de eventos EnteredBackground . Esto se debe a que es posible que la aplicación finalice mientras está en una prioridad más baja en segundo plano. Y como la aplicación no habrá pasado por el estado suspendido en ese caso, se perderán los datos.

Guardar los datos en el controlador de eventos EnteredBackground , antes de que comience la actividad en segundo plano, garantiza una buena experiencia de usuario cuando el usuario vuelve a poner la aplicación en primer plano. Puede usar las API de datos de aplicación para guardar los datos y la configuración. Para más información, consulte Almacenar y recuperar la configuración y otros datos de aplicación.

Después de guardar los datos, si supera el límite de uso de memoria, puede liberar los datos de la memoria, ya que puede volver a cargarlos más adelante. Esto liberará la memoria que pueden usar los recursos necesarios para la actividad en segundo plano.

Tenga en cuenta que si la aplicación tiene actividad en segundo plano en curso que puede pasar de la ejecución en segundo plano al estado en ejecución en primer plano sin alcanzar nunca el estado suspendido.

Nota:

Cuando el usuario cierra la aplicación, es posible que el evento OnSuspending se desencadene antes del evento EnteredBackground . En algunos casos, es posible que el evento EnteredBackground no se desencadene antes de que finalice la aplicación. Es importante guardar los datos en el controlador de eventos OnSuspending .

Trabajos asincrónicos y aplazamientos

Si realiza una llamada asincrónica dentro del controlador, el control devuelve inmediatamente desde esa llamada asincrónica. Esto significa que la ejecución puede volver del controlador de eventos y la aplicación pasará al siguiente estado aunque la llamada asincrónica aún no se haya completado. Use el método GetDeferral en el objeto EnteredBackgroundEventArgs que se pasa al controlador de eventos para retrasar la suspensión hasta después de llamar al método Complete en el objeto Windows.Foundation.Deferral devuelto.

Un aplazamiento no aumenta la cantidad de tiempo que tienes que ejecutar el código antes de que finalice la aplicación. Solo retrasa la terminación hasta que se llama al método Complete del aplazamiento o la fecha límite pasa lo que ocurra primero.

Si necesita más tiempo para guardar el estado, investigue formas de guardar el estado en fases antes de que la aplicación entre en segundo plano para que haya menos que guardar en el controlador de eventos OnSuspending . O bien, puede solicitar una ExtendedExecutionSession para obtener más tiempo. Sin embargo, no hay ninguna garantía de que se concederá la solicitud, por lo que es mejor encontrar formas de minimizar la cantidad de tiempo que necesita para guardar el estado.

Suspensión de la aplicación

Cuando el usuario minimiza una aplicación, Windows espera unos segundos para ver si el usuario volverá a cambiar a ella. Si no vuelven dentro de este período de tiempo y no hay ninguna ejecución extendida, tarea en segundo plano o ejecución patrocinada por la actividad está activa, Windows suspende la aplicación. Una aplicación también se suspende cuando la pantalla de bloqueo aparece siempre que no haya ninguna sesión de ejecución extendida, etc. esté activa en esa aplicación.

Cuando se suspende una aplicación, invoca el evento Application.Suspending. Las plantillas de proyecto para UWP de Visual Studio proporcionan un controlador para este evento llamado OnSuspending en App.xaml.cs. Debe colocar el código para guardar el estado de la aplicación aquí.

Debes liberar los recursos exclusivos y los identificadores de archivo para que otras aplicaciones puedan acceder a ellos mientras la aplicación está suspendida. Algunos ejemplos de recursos exclusivos son cámaras, dispositivos de E/S, dispositivos externos y recursos de red. Liberar explícitamente recursos exclusivos y identificadores de archivo ayuda a garantizar que otras aplicaciones puedan acceder a ellos mientras la aplicación está suspendida. Cuando se reanuda la aplicación, debe volver a adquirir sus recursos exclusivos y identificadores de archivo.

Tenga en cuenta la fecha límite

Para garantizar un dispositivo rápido y con capacidad de respuesta, hay un límite durante el tiempo que tiene que ejecutar el código en el controlador de eventos de suspensión. Es diferente para cada dispositivo y puede averiguar lo que está usando una propiedad del objeto SuspendingOperation denominado fecha límite.

Al igual que con el controlador de eventos EnteredBackground , si realiza una llamada asincrónica desde el controlador, el control devuelve inmediatamente desde esa llamada asincrónica. Esto significa que la ejecución puede volver del controlador de eventos y la aplicación pasará al estado de suspensión aunque la llamada asincrónica aún no se haya completado. Use el método GetDeferral en el objeto SuspendingOperation (disponible a través de los argumentos del evento) para retrasar la entrada del estado suspendido hasta después de llamar al método Complete en el objeto SuspendingDeferral devuelto.

Si necesita más tiempo, puede solicitar extendedExecutionSession. Sin embargo, no hay ninguna garantía de que se concederá la solicitud, por lo que es mejor encontrar formas de minimizar la cantidad de tiempo que necesita en el controlador de eventos Suspendido .

Finalización de la aplicación

El sistema intenta mantener la aplicación y sus datos en la memoria mientras está suspendido. Sin embargo, si el sistema no tiene los recursos para mantener la aplicación en memoria, finalizará la aplicación. Las aplicaciones no reciben una notificación de que finalizan, por lo que la única oportunidad de guardar los datos de la aplicación está en el controlador de eventos OnSuspending .

Cuando la aplicación determina que se ha activado después de finalizarse, debe cargar los datos de la aplicación que guardó para que la aplicación esté en el mismo estado en el que estaba antes de que se finalizara. Cuando el usuario vuelve a una aplicación suspendida que se ha terminado, la aplicación debe restaurar sus datos de aplicación en su método OnLaunched. El sistema no notifica a una aplicación cuando finaliza, por lo que la aplicación debe guardar sus datos de aplicación y liberar recursos exclusivos y identificadores de archivo antes de que se suspenda y restaurarlos cuando la aplicación se active después de la finalización.

Nota sobre la depuración mediante Visual Studio: Visual Studio impide que Windows suspenda una aplicación que esté asociada al depurador. Esto es para permitir que el usuario vea la interfaz de usuario de depuración de Visual Studio mientras se ejecuta la aplicación. Al depurar una aplicación, puede enviarlo a un evento de suspensión mediante Visual Studio. Asegúrese de que se muestra la barra de herramientas Ubicación de depuración y, a continuación, haga clic en el icono Suspender .

Reanudación de la aplicación

Una aplicación suspendida se reanuda cuando el usuario cambia a ella o cuando es la aplicación activa cuando el dispositivo sale de un estado de baja potencia.

Cuando se reanuda una aplicación desde el estado Suspendido , entra en el estado En segundo plano y el sistema restaura la aplicación donde se dejó para que parezca al usuario como si hubiera estado ejecutándose todo el proceso. No se pierden los datos de la aplicación almacenados en la memoria. Por lo tanto, la mayoría de las aplicaciones no necesitan restaurar el estado cuando se reanudan, aunque deben volver a adquirir los identificadores de archivo o dispositivo que liberaron cuando se suspendieron y restaurar cualquier estado que se liberó explícitamente cuando se suspendió la aplicación.

Es posible que la aplicación se suspenda durante horas o días. Si la aplicación tiene contenido o conexiones de red que pueden haber quedado obsoletas, se deben actualizar cuando se reanude la aplicación. Si una aplicación registró un controlador de eventos para el evento Application.Resuming, se llama cuando la aplicación se reanuda desde el estado Suspendido. Puede actualizar el contenido y los datos de la aplicación en este controlador de eventos.

Si se activa una aplicación suspendida para participar en un contrato o extensión de aplicación, recibe primero el evento Resuming y, a continuación, el evento Activated .

Si se finalizó la aplicación suspendida, no hay ningún evento Resuming y, en su lugar, se llama a OnLaunched() con un ApplicationExecutionState de Terminated. Como guardó el estado cuando se suspendió la aplicación, puede restaurar ese estado durante OnLaunched() para que la aplicación aparezca al usuario como cuando se desplazó de ella.

Mientras se suspende una aplicación, no recibe ningún evento de red que haya registrado para recibir. Estos eventos de red no se ponen en cola; simplemente se pierden. Por lo tanto, la aplicación debe probar el estado de red cuando se reanude.

Nota Dado que el evento Resuming no se genera desde el subproceso de la interfaz de usuario, se debe usar un distribuidor si el código del controlador de reanudación se comunica con la interfaz de usuario. Consulte Actualización del subproceso de interfaz de usuario desde un subproceso en segundo plano para obtener un ejemplo de código de cómo hacerlo.

Para obtener instrucciones generales, consulte Directrices para suspender y reanudar aplicaciones.

Cierre de la aplicación

Por lo general, los usuarios no necesitan cerrar las aplicaciones, pueden permitir que Windows los administre. Sin embargo, los usuarios pueden optar por cerrar una aplicación con el gesto cerrar o presionando Alt+F4 o mediante el conmutador de tareas en Windows Phone.

No hay ningún evento para indicar que el usuario cerró la aplicación. Cuando el usuario cierra una aplicación, primero se suspende para ofrecerle la oportunidad de guardar su estado. En Windows 8.1 y versiones posteriores, después de que el usuario haya cerrado una aplicación, la aplicación se quita de la pantalla y cambia la lista, pero no finaliza explícitamente.

Comportamiento cerrado por usuario: si la aplicación necesita hacer algo diferente cuando el usuario lo cierra que cuando windows lo cierra, puedes usar el controlador de eventos de activación para determinar si el usuario o Windows finalizaron la aplicación. Consulte las descripciones de los estados ClosedByUser y Terminated en la referencia de la enumeración ApplicationExecutionState .

Se recomienda que las aplicaciones no se cierren mediante programación a menos que sea absolutamente necesario. Por ejemplo, si una aplicación detecta una pérdida de memoria, puede cerrarse para garantizar la seguridad de los datos personales del usuario.

Bloqueo de la aplicación

La experiencia de bloqueo del sistema está diseñada para devolver a los usuarios lo que hacían lo más rápido posible. No debe proporcionar un cuadro de diálogo de advertencia u otra notificación porque retrasará al usuario.

Si la aplicación se bloquea, deja de responder o genera una excepción, se envía un informe de problemas a Microsoft según la configuración de diagnóstico y comentarios del usuario. Consulte Diagnósticos, comentarios y privacidad en Windows para obtener más información. Microsoft proporciona un subconjunto de los datos de error en el informe del problema para que pueda usarlo para mejorar la aplicación. Podrás ver estos datos en la página Calidad de la aplicación en el panel.

Cuando el usuario activa una aplicación después de que se bloquea, su controlador de eventos de activación recibe un valor ApplicationExecutionState de NotRunning y debe mostrar su interfaz de usuario inicial y sus datos. Después de un bloqueo, no use de forma rutinaria los datos de la aplicación que habría usado para Reanudar con Suspendido porque esos datos podrían estar dañados; consulte Directrices para suspender y reanudar la aplicación.

Eliminación de aplicaciones

Cuando un usuario elimina la aplicación, se quita la aplicación, junto con todos sus datos locales. Quitar una aplicación no afecta a los datos del usuario almacenados en ubicaciones comunes, como las bibliotecas documentos o imágenes.

Ciclo de vida de la aplicación y las plantillas de proyecto de Visual Studio

El código básico que es relevante para el ciclo de vida de la aplicación se proporciona en las plantillas de proyecto de Visual Studio. La aplicación básica controla la activación del inicio, proporciona un lugar para restaurar los datos de la aplicación y muestra la interfaz de usuario principal incluso antes de agregar cualquiera de su propio código. Para obtener más información, consulta Plantillas de proyecto de C#, VB y C++ para aplicaciones.

API clave del ciclo de vida de la aplicación