תהליכים ברקע יכולים להיות עתירי זיכרון וסוללה. לדוגמה, שידור משתמע עשוי להפעיל הרבה תהליכי רקע שנרשמו להאזין לו, גם אם התהליכים האלה לא מבצעים הרבה עבודה. הדבר יכול להשפיע באופן משמעותי על ביצועי המכשיר ועל חוויית המשתמש.
כדי לצמצם את הבעיה הזו, בגרסה 7.0 של Android (רמת API 24) חלות ההגבלות הבאות:
- אפליקציות שמטרגטות את Android מגרסה 7.0 (רמת API 24) ואילך לא מקבלות שידורי
CONNECTIVITY_ACTION
אם הן מצהירות על מקלט השידור שלהן במניפסט. אפליקציות עדיין יקבלו שידוריCONNECTIVITY_ACTION
אם הן יירשמו עםBroadcastReceiver
ב-Context.registerReceiver()
וההקשר הזה עדיין תקף. - אפליקציות לא יכולות לשלוח או לקבל שידורים של
ACTION_NEW_PICTURE
אוACTION_NEW_VIDEO
. האופטימיזציה הזו משפיעה על כל האפליקציות, ולא רק על אלה שמטרגטות ל-Android 7.0 (רמת API 24).
אם האפליקציה שלך משתמשת באחד מהאובייקטים האלה של Intent, עליך להסיר את התלות באובייקטים האלה בהקדם האפשרי כדי שתהיה לך אפשרות לטרגט כראוי מכשירים עם Android 7.0
ואילך. ה-framework של Android מספק מספר פתרונות כדי לצמצם את
הצורך בשידורים מרומזים כאלה. לדוגמה, JobScheduler
ו-WorkManager החדש מספקים מנגנונים חזקים לתזמון פעולות ברשת כשמתקיימים תנאים מסוימים, כמו חיבור לרשת ללא חיוב לפי שימוש. עכשיו אפשר גם להשתמש ב-JobScheduler
כדי להגיב לשינויים בספקי התוכן. אובייקטים של JobInfo
מכילים את הפרמטרים שבהם JobScheduler
משתמש כדי לתזמן את המשימה. כשהתנאים של המשימה מתקיימים, המערכת מבצעת אותה ב-JobService
של האפליקציה.
בדף הזה נסביר איך להשתמש בשיטות חלופיות, כמו JobScheduler
, כדי להתאים את האפליקציה להגבלות החדשות האלה.
הגבלות שמשתמשים יוזמים
בדף שימוש בסוללה בהגדרות המערכת, המשתמש יכול לבחור מבין האפשרויות הבאות:
- ללא הגבלה: מתן הרשאה לכל הפעולות ברקע, שעשויות לצרוך יותר סוללה.
- אופטימיזציה (ברירת המחדל): אופטימיזציה של היכולת של האפליקציה לבצע משימות ברקע, על סמך האינטראקציה של המשתמש עם האפליקציה.
- מוגבלת: ההגדרה הזו מונעת לגמרי מאפליקציה לפעול ברקע. יכול להיות שהאפליקציות לא יפעלו כצפוי.
אם אפליקציה מציגה חלק מההתנהגויות השליליות שמתוארות במדדי הפעילות של Android, יכול להיות שהמערכת תבקש מהמשתמש להגביל את הגישה של האפליקציה הזו למשאבי המערכת.
אם המערכת מזהה שאפליקציה צורכת משאבים מיותרים, היא תודיע למשתמש ותאפשר לו להגביל את הפעולות של האפליקציה. התנהגויות שיכולות להפעיל את ההודעה:
- חסימות מצב שינה מוגזמות: חסימה מצב שינה חלקית אחת שנמשכת שעה כשהמסך כבוי
- שירותי רקע מוגזמים: אם האפליקציה מטרגטת לרמות API נמוכות מ-26 ויש לה יותר מדי שירותי רקע
ההגבלות המדויקות שהוטלו נקבעות על ידי יצרן המכשיר. לדוגמה, בגרסאות build של AOSP שפועלות עם Android 9 (רמת API 28) ואילך, לאפליקציות שפועלות ברקע במצב 'מוגבל' יש את המגבלות הבאות:
- לא ניתן להפעיל שירותים שפועלים בחזית
- שירותים קיימים שפועלים בחזית יוסרו מהחזית
- ההתראות לא מופעלות
- משימות לא מתבצעות
בנוסף, אם אפליקציה מטרגטת ל-Android 13 (רמת API 33) ואילך והיא נמצאת במצב 'מוגבל', המערכת לא מעבירה את השידור BOOT_COMPLETED
או את השידור LOCKED_BOOT_COMPLETED
עד שהאפליקציה מופעלת מסיבות אחרות.
המגבלות הספציפיות מפורטות בקטע הגבלות על ניהול צריכת החשמל.
הגבלות על קבלת שידורים של פעילות ברשת
אפליקציות שמטרגטות את Android 7.0 (רמת API 24) לא מקבלות שידורי CONNECTIVITY_ACTION
אם הן נרשמות לקבלתם במניפסט, ותהליכים שתלויים בשידור הזה לא יתחילו לפעול. המצב הזה עלול להוות בעיה לאפליקציות שרוצות להקשיב לשינויים ברשת או לבצע פעילויות מרובות ברשת כשהמכשיר מחובר לרשת ללא חיוב לפי שימוש. כבר קיימים ב-Android כמה פתרונות לעקיפת
ההגבלה הזו, אבל חשוב לבחור
את הפתרון המתאים בהתאם למה שרוצים שהאפליקציה תבצע.
הערה: מכשיר BroadcastReceiver
שמשויך ל-Context.registerReceiver()
ממשיך לקבל את השידור הזה בזמן שהאפליקציה פועלת.
תזמון משימות רשת בחיבורים ללא מדידה
כשמשתמשים במחלקה JobInfo.Builder
כדי ליצור את האובייקט JobInfo
, צריך להחיל את השיטה setRequiredNetworkType()
ולהעביר את JobInfo.NETWORK_TYPE_UNMETERED
כפרמטר של משימה. דוגמת הקוד הבאה
מתזמנת שירות כך שיפעל כשהמכשיר מתחבר לרשת שאינה נמדדת
ונמצא בטעינה:
Kotlin
const val MY_BACKGROUND_JOB = 0 ... fun scheduleJob(context: Context) { val jobScheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler val job = JobInfo.Builder( MY_BACKGROUND_JOB, ComponentName(context, MyJobService::class.java) ) .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED) .setRequiresCharging(true) .build() jobScheduler.schedule(job) }
Java
public static final int MY_BACKGROUND_JOB = 0; ... public static void scheduleJob(Context context) { JobScheduler js = (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE); JobInfo job = new JobInfo.Builder( MY_BACKGROUND_JOB, new ComponentName(context, MyJobService.class)) .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED) .setRequiresCharging(true) .build(); js.schedule(job); }
כשהתנאים של המשימה מתקיימים, האפליקציה מקבלת קריאה חוזרת (callback) להרצת השיטה onStartJob()
ב-JobService.class
שצוין. דוגמאות נוספות להטמעת JobScheduler
זמינות באפליקציית הדוגמה JobScheduler.
חלופה חדשה ל-JobScheduler היא WorkManager, ממשק API שמאפשר לתזמן משימות רקע שצריך להבטיח את השלמתן, גם אם תהליך האפליקציה לא פועל. WorkManager בוחר את הדרך המתאימה להפעלת העבודה (באופן ישיר בשרשור בתהליך האפליקציה, וגם באמצעות JobScheduler, FirebaseJobDispatcher או AlarmManager) על סמך גורמים כמו רמת ה-API של המכשיר. בנוסף, לא צריך את Play Services כדי להשתמש ב-WorkManager, והוא מספק כמה תכונות מתקדמות, כמו קישור משימות או בדיקת סטטוס של משימה. למידע נוסף, ראו WorkManager.
מעקב אחר החיבור לרשת בזמן שהאפליקציה פועלת
אפליקציות שפועלות עדיין יכולות להאזין ל-CONNECTIVITY_CHANGE
עם
BroadcastReceiver
רשום. עם זאת, ב-ConnectivityManager
API יש שיטה חזקה יותר לבקשה של קריאה חוזרת רק כשמתקיימים תנאי הרשת שצוינו.
האובייקטים של NetworkRequest
מגדירים את הפרמטרים של הקריאה החוזרת (callback) ברשת במונחים של NetworkCapabilities
. יוצרים NetworkRequest
אובייקטים במחלקה NetworkRequest.Builder
. registerNetworkCallback()
מעביר את האובייקט NetworkRequest
למערכת. כשהתנאים ברשת מתקיימים, האפליקציה מקבלת קריאה חוזרת (callback) כדי להריץ את השיטה onAvailable()
שהוגדרה בכיתה ConnectivityManager.NetworkCallback
שלה.
האפליקציה ממשיכה לקבל קריאות חוזרות עד שהיא יוצאת או קוראת ל-unregisterNetworkCallback()
.
הגבלות על קבלת שידורים של תמונות וסרטונים
ב-Android 7.0 (רמת API 24), אפליקציות לא יכולות לשלוח או לקבל שידורים של ACTION_NEW_PICTURE
או ACTION_NEW_VIDEO
. ההגבלה הזו
מצמצמת את הביצועים ואת ההשפעות על חוויית המשתמש במקרים שבהם מספר אפליקציות צריכות לצאת ממצב שינה כדי לעבד תמונה או סרטון חדשים. מערכת Android 7.0 (רמת API 24)
מורחבת ב-JobInfo
וב-JobParameters
כדי לספק פתרון חלופי.
הפעלת משימות כשיש שינויים ב-URI של תוכן
כדי להפעיל משימות בעקבות שינויים ב-URI של תוכן, Android 7.0 (רמת API 24) מרחיב את ה-API JobInfo
באמצעות השיטות הבאות:
-
JobInfo.TriggerContentUri()
- עטיפת הפרמטרים הנדרשים להפעלת משימה במקרה של שינויים במזהי URI של תוכן.
-
JobInfo.Builder.addTriggerContentUri()
-
מעביר אובייקט
TriggerContentUri
אלJobInfo
.ContentObserver
מנטר את URI של התוכן המתומצת. אם יש כמה אובייקטים מסוגTriggerContentUri
שמשויכים למשימה, המערכת מספקת קריאה חוזרת (callback) גם אם היא מדווחת על שינוי רק באחד ממזהי ה-URI של התוכן. -
מוסיפים את הדגל
TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS
כדי להפעיל את המשימה אם יש שינוי באחד מהצאצאים של ה-URI הנתון. הדגל הזה תואם לפרמטרnotifyForDescendants
שמוענק ל-registerContentObserver()
.
הערה: אי אפשר להשתמש ב-TriggerContentUri()
בשילוב עם setPeriodic()
או setPersisted()
. כדי לעקוב באופן שוטף אחרי שינויים בתוכן, צריך לתזמן JobInfo
חדש לפני ש-JobService
של האפליקציה מסיים לטפל בקריאה החוזרת האחרונה.
הקוד לדוגמה הבא מתזמן משימה שתופעל כשהמערכת מדווחת על שינוי ב-URI של התוכן, MEDIA_URI
:
Kotlin
const val MY_BACKGROUND_JOB = 0 ... fun scheduleJob(context: Context) { val jobScheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler val job = JobInfo.Builder( MY_BACKGROUND_JOB, ComponentName(context, MediaContentJob::class.java) ) .addTriggerContentUri( JobInfo.TriggerContentUri( MediaStore.Images.Media.EXTERNAL_CONTENT_URI, JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS ) ) .build() jobScheduler.schedule(job) }
Java
public static final int MY_BACKGROUND_JOB = 0; ... public static void scheduleJob(Context context) { JobScheduler js = (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE); JobInfo.Builder builder = new JobInfo.Builder( MY_BACKGROUND_JOB, new ComponentName(context, MediaContentJob.class)); builder.addTriggerContentUri( new JobInfo.TriggerContentUri(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS)); js.schedule(builder.build()); }
כשהמערכת מדווחת על שינוי ב-URI של התוכן שצוין, האפליקציה מקבלת קריאה חוזרת(callback) ואובייקט JobParameters
מועבר לשיטה onStartJob()
ב-MediaContentJob.class
.
איך בודקים אילו רשויות תוכן הפעילו משימה
ב-Android 7.0 (רמת API 24) הורחבה גם ההגדרה JobParameters
כדי לאפשר לאפליקציה לקבל מידע שימושי על רשויות התוכן וכתובות ה-URI שהפעילו את המשימה:
-
Uri[] getTriggeredContentUris()
-
מערך של מזהי URI שהפעילו את המשימה. הערך יהיה
null
אם אף URI לא הפעיל את המשימה (לדוגמה, המשימה הופעלה עקב מועד הגשה או מסיבה אחרת), או אם מספר ה-URIs שהשתנו גדול מ-50. -
String[] getTriggeredContentAuthorities()
-
מחזירה מערך מחרוזות של רשויות תוכן שהפעילו את המשימה.
אם המערך שמוחזר הוא לא
null
, משתמשים ב-getTriggeredContentUris()
כדי לאחזר את הפרטים של מזהי ה-URI שהשתנו.
הקוד לדוגמה הבא מבטל את השיטה JobService.onStartJob()
ומתעדה את רשויות התוכן ואת מזהי ה-URI שהפעילו את המשימה:
Kotlin
override fun onStartJob(params: JobParameters): Boolean { StringBuilder().apply { append("Media content has changed:\n") params.triggeredContentAuthorities?.also { authorities -> append("Authorities: ${authorities.joinToString(", ")}\n") append(params.triggeredContentUris?.joinToString("\n")) } ?: append("(No content)") Log.i(TAG, toString()) } return true }
Java
@Override public boolean onStartJob(JobParameters params) { StringBuilder sb = new StringBuilder(); sb.append("Media content has changed:\n"); if (params.getTriggeredContentAuthorities() != null) { sb.append("Authorities: "); boolean first = true; for (String auth : params.getTriggeredContentAuthorities()) { if (first) { first = false; } else { sb.append(", "); } sb.append(auth); } if (params.getTriggeredContentUris() != null) { for (Uri uri : params.getTriggeredContentUris()) { sb.append("\n"); sb.append(uri); } } } else { sb.append("(No content)"); } Log.i(TAG, sb.toString()); return true; }
אופטימיזציה נוספת של האפליקציה
אופטימיזציה של האפליקציות כך שיפעלו במכשירים עם נפח זיכרון נמוך, או בתנאים של נפח זיכרון נמוך, יכולה לשפר את הביצועים ואת חוויית המשתמש. הסרת התלות בשירותי רקע ובמקלטי שידורים משתמעים שרשומים כמניפסטים יכולה לעזור לאפליקציה שלך לפעול טוב יותר במכשירים כאלה. מערכת Android 7.0 (רמת API 24) מצמצמת חלק מהבעיות האלה, אבל מומלץ לבצע אופטימיזציה של האפליקציה כך שתפעל בלי להשתמש בתהליכי הרקע האלה.
הפקודות הבאות של Android Debug Bridge (ADB) יכולות לעזור לכם לבדוק את התנהגות האפליקציה כשתהליכי הרקע מושבתים:
- כדי לדמות תנאים שבהם שידורים מרומזים ושירותים ברקע לא זמינים, מזינים את הפקודה הבאה:
-
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore
- כדי להפעיל מחדש שידורים מרומזים ושירותים ברקע, מזינים את הפקודה הבאה:
-
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow
- אתם יכולים לדמות מצב שבו המשתמש מעביר את האפליקציה שלכם למצב 'מוגבל' בנוגע לשימוש בסוללה ברקע. ההגדרה הזו מונעת מהאפליקציה לפעול ברקע. כדי לעשות זאת, מריצים את הפקודה הבאה בחלון מסוף:
-
$ adb shell cmd appops set <PACKAGE_NAME> RUN_ANY_IN_BACKGROUND deny