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

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

התקנה

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

1. install
2. onInstall
3. activate

ServiceWorkerRegistration.install

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

chrome.runtime.onInstalled

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

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

ServiceWorkerRegistration.active

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

הפעלת תוסף

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

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

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

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

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

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

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

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

‫chrome.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, אתם צריכים להשתמש ב-chrome.storage.

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

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

‫Chrome 120

מעכשיו אפשר להגדיר את ההתראות לתקופה מינימלית של 30 שניות, בהתאם למחזור החיים של קובץ השירות (service worker). פרטים נוספים מופיעים במאמר chrome.alarms.

‫Chrome 118

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

Chrome 116

ב-Chrome 116 הוספנו את השיפורים הבאים בנוגע לזמן החיים של Service Worker:

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

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

‫Chrome 114

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

‫Chrome 110

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

‫Chrome 109

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

‫Chrome 105

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