बैकग्राउंड में होने वाले टास्क पर सिस्टम की पाबंदियां

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

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

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

अगर कोई ऐप्लिकेशन, Android की ज़रूरी जानकारी में बताई गई खराब परफ़ॉर्मेंस से जुड़ी कुछ समस्याओं को दिखाता है, तो सिस्टम उपयोगकर्ता को उस ऐप्लिकेशन के सिस्टम के संसाधनों के ऐक्सेस पर पाबंदी लगाने के लिए कहता है.

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

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

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

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

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

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

WorkRequest बनाते समय, NetworkType.UNMETERED Constraint जोड़ें.

fun scheduleWork(context: Context) {
    val workManager = WorkManager.getInstance(context)
    val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
       .setConstraints(
           Constraints.Builder()
               .setRequiredNetworkType(NetworkType.UNMETERED)
               .build()
           )
       .build()

    workManager.enqueue(workRequest)
}

जब आपके काम की शर्तें पूरी हो जाती हैं, तो आपके ऐप्लिकेशन को एक कॉलबैक मिलता है. इससे, तय की गई Worker क्लास में doWork() तरीका चलाया जा सकता है.

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

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

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

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

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

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

यह पता लगाना कि किन कॉन्टेंट अथॉरिटी ने काम ट्रिगर किया है

WorkerParameters की मदद से, आपके ऐप्लिकेशन को यह अहम जानकारी मिलती है कि किन कॉन्टेंट अथॉरिटी और यूआरआई ने काम ट्रिगर किया है:

List<Uri> getTriggeredContentUris()

इससे, उन यूआरआई की सूची मिलती है जिन्होंने काम ट्रिगर किया है. अगर किसी भी यूआरआई ने काम ट्रिगर नहीं किया है (उदाहरण के लिए, काम किसी समयसीमा या किसी अन्य वजह से ट्रिगर हुआ है) या बदले गए यूआरआई की संख्या 50 से ज़्यादा है, तो यह सूची खाली होती है.

List<String> getTriggeredContentAuthorities()

इससे, उन कॉन्टेंट अथॉरिटी की स्ट्रिंग सूची मिलती है जिन्होंने काम ट्रिगर किया है. अगर दिखाई गई सूची खाली नहीं है, तो यह जानने के लिए कि किन यूआरआई में बदलाव हुआ है, getTriggeredContentUris() का इस्तेमाल करें.

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

class MyWorker(
    appContext: Context,
    params: WorkerParameters
): CoroutineWorker(appContext, params)
    override suspend fun doWork(): Result {
        StringBuilder().apply {
            append("Media content has changed:\n")
            params.triggeredContentAuthorities
                .takeIf { it.isNotEmpty() }
                ?.let { authorities ->
                    append("Authorities: ${authorities.joinToString(", ")}\n")
                    append(params.triggeredContentUris.joinToString("\n"))
                } ?: append("(No content)")
            Log.i(TAG, toString())
        }
        return Result.success()
    }
}

सिस्टम की पाबंदियों के तहत ऐप्लिकेशन की जांच करना

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

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

• ऐसी स्थितियों को सिम्युलेट करने के लिए जहां इंप्लिसिट ब्रॉडकास्ट और बैकग्राउंड में चलने वाली सेवाएं उपलब्ध नहीं हैं, यह कमांड डालें:

  $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore

• इंप्लिसिट ब्रॉडकास्ट और बैकग्राउंड में चलने वाली सेवाओं को फिर से चालू करने के लिए, यह कमांड डालें:

  $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow

अपने ऐप्लिकेशन को और ऑप्टिमाइज़ करना

बैकग्राउंड में चलने वाले टास्क के व्यवहार को ऑप्टिमाइज़ करने के अन्य बेहतर तरीकों के लिए, टास्क शेड्यूल करने वाले एपीआई के लिए, बैटरी के इस्तेमाल को ऑप्टिमाइज़ करना लेख देखें.