מפתחים רבים שוכחים שלגרסת האנדרואיד של Chrome יש מגבלות שונות: רק טאבלטים, Service Worker חובה, שליטה במגע. נתקלנו בפרויקטים שבהם הרחבה מוכנה נכשלה בבדיקת Google עקב שימוש לא נכון ב-API — לדוגמה, ניסיון לשמור נתונים במשתנים גלובליים של Service Worker או שימוש באירועי mouseover שלא עובדים על מסכי מגע. לצוות שלנו יש ניסיון של למעלה מ-5 שנים בהרחבות דפדפן ויותר מ-10 פרויקטים מוצלחים ב-Chrome Web Store — אנו מבטיחים תאימות וביצועים.
כיצד לפתח הרחבת Chrome לאנדרואיד
מה זמין בפועל ומה לא
הרחבות ל-Chrome Android הן אותן WebExtensions (Manifest V3) כמו ל-Chrome לשולחן העבודה. רוב ה-APIs עובדים, אך עם התאמה לפלטפורמה הניידת.
עובד: content_scripts, browser_action (חלון קופץ של סרגל הכלים), storage.local, tabs (טאב פעיל), runtime.sendMessage, declarativeNetRequest לחסימת תוכן. לא עובד או שונה: background.js — רק Service Worker, סקריפט רקע קבוע בלתי אפשרי. windows API — חלון יחיד. contextMenus — תפריט הקשר במגע שונה.
| API | Chrome לשולחן העבודה | Chrome Android |
|---|---|---|
| Service Worker | רקע קבוע | נטען מחדש על ידי המערכת |
| browser_action/popup | רוחב קבוע | רוחב מוגבל 300–400 פיקסלים |
| contextMenus | תמיכה מלאה | מוגבל, מותאם למגע |
| declarativeNetRequest | מלא | מלא |
Service Worker בגרסת האנדרואיד חוסך עד 40% זיכרון בהשוואה לתהליך הרקע הישן, אך דורש עיצוב מחדש של הלוגיקה MDN Web Docs.
מדוע Manifest V3 הוא חובה לאנדרואיד
{
"manifest_version": 3,
"name": "My Extension",
"version": "1.0",
"permissions": ["storage", "activeTab"],
"background": {
"service_worker": "background.js"
},
"action": {
"default_popup": "popup.html",
"default_icon": "icon.png"
},
"content_scripts": [
{
"matches": ["https://*/*"],
"js": ["content.js"]
}
]
}הרחבות Manifest V2 כבר הושבתו ב-Chrome לשולחן העבודה ואינן נתמכות באנדרואיד. כל הפרויקטים שלנו משתמשים רק ב-Manifest V3 — זה מבטיח תאימות לגרסאות דפדפן עתידיות.
כיצד Service Worker משפיע על ביצועים
Service Worker לא נשאר פעיל כל הזמן — Chrome יכול לפרוק אותו בכל רגע. לא ניתן לאחסן מצב במשתנים: רק ב-{ "manifest_version": 3, "name": "My Extension", "version": "1.0", "permissions": ["storage", "activeTab"], "background": { "service_worker": "background.js" }, "action": { "default_popup": "popup.html", "default_icon": "icon.png" }, "content_scripts": [{ "matches": ["https://*/*"], "js": ["content.js"] }] } . טעות אופיינית היא אחסון נתונים במשתנה גלובלי של Worker. בטעינה הראשונה הכל עובד, לאחר הפעלה מחדש — chrome.storage. אנו מתכננים את הארכיטקטורה תוך התחשבות בהתנהגות זו כדי למנוע אובדן נתונים.
// Неправильно
let userData = {};
// Правильно
chrome.storage.local.get(['userData'], (result) => {
const userData = result.userData || {};
// работаем с userData
});לשם השוואה, סקריפט רקע קבוע ב-Manifest V2 צרך פי שניים זיכרון, ו-Service Worker ב-MV3 נטען רק בעת הצורך, מה שחיוני לטאבלטים עם משאבים מוגבלים.
כיצד להתאים את החלון הקופץ לממשק מגע
החלון הקופץ נפתח בלחיצה על סמל סרגל הכלים — בטאבלט הוא נמצא בצד ימין בשורת הכתובת. החלון הקופץ הוא HTML עם רוחב מוגבל (300–400 פיקסלים). למגע, אלמנטים אינטראקטיביים חייבים להיות בגובה של לפחות 44 פיקסלים. סקריפטים של תוכן במגע: אירועי undefined/// Неправильно let userData = {}; // Правильно chrome.storage.local.get(['userData'], (result) => { const userData = result.userData || {}; // работаем с userData }); לא מופעלים — החליפו אותם ב-mouseover/mouseenter. אם גרסת שולחן העבודה משתמשת ב-hover לתצוגה מקדימה, באנדרואיד אנו משנים זאת ללחיצה. גישה זו מפחיתה שגיאות אינטראקציה ב-30–50%.
כיצד אנו בודקים התאמה למגע?
אנו משתמשים באמולטורים של טאבלטים ובמכשירים אמיתיים עם גרסאות Android שונות. אנו בודקים טיפול נכון באירועי מגע, ללא הקפאות במהלך החלקות מהירות, ועמידה ויזואלית במוקאפ.שגיאות אופייניות וכיצד לתקן אותן
בעיה נפוצה אחת היא אחסון מצב במשתנים גלובליים של Service Worker. כאשר ה-Worker נפרק, הנתונים אובדים. הפתרון הוא להשתמש ב-touchstart, השומר נתונים גם לאחר פריקה. טעות נוספת היא שימוש באירועי click בסקריפטים של תוכן בטאבלטים. במסכי מגע, אירועים אלה לא נוצרים, לכן החליפו אותם ב-chrome.storage.local או mouseover. מלכודת שלישית היא רוחב חלון קופץ קטן מ-300 פיקסלים. Google דורשת רוחב מינימלי של 320 פיקסלים, אחרת ההרחבה נדחית. אנו תמיד מתכנתים עם מרווח ביטחון ופריסה רספונסיבית. לבסוף, פרסום ללא בדיקה על מכשיר אמיתי הוא סיבה נפוצה לדחייה. אנו בודקים על טאבלטים של Samsung, Lenovo ומכשירי ChromeOS.
תהליך הפיתוח ולוחות זמנים
- ניתוח דרישות — קביעת מכשירי יעד, APIs, אינטגרציות.
- עיצוב ארכיטקטורה — סכמת Service Worker, אחסון, אינטראקציה עם תוכן.
- יישום — כתיבת קוד ב-Manifest V3 תוך התחשבות במגבלות מגע ופלטפורמה.
- בדיקה — על טאבלטים עם Android ו-ChromeOS, בדיקת פריקת Service Worker, אירועי מגע.
- פרסום — העלאה ל-Chrome Web Store, מעבר בדיקת Google.
לוחות זמנים: הרחבה פשוטה — בין 3 ל-5 ימים; מורכבת עם Service Worker ואחסון — בין 2 ל-3 שבועות. צרו קשר להערכת פרויקט — נחשב את העלות באופן אישי. הזמינו פיתוח הרחבה במפתח — קבלו פתרון מוכן המותאם לאנדרואיד.
מה כלול
- ניתוח דרישות ואב-טיפוס
- ארכיטקטורת Manifest V3
- יישום סקריפטים של תוכן, חלון קופץ, Service Worker
- התאמת ממשק מגע
- אינטגרציה עם
click,touchstart - בדיקה על מכשירים אמיתיים
- פרסום ב-Chrome Web Store
- תיעוד API והוראות שימוש
- אחריות חודש אחד לאחר ההשקה
למה לבחור בנו
אנו מפתחים מוסמכים עם ניסיון של 5+ שנים בהרחבות דפדפן. למעלה מ-10 פרויקטים רצים בהצלחה ב-Chrome Web Store. אנו מבטיחים תאימות לגרסאות Chrome העדכניות ועמידה בהנחיות פיתוח WebExtensions.







