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

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

כדי לצמצם את הבעיה הזו, בגרסה 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