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

הפעלת תוסף

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

IndexedDB API

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

CacheStorage API

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

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

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

Chrome 120

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

Chrome 118

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

Chrome 116

ב-Chrome 116 הוספנו את השיפורים הבאים ב-service worker:

• חיבורים פעילים של WebSocket מארינים עכשיו את משך החיים של עובדי השירות של התוספים. שליחה או קבלה של הודעות דרך WebSocket בתגובה של שירות מנוהל בתוסף מאפסת את טיימר ההשבתה של שירות ה-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 של היציאה.