מחזור החיים של ה-Service Worker בתוסף

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

התקנה

ההתקנה מתרחשת כשהמשתמש מתקין או מעדכן service worker מחנות האינטרנט של Chrome, או כשהוא טוען או מעדכן תוסף לא ארוז באמצעות הדף chrome://extensions. שלושה אירועים מתרחשים, לפי הסדר הזה:

1. ‫install (אירוע של קובץ שירות)
2. ‫browser.runtime.onInstalled (אירוע של תוסף)
3. ‫activate (אירוע של קובץ שירות)

ServiceWorkerRegistration.install

האירוע הראשון שמופעל במהלך ההתקנה הוא האירוע install של Web service worker.

browser.runtime.onInstalled

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

browser.runtime.onInstalled.addListener((details) => {
  if(details.reason !== "install" && details.reason !== "update") return;
  browser.contextMenus.create({
    "id": "sampleContextMenu",
    "title": "Sample Context Menu",
    "contexts": ["selection"]
  });
});

ServiceWorkerRegistration.active

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

הפעלת התוסף

כשפרופיל משתמש מתחיל, האירוע browser.runtime.onStartup מופעל אבל לא מופעלים אירועים של Service Worker.

מצב המתנה וכיבוי

בדרך כלל, Chrome מפסיק את פעולת ה-Service Worker כשמתקיים אחד מהתנאים הבאים:

• אחרי 30 שניות ללא פעילות. הטיימר הזה מתאפס כשמתקבל אירוע או כשמתבצעת קריאה ל-API של התוסף.
• כשעיבוד של בקשה אחת, כמו אירוע או קריאה ל-API, נמשך יותר מ-5 דקות.
• כשנדרשות יותר מ-30 שניות כדי לקבל תשובה מ-fetch().

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

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

שמירת הנתונים במקום שימוש במשתנים גלובליים

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

‫browser.storage API

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

‫IndexedDB API

‫

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

‫CacheStorage API

מנגנון אחסון מתמיד לזוגות של אובייקטים מסוג Request ו-Response. ממשק ה-API הזה תוכנן במיוחד בשביל web service workers, והוא משמש לאחזור נתונים מנקודת קצה. יש מגוון דרכים להשתמש ב-API הזה, בהתאם לחשיבות של הצגת נתונים עדכניים למשתמשים. מידע נוסף זמין במאמר The Offline Cookbook. אלא אם אתם משתמשים ב-fetch handler כדי להעביר בקשות רשת דרך שרת proxy, אתם צריכים להשתמש ב-browser.storage.

בחירת גרסת Chrome מינימלית

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

Chrome 120

מעכשיו אפשר להגדיר התראות לתקופה מינימלית של 30 שניות, בהתאם למחזור החיים של Service Worker. פרטים נוספים מופיעים במאמר browser.alarms.

Chrome 118

סשנים פעילים של ניפוי באגים שנוצרו באמצעות browser.debugger API שומרים עכשיו על פעילות של Service Worker. כך נמנע מצב שבו ה-service workers יפסיקו לפעול במהלך קריאות ל-API הזה.

Chrome 116

בגרסה 116 של Chrome הוספנו את השיפורים הבאים בנוגע לזמן החיים של קובץ השירות (service worker):

• חיבורים פעילים של WebSocket מאריכים עכשיו את משך החיים של מופעי קובץ שירות (service worker) של תוספים. שליחה או קבלה של הודעות ב-WebSocket ב-service worker של תוסף מאפסות את טיימר חוסר הפעילות של ה-service worker.

• מותר לממשקי API נוספים של תוספים לחרוג מתקופת הזמן הקצוב לתפוגה של חמש דקות לקובצי שירות (service worker) של תוספים. ממשקי ה-API האלה מציגים הנחיה למשתמש, ולכן יכול להיות שיחלפו יותר מחמש דקות עד שהם יפעלו. הם כוללים את desktopCapture.chooseDesktopMedia(),‏ identity.launchWebAuthFlow(),‏ management.uninstall() ו-permissions.request().

Chrome 114

שליחת הודעה באמצעות העברת הודעות לטווח ארוך שומרת על פעילותו של ה-service worker. פתיחת יציאה לא מאפסת יותר את הטיימרים.

Chrome 110

קריאות ל-API של התוסף מאפסות את מגבלות הזמן. לפני השינוי הזה, רק הפעלה של handlers של אירועים שמרה על פעילות של service worker. אירועים שהוכנסו לתור, אבל לא הופעל לגביהם גורם מטפל, לא יגרמו לאיפוס.

Chrome 109

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

Chrome 105

התחברות למארח להעברת הודעות נייטיב באמצעות browser.runtime.connectNative() תשאיר את קובץ השירות (service worker) פעיל. אם תהליך המארח קורס או מושבת, היציאה נסגרת וקובץ ה-Service Worker יסתיים אחרי שהטיימרים יסתיימו. כדי למנוע את זה, מפעילים את browser.runtime.connectNative() בגורם המטפל באירועים של היציאה ב-onDisconnect.