השימוש ברדיו האלחוטי להעברת נתונים הוא אחד האמצעים הנפוצים ביותר באפליקציה מקורות משמעותיים של התרוקנות הסוללה. כדי למזער את אפשרות התרוקנות הסוללה עם פעילות ברשת, חשוב מאוד להבין איך הקישוריות ישפיע על חומרת הרדיו שעליה מבוסס הרדיו.
קטע זה מציג את מכונת מצב הרדיו האלחוטית ומסביר כיצד מודל הקישוריות של האפליקציה מקיים אינטראקציה איתה. לאחר מכן הוא מציע כמה שיטות מידע כזה יעזור לצמצם את ההשפעה של נתוני האפליקציה צריכת הסוללה.
מכשיר מצב הרדיו
הרדיו האלחוטי במכשיר של המשתמש כולל תכונות מובנות לחיסכון בחשמל כדי לצמצם את צריכת הסוללה שלו. כשהערך פעיל באופן מלא, רדיו אלחוטי צורך חשמל רב, אבל כשהוא לא פעיל או במצב המתנה, הרדיו צורך מעט מאוד חשמל.
אחד מהגורמים שחשוב לזכור הוא שהרדיו לא יכול לעבור ממצב המתנה אל באופן מיידי. יש תקופת זמן אחזור שמשויכת "לחדד את ההנחיה" ברדיו. כך הסוללה עוברת ממצבים של צריכת אנרגיה גבוהה יותר למצב רמת אנרגיה נמוכה יותר מופיעה באיטיות, כדי לחסוך בצריכת החשמל בזמן שהיא לא בשימוש בניסיון לצמצם את זמן האחזור שקשור ל"טעינה" ברדיו.
מכונה המדינה לרדיו של רשת 3G טיפוסית מורכבת משלושה מצבי אנרגיה:
- הפעלה מלאה: השירות משמש כשחיבור פעיל, וכך המכשיר יכול: להעביר נתונים בקצב גבוה ככל האפשר.
- אספקת חשמל נמוכה: מצב ביניים שמפחית את צריכת הסוללה בשיעור של בערך 50%.
- Standby: מצב צריכת החשמל המינימלית שבמהלכו אין רשת חיבור פעיל.
המצבים 'חלש' ו'מצב המתנה' מתרוקנים פחות משמעותית, אבל הם גם יצירת זמן אחזור משמעותי לבקשות רשת. חוזרים לסוללה מלאה מ- מצב 'נמוך' נמשך כ-1.5 שניות, ועובר ממצב המתנה לחשמל מלא יכולה להימשך יותר מ-2 שניות.
כדי למזער את זמן האחזור, מכונת המצב משתמשת בעיכוב כדי לדחות את המעבר למצבים של אנרגיה נמוכה יותר. איור 1 משתמש בתזמונים של AT&T לרדיו 3G טיפוסי.
מכשיר מצב הרדיו בכל מכשיר, בייחוד המעבר המשויך העיכוב ("זמן הסוף") וזמן האחזור של ההפעלה, ישתנו בהתאם לרדיו האלחוטי שנעשה בה שימוש (3G, LTE, 5G וכן הלאה) ומוגדרת ומוגדרת על ידי הרשת של הספק שדרכה המכשיר פועל.
בדף זה מתוארת מכונה מייצגת של מכשיר אלחוטי טיפוסי של 3G רדיו, שמבוסס על נתונים שסופקו על ידי AT&T. אבל העקרונות הכלליים כתוצאה מכך, ניתן ליישם את השיטות המומלצות בכל יישומי הרדיו האלחוטי.
הגישה הזו יעילה במיוחד בגלישה רגילה באינטרנט לנייד, כי היא למניעת זמן אחזור לא רצוי בזמן שמשתמשים גולשים באינטרנט. היא נמוכה יחסית זמן אחזור תכנים מבטיח גם שבתום סשן גלישה, הרדיו למצב צריכת אנרגיה נמוכה יותר.
לצערנו, הגישה הזו עלולה להוביל לאפליקציות לא יעילות בסמארטפונים מודרניים במערכות הפעלה כמו Android, שבהן האפליקציות פועלות בחזית זמן האחזור חשוב) וברקע (שם חיי הסוללה צריכים להיות ).
איך אפליקציות משפיעות על מכשיר מצב הרדיו
בכל פעם שיוצרים חיבור חדש לרשת, הרדיו עובר אל מצב של אספקת חשמל מלאה. אם מדובר במכונה הטיפוסית של רדיו 3G שמתוארת קודם לכן, המכשיר יישאר במצב מלא במהלך כל תקופת ההעברה — וגם 5 שניות נוספות של זמן "זנב" ואז 12 שניות בצריכת אנרגיה נמוכה . כך שעבור מכשיר 3G טיפוסי, כל סשן של העברת נתונים יגרום כדי לנצל אנרגיה למשך 18 שניות לפחות.
בפועל, המשמעות היא שאפליקציה שמבצעת העברת נתונים שנייה אחת, שלוש פעמים בדקה, הרדיו האלחוטי ימשיך לפעול באופן קבוע, ומזיז אותו בחזרה לחשמל בעוצמה גבוהה בדיוק כשהוא עובר למצב המתנה.
לשם השוואה, אם אותה אפליקציה ארזה את העברות הנתונים שלה, העברה של שלוש שניות כל דקה, כך שהרדיו יישאר בעוצמה גבוהה למשך זמן כולל של 20 שניות בלבד כל דקה. הפעולה הזו תאפשר לרדיו: יהיה בהמתנה במשך 40 שניות בכל דקה, וכתוצאה מכך ירידה בצריכת הסוללה.
טכניקות אופטימיזציה
עכשיו, אחרי שהבנתם איך הגישה לרשת משפיעה על חיי הסוללה, בואו נדבר על זה: כמה דברים שאפשר לעשות כדי להפחית את התרוקנות הסוללה, מתן חוויית משתמש מהירה וזורמת.
העברות נתונים בחבילות
כפי שצוין בקטע הקודם, קיבוץ העברות הנתונים הוא בהתאם העברת נתונים בתדירות נמוכה יותר היא אחת הדרכים הטובות ביותר לשיפור הסוללה יעילות.
כמובן, לא תמיד אפשר לעשות זאת אם האפליקציה צריכה לקבל או שליחה של נתונים באופן מיידי בתגובה לפעולת משתמש. אפשר לצמצם את הבעיה באמצעות חיזוי ושליפה מראש של נתונים. תרחישים אחרים, כמו שליחת יומנים או ניתוחי נתונים לשרת ונתונים אחרים שמופעלים על ידי האפליקציה, לא דחופים מתאימות מאוד לקיבוץ וקיבוץ. למידע נוסף, ראו אופטימיזציה ביוזמת אפליקציה משימות בשביל טיפים לתזמון העברות של רשת ברקע.
שליפה מראש של נתונים
שליפה מראש של נתונים היא דרך יעילה נוספת לצמצום מספר הנתונים הבלתי תלויים פעילויות של העברת נתונים באפליקציה. בשליפה מראש (prefetch), כשהמשתמש מבצע פעולה באפליקציה, האפליקציה צופה אילו נתונים סביר להניח נדרש לסדרה הבאה של פעולות משתמש, ומאחזר את הנתונים האלה בפעולה אחת כדי להתפוצץ, בחיבור יחיד, בקיבולת מלאה.
טעינה קדמית של ההעברות מפחיתה את מספר הפעלות הרדיו שנדרשים כדי להוריד את הנתונים. כתוצאה מכך, לא רק מאריכים את חיי הסוללה, אבל גם לשפר את זמן האחזור, להפחית את רוחב הפס הדרוש ולצמצם את ההורדה פעמים.
השליפה מראש (prefetch) גם משפרת את חוויית המשתמש על ידי צמצום החיפוש בתוך האפליקציה זמן אחזור נובע מהמתנה להשלמת ההורדות לפני ביצוע פעולה או הצגת הנתונים.
נראה דוגמה מעשית.
קורא חדשות
אפליקציות חדשות רבות מנסות לצמצם את רוחב הפס על ידי הורדת כותרות רק לאחר נבחרה קטגוריה, כתבות מלאות רק כשהמשתמש רוצה לקרוא אותן, ותמונות ממוזערות, ממש כפי שהן נגללות לתצוגה.
בגישה הזו, הרדיו חייב להישאר פעיל לרוב של המשתמשים בזמן שהם גוללים בכותרות, משנים קטגוריות לקרוא מאמרים. מעבר לזה, המעבר המתמיד בין מצבי האנרגיה יובילו לזמן אחזור משמעותי כשמחליפים קטגוריות או מבצעים קריאה מאמרים
עדיף לשלוף מראש כמות סבירה של נתונים בזמן ההפעלה, החל מהסדרה הראשונה של כותרות חדשות ותמונות ממוזערות, באופן שמבטיח עם זמן אחזור קצר, והמערכת תמשיך לפעול עם שאר הכותרות תמונות ממוזערות, וגם את הטקסט של כל מאמר שזמין לפחות רשימת הכותרות הראשית.
חלופה נוספת היא לאחזר מראש כל כותרת, תמונה ממוזערת, טקסט מאמר אולי אפילו תמונות מלאות של כתבה - בדרך כלל ברקע לוח זמנים קבוע מראש. גישה זו מסתכנת בהוצאה משמעותית ברוחב פס חיי סוללה שמורידים תוכן שלא נעשה בו שימוש אף פעם, לכן צריך להטמיע אותו בזהירות.
שיקולים נוספים
לשליפה מראש (prefetch) של נתונים יש יתרונות רבים, אבל נעשה בה שימוש אגרסיבי מדי שליפה מראש (prefetch) גם מגדילה את הסיכון להגברת התרוקנות הסוללה ורוחב הפס להשתמש בו – וכן במכסת ההורדות – על ידי הורדת נתונים שלא נמצאים בשימוש. זה גם כדי לוודא שהשליפה מראש לא מעכבת את ההפעלה של האפליקציה, האפליקציה ממתינה להשלמת השליפה מראש (prefetch). מבחינה מעשית עשויה להוביל מתבצע עיבוד נתונים הדרגתי או להתחיל העברות ברצף לפי עדיפות כך שהנתונים שנדרשים להפעלת האפליקציה יורדו ומעובדים קודם.
מידת האגרסיביות שבה השליפה מראש של נתונים תלויה בגודל הנתונים והסבירות שייעשה בו שימוש. כמדריך כללי, בהתאם שתואר קודם לכן, לגבי נתונים שיש סיכוי של 50% שהם ינוצלו בסשן הנוכחי של המשתמש, בדרך כלל אפשר לאחזר מראש למשך כ-6 שניות (בערך 1-2 מגה-בייט) לפני העלות הפוטנציאלית של הורדה שאינה בשימוש תואם לחיסכון האפשרי בכך שלא תתבצע הורדה של הנתונים מלכתחילה.
באופן כללי, מומלץ לאחזר מראש נתונים כך תצטרכו להתחיל הורדה נוספת כל 2 עד 5 דקות, ובסדר של 1 עד 1 5 מגה-בייט.
בהתאם לעיקרון זה, הורדות גדולות (כגון קובצי וידאו) צריכות להיות להוריד במקטעים במרווחי זמן קבועים (כל 2 עד 5 דקות), ביעילות אחזור מראש רק של נתוני הסרטונים שסביר להניח שייצפו בהם בדקות הקרובות.
פתרון אחד הוא לתזמן את ההורדה המלאה כך שתתרחש רק כאשר אתם מחוברים אל חיבור Wi-Fi, ויכול להיות שרק כשהמכשיר בטעינה. ב-WorkManager API תומכת בדיוק בתרחיש לדוגמה הזה, וכך מאפשרת להגביל את העבודה ברקע עד שהמכשיר יעמוד בקריטריונים שצוינו על ידי המפתח, כמו טעינה מחובר לרשת Wi-Fi.
בדיקת קישוריות לפני שליחת בקשות
חיפוש של אות סלולרי הוא אחת מפעולות ניקוז החשמל
מהמכשיר הנייד. שיטה מומלצת לבקשות ביוזמת המשתמש היא לבדוק קודם אם יש
חיבור באמצעות
ConnectivityManager
, כפי שמוצג
מעקב אחרי סטטוס הקישוריות והחיבור
מכסת מאמרים ללא תשלום.
אם אין רשת, האפליקציה יכולה לחסוך בצריכת הסוללה אם לא תאלץ את הרדיו הסלולרי
כדי לבצע חיפוש. לאחר מכן ניתן לתזמן את הבקשה ולבצע אותה באצווה יחד עם
בקשות כשנוצר חיבור.
חיבורי בריכה
אסטרטגיה נוספת שיכולה לעזור לאחזור ולאחזור מראש: כדי ליצור מאגר של חיבורי הרשת של האפליקציה שלכם.
בדרך כלל עדיף להשתמש מחדש בחיבורי רשת קיימים כדי ליזום בדיקות חדשות. שימוש חוזר בחיבורים מאפשר גם לרשת להגיב בצורה חכמה יותר לעומס ולבעיות בנתונים ברשת.
HttpURLConnection
ורוב HTTP
כמו OkHttp, להפעיל
מאגר חיבורים כברירת מחדל, ושימוש חוזר באותו חיבור עבור
בקשות.
סיכום ומבט קדימה
בחלק הזה למדתם הרבה על הרדיו האלחוטי וכמה אסטרטגיות שאפשר ליישם באופן נרחב כדי לספק חוויית משתמש מהירה ורספונסיבית להפחתת התרוקנות הסוללה.
בקטע הבא נסביר בפירוט על שלושה סוגים שונים של אינטראקציות ברשת הנפוצות לרוב האפליקציות. כאן אפשר להבין את הנהגים בכל אחד מהמצבים האלה הסוגים האלו וכן שיטות מודרניות וממשקי API לניהול באופן יעיל יותר.