ממשק API של מחזור החיים של דפים

Philip Walton

דפדפנים מודרניים משהים לפעמים דפים או מוחקים אותם לגמרי ומשאבי המערכת מוגבלים. בעתיד, דפדפנים ירצו לעשות זאת באופן יזום, כך שהם צורכים פחות חשמל וזיכרון. ממשק ה-API של מחזור החיים של דף מספק הוקים (hooks) למחזור החיים כדי שהדפים שלכם יוכלו לטפל בהם בבטחה בלי להשפיע על חוויית המשתמש. כדאי לעיין ב-API כדי לבדוק אם אתם צריכים להטמיע את התכונות האלה באפליקציה שלכם.

רקע

מחזור החיים של אפליקציות הוא אחד מהנושאים העיקריים שמערכות הפעלה מודרניות מנהלות במשאבי אנוש. ב-Android, ב-iOS ובגרסאות עדכניות של Windows, אפשר להפעיל אפליקציות עצר בכל שלב על ידי מערכת ההפעלה. כך הפלטפורמות האלה יכולות לייעל להקצות מחדש משאבים באופן שיועיל למשתמש בצורה הטובה ביותר.

באינטרנט, לא היה מחזור חיים כזה, וניתן לשמור אפליקציות הם חיים ללא הגבלת זמן. עם הרבה דפי אינטרנט פעילים, מערכת חיונית מצב שבו יש צורך ברכישת יתר של משאבים כמו זיכרון, מעבד (CPU), סוללה ורשת, שמובילה לחוויה גרועה של משתמשי קצה.

בפלטפורמת האינטרנט יש כבר זמן רב אירועים שקשורים למצבים של מחזור חיים — כמו load, unload, וגם visibilitychange – האירועים האלה מאפשרים רק למפתחים כדי להגיב לשינויים במצב של מחזור החיים ביוזמת המשתמש. כדי שהאינטרנט יפעל במכשירים בעלי עוצמה נמוכה (ובאופן כללי, להיות יותר ממוקדים במשאבים כל הפלטפורמות) דפדפנים זקוקים לדרך כדי לתבוע מחדש את המערכת ולהקצות אותה מחדש באופן יזום במשאבי אנוש.

למעשה, דפדפנים כיום כבר נוקטים אמצעים פעילים לשימור משאבים עבור דפים בכרטיסיות הרקע, ודפדפנים רבים (במיוחד Chrome) מעדיפים לעשות הרבה יותר מזה – כדי לצמצם את טביעת הרגל הפחמנית הכוללת של המשאבים.

הבעיה היא שלמפתחים אין דרך להתכונן לשינויים מהסוגים האלה התערבות יזומה של המערכת, או אפילו לדעת שהם קורים. כלומר דפדפנים צריכים להיות שמרניים, או לגרום לקריסה של דפי אינטרנט.

ממשק ה-API של מחזור החיים של דף מנסה לפתור את הבעיה באמצעות:

• השקה וסטנדרטיזציה של המושג 'מצבים במחזור החיים' באינטרנט.
• הגדרת מצבים חדשים ביוזמת המערכת, שמאפשרים לדפדפנים להגביל משאבים שהכרטיסיות המוסתרות או לא פעילות יכולות לצרוך אותם.
• יצירת ממשקי API ואירועים חדשים שמאפשרים למפתחי אתרים להגיב עליהם מעבר אל המצבים החדשים ביוזמת המערכת ומהם.

הפתרון הזה מספק את יכולת החיזוי שמפתחי אתרים צריכים לבנות ולכן הם עמידים להתערבות במערכת, והם מאפשרים לדפדפנים יותר אופטימיזציה אגרסיבית של משאבי המערכת, ובסופו של דבר תועיל לכל משתמשי האינטרנט.

שאר הפוסט הזה יציג את התכונות החדשות של מחזור החיים של הדף ולראות איך הם קשורים לכל המצבים הקיימים של פלטפורמות האינטרנט. ואירועים. כמו כן, יוצגו בו המלצות ושיטות מומלצות לגבי הסוגים של העבודה שמפתחים צריכים לעשות בכל מדינה, וגם לא אמורים לעשות זאת.

סקירה כללית של מצבים ואירועים במחזור החיים של הדף

כל המצבים של מחזור החיים של דף הם נפרדים ובלעדיים, כלומר דף יכולים להיות במדינה אחת בלבד בכל פעם. ורוב השינויים במצב מחזור החיים של דף בדרך כלל ניתן לראות אותם דרך אירועי DOM (מידע על החריגים זמין בהמלצות למפתחים).

אולי הדרך הקלה ביותר להסביר את המצבים של מחזור החיים של הדף — וגם האירועים שמסמנים מעברים ביניהם – מופיעים בדיאגרמה:

מדינות

הטבלה הבאה מסבירה בפירוט כל מצב. כאן גם מפורטות האפשרויות שיכולים להופיע לפני ואחרי האירועים שהמפתחים יכולים שישמשו לתצפית על השינויים.

אירועים

דפדפנים שולחים הרבה אירועים, אבל רק חלק קטן מהם מסמנים שינוי אפשרי במצב של מחזור החיים של הדף. כל האירועים מפורטים בטבלה הבאה בנושאים שקשורים למחזור החיים ומפרטות את המצבים שאליהם הם עשויים לעבור ומהם.

* מציין אירוע חדש שהוגדר על ידי ה-API של מחזור החיים של הדף

תכונות חדשות שנוספו בגרסה 68 של Chrome

בתרשים הקודם מוצגים שני מצבים ביוזמת המערכת ולא ביוזמת המערכת ביוזמת המשתמש: הוקפאה והוסרה. כפי שצוין קודם, דפדפנים היום כבר קופאים ונסגרים מדי פעם כרטיסיות מוסתרות (על פי שיקול דעתם), אבל למפתחים אין דרך לדעת מתי זה קורה.

ב-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 נכס ב-Chrome למחשב (מתקיים מעקב אחר תמיכה ב-Android בבעיה הזו). כדי לקבוע אם דף נמחק כשהוא במצב מוסתר ניתן לבדוק את הערך של המאפיין הזה בזמן הטעינה של הדף (הערה: כדי להשתמש בהם שוב, צריך לטעון מחדש את הדפים שנמחקו).

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

כדי לקבל עצות לגבי דברים שחשוב לעשות בfreeze ובresume אירועים, וגם איך לטפל בדפים שנמחקו ולהכין אותם, המלצות למפתחים לכל מדינה.

בחלקים הבאים יש סקירה כללית של האופן שבו התכונות החדשות משתלבות את המצבים והאירועים הקיימים של פלטפורמת האינטרנט.

איך להבחין במצבים של מחזור החיים של הדף בקוד

בעמודות הפעיל, הפסיבית והמוסתרת קיימת אפשרות להריץ קוד JavaScript שקובע מצב מחזור החיים של הדף מממשקי API קיימים של פלטפורמת האינטרנט.

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

המצב קפוא וסגור, מצד שני, ניתן לזהות רק ב-event listener המתאים שלהם (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().
• מגדירה פונקציה שמקבלת את המצב הבא, ואם יש שינוי, רושם את שינויי המצב במסוף.
• הוספות צילום פונקציות event listener לכל האירועים הנחוצים במחזור החיים, אשר בתורו מפעילים logStateChange(), עוברים במצב הבא.

דבר אחד שכדאי לדעת לגבי הקוד הוא שכל פונקציות ה-event listener מתווספים אל window וכולם עוברים {capture: true}. יכולות להיות לכך כמה סיבות:

• לא לכל האירועים במחזור החיים של הדף יש יעד זהה. pagehide, וגם pageshow הופעלו בתאריך window; visibilitychange, freeze וגם resume מופעלים בתאריך document, ו-focus ו-blur מופעלים במכשיר רכיבי ה-DOM המתאימים.
• רוב האירועים האלה לא מופיעים בבועות, ולכן אי אפשר להוסיף שלא מתעדים את פונקציות event listener לאלמנט אב משותף, ובוחנים את כל מהם.
• שלב הצילום מתבצע לפני שלבי היעד או הבועה, לכן מאזינים שם מוודאים שהם ירוצו לפני שקוד אחר יכול לבטל אותם.

המלצות למפתחים בכל מדינה

כמפתחים, חשוב להבין את המצבים של מחזור החיים של הדף וגם לדעת איך להבחין בהם בקוד, כי סוג העבודה שצריך (וצריך) לא) עושה תלוי במידה רבה במצב של הדף.

לדוגמה, ברור שלא הגיוני להציג התראה זמנית. למשתמש אם הדף במצב סמוי. אומנם הדוגמה הזאת יפה כמובן, יש המלצות אחרות שהן לא כל כך ברורות מאליהן, של ספירת ההמרות.

שוב, מכיוון שהאמינות והסדר של אירועים במחזור החיים אינם מיושמת באופן עקבי בכל הדפדפנים, הדרך הקלה ביותר לקבל את העצות שבטבלה הוא להשתמש PageLifecycle.js.

ממשקי API מדור קודם למחזור חיים שיש להימנע מהם

יש להימנע ככל האפשר מהאירועים הבאים.

האירוע 'הסרת הנתונים שנטענו'

מפתחים רבים מתייחסים לאירוע של unload כאל קריאה חוזרת מובטחת ומשתמשים בו בתור אות סיום סשן כדי לשמור את המצב ולשלוח ניתוח נתונים. אבל הפעולה הזו הוא מאוד לא אמין, במיוחד בנייד! האירוע unload לא מופעלת במצבים נפוצים רבים של הסרת טעינה, כולל סגירת כרטיסייה מהכרטיסייה מתג לנייד או סגירת אפליקציית הדפדפן דרך מחליף האפליקציות.

לכן תמיד עדיף להסתמך אירוע visibilitychange שקובע מתי סשן מסתיים, ובוחנים את המצב הסמוי הזמן האמין האחרון לשמירת נתוני אפליקציה ומשתמשים.

בנוסף, עצם הנוכחות של גורם מטפל באירועים רשום ב-unload (דרך onunload או addEventListener()) יכולים למנוע מדפדפנים כדי לשמור דפים במטמון לדף הקודם/הבא מהר יותר טעינה קדימה ואחורה.

בכל הדפדפנים המתקדמים מומלץ להשתמש תמיד pagehide כדי לזהות העלאות אפשריות של דפים (שנקראת גם מצב הסתיים) ולא באירוע unload. אם צריכים לתמוך ב-Internet Explorer מגרסה 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 עשויה למנוע מאתרים שעומד בדרישות לשימוש במטמון לדף הקודם/הבא. דפדפנים מודרניים מכילים את ההגבלה הזו. למרות שדפדפנים מסוימים, ליתר ביטחון, לא יופעלו אירוע 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);
  }
});

במקום זאת, עשו זאת (מכיוון שהוא מוסיף את ה-listen של 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);
});

שאלות נפוצות

למה אין 'טעינה' מדינה?

ה-API של מחזור החיים של הדף מגדיר מצבים בדידים ובלעדיים. מאחר שניתן לטעון דף במצב פעיל, פסיבי או מוסתר, וגם מכיוון שהוא יכול לשנות מצבים - או אפילו להיפסק - לפני שהטעינה שלו מסתיימת, לא הגיוני במצב טעינה נפרד בתוך הפרדיגמה הזו.

הדף שלי עובד חשוב כשהוא מוסתר. איך אפשר למנוע הקפאה או מחיקה של הדף?

יש הרבה סיבות לגיטימיות לכך שאין להקפיא דפי אינטרנט בזמן שהם פועלים. במצב הסמוי. הדוגמה הבולטת ביותר היא אפליקציה שמשמיעה מוזיקה.

יש גם מצבים שבהם עלול להיווצר סיכון ש-Chrome ימחק דף, למשל, אם הוא מכיל טופס עם קלט של משתמשים שלא נשלחו, או אם handler של beforeunload שמציג אזהרה כשמתבצעת טעינה של הדף.

בשלב זה, Chrome הולך לנקוט דעה שמרנית יותר בעת מחיקת דפים לעשות זאת רק אם יש לך ספק שהוא לא ישפיע על המשתמשים. לדוגמה, דפים לבצע אחת מהפעולות הבאות בזמן שבמצב סמוי מותר למחוק אותם, אלא אם כן כפופים למגבלות משאבים קיצוניות:

• מושמע אודיו
• שימוש ב-WebRTC
• עדכון הכותרת או סמל האתר של הטבלה
• הצגת התראות
• נשלחות התראות

לגבי תכונות הרשימה הנוכחיות שמשמשות לקביעה אם ניתן להשתמש בכרטיסייה בצורה בטוחה קפוא או נמחק, למידע נוסף: נתונים להקפאה סגירה ב-Chrome.

מה זה מטמון לדף הקודם/הבא?

מטמון לדף הקודם/הבא הוא מונח שמשמש לתיאור של ניווט, חלק מהדפדפנים מטמיעים, שהופכת את השימוש ב בבית את לחצני ההעברה קדימה מהר יותר.

כשמשתמש מנווט אל מחוץ לדף, הדפדפנים האלה מקפיאים גרסה שלו כך שניתן יהיה להמשיך אותו במהירות במקרה שהמשתמש יחזור באמצעות על לחצני 'הקודם' ו'הבא'. חשוב לזכור שהוספת unload הגורם המטפל באירועים מונע מהאופטימיזציה הזו את האפשרות.

מכל הכוונות והמטרות, ההקפאה הזו זהה מבחינה פונקציונלית שהדפדפנים שקופאים פועלים כדי לחסוך בזיכרון המעבד (CPU)/בסוללה. לכן, נחשבות לחלק ממצב הקפוא של מחזור החיים.

אם אי אפשר להריץ ממשקי API אסינכרוניים במצב של 'קפוא' או של 'הסתיים', איך אפשר לשמור את הנתונים ב-IndexedDB?

במצב קפוא או סגור, משימות שניתנות להקפאה בתורי המשימות של דף מושעים, כלומר ממשקי API אסינכרוניים ומבוססי קריאה חוזרת (callback), כמו IndexedDB בלתי מהימן.

בעתיד נוסיף method commit() ל-IDBTransaction אובייקטים, לתת למפתחים דרך לבצע עסקאות מסוג 'כתיבה בלבד' ביעילות שלא מחייבות התקשרות חזרה. במילים אחרות, אם המפתח רק כותב לנתונים של IndexedDB ולא לבצע עסקה מורכבת שכוללת קריאות וכותבים, השיטה commit() תוכל להסתיים לפני שתורי המשימות מושעים (בהנחה שמסד הנתונים של IndexedDB כבר פתוח).

עם זאת, יש למפתחים שתי אפשרויות לקוד שאמור לפעול היום:

• שימוש באחסון סשנים: אחסון סשנים הוא סינכרוני ונשמר בכל הדפים שנמחקו.
• משתמשים ב-IndexedDB מ-Service Worker, Service Worker יכול לאחסן נתונים ב- IndexedDB אחרי שהדף נסגר או נמחק. בfreeze או האזנה לאירוע של pagehide אפשר לשלוח נתונים ל-Service Worker באמצעות postMessage(), וה-Service Worker יכול לטפל בשמירת הנתונים.

בדיקת האפליקציה במצב 'קפוא' או 'נמחק'

כדי לבדוק את אופן הפעולה של האפליקציה במצב 'קפוא' או 'נמחק', אפשר לעבור לכתובת chrome://discards כדי להקפיא או למחוק בפועל לפתוח כרטיסיות.

כך אפשר לוודא שהדף שלך מטפל כראוי בfreeze ובresume אירועים וגם את הדגל document.wasDiscarded כשדפים נטענים מחדש אחרי זריקת מרץ.

סיכום

מפתחים שרוצים לכבד את משאבי המערכת במכשירים של המשתמשים שלהם צריכים לפתח את האפליקציות תוך התייחסות למצבים של מחזור החיים של הדף. חשוב מאוד דפי אינטרנט לא צורכים כמות מוגזמת של משאבי מערכת במצבים שבהם המשתמש לא מצפה

ככל שיותר מפתחים יתחילו להטמיע את ממשקי ה-API החדשים של מחזור החיים של הדפים, כך מאפשרים לדפדפנים להקפיא ולמחוק דפים שלא נמצאים בשימוש. הזה כלומר, דפדפנים יצרוך פחות זיכרון, מעבד (CPU), סוללה ומשאבי רשת, וזה לטובת המשתמשים.