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