כרטיסיות רקע ב-Chrome 57

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

ביצוע אופטימיזציה של אפליקציה לרקע

מפתחי אתרים צריכים להיות מודעים לכך שלמשתמשים בדרך כלל יש הרבה כרטיסיות פתוחות ברקע עלולה להיות לה השפעה חמורה על השימוש בחשמל ועל חיי הסוללה. עבודה ברקע צריך להיות מינימלי, אלא אם הדבר הכרחי לחוויית משתמש מסוימת. צריך להשתמש ב-Page visibility API כדי לזהות מתי הדף נמצא ברקע ולהשהות את כל העבודה הלא הכרחית, כמו עדכונים חזותיים.

בחלק מהאתרים האופטימיזציה הפשוטה הזו יכולה להפחית את השימוש במעבד בשיעור של עד 75%:

var doVisualUpdates = true;

document.addEventListener('visibilitychange', function(){
    doVisualUpdates = !document.hidden;
});

function update() {
    if (!doVisualUpdates) {
    return;
    }
    doStuff();
}

מדיניות

requestAnimationFrame()

בהתאם למסמכי העזרה, Chrome לא קורא ל-requestAnimationFrame() כשדף נמצא ברקע. ההתנהגות הזו קיימת מאז 2011.

יישור הטיימר ברקע

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

חשוב לזכור: אודיו נחשב כאודיו רק כשסמל האודיו מוצג ב-Chrome. שידורי אודיו שקטים לא מקבלים פטור.

ויסות נתונים (throttling) של טיימר ברקע שמבוסס על תקציב

משלוח ב-Chrome 57, ויסות טיימר מבוסס-תקציב הוא הרחבה נוספת של מנגנון היישור של הטיימר, הוספת מגבלה נוספת על השימוש במעבד (CPU) בטיימר ברקע. כך זה עובד:

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

יש כמה פטורים אוטומטיים מויסות הנתונים הזה:

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

חשוב לזכור שהמנגנון הזה משתמש בזמן חולף, ולא בזמן מעבד. מדובר באומדן טוב של זמן ה-CPU, והוא מאפשר להעניש חסימה של ה-thread הראשי למשך זמן רב.

לבסוף, חשוב לזכור שאם משתמשים במשימות ארוכות ברקע, יכול להיות שהאפליקציה תוגבל למשך זמן רב מאוד (עד פי 100 ממשך המשימה). אפשר לפצל את העבודה למקטעי נתונים של 50 אלפיות השנייה או פחות לכל ההנחיות לגבי ביצועים ולהשתמש ב-listener visibilityChange כדי להימנע מביצוע עבודה מיותרת ברקע.

ביטולי הסכמה

הדגל --disable-background-timer-throttling ב-Chrome מיועד למקרים לדוגמה כמו הפעלת חבילות בדיקות וחישובים כבדים אחרים שאושרו על ידי המשתמשים.