बैकग्राउंड ऑप्टिमाइज़ेशन

बैकग्राउंड में चलने वाली प्रोसेस, मेमोरी और बैटरी का ज़्यादा इस्तेमाल कर सकती हैं. उदाहरण के लिए, कोई इंप्लिसिट ब्रॉडकास्ट, बैकग्राउंड में कई ऐसी प्रोसेस शुरू कर सकता है जिन्होंने इसे सुनने के लिए रजिस्टर किया है. भले ही, वे प्रोसेस ज़्यादा काम न करें. इससे डिवाइस की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव, दोनों पर काफ़ी असर पड़ सकता है.

इस समस्या को कम करने के लिए, Android 7.0 (एपीआई लेवल 24) में ये पाबंदियां लागू की गई हैं:

  • Android 7.0 (एपीआई लेवल 24) और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को CONNECTIVITY_ACTION ब्रॉडकास्ट नहीं मिलते. ऐसा तब होता है, जब वे मेनिफ़ेस्ट में ब्रॉडकास्ट रिसीवर का एलान करते हैं. अगर ऐप्लिकेशन, Context.registerReceiver() के साथ BroadcastReceiver रजिस्टर करते हैं और वह कॉन्टेक्स्ट अब भी मान्य है, तो उन्हें अब भी CONNECTIVITY_ACTION ब्रॉडकास्ट मिलेंगे.
  • ऐप्लिकेशन, ACTION_NEW_PICTURE या ACTION_NEW_VIDEO ब्रॉडकास्ट न तो भेज सकते हैं और न ही पा सकते हैं. इस ऑप्टिमाइज़ेशन का असर सभी ऐप्लिकेशन पर पड़ता है. यह सिर्फ़ Android 7.0 (एपीआई लेवल 24) को टारगेट करने वाले ऐप्लिकेशन पर लागू नहीं होता.

अगर आपका ऐप्लिकेशन इनमें से किसी भी इंटेंट का इस्तेमाल करता है, तो आपको जल्द से जल्द इन पर निर्भरता हटा देनी चाहिए, ताकि Android 7.0 या उसके बाद के वर्शन वाले डिवाइसों को सही तरीके से टारगेट किया जा सके. Android फ़्रेमवर्क, इन इंप्लिसिट ब्रॉडकास्ट की ज़रूरत को कम करने के लिए कई समाधान उपलब्ध कराता है. उदाहरण के लिए, JobScheduler और नया WorkManager, नेटवर्क ऑपरेशन शेड्यूल करने के लिए मज़बूत तरीके उपलब्ध कराते हैं. ऐसा तब होता है, जब तय की गई शर्तें पूरी हो जाती हैं. जैसे, ऐसा इंटरनेट कनेक्शन जिस पर डेटा इस्तेमाल करने की कोई सीमा न हो. अब कॉन्टेंट उपलब्ध कराने वाली कंपनियों में हुए बदलावों पर प्रतिक्रिया देने के लिए, JobScheduler का इस्तेमाल भी किया जा सकता है. JobInfo ऑब्जेक्ट में वे पैरामीटर शामिल होते हैं जिनका इस्तेमाल JobScheduler आपके जॉब को शेड्यूल करने के लिए करता है. जब नौकरी की शर्तें पूरी हो जाती हैं, तो सिस्टम आपके ऐप्लिकेशन के JobService पर इस नौकरी को पूरा करता है.

इस पेज पर, हम JobScheduler जैसे अन्य तरीकों का इस्तेमाल करके, इन नई पाबंदियों के हिसाब से अपने ऐप्लिकेशन को ढालने का तरीका जानेंगे.

उपयोगकर्ता की ओर से लगाई गई पाबंदियां

सिस्टम सेटिंग में मौजूद बैटरी के इस्तेमाल पेज पर, उपयोगकर्ता इनमें से कोई विकल्प चुन सकता है:

  • बिना किसी पाबंदी के: बैकग्राउंड में सभी कामों को पूरा करने की अनुमति दें. इससे बैटरी ज़्यादा खर्च हो सकती है.
  • ऑप्टिमाइज़ किया गया (डिफ़ॉल्ट): यह विकल्प, ऐप्लिकेशन के बैकग्राउंड में काम करने की क्षमता को ऑप्टिमाइज़ करता है. यह इस बात पर निर्भर करता है कि उपयोगकर्ता, ऐप्लिकेशन से कैसे इंटरैक्ट करता है.
  • पाबंदी लगाई गई है: इससे किसी ऐप्लिकेशन को बैकग्राउंड में चलने से पूरी तरह से रोका जा सकता है. ऐसा हो सकता है कि ऐप्लिकेशन ठीक से काम न करें.

अगर कोई ऐप्लिकेशन, Android vitals में बताए गए कुछ खराब व्यवहार दिखाता है, तो सिस्टम उपयोगकर्ता को उस ऐप्लिकेशन के सिस्टम संसाधनों के ऐक्सेस को सीमित करने के लिए कह सकता है.

अगर सिस्टम को पता चलता है कि कोई ऐप्लिकेशन बहुत ज़्यादा संसाधनों का इस्तेमाल कर रहा है, तो वह उपयोगकर्ता को इसकी सूचना देता है. साथ ही, उसे ऐप्लिकेशन की कार्रवाइयों को सीमित करने का विकल्प देता है. इन गतिविधियों की वजह से, सूचना ट्रिगर हो सकती है:

  • वेक लॉक का ज़्यादा इस्तेमाल: स्क्रीन बंद होने पर, एक घंटे तक पार्शियल वेक लॉक का इस्तेमाल किया गया
  • बैकग्राउंड में बहुत ज़्यादा सेवाएं चल रही हैं: अगर ऐप्लिकेशन, एपीआई लेवल 26 से पहले के वर्शन को टारगेट करता है और उसमें बैकग्राउंड में बहुत ज़्यादा सेवाएं चल रही हैं

डिवाइस बनाने वाली कंपनी, यह तय करती है कि कौनसी पाबंदियां लगाई जाएंगी. उदाहरण के लिए, Android 9 (एपीआई लेवल 28) या इसके बाद के वर्शन पर चलने वाले AOSP बिल्ड पर, बैकग्राउंड में चल रहे "प्रतिबंधित" स्थिति वाले ऐप्लिकेशन पर ये पाबंदियां लागू होती हैं:

  • फ़ोरग्राउंड सेवाएं लॉन्च नहीं की जा सकतीं
  • मौजूदा फ़ोरग्राउंड सेवाओं को फ़ोरग्राउंड से हटा दिया जाता है
  • अलार्म ट्रिगर नहीं होते
  • जॉब पूरे नहीं होते

इसके अलावा, अगर कोई ऐप्लिकेशन Android 13 (एपीआई लेवल 33) या उसके बाद के वर्शन को टारगेट करता है और "प्रतिबंधित" स्थिति में है, तो सिस्टम BOOT_COMPLETED ब्रॉडकास्ट या LOCKED_BOOT_COMPLETED ब्रॉडकास्ट तब तक डिलीवर नहीं करता, जब तक ऐप्लिकेशन को किसी अन्य वजह से शुरू नहीं किया जाता.

पाबंदियों के बारे में ज़्यादा जानकारी के लिए, पावर मैनेजमेंट से जुड़ी पाबंदियां लेख पढ़ें.

नेटवर्क गतिविधि के ब्रॉडकास्ट पाने से जुड़ी पाबंदियां

Android 7.0 (एपीआई लेवल 24) को टारगेट करने वाले ऐप्लिकेशन को CONNECTIVITY_ACTION ब्रॉडकास्ट नहीं मिलते. ऐसा तब होता है, जब वे अपने मेनिफ़ेस्ट में इन्हें पाने के लिए रजिस्टर करते हैं. साथ ही, इस ब्रॉडकास्ट पर निर्भर प्रोसेस शुरू नहीं होंगी. इससे उन ऐप्लिकेशन को समस्या हो सकती है जो नेटवर्क में होने वाले बदलावों के बारे में सूचना पाना चाहते हैं या जब डिवाइस किसी ऐसे नेटवर्क से कनेक्ट होता है जिसमें डेटा के इस्तेमाल के लिए शुल्क नहीं लिया जाता, तब नेटवर्क से जुड़ी कई गतिविधियां करना चाहते हैं. इस पाबंदी को हटाने के लिए, Android फ़्रेमवर्क में पहले से ही कई समाधान मौजूद हैं. हालांकि, सही समाधान चुनना इस बात पर निर्भर करता है कि आपको अपने ऐप्लिकेशन से क्या काम करवाना है.

ध्यान दें: Context.registerReceiver() के साथ रजिस्टर किया गया BroadcastReceiver, ऐप्लिकेशन के चालू रहने के दौरान इन ब्रॉडकास्ट को पाना जारी रखता है.

अनमीटर्ड कनेक्शन पर नेटवर्क जॉब शेड्यूल करना

JobInfo ऑब्जेक्ट बनाने के लिए, JobInfo.Builder क्लास का इस्तेमाल करते समय, 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);
}

जब आपकी नौकरी की शर्तें पूरी हो जाती हैं, तो आपके ऐप्लिकेशन को कॉलबैक मिलता है. इससे वह तय किए गए JobService.class में onStartJob() तरीके को चला पाता है. JobScheduler को लागू करने के और उदाहरण देखने के लिए, JobScheduler का सैंपल ऐप्लिकेशन देखें.

JobScheduler के विकल्प के तौर पर, WorkManager का इस्तेमाल किया जा सकता है. यह एक ऐसा एपीआई है जिसकी मदद से, बैकग्राउंड में किए जाने वाले ऐसे टास्क शेड्यूल किए जा सकते हैं जिन्हें पूरा करना ज़रूरी है. भले ही, ऐप्लिकेशन प्रोसेस चल रही हो या नहीं. WorkManager, डिवाइस के एपीआई लेवल जैसे फ़ैक्टर के आधार पर, टास्क को पूरा करने का सही तरीका चुनता है. जैसे, सीधे तौर पर आपके ऐप्लिकेशन की प्रोसेस में किसी थ्रेड पर टास्क को पूरा करना. इसके अलावा, JobScheduler, FirebaseJobDispatcher या AlarmManager का इस्तेमाल करना. इसके अलावा, WorkManager को Play services की ज़रूरत नहीं होती. साथ ही, यह कई ऐडवांस सुविधाएं देता है. जैसे, टास्क को एक साथ जोड़ना या टास्क की स्थिति की जांच करना. ज़्यादा जानने के लिए, WorkManager देखें.

ऐप्लिकेशन के चालू रहने के दौरान, नेटवर्क कनेक्टिविटी की निगरानी करना

चालू ऐप्लिकेशन, रजिस्टर किए गए BroadcastReceiver की मदद से अब भी CONNECTIVITY_CHANGE की बात सुन सकते हैं. हालांकि, ConnectivityManager एपीआई, कॉलबैक का अनुरोध करने का ज़्यादा बेहतर तरीका उपलब्ध कराता है. ऐसा सिर्फ़ तब किया जाता है, जब नेटवर्क से जुड़ी तय की गई शर्तें पूरी हो जाती हैं.

NetworkRequest ऑब्जेक्ट, NetworkCapabilities के हिसाब से नेटवर्क कॉलबैक के पैरामीटर तय करते हैं. NetworkRequest.Builder क्लास की मदद से NetworkRequest ऑब्जेक्ट बनाए जाते हैं. registerNetworkCallback() इसके बाद, NetworkRequest ऑब्जेक्ट को सिस्टम को पास करता है. नेटवर्क की ज़रूरी शर्तें पूरी होने पर, ऐप्लिकेशन को एक कॉलबैक मिलता है. इससे वह अपनी ConnectivityManager.NetworkCallback क्लास में तय किए गए onAvailable() तरीके को लागू कर पाता है.

ऐप्लिकेशन को तब तक कॉलबैक मिलते रहते हैं, जब तक ऐप्लिकेशन बंद नहीं हो जाता या वह unregisterNetworkCallback() को कॉल नहीं करता.

इमेज और वीडियो ब्रॉडकास्ट पाने से जुड़ी पाबंदियां

Android 7.0 (एपीआई लेवल 24) में, ऐप्लिकेशन ACTION_NEW_PICTURE या ACTION_NEW_VIDEO ब्रॉडकास्ट नहीं भेज सकते या पा नहीं सकते. इस पाबंदी से, परफ़ॉर्मेंस और उपयोगकर्ता अनुभव पर पड़ने वाले असर को कम करने में मदद मिलती है. ऐसा तब होता है, जब नई इमेज या वीडियो को प्रोसेस करने के लिए कई ऐप्लिकेशन को चालू करना पड़ता है. Android 7.0 (एपीआई लेवल 24) में, JobInfo और JobParameters को बढ़ाया गया है, ताकि कोई वैकल्पिक समाधान दिया जा सके.

कॉन्टेंट यूआरआई में बदलाव होने पर, नौकरियों को ट्रिगर करना

कॉन्टेंट यूआरआई में बदलाव होने पर टास्क ट्रिगर करने के लिए, Android 7.0 (एपीआई लेवल 24) में JobInfo एपीआई को इन तरीकों से बढ़ाया गया है:

JobInfo.TriggerContentUri()
इसमें कॉन्टेंट यूआरआई में हुए बदलावों के आधार पर कोई जॉब ट्रिगर करने के लिए ज़रूरी पैरामीटर शामिल होते हैं.
JobInfo.Builder.addTriggerContentUri()
TriggerContentUri ऑब्जेक्ट को JobInfo पर पास करता है. ContentObserver इनकैप्सुलेट किए गए कॉन्टेंट यूआरआई को मॉनिटर करता है. अगर किसी नौकरी से कई TriggerContentUri ऑब्जेक्ट जुड़े हैं, तो सिस्टम एक कॉलबैक उपलब्ध कराता है. भले ही, वह कॉन्टेंट यूआरआई में से सिर्फ़ एक में बदलाव की सूचना दे.
दिए गए यूआरआई के किसी भी डिसेंडेंट में बदलाव होने पर, नौकरी को ट्रिगर करने के लिए TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS फ़्लैग जोड़ें. यह फ़्लैग, notifyForDescendants पैरामीटर से मेल खाता है. इसे registerContentObserver() में पास किया जाता है.

ध्यान दें: TriggerContentUri() का इस्तेमाल, setPeriodic() या setPersisted() के साथ नहीं किया जा सकता. कॉन्टेंट में हुए बदलावों को लगातार मॉनिटर करने के लिए, JobInfo को शेड्यूल करें. ऐसा ऐप्लिकेशन के JobService के सबसे हाल के कॉलबैक को हैंडल करने से पहले करें.

यहां दिया गया सैंपल कोड, कॉन्टेंट यूआरआई में बदलाव होने पर ट्रिगर होने वाले जॉब को शेड्यूल करता है. 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());
}

जब सिस्टम, बताए गए कॉन्टेंट यूआरआई में बदलाव की सूचना देता है, तब आपके ऐप्लिकेशन को कॉलबैक मिलता है. साथ ही, JobParameters ऑब्जेक्ट को MediaContentJob.class में onStartJob() तरीके से पास किया जाता है.

यह पता लगाना कि किस कॉन्टेंट अथॉरिटी ने नौकरी का विज्ञापन दिखाया

Android 7.0 (एपीआई लेवल 24) में JobParameters को भी बढ़ाया गया है, ताकि आपका ऐप्लिकेशन यह काम कर सके: कॉन्टेंट अथॉरिटी और यूआरआई ने कौनसे जॉब ट्रिगर किए, इस बारे में काम की जानकारी पाना:

Uri[] getTriggeredContentUris()
यह उन यूआरआई का कलेक्शन दिखाता है जिन्होंने जॉब को ट्रिगर किया है. अगर किसी भी यूआरआई ने जॉब को ट्रिगर नहीं किया है (उदाहरण के लिए, जॉब को समयसीमा खत्म होने या किसी अन्य वजह से ट्रिगर किया गया था) या बदले गए यूआरआई की संख्या 50 से ज़्यादा है, तो यह null होगा.
String[] getTriggeredContentAuthorities()
यह फ़ंक्शन, कॉन्टेंट अथॉरिटी के स्ट्रिंग अरे दिखाता है. इन अथॉरिटी ने जॉब को ट्रिगर किया है. अगर दिखाया गया कलेक्शन null नहीं है, तो getTriggeredContentUris() का इस्तेमाल करके, उन यूआरआई की जानकारी पाएं जिनमें बदलाव हुआ है.

यहां दिए गए सैंपल कोड में, JobService.onStartJob() तरीके को बदला गया है. साथ ही, इसमें उन कॉन्टेंट अथॉरिटी और यूआरआई को रिकॉर्ड किया गया है जिन्होंने नौकरी को ट्रिगर किया है:

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 (एपीआई लेवल 24) में इनमें से कुछ समस्याओं को कम करने के लिए कदम उठाए गए हैं. फिर भी, हमारा सुझाव है कि आप अपने ऐप्लिकेशन को इस तरह से ऑप्टिमाइज़ करें कि वह इन बैकग्राउंड प्रोसेस का इस्तेमाल किए बिना पूरी तरह से काम कर सके.

Android डीबग ब्रिज (एडीबी) की इन कमांड की मदद से, बैकग्राउंड प्रोसेस बंद होने पर ऐप्लिकेशन के व्यवहार की जांच की जा सकती है:

  • ऐसी स्थितियां सिम्युलेट करने के लिए जहां इंप्लिसिट ब्रॉडकास्ट और बैकग्राउंड सेवाएं उपलब्ध नहीं हैं, यह कमांड डालें: 
  • $ 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