API Siklus Proses Halaman

Philip Walton

{i>Browser<i} modern saat ini terkadang akan menangguhkan laman atau membuangnya sepenuhnya ketika resource sistem dibatasi. Di masa mendatang, browser akan melakukan ini secara proaktif, sehingga mereka memakai lebih sedikit daya dan memori. Page Lifecycle API menyediakan hook siklus proses sehingga halaman Anda dapat menangani browser ini dengan aman intervensi tanpa mempengaruhi pengalaman pengguna. Lihat API untuk melihat apakah Anda harus mengimplementasikan fitur-fitur ini dalam aplikasi Anda.

Latar belakang

Siklus hidup aplikasi adalah cara utama yang dikelola sistem operasi modern Google Cloud Platform. Di Android, iOS, dan versi Windows terbaru, aplikasi dapat dimulai dan dihentikan kapan saja oleh OS. Hal ini memungkinkan platform ini untuk menyederhanakan dan mengalokasikan ulang sumber daya ke tempat yang memberikan manfaat terbaik bagi pengguna.

Di web, secara historis tidak ada siklus proses seperti itu, dan aplikasi dapat dipertahankan hidup tanpa batas. Dengan sejumlah besar laman web yang sedang berjalan, sistem penting seperti memori, CPU, baterai, dan jaringan bisa menjadi langganan berlebihan, yang menyebabkan pengalaman pengguna akhir yang buruk.

Platform web telah lama mengalami peristiwa yang terkait dengan status siklus proses — seperti load, unload, dan visibilitychange — acara ini hanya mengizinkan developer untuk merespons perubahan status siklus proses yang dimulai oleh pengguna. Agar web dapat berfungsi andal pada perangkat bertenaga rendah (dan lebih sadar akan sumber daya secara umum semua platform) browser memerlukan cara untuk secara proaktif mengklaim kembali dan mengalokasikan ulang sistem Google Cloud Platform.

Faktanya, browser saat ini sudah mengambil tindakan aktif untuk menghemat resource untuk halaman di tab latar belakang, dan banyak browser (terutama Chrome) yang menginginkan untuk melakukan lebih banyak hal ini — untuk mengurangi jejak resource mereka secara keseluruhan.

Masalahnya, pengembang tidak memiliki cara untuk mempersiapkan diri menghadapi jenis intervensi yang dimulai oleh sistem atau bahkan mengetahui bahwa itu sedang terjadi. Artinya browser harus konservatif atau berisiko merusak laman web.

Page Lifecycle API mencoba memecahkan masalah ini dengan:

• Memperkenalkan dan menstandardisasi konsep status siklus proses di web.
• Mendefinisikan status baru yang dimulai oleh sistem yang memungkinkan browser membatasi yang dapat dipakai oleh tab tersembunyi atau tidak aktif.
• Membuat API dan peristiwa baru yang memungkinkan developer web merespons bertransisi ke dan dari status yang dimulai oleh sistem ini.

Solusi ini memberikan prediktabilitas yang dibutuhkan developer web untuk membangun lebih tangguh terhadap intervensi sistem, dan memungkinkan browser untuk lebih mengoptimalkan resource sistem secara agresif, yang pada akhirnya menguntungkan semua pengguna web.

Bagian selanjutnya dari postingan ini akan memperkenalkan fitur Siklus Proses Halaman yang baru dan mengeksplorasi bagaimana mereka berhubungan dengan semua status platform web yang ada dan peristiwa. Dasbor ini juga akan memberikan rekomendasi dan praktik terbaik untuk jenis pekerjaan yang seharusnya (dan tidak boleh) dilakukan pengembang di setiap negara bagian.

Ringkasan status dan peristiwa Siklus Proses Halaman

Semua status Siklus Proses Halaman bersifat terpisah dan sama-sama bersifat eksklusif, artinya halaman hanya bisa berada dalam satu keadaan dalam satu waktu. Dan sebagian besar perubahan pada status siklus proses halaman umumnya dapat diamati melalui peristiwa DOM (lihat rekomendasi developer untuk setiap status untuk pengecualian).

Mungkin cara termudah untuk menjelaskan status Siklus Proses Halaman — serta peristiwa yang menandakan transisi di antaranya — adalah dengan diagram:

Negara bagian

Tabel berikut menjelaskan setiap status secara mendetail. Kolom ini juga mencantumkan kemungkinan yang bisa muncul sebelum dan sesudah serta peristiwa yang dapat developer gunakan untuk mengamati perubahan.

Acara

Browser mengirim banyak peristiwa, tetapi hanya sebagian kecil yang menandakan kemungkinan perubahan status Siklus Proses Halaman. Tabel berikut menguraikan semua peristiwa yang berkaitan dengan siklus proses dan berisi daftar status yang dapat menjadi tujuan transisi mereka.

* Menunjukkan peristiwa baru yang ditentukan oleh Page Lifecycle API

Fitur baru yang ditambahkan di Chrome 68

Diagram sebelumnya menunjukkan dua status yang dimulai oleh sistem, bukan dimulai oleh pengguna: dibekukan dan dihapus. Seperti yang disebutkan sebelumnya, browser saat ini terkadang membekukan dan membuang tab tersembunyi (sesuai pertimbangan mereka), tetapi developer tidak dapat mengetahui kapan hal ini sedang terjadi.

Di Chrome 68, developer kini dapat mengamati saat tab tersembunyi dibekukan dan diproses kembali dengan memproses freeze dan peristiwa resume pada document.

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

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

Dari Chrome 68, objek document kini menyertakan wasDiscarded di Chrome desktop (dukungan Android dilacak dalam masalah ini). Untuk menentukan apakah halaman dihapus saat berada di browser tersembunyi , Anda dapat memeriksa nilai properti ini pada waktu pemuatan halaman (catatan: halaman yang dihapus harus dimuat ulang agar dapat digunakan lagi).

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

Untuk saran tentang hal-hal penting yang perlu dilakukan di freeze dan resume peristiwa, serta cara menangani dan mempersiapkan laman yang dihapus, lihat rekomendasi developer untuk setiap negara bagian.

Beberapa bagian selanjutnya menawarkan ikhtisar tentang bagaimana fitur-fitur baru ini sesuai dengan status dan peristiwa platform web yang ada.

Cara mengamati status Siklus Proses Halaman dalam kode

Dalam mode active, pasif, dan hidden status, Anda dapat menjalankan kode JavaScript yang menentukan Status Siklus Proses Halaman dari API platform web yang ada.

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

Status beku dan dihentikan, di sisi lain, hanya dapat dideteksi di pemroses peristiwanya masing-masing (freeze dan pagehide) sebagaimana negara bagian berganti.

Cara mengamati perubahan status

Dengan menggunakan fungsi getState() yang ditentukan sebelumnya, Anda dapat mengamati semua Halaman Status siklus proses berubah dengan kode berikut.

// 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);

Kode ini melakukan tiga hal:

• Menetapkan status awal menggunakan fungsi getState().
• Menentukan fungsi yang menerima status berikutnya dan, jika terjadi perubahan, mencatat perubahan status ke konsol.
• Penambahan mengambil foto pemroses peristiwa untuk semua peristiwa siklus proses yang diperlukan, yang akan memanggil logStateChange(), yang meneruskan status berikutnya.

Satu hal yang perlu diperhatikan tentang kode ini adalah semua pemroses peristiwa ditambahkan ke window dan semuanya lulus {capture: true}. Ada beberapa alasan:

• Tidak semua peristiwa Siklus Proses Halaman memiliki target yang sama. pagehide, dan pageshow diaktifkan pada window; visibilitychange, freeze, dan resume diaktifkan pada document, dan focus serta blur diaktifkan pada elemen DOM masing-masing.
• Sebagian besar peristiwa ini tidak muncul sebagai balon, sehingga tidak mungkin untuk ditambahkan pemroses peristiwa non-capturing ke elemen ancestor umum dan mengamati semua tersebut lebih mendalam.
• Fase pengambilan gambar dijalankan sebelum fase target atau balon, jadi menambahkan pemroses di sana memastikannya berjalan sebelum kode lain dapat membatalkannya.

Rekomendasi developer untuk setiap negara bagian

Sebagai developer, penting untuk memahami status Siklus Proses Halaman dan tahu cara mengamatinya dalam kode karena jenis pekerjaan yang harus Anda (dan harus tidak) sangat bergantung pada status halaman Anda.

Misalnya, tidak masuk akal untuk menampilkan notifikasi sementara kepada pengguna jika halaman dalam status tersembunyi. Meskipun contoh ini cukup jelas, ada rekomendasi lain yang tidak begitu jelas namun bernilai melakukan penghitungan.

Sekali lagi, karena keandalan dan pengurutan peristiwa siklus proses diterapkan secara konsisten di semua browser, cara termudah untuk mengikuti saran pada tabel adalah dengan menggunakan PageLifecycle.js.

API siklus proses lama yang harus dihindari

Hal-hal berikut sebaiknya dihindari sebisa mungkin.

Peristiwa penghapusan muatan

Banyak developer memperlakukan peristiwa unload sebagai callback yang dijamin dan menggunakannya sebagai sinyal akhir sesi untuk menyimpan status dan mengirim data analisis, tetapi melakukan hal ini sangat tidak dapat diandalkan, terutama di perangkat seluler! Peristiwa unload tidak aktif dalam berbagai situasi penghapusan muatan yang biasa, termasuk menutup tab dari tab pengalih di perangkat seluler atau menutup aplikasi browser dari pengalih aplikasi.

Karena alasan ini, lebih baik untuk mengandalkan Peristiwa visibilitychange untuk menentukan waktu sesi berakhir, dan anggap status tersembunyi waktu terakhir yang dapat diandalkan untuk menyimpan data aplikasi dan pengguna.

Selain itu, keberadaan pengendali peristiwa unload terdaftar (melalui onunload atau addEventListener()) dapat mencegah browser dapat untuk menempatkan halaman dalam back/forward cache agar lebih cepat muatan mundur dan maju.

Dalam semua browser modern, disarankan untuk selalu menggunakan Peristiwa pagehide untuk mendeteksi kemungkinan penghapusan muatan halaman (alias status dihentikan), bukan peristiwa unload. Jika Anda mendukung Internet Explorer versi 10 dan yang lebih rendah, Anda harus menyertakan mendeteksi peristiwa pagehide dan hanya menggunakan unload jika browser tidak mendukung 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.
});

Peristiwa beforeunload

Peristiwa beforeunload memiliki masalah yang serupa dengan peristiwa unload. secara historis, keberadaan peristiwa beforeunload dapat mencegah halaman untuk memenuhi syarat untuk back/forward cache. Browser modern tidak memiliki batasan ini. Meskipun beberapa browser, sebagai tindakan pencegahan, tidak akan diaktifkan peristiwa beforeunload saat mencoba menempatkan halaman ke dalam mode back/forward {i>cache<i}, yang berarti bahwa peristiwa tersebut tidak dapat diandalkan sebagai sinyal akhir sesi. Selain itu, beberapa browser (termasuk Chrome) memerlukan interaksi pengguna di halaman sebelum mengizinkan peristiwa beforeunload terbakar, sehingga akan mempengaruhi keandalannya.

Satu perbedaan antara beforeunload dan unload adalah bahwa ada penggunaan yang sah atas beforeunload. Misalnya, ketika Anda ingin memperingatkan pengguna bahwa ada perubahan yang belum disimpan yang akan hilang jika mereka terus membongkar halaman.

Karena ada alasan yang valid untuk menggunakan beforeunload, sebaiknya Anda hanya menambahkan pemroses beforeunload saat pengguna memiliki perubahan yang belum disimpan, lalu menghapusnya segera setelah disimpan.

Dengan kata lain, jangan lakukan ini (karena akan menambahkan pemroses beforeunload tanpa syarat):

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);
  }
});

Sebagai gantinya, lakukan ini (karena hanya menambahkan pemroses beforeunload saat diperlukan, dan menghapusnya jika tidak):

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);
});

FAQ

Mengapa tidak ada "memuat" negara bagian?

Page Lifecycle API mendefinisikan status menjadi diskret dan saling eksklusif. Karena suatu halaman dapat dimuat dalam status aktif, pasif, atau tersembunyi, dan karena dapat mengubah status—atau bahkan dihentikan—sebelum selesai dimuat, status pemuatan terpisah tidak masuk akal dalam paradigma ini.

Halaman saya berfungsi penting jika disembunyikan, bagaimana cara agar halaman tidak dibekukan atau dihapus?

Ada banyak alasan sah agar halaman web tidak dibekukan saat dijalankan dalam status tersembunyi. Contoh yang paling jelas adalah aplikasi yang memutar musik.

Ada situasi di mana Chrome akan berisiko menghapus sebuah halaman, seperti jika file berisi formulir dengan input pengguna yang belum dikirim, atau jika Pengendali beforeunload yang memperingatkan saat halaman menghapus muatan.

Untuk saat ini, Chrome akan bersikap konservatif saat membuang halaman dan lakukan hanya jika yakin bahwa hal tersebut tidak akan memengaruhi pengguna. Misalnya, halaman yang telah diamati untuk melakukan salah satu dari hal berikut sementara dalam status tersembunyi tidak akan dibuang kecuali dalam kendala sumber daya yang ekstrem:

• Memutar audio
• Menggunakan WebRTC
• Memperbarui judul tabel atau favicon
• Menampilkan peringatan
• Mengirim notifikasi push

Untuk fitur daftar saat ini yang digunakan untuk menentukan apakah tab dapat aman dibekukan atau dibuang, lihat: Heuristik untuk Pembekuan & Menghapus di Chrome.

Apa itu back-forward cache?

Back/forward cache adalah istilah yang digunakan untuk menggambarkan pengoptimalan navigasi yang diterapkan beberapa browser, yang memanfaatkan tombol maju lebih cepat.

Saat pengguna keluar dari halaman, browser ini membekukan versi tersebut sehingga dapat dilanjutkan dengan cepat jika pengguna kembali menggunakan tombol kembali atau maju. Perlu diingat bahwa menambahkan unload pengendali peristiwa mencegah pengoptimalan ini.

Untuk semua maksud dan tujuan, pembekuan ini secara fungsional sama dengan browser yang membeku dilakukan untuk menghemat CPU/baterai; untuk alasan tersebut dianggap sebagai bagian dari status siklus proses yang dibekukan.

Jika saya tidak dapat menjalankan API asinkron dalam status terhenti atau dihentikan, bagaimana cara menyimpan data ke IndexedDB?

Dalam status dibekukan dan dihentikan, tugas yang dapat dibekukan di task queue halaman ditangguhkan, yang berarti API asinkron dan berbasis callback seperti tensorflow tidak dapat digunakan dengan andal.

Di masa mendatang, kita akan menambahkan metode commit() ke objek IDBTransaction, yang akan memberi pengembang cara untuk melakukan apa yang secara efektif merupakan transaksi hanya-tulis yang tidak memerlukan callback. Dengan kata lain, jika pengembang hanya menulis data kepada tensorflow dan tidak melakukan transaksi yang kompleks yang terdiri atas pembacaan dan penulisan, metode commit() dapat selesai sebelum task queue ditangguhkan (dengan asumsi database IndexedDB sudah terbuka).

Namun, untuk kode yang harus berfungsi saat ini, developer memiliki dua opsi:

• Menggunakan Penyimpanan Sesi: Penyimpanan Sesi bersifat sinkron dan dipertahankan di seluruh penghapusan halaman.
• Menggunakan IndexedDB dari pekerja layanan Anda: pekerja layanan dapat menyimpan data di AlarmManager setelah halaman dihentikan atau dihapus. Di freeze atau Dengan pemroses peristiwa pagehide, Anda dapat mengirim data ke pekerja layanan melalui postMessage(), dan pekerja layanan dapat menangani penyimpanan data.

Menguji aplikasi Anda dalam status dibekukan dan dihapus

Untuk menguji perilaku aplikasi Anda dalam status dibekukan dan dihapus, Anda dapat mengunjungi chrome://discards untuk benar-benar membekukan atau menghapus membuka tab.

Hal ini memungkinkan Anda memastikan halaman menangani freeze dan resume dengan benar peristiwa serta flag document.wasDiscarded saat halaman dimuat ulang dibuang.

Ringkasan

Developer yang ingin menghormati resource sistem perangkat pengguna mereka harus membangun aplikasi mereka dengan mempertimbangkan status Siklus Proses Halaman. Sangat penting untuk halaman web tidak memakai sumber daya sistem yang berlebihan dalam situasi yang yang tidak diharapkan pengguna

Makin banyak developer yang mulai mengimplementasikan Page Lifecycle API yang baru, makin aman API ini agar browser membeku dan menghapus halaman yang tidak digunakan. Ini berarti browser akan menggunakan lebih sedikit memori, CPU, baterai, dan sumber daya jaringan, yang menguntungkan pengguna.