अपने ऐप्लिकेशन को रिस्पॉन्सिव रखें

इस दस्तावेज़ में बताया गया है कि Android सिस्टम यह कैसे तय करता है कि कोई ऐप्लिकेशन काम नहीं कर रहा है. साथ ही, इसमें यह भी बताया गया है कि अपने ऐप्लिकेशन को रिस्पॉन्सिव कैसे रखा जाए.

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

एएनआर ट्रिगर

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

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

Android में, ऐप्लिकेशन के रिस्पॉन्स देने की क्षमता को ActivityManager और WindowManager सिस्टम सेवाएं मॉनिटर करती हैं. Android, किसी ऐप्लिकेशन के लिए एएनआर डायलॉग तब दिखाता है, जब उसे इनमें से कोई एक स्थिति मिलती है:

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

एएनआर से बचें

एएनआर से बचने के लिए, यहां कुछ सामान्य सुझाव दिए गए हैं. अलग-अलग तरह के एएनआर का पता लगाने और उन्हें डीबग करने के बारे में ज़्यादा जानने के लिए, इस सेक्शन के अन्य पेज देखें.

• मुख्य थ्रेड को हमेशा अनब्लॉक रखें और थ्रेड का इस्तेमाल रणनीति के तहत करें.

  • ऐप्लिकेशन की मुख्य थ्रेड पर, लंबे समय तक चलने वाले या ब्लॉक करने वाले ऑपरेशन न करें. इसके बजाय, एक वर्कर थ्रेड बनाएं और ज़्यादातर काम वहीं करें.

  • मुख्य थ्रेड और अन्य थ्रेड के बीच लॉक के लिए होने वाले विवाद को कम करने की कोशिश करें.

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

  • कॉम्पोनेंट के बीच थ्रेड पूल शेयर करते समय सावधानी बरतें. ब्रॉडकास्ट पाने जैसे समय के हिसाब से ज़रूरी टास्क और लंबे समय तक चलने वाले ऑपरेशन के लिए, एक ही थ्रेड का इस्तेमाल न करें.

• ऐप्लिकेशन को तेज़ी से चालू करें. ऐप्लिकेशन के स्टार्टअप कोड में, धीमी या ब्लॉक करने वाली कार्रवाइयों को कम करें. जैसे, डैगर को शुरू करने के दौरान चलने वाले तरीके.

• अगर BroadcastReceiver का इस्तेमाल किया जा रहा है, तो Context.registerReceiver का इस्तेमाल करके, ब्रॉडकास्ट रिसीवर को नॉन-मेन थ्रेड में चलाएं. ज़्यादा जानकारी के लिए, BroadcastReceiver में एएनआर देखें.

  • अगर goAsync() का इस्तेमाल किया जाता है, तो पक्का करें कि एएनआर टाइमआउट से पहले PendingResult.finish को तुरंत कॉल किया गया हो.

BroadcastReceiver में ANR की गड़बड़ियां

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

BroadcastReceiver ऑब्जेक्ट से जुड़ी एक और सामान्य समस्या तब होती है, जब वे बहुत बार एक्ज़ीक्यूट होते हैं. बैकग्राउंड में बार-बार ऐप्लिकेशन के चलने से, अन्य ऐप्लिकेशन के लिए उपलब्ध मेमोरी कम हो सकती है. BroadcastReceiver ऑब्जेक्ट को चालू और बंद करने के तरीके के बारे में ज़्यादा जानने के लिए, ब्रॉडकास्ट की खास जानकारी देखें.

जवाब देने की क्षमता को बेहतर बनाना

आम तौर पर, 100 से 200 मिलीसेकंड के बाद, उपयोगकर्ताओं को ऐप्लिकेशन धीमा लगने लगता है. यहां कुछ और सुझाव दिए गए हैं, जिनसे उपयोगकर्ताओं को आपका ऐप्लिकेशन तेज़ी से काम करता हुआ लगेगा:

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

• खास तौर पर गेम के लिए, वर्कर थ्रेड में चालों की गिनती करें.

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

• Perfetto और सीपीयू प्रोफ़ाइलर जैसे परफ़ॉर्मेंस टूल का इस्तेमाल करके, अपने ऐप्लिकेशन की रिस्पॉन्सिवनेस में आने वाली रुकावटों का पता लगाएं.