API Page Lifecycle

Philip Walton

I browser moderni odierni a volte sospenderanno o eliminano del tutto le pagine quando risorse di sistema sono limitate. In futuro, i browser vorranno farlo in modo proattivo, riducendo il consumo di energia e memoria. L'API Page Lifecycle fornisce hook del ciclo di vita in modo che le pagine possano gestire in sicurezza senza influire sull'esperienza utente. Dai un'occhiata all'API per per vedere se devi implementare queste funzioni nella tua applicazione.

Sfondo

Il ciclo di vita dell'applicazione è un modo chiave gestito dai sistemi operativi moderni Google Cloud. Su Android, iOS e versioni recenti di Windows, le app possono essere avviate e in qualsiasi momento dal sistema operativo. Ciò consente a queste piattaforme di semplificare e riallocare le risorse nel momento in cui apportano maggiori vantaggi all'utente.

Sul web storicamente non esiste un ciclo di vita di questo tipo e le app possono essere mantenute. vivi a tempo indeterminato. Con un gran numero di pagine web in esecuzione, è fondamentale di risorse come memoria, CPU, batteria e rete possono superare la sottoscrizione, a un'esperienza negativa per l'utente finale.

Sebbene la piattaforma web abbia da tempo eventi correlati agli stati del ciclo di vita ad esempio load, unload e visibilitychange , questi eventi consentono solo agli sviluppatori per rispondere alle modifiche dello stato del ciclo di vita avviate dall'utente. Affinché il web funzioni in modo affidabile sui dispositivi a basso consumo (ed essere più attenti alle risorse in generale tutte le piattaforme) i browser necessitano di un modo per recuperare e riallocare proattivamente Google Cloud.

Infatti, oggi i browser adottano già misure attive per risparmiare risorse per le pagine nelle schede in background e molti browser (soprattutto Chrome) vorrebbero per fare molto di più, per ridurre l'utilizzo complessivo delle risorse.

Il problema è che gli sviluppatori non hanno modo di prepararsi a questo tipo di avviati dal sistema o persino sapere che stanno accadendo. Ciò significa i browser devono essere conservativi o rischiano di compromettere le pagine web.

L'API Page Lifecycle prova a risolvere il problema:

• Presentazione e standardizzazione del concetto di stati del ciclo di vita sul web.
• La definizione di nuovi stati avviati dal sistema che consentano ai browser di limitare la risorse utilizzabili da schede nascoste o non attive.
• Creazione di nuove API ed eventi che consentono agli sviluppatori web di rispondere transizioni da e verso questi nuovi stati avviati dal sistema.

Questa soluzione offre la prevedibilità di cui gli sviluppatori web hanno bisogno per creare resilienti agli interventi del sistema e consente ai browser di ottimizzare in modo massiccio le risorse di sistema, a beneficio di tutti gli utenti web.

Il resto di questo post introdurrà le nuove funzionalità del ciclo di vita delle pagine ed esplorare come si relazionano con tutti gli stati esistenti delle piattaforme web. ed eventi. Fornirà inoltre consigli e best practice per i tipi del lavoro che gli sviluppatori dovrebbero (e non dovrebbero) svolgere in ogni stato.

Panoramica di stati ed eventi del ciclo di vita delle pagine

Tutti gli stati del ciclo di vita della pagina sono discreti e si escludono a vicenda, il che significa che una pagina può essere in un solo stato alla volta. La maggior parte delle modifiche allo stato del ciclo di vita di una pagina sono generalmente osservabili tramite eventi DOM (per le eccezioni, leggi i consigli per gli sviluppatori per ogni stato).

Forse il modo più semplice per spiegare gli stati del ciclo di vita della pagina, gli eventi che segnalano transizioni tra di loro, è rappresentato da un diagramma:

Stati

La tabella seguente spiega ogni stato in dettaglio. Elenca anche le possibili gli stati che possono precedere e dopo gli eventi, nonché gli eventi che gli sviluppatori per osservare i cambiamenti.

Eventi

I browser inviano molti eventi, ma solo una piccola parte di essi segnala una possibile modifica allo stato del ciclo di vita della pagina. La tabella seguente illustra tutti gli eventi che riguardano il ciclo di vita ed elenca gli stati da cui possono effettuare la transizione.

* Indica un nuovo evento definito dall'API Page Lifecycle

Nuove funzionalità aggiunte in Chrome 68

Il grafico precedente mostra due stati avviati dal sistema anziché avviato dall'utente: bloccato e ignorato. Come accennato in precedenza, oggi i browser si bloccano e ignorano schede nascoste (a loro discrezione), ma gli sviluppatori non hanno modo di sapere quando in cui la situazione sta accadendo.

In Chrome 68, gli sviluppatori possono ora osservare quando una scheda nascosta si blocca sbloccato ascoltando freeze e resume il giorno document.

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

In Chrome 68, l'oggetto document ora include un oggetto wasDiscarded su Chrome desktop (l'assistenza Android è monitorata in questo problema). Per determinare se una pagina è stata eliminata in un ambiente nascosto , puoi controllare il valore di questa proprietà al momento del caricamento della pagina (nota: le pagine eliminate devono essere ricaricate per poter essere riutilizzate).

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

Per consigli sulle cose importanti da fare in freeze e resume nonché la gestione e la preparazione per le pagine eliminate, consulta consigli per gli sviluppatori in ogni stato.

Le prossime sezioni forniscono una panoramica di come queste nuove funzioni si inseriscono gli stati e gli eventi della piattaforma web esistente.

Come osservare gli stati del ciclo di vita della pagina nel codice

Nei campi attivi, passivi e nascosti stati, è possibile eseguire codice JavaScript che determina lo stato Stato del ciclo di vita della pagina dalle API della piattaforma web esistenti.

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

Gli stati bloccato e terminato nella dall'altro lato, possono essere rilevati solo nel rispettivo listener di eventi (freeze e pagehide) perché lo stato è cambiare.

Come osservare i cambiamenti di stato

Basandoti sulla funzione getState() definita in precedenza, puoi osservare tutte le metriche Pagina Lo stato del ciclo di vita cambia con il codice seguente.

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

Questo codice fa tre cose:

• Imposta lo stato iniziale utilizzando la funzione getState().
• Definisce una funzione che accetta uno stato successivo e, in caso di modifica, registra le modifiche dello stato nella console.
• Aggiunge scattare per tutti gli eventi necessari del ciclo di vita, che a loro volta richiamano logStateChange(), passa allo stato successivo.

Una cosa da notare sul codice è che tutti i listener di eventi vengono aggiunti a window e passano tutti {capture: true} Ecco alcuni dei motivi:

• Non tutti gli eventi del ciclo di vita della pagina hanno lo stesso target. pagehide e pageshow sono stati attivati il giorno window; visibilitychange, freeze e resume vengono attivati il giorno document, mentre focus e blur vengono attivati sul relativo i rispettivi elementi DOM.
• La maggior parte di questi eventi non mostra le bolle, il che significa che è impossibile aggiungere listener di eventi non acquisibili in un elemento predecessore comune e osservare tutti alcune.
• La fase di cattura viene eseguita prima delle fasi target o a bolle, quindi aggiungendo aiuta ad assicurarsi che vengano eseguiti prima che altro codice possa annullarli.

Consigli per gli sviluppatori per ogni stato

In qualità di sviluppatori, è importante comprendere gli stati del ciclo di vita delle pagine e sapere come osservarle nel codice perché il tipo di lavoro che dovreste (e non) dipende in gran parte dallo stato della pagina.

Ad esempio, è chiaro che non ha senso visualizzare una notifica transitoria. all'utente se la pagina è nascosta. Sebbene questo esempio sia ovvio, ci sono altri consigli non così evidenti che vale la pena enumerazione.

Ancora una volta, poiché l'affidabilità e l'ordine degli eventi del ciclo di vita costantemente implementato in tutti i browser, il modo più semplice per seguire i consigli nella tabella è l'utilizzo PageLifecycle.js.

API del ciclo di vita legacy da evitare

Se possibile, evita i seguenti eventi.

Evento unload

Molti sviluppatori considerano l'evento unload un callback garantito e lo usano come un indicatore di fine sessione per salvare lo stato e inviare i dati di analisi, è estremamente inaffidabile, soprattutto sui dispositivi mobili. L'evento unload non si attivano in molte situazioni tipiche di unload, inclusa la chiusura di una scheda dalla scheda selettore su dispositivo mobile o chiudendo l'app del browser dal selettore di app.

Per questo motivo, è sempre meglio fare affidamento visibilitychange per determinare quando una sessione e considera lo stato nascosto l'ultima volta in cui puoi risparmiare dati utente e dell'app.

Inoltre, la sola presenza di un gestore di eventi unload registrato (tramite onunload o addEventListener()) può impedire ai browser di inserire le pagine nella cache back/forward in modo da velocizzare per i caricamenti avanti e indietro.

In tutti i browser moderni, si consiglia di utilizzare sempre pagehide per rilevare possibili unload di pagine (ovvero il chiuso) anziché l'evento unload. Se deve supportare Internet Explorer 10 e versioni precedenti, rilevare l'evento pagehide e usare unload solo se il browser non supporta pagehide:

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

L'evento beforeunload

L'evento beforeunload ha un problema simile all'evento unload, in quanto: storicamente, la presenza di un evento beforeunload potrebbe impedire alle pagine di essere idonei per la cache back/forward. Browser moderni non presentano questa restrizione. Anche se alcuni browser, per precauzione, non si attivano l'evento beforeunload quando tenti di inserire una pagina nel back-forward Cache, il che significa che l'evento non è affidabile come indicatore di fine sessione. Inoltre, alcuni browser (tra cui Chrome) richiedi un'interazione dell'utente sulla pagina prima di consentire l'evento beforeunload in modo che si attivi, influenzando ulteriormente la sua affidabilità.

Una differenza tra beforeunload e unload è che ci sono usi legittimi di beforeunload. Ad esempio, quando vuoi avvisare l'utente che hanno modifiche non salvate che perderanno se continuano a scaricare la pagina.

Poiché esistono motivi validi per utilizzare beforeunload, ti consigliamo di: aggiungi solo listener beforeunload quando un utente ha modifiche non salvate e poi li rimuovi subito dopo il salvataggio.

In altre parole, non farlo (perché aggiunge un listener beforeunload) incondizionatamente):

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    return (event.returnValue = true);
  }
});

In questo modo, viene aggiunto il listener beforeunload solo quando necessario e la rimuove quando non è presente):

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

Domande frequenti

Perché non è disponibile un caricamento in corso... ?

L'API Page Lifecycle definisce gli stati come discreti e che si escludono a vicenda. Poiché una pagina può essere caricata in stato attivo, passivo o nascosto, poiché può cambiare stato (o persino essere terminato) prima che venga completato il caricamento, uno stato di caricamento separato non ha senso all'interno di questo paradigma.

La mia pagina svolge operazioni importanti quando è nascosta. Come posso evitare che venga bloccata o eliminata?

Esistono molti motivi legittimi per cui le pagine web non dovrebbero essere bloccate durante l'esecuzione nello stato nascosto. L'esempio più ovvio è un'app che riproduce musica.

Ci sono anche situazioni in cui Chrome potrebbe essere rischioso scartare una pagina, ad esempio se contiene un modulo con input utente non inviato o se presenta Gestore beforeunload che avvisa quando è in corso l'unload della pagina.

Per il momento, Chrome adotta un approccio conservativo quando scarta le pagine e fallo solo quando hai la certezza che non avrà effetti sugli utenti. Ad esempio, le pagine che che è stato osservato esegue una delle seguenti azioni mentre lo stato nascosto non a meno che non si tratti di vincoli estremi per le risorse:

• Riproduzione dell'audio
• Utilizzo di WebRTC
• Aggiornamento del titolo o della favicon della tabella
• Visualizzazione degli avvisi
• Invio di notifiche push

Per le funzionalità dell'elenco corrente utilizzate per determinare se una scheda può essere sicura congelati o eliminati, consulta: Euristica per il congelamento e la Annullamento in corso... in Chrome.

Che cos'è la cache back-forward?

La cache back/forward è un termine utilizzato per descrivere un dell'ottimizzazione della navigazione implementata da alcuni browser che consente di utilizzare i pulsanti Avanti più velocemente.

Quando un utente esce da una pagina, questi browser bloccano una versione della pagina in modo da poterla riprendere rapidamente nel caso in cui l'utente ritorni utilizzando i pulsanti Indietro o Avanti. Ricorda che l'aggiunta di un unload gestore di eventi impedisce la possibilità di questa ottimizzazione.

A tutti gli effetti, questo blocco è funzionalmente uguale il blocco dei browser permette di risparmiare CPU/batteria; per questo motivo sono considerati parte del ciclo di vita bloccato.

Se non posso eseguire API asincrone negli stati bloccati o terminati, come posso salvare i dati in IndexedDB?

Negli stati bloccati e terminati, attività bloccabili nelle code di attività di una pagina sono sospese, il che significa API asincrone e basate su callback come IndexedDB non possono essere utilizzati in modo affidabile.

In futuro, aggiungeremo un metodo commit() agli oggetti IDBTransaction, in modo da offrono agli sviluppatori un modo per eseguire effettivamente transazioni di sola scrittura che non richiedono callback. In altre parole, se lo sviluppatore scrive di dati in IndexedDB e non esegue una transazione complessa costituita da letture e scritture, il metodo commit() potrà terminare prima che le code di attività vengano sospeso (supponendo che il database IndexedDB sia già aperto).

Tuttavia, per il codice che deve funzionare al momento, gli sviluppatori hanno due opzioni:

• Utilizza Spazio di archiviazione di sessione: Spazio di archiviazione di sessione è sincrona ed è persistente in tutti gli scarti della pagina.
• Utilizza IndexedDB del tuo service worker: un service worker può archiviare dati in IndexedDB dopo che la pagina è stata terminata o eliminata. Nell'freeze o Listener di eventi pagehide con cui puoi inviare dati al Service worker tramite postMessage(), e il service worker può gestire il salvataggio dei dati.

Test dell'app in stato bloccato e eliminato

Per testare il comportamento della tua app nello stato bloccato e ignorato, puoi visitare la pagina chrome://discards per bloccare o eliminare effettivamente i tuoi schede aperte.

In questo modo puoi assicurarti che la tua pagina gestisca correttamente freeze e resume eventi e il flag document.wasDiscarded quando le pagine vengono ricaricate dopo uno scarto.

Riepilogo

Sviluppatori che vogliono rispettare le risorse di sistema dei dispositivi dei loro utenti devono creare le proprie app tenendo presenti gli stati del ciclo di vita delle pagine. È fondamentale che le pagine web non consumano risorse di sistema eccessive in situazioni l'utente non si aspetta

Più sviluppatori iniziano a implementare le nuove API del ciclo di vita delle pagine, più sono sicure consente ai browser di bloccare e ignorare le pagine non utilizzate. Questo significa che i browser consumeranno meno memoria, CPU, batteria e risorse di rete, il che è un vantaggio per gli utenti.