Page Lifecycle API

Philip Walton

مرورگرهای مدرن امروزی گاهی اوقات صفحات را به حالت تعلیق در می آورند یا در صورت محدود بودن منابع سیستم به طور کامل آنها را کنار می گذارند. در آینده، مرورگرها می خواهند این کار را فعالانه انجام دهند، بنابراین انرژی و حافظه کمتری مصرف می کنند. Page Lifecycle API قلاب‌های چرخه حیات را فراهم می‌کند تا صفحات شما بتوانند با خیال راحت این مداخلات مرورگر را بدون تأثیر بر تجربه کاربر انجام دهند. نگاهی به API بیندازید تا ببینید آیا باید این ویژگی ها را در برنامه خود پیاده سازی کنید یا خیر.

پس زمینه

چرخه عمر برنامه یک راه کلیدی برای مدیریت منابع سیستم عامل های مدرن است. در اندروید، iOS و نسخه‌های اخیر ویندوز، برنامه‌ها را می‌توان در هر زمانی که بخواهید توسط سیستم عامل راه‌اندازی و متوقف کرد. این به این پلتفرم‌ها اجازه می‌دهد منابع را در جایی که به بهترین وجه برای کاربر مفید هستند، ساده‌سازی و تخصیص مجدد دهند.

در وب، از لحاظ تاریخی چنین چرخه حیاتی وجود نداشته است و برنامه ها را می توان به طور نامحدود زنده نگه داشت. با تعداد زیادی از صفحات وب در حال اجرا، منابع حیاتی سیستم مانند حافظه، CPU، باتری و شبکه می توانند بیش از حد اشتراک داشته باشند که منجر به تجربه بد کاربر نهایی می شود.

در حالی که پلتفرم وب مدت‌هاست که رویدادهایی مرتبط با وضعیت‌های چرخه حیات دارد - مانند load ، unload ، و visibilitychange - این رویدادها فقط به توسعه‌دهندگان اجازه می‌دهند تا به تغییرات وضعیت چرخه عمر آغاز شده توسط کاربر پاسخ دهند. برای اینکه وب به طور قابل اعتماد بر روی دستگاه‌های کم مصرف کار کند (و به طور کلی در همه پلتفرم‌ها از منابع آگاه‌تر باشد)، مرورگرها به راهی برای بازیابی فعال و تخصیص مجدد منابع سیستم نیاز دارند.

در واقع، امروزه مرورگرها اقدامات فعالی را برای حفظ منابع برای صفحات در برگه‌های پس‌زمینه انجام می‌دهند، و بسیاری از مرورگرها (مخصوصا کروم) مایلند کارهای بیشتری از این کار انجام دهند - تا ردپای کلی منابع خود را کاهش دهند.

مشکل این است که توسعه دهندگان راهی برای آماده شدن برای این نوع مداخلات آغاز شده توسط سیستم ندارند یا حتی می دانند که آنها در حال وقوع هستند. این بدان معناست که مرورگرها باید محافظه کار باشند یا در خطر شکستن صفحات وب هستند.

Page Lifecycle API سعی می کند این مشکل را با استفاده از موارد زیر حل کند:

• معرفی و استانداردسازی مفهوم حالت های چرخه حیات در وب.
• تعریف حالت‌های جدید و شروع‌شده توسط سیستم که به مرورگرها اجازه می‌دهد منابعی را که می‌توانند توسط برگه‌های مخفی یا غیرفعال مصرف می‌شوند، محدود کنند.
• ایجاد APIها و رویدادهای جدید که به توسعه دهندگان وب اجازه می دهد به انتقال به و از این حالت های جدید شروع شده توسط سیستم پاسخ دهند.

این راه حل قابلیت پیش بینی نیاز توسعه دهندگان وب را برای ساخت برنامه های کاربردی مقاوم در برابر مداخلات سیستمی را فراهم می کند و به مرورگرها اجازه می دهد تا منابع سیستم را با شدت بیشتری بهینه کنند و در نهایت به نفع همه کاربران وب باشد.

بقیه این پست ویژگی های جدید چرخه حیات صفحه را معرفی می کند و چگونگی ارتباط آنها با تمام وضعیت ها و رویدادهای پلت فرم وب موجود را بررسی می کند. همچنین توصیه‌ها و بهترین روش‌ها را برای انواع کارهایی که توسعه‌دهندگان باید (و نباید) در هر ایالت انجام دهند، ارائه می‌دهد.

مروری بر وضعیت ها و رویدادهای چرخه عمر صفحه

همه حالت‌های چرخه عمر صفحه گسسته و متقابلاً انحصاری هستند، به این معنی که یک صفحه در یک زمان فقط می‌تواند در یک حالت باشد. و اکثر تغییرات در حالت چرخه عمر صفحه عموماً از طریق رویدادهای DOM قابل مشاهده است (به توصیه های توسعه دهنده برای هر حالت برای موارد استثنا مراجعه کنید).

شاید ساده‌ترین راه برای توضیح حالت‌های چرخه عمر صفحه - و همچنین رویدادهایی که سیگنال انتقال بین آنها را نشان می‌دهند - با یک نمودار باشد:

ایالات

جدول زیر هر حالت را به تفصیل توضیح می دهد. همچنین حالت‌های احتمالی را که می‌توانند قبل و بعد از آن بیایند و همچنین رویدادهایی که توسعه‌دهندگان می‌توانند برای مشاهده تغییرات استفاده کنند، فهرست می‌کند.

رویدادها

مرورگرها رویدادهای زیادی را ارسال می کنند، اما تنها بخش کوچکی از آنها تغییر احتمالی در وضعیت چرخه عمر صفحه را نشان می دهد. جدول زیر تمام رویدادهایی را که به چرخه حیات مربوط می‌شوند را نشان می‌دهد و فهرستی از حالت‌هایی که ممکن است به و از چه حالت‌هایی منتقل شوند را نشان می‌دهد.

* یک رویداد جدید را نشان می دهد که توسط صفحه Lifecycle API تعریف شده است

ویژگی های جدید اضافه شده در کروم 68

نمودار قبلی دو حالت را نشان می‌دهد که به جای شروع توسط کاربر، توسط سیستم راه‌اندازی شده‌اند: منجمد و دور انداخته شده . همانطور که قبلاً ذکر شد، امروزه مرورگرها گاهی اوقات برگه های مخفی را (به صلاحدید خود) مسدود می کنند و دور می اندازند، اما توسعه دهندگان راهی برای اطلاع از زمان وقوع این اتفاق ندارند.

در Chrome 68، توسعه‌دهندگان اکنون می‌توانند با گوش دادن به freeze و resume رویدادها در document ، مشاهده کنند که یک برگه مخفی ثابت و غیر منجمد می‌شود.

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

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

از Chrome 68 شی document اکنون شامل یک ویژگی wasDiscarded در کروم دسکتاپ است ( پشتیبانی از Android در این شماره ردیابی می شود ). برای تعیین اینکه آیا یک صفحه زمانی که در یک برگه مخفی است کنار گذاشته شده است یا خیر، می توانید مقدار این ویژگی را در زمان بارگذاری صفحه بررسی کنید (توجه داشته باشید: برای استفاده مجدد، صفحات حذف شده باید دوباره بارگیری شوند).

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

برای مشاوره در مورد کارهایی که در freeze و resume رویدادها مهم هستند، و همچنین نحوه مدیریت و آماده شدن برای صفحاتی که دور ریخته می شوند، توصیه های برنامه نویس برای هر ایالت را ببینید.

چندین بخش بعدی یک نمای کلی از نحوه تناسب این ویژگی های جدید با وضعیت ها و رویدادهای پلت فرم وب موجود ارائه می دهد.

نحوه مشاهده حالتهای چرخه عمر صفحه در کد

در حالت‌های فعال ، غیرفعال و پنهان ، می‌توان کد جاوا اسکریپت را اجرا کرد که وضعیت چرخه حیات صفحه را از APIهای پلتفرم وب موجود تعیین می‌کند.

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

از طرف دیگر، حالت‌های یخ‌زده و خاتمه‌یافته ، تنها در شنونده رویداد مربوطه ( freeze و pagehide ) با تغییر وضعیت قابل شناسایی هستند.

نحوه مشاهده تغییرات حالت

با استفاده از تابع getState() که قبلا تعریف شده بود، می توانید تمام تغییرات حالت چرخه عمر صفحه را با کد زیر مشاهده کنید.

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

این کد سه کار را انجام می دهد:

• با استفاده از تابع getState() حالت اولیه را تنظیم می کند.
• تابعی را تعریف می کند که حالت بعدی را می پذیرد و در صورت تغییر، تغییرات وضعیت را به کنسول ثبت می کند.
• شنوندگان رویداد را برای همه رویدادهای چرخه حیات ضروری اضافه می کند، که به نوبه خود logStateChange() فراخوانی می کند و در حالت بعدی ارسال می شود.

یک نکته در مورد کد این است که تمام شنوندگان رویداد به window اضافه می شوند و همه آنها {capture: true} را پاس می کنند. چند دلیل برای این وجود دارد:

• همه رویدادهای چرخه عمر صفحه هدف یکسانی ندارند. pagehide ، و pageshow بر روی window شلیک می شود. visibilitychange ، freeze و resume روی document فعال می‌شوند و focus و blur روی عناصر DOM مربوطه فعال می‌شوند.
• بیشتر این رویدادها حباب نمی‌شوند، به این معنی که اضافه کردن شنوندگان رویداد غیرمجاز به یک عنصر جد مشترک و مشاهده همه آنها غیرممکن است.
• مرحله ضبط قبل از مرحله هدف یا حباب اجرا می شود، بنابراین افزودن شنوندگان به آنجا کمک می کند تا اطمینان حاصل شود که قبل از اینکه سایر کدها بتوانند آنها را لغو کنند، اجرا می شوند.

توصیه های توسعه دهنده برای هر ایالت

به عنوان توسعه‌دهندگان، مهم است که وضعیت‌های چرخه عمر صفحه را درک کنید و بدانید که چگونه آنها را در کد مشاهده کنید، زیرا نوع کاری که باید (و نباید) انجام دهید تا حد زیادی به وضعیت صفحه شما بستگی دارد.

به عنوان مثال، اگر صفحه در حالت مخفی است، واضح است که نمایش یک اعلان گذرا به کاربر منطقی نیست. در حالی که این مثال کاملا واضح است، توصیه های دیگری وجود دارد که چندان واضح نیستند که ارزش شمردن را دارند.

بار دیگر، از آنجایی که قابلیت اطمینان و ترتیب رویدادهای چرخه حیات به طور مداوم در همه مرورگرها اجرا نمی شود، ساده ترین راه برای پیروی از توصیه های جدول استفاده از PageLifecycle.js است.

APIهای چرخه عمر قدیمی که باید اجتناب کنید

تا جایی که ممکن است باید از اتفاقات زیر اجتناب شود.

رویداد تخلیه

بسیاری از توسعه دهندگان رویداد unload را به عنوان یک تماس تضمین شده در نظر می گیرند و از آن به عنوان سیگنال پایان جلسه برای ذخیره وضعیت و ارسال داده های تجزیه و تحلیل استفاده می کنند، اما انجام این کار به خصوص در تلفن همراه بسیار غیر قابل اعتماد است! رویداد unload در بسیاری از موقعیت‌های بارگیری معمولی فعال نمی‌شود، از جمله بستن یک برگه از تعویض‌کننده برگه در تلفن همراه یا بستن برنامه مرورگر از تعویض‌کننده برنامه.

به همین دلیل، همیشه بهتر است برای تعیین زمان پایان جلسه به رویداد visibilitychange تکیه کنید و حالت پنهان را آخرین زمان قابل اعتماد برای ذخیره اطلاعات برنامه و کاربر در نظر بگیرید.

علاوه بر این، صرف حضور یک کنترل‌کننده unload ثبت‌شده (از طریق onunload یا addEventListener() ) می‌تواند مانع از این می‌شود که مرورگرها بتوانند صفحات را در حافظه پنهان عقب و جلو برای بارگیری سریع‌تر به عقب و جلو قرار دهند.

در همه مرورگرهای مدرن، توصیه می‌شود که همیشه از رویداد pagehide برای شناسایی بارگیری‌های احتمالی صفحه (معروف به حالت پایان یافته ) به جای رویداد unload استفاده شود. اگر نیاز به پشتیبانی از اینترنت اکسپلورر نسخه 10 و پایین‌تر دارید، باید قابلیت تشخیص رویداد pagehide را داشته باشید و فقط در صورتی unload استفاده کنید که مرورگر از 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.
});

رویداد قبل از بارگیری

رویداد beforeunload مشکلی مشابه با رویداد unload دارد، زیرا از نظر تاریخی، وجود یک رویداد beforeunload می‌تواند از واجد شرایط بودن صفحات برای کش عقب/ جلو جلوگیری کند. مرورگرهای مدرن این محدودیت را ندارند. اگرچه برخی از مرورگرها، به عنوان یک اقدام احتیاطی، هنگام تلاش برای قرار دادن یک صفحه در حافظه پنهان عقب/ جلو، رویداد beforeunload فعال نمی‌کنند، به این معنی که رویداد به عنوان سیگنال پایان جلسه قابل اعتماد نیست. علاوه بر این، برخی از مرورگرها (از جمله Chrome ) قبل از اینکه اجازه دهند رویداد beforeunload فعال شود، نیاز به تعامل با کاربر در صفحه دارند که بر قابلیت اطمینان آن تأثیر می گذارد.

یک تفاوت بین beforeunload و unload این است که استفاده های قانونی از beforeunload وجود دارد. به عنوان مثال ، هنگامی که می خواهید به کاربر هشدار دهید که در صورت ادامه بارگیری صفحه ، تغییراتی غیرقانونی از دست می دهند.

از آنجایی که دلایل معتبری برای استفاده beforeunload وجود دارد، توصیه می‌شود فقط زمانی که کاربر تغییرات ذخیره‌نشده‌ای دارد، شنونده‌های beforeunload اضافه کنید و بلافاصله پس از ذخیره آن‌ها را حذف کنید.

به عبارت دیگر، این کار را انجام ندهید (زیرا یک شنونده beforeunload بدون قید و شرط اضافه می کند):

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

در عوض این کار را انجام دهید (زیرا فقط در صورت نیاز شنونده beforeunload را اضافه می کند و در صورت عدم نیاز آن را حذف می کند):

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

سوالات متداول

چرا حالت "بارگیری" وجود ندارد؟

Page Lifecycle API حالتها را مجزا و انحصاری متقابل تعریف می کند. از آنجایی که یک صفحه می‌تواند در حالت فعال، غیرفعال یا پنهان بارگیری شود، و از آنجایی که می‌تواند حالت‌ها را تغییر دهد - یا حتی خاتمه یابد - قبل از اتمام بارگذاری، یک حالت بارگذاری جداگانه در این پارادایم معنا ندارد.

صفحه من وقتی پنهان است کارهای مهمی انجام می دهد، چگونه می توانم جلوی فریز یا دور انداختن آن را بگیرم؟

دلایل قانونی زیادی وجود دارد که صفحات وب نباید هنگام اجرا در حالت مخفی مسدود شوند. بارزترین مثال اپلیکیشنی است که موسیقی پخش می کند.

همچنین شرایطی وجود دارد که دور انداختن صفحه برای Chrome خطرناک است، مثلاً اگر حاوی فرمی با ورودی کاربر ارسال‌نشده باشد، یا اگر دارای یک کنترل کننده beforeunload بارگیری باشد که هنگام بارگیری صفحه هشدار می‌دهد.

در حال حاضر، کروم در حذف صفحات محافظه کارانه عمل می کند و تنها زمانی این کار را انجام می دهد که مطمئن باشد بر کاربران تأثیری نخواهد گذاشت. برای مثال، صفحاتی که مشاهده شده‌اند هر یک از کارهای زیر را در حالت مخفی انجام می‌دهند، کنار گذاشته نمی‌شوند، مگر اینکه تحت محدودیت شدید منابع باشند:

• پخش صدا
• با استفاده از WebRTC
• به روز رسانی عنوان جدول یا فاویکون
• نمایش هشدارها
• ارسال اعلان های فشار

برای ویژگی‌های فهرست فعلی که برای تعیین اینکه آیا یک برگه را می‌توان به‌طور ایمن ثابت کرد یا دور انداخت، ببینید: Heuristics for Freezing & Discarding در Chrome.

کش عقب/ جلو چیست؟

کش عقب و جلو اصطلاحی است که برای توصیف بهینه‌سازی ناوبری استفاده می‌شود که برخی از مرورگرها اجرا می‌کنند که استفاده از دکمه‌های برگشت و جلو را سریع‌تر می‌کند.

هنگامی که کاربر از صفحه ای دور می شود، این مرورگرها نسخه ای از آن صفحه را مسدود می کنند تا در صورتی که کاربر با استفاده از دکمه های برگشت یا جلو به عقب برگردد، به سرعت از سر گرفته شود. به یاد داشته باشید که افزودن یک کنترل کننده رویداد unload از امکان این بهینه سازی جلوگیری می کند .

برای همه مقاصد، این انجماد از نظر عملکردی همانند مرورگرهای انجماد برای حفظ CPU/باتری است. به همین دلیل بخشی از حالت چرخه حیات منجمد در نظر گرفته می شود.

اگر نمی‌توانم APIهای ناهمزمان را در حالت‌های ثابت یا خاتمه اجرا کنم، چگونه می‌توانم داده‌ها را در IndexedDB ذخیره کنم؟

در حالت‌های ثابت و خاتمه‌یافته، وظایف قابل انجماد در صف‌های وظیفه صفحه به حالت تعلیق در می‌آیند، به این معنی که APIهای ناهمزمان و مبتنی بر تماس مانند IndexedDB قابل استفاده نیستند.

در آینده، یک متد commit() به اشیاء IDBTransaction اضافه خواهیم کرد، که به توسعه دهندگان راهی می دهد تا تراکنش هایی را که به طور موثر فقط نوشتن هستند و نیازی به callback ندارند، انجام دهند. به عبارت دیگر، اگر توسعه‌دهنده فقط داده‌ها را در IndexedDB می‌نویسد و یک تراکنش پیچیده شامل خواندن و نوشتن را انجام نمی‌دهد، متد commit() می‌تواند قبل از تعلیق صف‌های وظیفه به پایان برسد (با فرض اینکه پایگاه داده IndexedDB از قبل باز باشد).

با این حال، برای کدهایی که باید امروز کار کنند، توسعه دهندگان دو گزینه دارند:

• از فضای ذخیره‌سازی جلسه استفاده کنید: ذخیره‌سازی جلسه همزمان است و در بین صفحات نادیده گرفته می‌شود.
• از IndexedDB از سرویس‌کار خود استفاده کنید: یک سرویس‌گر می‌تواند داده‌ها را پس از پایان یا دور انداختن صفحه در IndexedDB ذخیره کند. در شنونده رویداد freeze یا pagehide می‌توانید داده‌ها را از طریق postMessage() به سرویس‌کار خود ارسال کنید و سرویس‌کار می‌تواند ذخیره داده‌ها را انجام دهد.

آزمایش برنامه شما در حالت یخ زده و دور انداخته شده

برای آزمایش نحوه عملکرد برنامه‌تان در حالت‌های ثابت و دور انداخته‌شده، می‌توانید از chrome://discards دیدن کنید تا در واقع هر یک از برگه‌های باز خود را ثابت یا نادیده بگیرید.

این به شما این امکان را می دهد که مطمئن شوید صفحه شما به درستی رویدادهای freeze و resume و همچنین پرچم document.wasDiscarded را هنگام بارگیری مجدد صفحات پس از رد کردن، مدیریت می کند.

خلاصه

توسعه‌دهندگانی که می‌خواهند به منابع سیستمی دستگاه‌های کاربر خود احترام بگذارند، باید برنامه‌های خود را با در نظر گرفتن حالت‌های چرخه عمر صفحه بسازند. بسیار مهم است که صفحات وب منابع بیش از حد سیستم را در شرایطی که کاربر انتظار ندارد مصرف نکنند.

هرچه توسعه‌دهندگان بیشتر شروع به پیاده‌سازی APIهای جدید Page Lifecycle کنند، برای مرورگرها ایمن‌تر می‌شوند که صفحاتی را که استفاده نمی‌شوند مسدود کرده و دور بیندازند. این بدان معناست که مرورگرها حافظه، CPU، باتری و منابع شبکه کمتری مصرف می کنند که برای کاربران یک پیروزی محسوب می شود.