MessageQueue के व्यवहार में बदलाव से जुड़े दिशा-निर्देश

Android 17 से, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को android.os.MessageQueue का नया लॉक-फ़्री इंप्लिमेंटेशन मिलता है. इस नए तरीके से परफ़ॉर्मेंस बेहतर होती है और फ़्रेम छूटने की समस्या कम होती है. हालांकि, इससे उन क्लाइंट पर असर पड़ सकता है जो MessageQueue के निजी फ़ील्ड और तरीकों का इस्तेमाल करते हैं.

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

असर कम करना

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

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

इसके अलावा, अगर टेस्टिंग के लिए कुछ लोकप्रिय लाइब्रेरी का इस्तेमाल किया जाता है, तो आपको अपनी लाइब्रेरी अपडेट करनी होंगी, ताकि वे MessageQueue के नए वर्शन के साथ काम कर सकें.

एस्प्रेसो

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

कार्रवाई

Espresso 3.7.0 या इसके बाद के वर्शन पर अपडेट करें. यह वर्शन, TestLooperManager एपीआई का इस्तेमाल करता है. खास तौर पर, Android 16 में पेश किए गए नए एपीआई का इस्तेमाल करता है. इससे, इंटरनल इंप्लिमेंटेशन की जानकारी पर भरोसा किए बिना, Looper के साथ सुरक्षित तरीके से इंटरैक्ट किया जा सकता है.

Robolectric

इसी तरह, अगर Robolectric का इस्तेमाल करके यूनिट टेस्ट चलाए जाते हैं, तो आपको समस्याएं आ सकती हैं. ऐसा तब होता है, जब आपके टेस्ट लेगसी लूपर मोड पर निर्भर हों.

कार्रवाई

Robolectric 4.17 या इसके बाद के वर्शन पर अपडेट करें. अगर @LooperMode(LEGACY) का इस्तेमाल किया जा रहा है, तो आपको अपने टेस्ट को नए @LooperMode(PAUSED) पर माइग्रेट करना होगा. ज़्यादा जानकारी के लिए, Robolectric की माइग्रेट करने से जुड़ी गाइड देखें.

व्यवहार की जांच करना

targetSDK को अपडेट किए बिना, Android 17 पर व्यवहार में हुए बदलाव के साथ अपने ऐप्लिकेशन की जांच की जा सकती है. इसके लिए, यह कमांड चलाएं:

adb am compat enable USE_NEW_MESSAGEQUEUE <your-package-name>

अगर आपका ऐप्लिकेशन डीबग करने लायक बिल्ड है, तो इस निर्देश से उसमें लॉक-फ़्री MessageQueue चालू हो जाता है.

अगर आपका ऐप्लिकेशन Android 17 (एपीआई लेवल 37) को टारगेट करता है, तो नया व्यवहार डिफ़ॉल्ट रूप से चालू होता है. अगर इस एपीआई लेवल को टारगेट करने के बाद, आपको ऐप्लिकेशन के क्रैश होने या अनचाहे व्यवहार की समस्या दिखती है, तो नए तरीके को कुछ समय के लिए बंद किया जा सकता है. इससे यह पुष्टि की जा सकती है कि समस्या MessageQueue की वजह से है या नहीं.

इनमें से किसी एक विकल्प का इस्तेमाल करके, बदलाव को टॉगल किया जा सकता है:

  1. डेवलपर के लिए सेटिंग और टूल में मौजूद, ऐप्लिकेशन के साथ काम करने के लिए किए गए बदलाव मेन्यू.

  2. यह एडीबी कमांड चलाकर:

    adb am compat disable USE_NEW_MESSAGEQUEUE <your-package-name>
    

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