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

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

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

אם האפליקציה שלכם משתמשת באחת מהכוונות האלה, עליכם להסיר את התלות בהן בהקדם האפשרי כדי שתוכלו לטרגט כראוי מכשירים עם Android מגרסה 7.0 ואילך. מסגרת 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) נוספו ל-JobInfo API השיטות הבאות:

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