Articolo
11/17/2015

Numero speciale del 2015 su Windows 10

Volume 30 Numero 11

Il presente articolo è stato tradotto automaticamente.

Ciclo di vita dell'app - Sempre attiva con attività in background ed esecuzione estesa

Da Shawn Henry | Windows 2015

Utilizzato per che il ciclo di vita di un'applicazione è stata semplice. Quando un utente avvia un'applicazione, è possibile eseguire selvaggio nel sistema: risorse, visualizzando windows e in genere questo come presenta senza tener conto di altri utenti. Oggi le cose sono più difficile. In un mondo di mobilità, le applicazioni sono limitate a un ciclo di vita dell'applicazione definita. Questo ciclo di vita specifica quando un'applicazione può essere eseguito e la maggior parte dei casi non è possibile, se l'applicazione non è l'elemento corrente eseguite dall'utente, non è consentito per l'esecuzione.

Nella maggior parte dei casi, è buona, gli utenti sappiano che un'applicazione non è un consumo energetico o sapping delle prestazioni. Per le applicazioni, il sistema operativo consiste nell'imporre che cos'è sempre stata buona pratica, che le applicazioni immettano uno stato stazionario inattivo quando non è in uso. Ciò è particolarmente importante perché il modello di applicazione nella piattaforma di Windows universale (UWP) debba essere scalabili dai dispositivi più basso-end, quali telefoni cellulari e dispositivi Internet of Things (IoT), fino a desktop più potente e Xbox.

Per le applicazioni complesse, il modello applicazione moderna può sembrare restrittivo inizialmente, ma in questo articolo verrà descritto, esistono alcuni modi di applicazioni è possono espandere la finestra di dialogo ed eseguire il completamento delle attività e il recapito delle notifiche, anche quando non in primo piano.

Il ciclo di vita dell'applicazione

Nella tradizionale sviluppo desktop Win32 e .NET, le applicazioni sono in genere in uno dei due stati: "running" o "non è in esecuzione" e la maggior parte dei casi vengono eseguiti. Ciò potrebbe sembrare ovvio, ma si tratta di un'applicazione, ad esempio Skype o un'app di musica come Spotify di messaggistica immediata: l'utente viene avviato, non un'azione, l'invio di un messaggio o ricerca di brani musicali, quindi viene disattivato e un'altra operazione. Contempo le, Skype rimane in attesa di messaggi sono disponibili in background e Spotify mantiene la riproduzione di musica. Questo contrasta con le applicazioni moderne (ad esempio applicazioni di Windows create per il UWP), che trascorre la maggior parte del tempo in uno stato diverso in esecuzione.

App di Windows sono sempre in uno dei tre stati: in esecuzione, sospeso o non è in esecuzione, come illustrato nella Figura 1. Quando un utente avvia un'applicazione Windows, ad esempio toccando una tessera nel menu Start, l'applicazione viene attivata e passa allo stato in esecuzione. Fino a quando l'utente interagisce con l'applicazione, rimane in esecuzione. Se l'utente si sposta dell'applicazione o si riduce a icona, viene generato un evento sospeso. Si tratta di un'opportunità per l'applicazione serializzare qualsiasi stato che potrebbe essere necessario per quando ha ripreso o nuovamente attivato, ad esempio la pagina corrente dell'applicazione o dati parzialmente modulo compilato. Quando un'applicazione è in stato sospeso, il processo e i thread vengono sospesi da Windows e non può essere eseguito. Quando l'utente torna all'app, i thread dell'applicazione vengono sbloccati e l'applicazione riprende lo stato di esecuzione.

Figura 1, il ciclo di vita dell'applicazione Windows

Se un'applicazione è in stato sospeso ma le risorse utilizzate (in genere la memoria), sono necessari per qualcos'altro, ad esempio l'esecuzione di un'altra applicazione, l'applicazione viene spostato lo stato non è in esecuzione.

Dal punto di vista dell'esecuzione dell'applicazione, la differenza tra la sospensione e non è in esecuzione stati è l'applicazione può rimanere residente in memoria. Quando un'applicazione semplicemente viene sospeso, l'esecuzione è bloccata, ma tutte le informazioni sullo stato rimane in memoria. Quando un'applicazione non è in esecuzione, viene rimosso dalla memoria. Poiché nessun evento viene generato quando si sposta un'applicazione da sospeso non è in esecuzione, è importante per un'applicazione serializzare tutte le informazioni di stato che necessari dalla memoria, nel caso in cui viene nuovamente attivato da non è in esecuzione.

Figura 2 illustra quanto accade per l'utilizzo delle risorse come transizione applicazioni attraverso il ciclo di vita. Quando un'applicazione viene attivata, inizia a consumare memoria, in genere fino a raggiungere una relativamente stabile. Quando un'applicazione viene sospesa, l'utilizzo della memoria è in genere si arresta, buffer e le risorse vengono rilasciate e della CPU è pari a 0 (applicato dal sistema operativo). Quando un'applicazione da sospeso non è in esecuzione, della memoria e utilizzo della CPU andare a zero, anche in questo caso imposta dal sistema operativo.

Figura 2, il ciclo di vita dell'applicazione e l'utilizzo delle risorse

In molti sistemi desktop con grandi quantità di RAM e file di grandi dimensioni pagina, non è comune, ma non impossibile, per un'applicazione deve essere rimosso dalla memoria, ma questa transizione è molto più di frequente su dispositivi mobili e altre risorse limitate. Per questo motivo, è importante testare l'app UWP in un'ampia gamma di dispositivi. L'emulatore di Windows che viene fornito con Visual Studio può essere estremamente utile per questo oggetto. consente agli sviluppatori di dispositivi di destinazione come minimo 512MB di memoria.

Esecuzione esteso

Il ciclo di vita dell'applicazione descritto è efficiente, le applicazioni non utilizzano risorse se non sono utilizzati, ma può comportare uno scenario in cui un'applicazione che richiede non è possibile eseguire. Ad esempio, un caso di utilizzo tipico per un'applicazione di comunicazioni di social network è eseguire l'accesso e la sincronizzazione di una serie di dati nella cloud (contatti, feed, Cronologia conversazioni e così via). Con il ciclo di vita di un'applicazione di base come descritto, per scaricare i contatti, l'utente deve mantenere l'applicazione aperta e in primo piano tutto il tempo! Un altro esempio potrebbe essere un'applicazione di idoneità che deve tenere traccia di posizione di un utente o di navigazione. Non appena l'utente passa a un'applicazione diversa o inserire il dispositivo nella loro pocket, questo potrebbe non funzionare più. È necessario un meccanismo per consentire l'esecuzione di un po' più applicazioni.

La piattaforma Windows universale introduce il concetto di esecuzione esteso per questi tipi di scenari. Esistono due casi è in esecuzione esteso può essere utilizzato:

In qualsiasi momento durante l'esecuzione di regolari in primo piano, mentre l'applicazione è in esecuzione.
Dopo che l'applicazione ha ricevuto un evento di sospensione (il sistema operativo sta per spostare l'applicazione in stato di sospensione) nel gestore eventi di sospensione dell'applicazione.

Il codice per questi due casi è lo stesso, ma l'applicazione ha un comportamento leggermente differente in ognuno. Nel primo caso, l'applicazione rimane in stato di esecuzione, anche se si verifica un evento che normalmente attivano la sospensione (ad esempio, l'utente di passaggio a un'altra applicazione). L'applicazione non riceverà mai un evento di sospensione mentre è attiva l'estensione per l'esecuzione. Quando viene eliminato l'estensione, l'applicazione diventa nuovamente idoneo per la sospensione.

Nel secondo caso, l'applicazione effettua la transizione allo stato sospeso, rimarrà in stato di sospensione per il periodo dell'estensione. Una volta che scade, l'estensione per l'applicazione passa allo stato sospeso senza ulteriore notifica.

Figura 3 viene illustrato come utilizzare esecuzione esteso per estendere lo stato di uspending di un'applicazione. In primo luogo, un nuovo ExtendedExecutionSession viene creato e fornito con un motivo e una descrizione. Queste due proprietà vengono utilizzate per assegnare la risorsa corretta impostato per l'applicazione (ovvero, la quantità di memoria, CPU e il tempo di esecuzione che è consentito) e per esporre le informazioni all'utente relative alle operazioni delle applicazioni vengono eseguite in background. Quindi, l'applicazione associa un gestore di eventi di revoche di certificati, viene chiamato se Windows non supporta l'estensione, ad esempio, se un'altra attività ad alta priorità, ad esempio un'applicazione in primo piano o una chiamata in ingresso VoIP, le risorse. Infine, l'applicazione richiede l'estensione e se ha esito positivo, inizia il relativo salvataggio operazione. Se l'estensione viene negata, l'applicazione esegue un'operazione di sospensione come se non l'aveste ricevuto l'estensione, ad esempio un evento di sospensione regolari.

Figura 3 estesi l'esecuzione nel gestore OnSuspending

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
  var deferral = e.SuspendingOperation.GetDeferral();
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.SavingData;
    session.Description = "Upload Data";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied)
    {
      UploadBasicData();
    }
    // Upload Data
    var completionTime = await UploadDataAsync(session);
  }
  deferral.Complete();
}

Figura 4 viene illustrato l'impatto sul ciclo di vita app; confrontarla con Figura 2. Quando un'applicazione ottiene un evento di sospensione, inizia a rilasciare o serializzare le risorse. Se l'applicazione rileva richieda più tempo e ha un'estensione, rimane nello stato di sospensione fino a quando non viene revocato l'estensione.

Figura 4 utilizzo delle risorse durante l'esecuzione estesa

Come accennato in precedenza nel caso 2, estensione per l'esecuzione non deve necessariamente essere richiesta solo nel gestore di sospensione; può essere richiesto in qualsiasi momento mentre l'applicazione è in esecuzione. Ciò è utile per quando l'applicazione conosce in anticipo che è necessario continuare a eseguire in background, come con l'applicazione di navigazione menzionato in precedenza. Il codice è molto simile all'esempio precedente e viene visualizzato Figura 5.

Figura 5 estesi l'esecuzione durante l'esecuzione normale

private async void StartTbTNavigationSession()
{
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.LocationTracking;
    session.Description = "Turn By Turn Navigation";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied
    {
      ShowUserWarning("Background location tracking not available");
    }
    // Do Navigation
    var completionTime = await DoNavigationSessionAsync(session);
  }
}

Figura 6 viene illustrato il ciclo di vita dell'applicazione per questo scenario. Anche in questo caso, è molto simile; la differenza è che quando viene revocato l'estensione per l'esecuzione, l'applicazione verrà probabilmente rapidamente passare attraverso lo stato sospeso allo stato non è in esecuzione. Ciò accade perché, in questo caso, l'estensione in genere viene revocato solo a causa di risorse insufficienti, una situazione che può essere ridotta solo mediante il rilascio delle risorse (che è, rimuovere l'applicazione dalla memoria).

Figura 6 utilizzo delle risorse durante l'esecuzione estesa

Attività in background

Esiste un altro modo che un'applicazione può eseguire in background, ovvero come un'attività in background. Attività in background sono componenti distinti in un'applicazione che implementano l'interfaccia IBackgroundTask. Questi componenti possono essere eseguiti senza Framework dell'interfaccia utente di pesanti e in genere eseguite in un processo separato (anche se possono essere eseguiti anche in-process con l'eseguibile principale dell'applicazione).

Un'attività in background viene eseguita quando viene attivato il trigger associato. Un trigger è un evento di sistema in grado di generare e attivare un'applicazione, anche se l'applicazione non è in esecuzione. Ad esempio, può essere generato il TimeTrigger con un intervallo di tempo specifico (ad esempio, ogni 30 minuti), nel qual caso attività in background dell'applicazione potrebbe attivare ogni 30 minuti quando il trigger viene attivato. Esistono molti tipi di trigger supportati da Windows, tra cui questi tipi di trigger in background: TimeTrigger, PushNotificationTrigger, LocationTrigger, ContactStoreNotificationTrigger, BluetoothLEAdvertisementWatcherTrigger, UserPresent, InternetAvailable e PowerStateChange.

Utilizzo di un'attività in background è un processo in tre fasi: Il componente deve essere creato, quindi dichiarato nel manifesto dell'applicazione e quindi registrato in fase di esecuzione.

Attività in background vengono in genere implementate in progetti di componente Windows Runtime (WinRT) separati nella stessa soluzione del progetto dell'interfaccia utente. In questo modo l'attività in background essere attivata in un processo separato, riducendo la memoria overhead richiesta dal componente. Un'implementazione semplice di un IBackgroundTask viene visualizzata Figura 7. IBackgroundTask è una semplice interfaccia che definisce un solo metodo, eseguire. Si tratta del metodo chiamato quando viene attivato il trigger dell'attività in background. Unico parametro del metodo è un oggetto IBackgroundTaskInstance che contiene il contesto su volume activation (ad esempio, il payload di una notifica push associato o l'azione utilizzata da una notifica popup) e i gestori eventi per gestire gli eventi del ciclo di vita ad esempio l'annullamento. Quando viene completato il metodo Run, l'attività in background viene terminato. Per questo motivo, come illustrato in precedenza, il gestore di sospensione è importante utilizzare l'oggetto di rinvio (sporgente inoltre disattivare il IBackgroundTaskInstance) se il codice è asincrono.

Figura 7 BackgroundTask implementazione

public sealed class TimerTask : IBackgroundTask
{
  public void Run(IBackgroundTaskInstance taskInstance)
  {
    var deferral = taskInstance.GetDeferral();
    taskInstance.Canceled += TaskInstance_Canceled;
    await ShowToastAsync("Hello from Background Task");
    deferral.Complete();
  }
  private void TaskInstance_Canceled(IBackgroundTaskInstance sender,
    BackgroundTaskCancellationReason reason)
  {
    // Handle cancellation
    deferral.Complete();
  }
}

Nel manifesto dell'applicazione, devono essere registrate anche le attività in background. Questa registrazione indica il tipo di trigger, il punto di ingresso e l'host eseguibile dell'attività, come indicato di seguito:

<Extensions>
  <Extension Category="windows.backgroundTasks" EntryPoint="BackgroundTasks.TimerTask">
    <BackgroundTasks>
      <Task Type="timer" />
    </BackgroundTasks>
  </Extension>

Questa operazione può inoltre essere eseguita senza entrare in XML utilizzando la finestra di progettazione del manifesto incluso in Visual Studio.

Infine, l'attività deve essere registrato anche in fase di esecuzione e come illustrato nel Figura 8. Di seguito l'oggetto BackgroundTaskBuilder per registrare l'attività con un TimeTrigger che verrà attivato ogni 30 minuti, se è disponibile Internet. Questo è il tipo di trigger per le operazioni comuni come aggiornamento di un riquadro o periodicamente la sincronizzazione di piccole quantità di dati ideale.

Figura 8 registrazione di attività in Background

private void RegisterBackgroundTasks()
{
  BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
  builder.Name = "Background Test Class";
  builder.TaskEntryPoint = "BackgroundTaskLibrary.TestClass";
  IBackgroundTrigger trigger = new TimeTrigger(30, true);
  builder.SetTrigger(trigger);
  IBackgroundCondition condition =
    new SystemCondition(SystemConditionType.InternetAvailable);
  builder.AddCondition(condition);
  IBackgroundTaskRegistration task = builder.Register();
  task.Progress += new BackgroundTaskProgressEventHandler(task_Progress);
  task.Completed += new BackgroundTaskCompletedEventHandler(task_Completed);
}

Il vantaggio principale di attività in background può inoltre essere loro condanna: Poiché l'esecuzione di attività in background in background (quando l'utente potrebbe eseguire un'operazione importante in primo piano o il dispositivo è in modalità standby), sono rigorosamente limitati nella quantità di memoria e il tempo di CPU che possono utilizzare. Ad esempio, l'attività in background registrati in Figura 8 verrà eseguito solo per 30 secondi e non può utilizzare più di 16MB di memoria nei dispositivi con 512MB di memoria; ridimensionare i limiti di memoria con la quantità di memoria sul dispositivo. Per lo sviluppo e implementazione di attività in background, è importante tenere in considerazione questo. È opportuno sottoporre le attività in background su una vasta gamma di dispositivi, in particolare i dispositivi low-end, prima di pubblicare un'applicazione. Esistono un paio di altri aspetti da considerare, nonché:

Se il risparmio della batteria è disponibile e attivo (in genere quando la batteria è di sotto di una determinata soglia di costo), le attività in background è bloccate l'esecuzione fino a quando la batteria è cariche oltre la soglia di risparmio della batteria.
Nelle versioni precedenti di Windows, le applicazioni necessarie per essere "bloccato" al blocco affinché si consente di eseguire in background e, in alcuni casi, si sono verificati un numero massimo di attività in background che possono essere registrati, a livello di dispositivo. Non è più case 10 di Windows, ma un'applicazione deve sempre chiamare BackgroundExecutionManger.RequestAcessAsync per dichiarare l'intento di eseguire in background.

Un modo migliore per contattare la sincronizzazione

Esistono molte operazioni in background che possono essere completate con l'esecuzione esteso o con attività in background. In genere, si consiglia di utilizzare le attività in background, se possibile, sono più affidabile ed efficiente.

Ad esempio, lo scenario indicato in precedenza, la sincronizzazione dei dati quando il primo avvio di un'applicazione, può anche essere fatto e fatto in modo più efficiente, con un'attività in background, in questo caso utilizzando un trigger che è una novità di Windows 10: il trigger dell'applicazione.

ApplicationTrigger (ad esempio DeviceUseTrigger) appartiene a una classe speciale di trigger attivati direttamente dalla parte di primo piano dell'applicazione. Ciò avviene in modo esplicito chiamando RequestAsync sull'oggetto trigger. ApplicationTrigger è particolarmente utile per scenari in cui l'applicazione desideri avviare un'operazione in primo piano che deve continuare in base alle esigenze in background se l'applicazione non è più in primo piano e tale operazione non dipende da strettamente associato al primo piano. Di seguito viene riportato un esempio di un'attività ApplicationTrigger che può essere utilizzato al posto di esecuzione esteso per la maggior parte degli scenari:

var appTrigger = new ApplicationTrigger();
var backgroundTaskBuilder = new BackgroundTaskBuilder();
backgroundTaskBuilder.Name = "App Task";
backgroundTaskBuilder.TaskEntryPoint = typeof(AppTask).FullName;
backgroundTaskBuilder.SetTrigger(appTrigger);
backgroundTaskBuilder.Register();
var result = await appTrigger.RequestAsync();

Avvolgendo

In questo articolo viene fornita una panoramica dell'esecuzione del ciclo di vita e lo sfondo dell'applicazione in Windows 10 e introduce un paio di nuovi meccanismi che applicazioni è possono utilizzare per l'esecuzione in background: esteso le attività di esecuzione e di sfondo. Attività in background sono una scelta migliore per i dispositivi di fascia bassa e di memoria vincolata (come i telefoni), mentre l'esecuzione esteso è più appropriato per i dispositivi di fascia alta (ad esempio, PC desktop).

Shawn Henryè un Senior Program Manager del team Universal piattaforma Windows. È possibile contattarlo su Twitter: @shawnhenry.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Anis Mohammed Khaja Mohideen e Abdul Hadi Sheikh
Abdul Hadi Sheikh è uno sviluppatore Software del team di piattaforma Windows universale

Anis Mohammed Khaja Mohideen è uno sviluppatore di Software Senior del team di piattaforma Windows universale

Condividi tramite