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

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

התקנה

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

ServiceWorkerRegistration.install

האירוע הראשון שמופעל במהלך ההתקנה הוא אירוע install של עובד שירות אינטרנט.

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

הפעלת תוסף

כשפרופיל משתמש מתחיל, מתרחש האירוע chrome.runtime.onStartup אבל לא מתבצעת קריאה לאף אירוע של שירות עובד.

מצב חוסר פעילות וכיבוי

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

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

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

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

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

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

chrome.storage API

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

API של IndexedDB

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

ממשק API של CacheStorage

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

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

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

Chrome 120

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

Chrome 118

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

Chrome 116

ב-Chrome 116 נוספו השיפורים הבאים בכל משך החיים של קובצי שירות (service worker):

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

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

Chrome 114

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

Chrome 110

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

Chrome 109

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

Chrome 105

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