קובצי שירות (service worker) של תוספים מגיבים גם לאירועים של קובץ השירות הרגיל (service worker) וגם לאירועים במרחבי השמות של התוספים. הם מוצגים יחד מכיוון שבמקרים רבים, סוג אחד עוקב אחר סוג אחר במהלך השימוש של תוסף.
התקנה
ההתקנה מתרחשת כאשר המשתמש מתקין או מעדכן קובץ שירות (service worker) מחנות האינטרנט של Chrome, או כאשר הוא טוען או מעדכן תוסף לא ארוז באמצעות דף chrome://extensions
. שלושה אירועים מתרחשים לפי הסדר הבא.
ServiceWorkerRegistration.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 של קובץ השירות מופעל. חשוב לשים לב שבניגוד ל-Web Service Workers, האירוע הזה מופעל מיד לאחר התקנת תוסף, מפני שאין אפשרות דומה לטעינה מחדש של דף בתוסף.
הפעלת התוסף
כשפרופיל משתמש מתחיל, האירוע chrome.runtime.onStartup
מופעל אבל לא מופעלים אירועים של קובץ שירות (service worker).
ללא פעילות וכיבוי
בדרך כלל, Chrome מסיים קובץ שירות (service worker) כאשר מתקיים אחד מהתנאים הבאים:
- לאחר 30 שניות של חוסר פעילות. כשמקבלים אירוע או בהתקשרות לתוסף API, הטיימר מתאפס.
- כאשר עיבוד בקשה בודדת, כמו אירוע או קריאה ל-API, נמשך יותר מ-5 דקות.
- כשתגובה של
fetch()
מתקבלת תוך יותר מ-30 שניות.
אירועים וקריאות לממשקי API של תוספים מאפסים את הטיימרים האלה, ואם ה-Service Worker עובר למצב רדום, האירוע הנכנס יחדש אותם. עם זאת, עליכם לתכנן את קובץ השירות (service worker) כך שיהיה עמיד בפני סיום בלתי צפוי.
כדי לבצע אופטימיזציה של צריכת המשאבים של התוסף, כדאי להימנע מהשארת קובץ השירות פעיל ללא הגבלת זמן, אם אפשר. כדאי לבדוק את התוספים כדי לוודא שלא עשיתם זאת בטעות.
שמירת נתונים במקום שימוש במשתנים גלובליים
כל המשתנים הגלובליים שתגדירו יאבדו אם ה-Service Worker ייסגר. במקום להשתמש במשתנים גלובליים, אפשר לשמור ערכים באחסון. האפשרויות שלך מפורטות למטה. שימו לב ש-Web Storage API לא זמין ל-Service Workers של תוספים.
- ממשק API של chrome.storage
- ממשק API של תוסף שמציע סוגים שונים של אחסון: מקומי, סשן, מנוהל (דומיין) וסנכרון. ב-API הזה מאוחסנים אובייקטים של JSON שזוהו ואוחזרו באמצעות מפתחות שהוגדרו על ידי המפתח. אחסון מסוג זה לא יוסר כשהמשתמש ינקה את המטמון באינטרנט.
- IndexedDB API
- API ברמה נמוכה לאחסון נתונים מובְנים בצד הלקוח, כולל קבצים ו-blob. ה-API הזה מספק כלים פשוטים ליצירת אחסון ואחזור של נתונים של עסקאות. ה-API הזה מסובך מדי לתרחישים פשוטים לדוגמה, אבל קיימים עליו מספר פתרונות אחסון של צדדים שלישיים.
- CacheStorage API
- מנגנון אחסון קבוע לזוגות של אובייקטים מסוג 'בקשה' ו'תגובה'. ממשק ה-API הזה תוכנן במיוחד לעובדים בשירותי אינטרנט, והוא משמש לאחזור נתונים מנקודת קצה. קיימות דרכים שונות להשתמש ב-API הזה, בהתאם למידת החשיבות של הצגת נתונים עדכניים למשתמשים. מידע נוסף זמין במאמר מתכונים אופליין. אלא אם ניסית להעביר בקשות רשת ספציפיות לשרת proxy באמצעות handler של אחזור, יש להשתמש ב-
chrome.storage
.
בחירת גרסה מינימלית של Chrome
מאז ההשקה של Manifest V3, ביצענו כמה שיפורים לאורך כל משך החיים של קובץ השירות (service worker). כלומר, אם תוסף Manifest V3 תומך בגרסאות קודמות של Chrome, יש תנאים שאתם צריכים להיות מודעים להם. אם התנאים האלה לא משפיעים על התוסף, אפשר להמשיך מהקטע הזה. אם כן, כדאי לציין גרסת Chrome מינימלית במניפסט.
Chrome 120
עכשיו אפשר להגדיר התראות לפרק זמן מינימלי של 30 שניות, בהתאם למחזור החיים של קובץ השירות (service worker). פרטים נוספים זמינים בכתובת chrome.alarms
.
גרסה 118 של Chrome
סשנים פעילים של ניפוי באגים שנוצרו באמצעות chrome.debugger
API שומרים עכשיו את קובץ השירות (service worker) פעיל. כך לא ניתן יהיה להפסיק את הזמן הקצוב לתפוגה של קובצי שירות (service worker) במהלך קריאות ל-API הזה.
גרסה 116 של Chrome
בגרסה 116 של Chrome השקנו את השיפורים הבאים בכל משך החיים של קובץ השירות (service worker):
חיבורי
WebSocket
פעילים מאריכים עכשיו את משך החיים של קובץ שירות (service worker). שליחה או קבלה של הודעות ב-WebSocket
ב-Service Worker בתוסף מאפסת את הטיימר ללא פעילות של ה-Service Worker.ממשקי API נוספים של תוספים מורשים לעבור את פרק הזמן הקצוב לתפוגה של חמש דקות עבור עובדי שירות של תוספים. ממשקי ה-API האלה מציגים בקשה מהמשתמש, ולכן פתרון הבעיה עשוי להימשך זמן רב יותר מחמש דקות. למשל:
desktopCapture.chooseDesktopMedia()
,identity.launchWebAuthFlow()
,management.uninstall()
ו-permissions.request()
.
גרסה 114 של Chrome
שליחת הודעה באמצעות העברת הודעות לטווח ארוך משמרת את קובץ השירות (service worker). בעבר, פתיחת יציאה איפסה את הטיימרים, אבל שליחת הודעה לא איפסה את הטיימר. פתיחת יציאה כבר לא מאפסת את הטיימרים.
גרסה 110 של Chrome
קריאות ל-Extension API מאפסות את הטיימרים. לפני כן, רק רכיבי handler של אירועים פעילים היו מחזיקים את קובץ השירות (service worker) במצב פעיל. אירועים שעמדו בתור אבל לא הופעל עבורם handler לא יגרמו לאיפוס.
גרסה 109 של Chrome
הודעות שנשלחו ממסמך שאינו במסך איפסו את הטיימרים.
גרסה 105 של Chrome
חיבור למארח העברת הודעות מקומי באמצעות chrome.runtime.connectNative()
ישמור על קובץ שירות (service worker). אם תהליך המארח קורס או מושבת, היציאה תיסגר וה-Service Worker יפסיק לפעול לאחר שהטיימרים יושלמו. כדי להתגונן מפני מצב כזה, יש לקרוא ל-chrome.runtime.connectNative()
ב-handler של אירועי onניתוק של היציאה.