Page Lifecycle API

Philip Walton

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

پیشینه

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

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

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

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

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

API چرخه حیات صفحه تلاش می‌کند تا این مشکل را با روش‌های زیر حل کند:

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

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

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

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

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

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

ایالت‌ها

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

رویدادها

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

* نشان‌دهنده‌ی یک رویداد جدید است که توسط API چرخه‌ی حیات صفحه تعریف شده است.

ویژگی‌های جدید اضافه شده در کروم ۶۸

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

در کروم ۶۸، توسعه‌دهندگان اکنون می‌توانند با گوش دادن به رویدادهای freeze و resume در document ، متوجه شوند که یک تب پنهان چه زمانی متوقف و چه زمانی از حالت مسدود خارج می‌شود.

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

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

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

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 در بسیاری از موقعیت‌های معمول unload، از جمله بستن یک تب از طریق تعویض تب در موبایل یا بستن برنامه مرورگر از طریق تعویض برنامه، اجرا نمی‌شود.

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

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

در تمام مرورگرهای مدرن، توصیه می‌شود همیشه از رویداد 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

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

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

از آنجایی که دلایل معتبری برای استفاده از 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.
    event.returnValue = true;
  }
});

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

const beforeUnloadListener = (event) => {
  event.preventDefault();

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

// A function that adds a `beforeunload` listener if there are unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

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

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

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

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

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

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

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

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

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

برای مشاهده‌ی ویژگی‌های فعلی فهرست که برای تعیین اینکه آیا می‌توان یک تب را با خیال راحت فریز یا حذف کرد، استفاده می‌شوند، به بخش «روش‌های ابتکاری برای فریز و حذف در کروم» مراجعه کنید.

حافظه پنهان عقب/جلو چیست؟

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

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

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

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

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

در حالی که اکثر APIهای IndexedDB مبتنی بر فراخوانی مجدد هستند، متد commit() در رابط IDBTransaction راهی برای شروع فرآیند commit در یک تراکنش فعال بدون انتظار برای ارسال رویدادهای درخواست‌های معوقه فراهم می‌کند. این یک روش قابل اعتماد برای ذخیره داده‌ها در یک پایگاه داده IndexedDB در یک شنونده رویداد freeze یا visibilitychange فراهم می‌کند، زیرا commit بلافاصله اجرا می‌شود و در یک وظیفه جداگانه در صف قرار نمی‌گیرد.

تست برنامه در حالت‌های قفل‌شده و کنار گذاشته‌شده

برای آزمایش نحوه رفتار برنامه خود در حالت‌های مسدود شده و حذف شده، می‌توانید به chrome://discards مراجعه کنید تا هر یک از تب‌های باز خود را مسدود یا حذف کنید.

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

خلاصه

توسعه‌دهندگانی که می‌خواهند به منابع سیستم دستگاه‌های کاربران خود احترام بگذارند، باید برنامه‌های خود را با در نظر گرفتن وضعیت چرخه عمر صفحه (Page Lifecycle) بسازند. بسیار مهم است که صفحات وب در موقعیت‌هایی که کاربر انتظار ندارد، منابع سیستم را بیش از حد مصرف نکنند.

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