אופטימיזציה של הגישה לרשת

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

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

מכונת המצבים של הרדיו

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

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

מכונת המצבים של מכשיר רדיו טיפוסי לרשת 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 לניהול האינטראקציות האלה בצורה יעילה.