Android ऐप्लिकेशन, किसी गड़बड़ी की वजह से अचानक बंद हो जाता है
बिना हैंडल के अपवाद या सिग्नल. ऐसा ऐप्लिकेशन जिसे Java या Kotlin का इस्तेमाल करके लिखा गया है
अगर यह बिना हैंडल वाला अपवाद दिखाता है, तो क्रैश हो जाता है.
Throwable क्लास. अगर आप
मशीन कोड का इस्तेमाल करके लिखा गया ऐप्लिकेशन या C++ बंद होने पर, उसका रखरखाव नहीं किया जा सकता
जैसे कि SIGSEGV को चालू किया जा सकता है.
जब कोई ऐप्लिकेशन क्रैश होता है, तो Android उस ऐप्लिकेशन की प्रोसेस को बंद कर देता है और एक डायलॉग दिखाता है ताकि पहली इमेज में दिखाए गए तरीके से उपयोगकर्ता को बताया जा सके कि ऐप्लिकेशन बंद हो गया है.
पहला डायग्राम. Android डिवाइस पर ऐप्लिकेशन क्रैश होना
ऐप्लिकेशन के क्रैश होने के लिए, यह ज़रूरी नहीं है कि वह फ़ोरग्राउंड में चल रहा हो. सभी ऐप्लिकेशन कॉम्पोनेंट, यहां तक कि ब्रॉडकास्ट रिसीवर या कॉन्टेंट देने वालों जैसे कॉम्पोनेंट भी बैकग्राउंड में चल रहे हैं, तो इनकी वजह से ऐप्लिकेशन क्रैश हो सकता है. ये क्रैश जो उपयोगकर्ताओं को अक्सर भ्रमित करते हैं, क्योंकि वे आपके ऐप्लिकेशन के साथ सक्रिय रूप से इंटरैक्ट नहीं कर रहे थे.
अगर आपके ऐप्लिकेशन के क्रैश होने की समस्या आ रही है, तो इस पेज में दिए गए दिशा-निर्देशों का इस्तेमाल करके, समस्या का पता लगाकर उसे ठीक करें.
समस्या का पता लगाना
ऐसा हो सकता है कि आपको हमेशा यह पता न चले कि आपके उपयोगकर्ताओं को ऐप्लिकेशन क्रैश होने की समस्या का सामना करना पड़ रहा है वे आपके ऐप्लिकेशन का इस्तेमाल करते हैं. अगर आपने पहले ही अपना ऐप्लिकेशन पब्लिश कर दिया है, तो 'Android की ज़रूरी जानकारी' से, अपने ऐप्लिकेशन की क्रैश रेट देखी जा सकती हैं.
Android की ज़रूरी जानकारी
'Android की ज़रूरी जानकारी' की मदद से, अपने ऐप्लिकेशन के क्रैश रेट पर नज़र रखी जा सकती है और उसे बेहतर बनाया जा सकता है. 'Android की ज़रूरी जानकारी' से कई क्रैश रेट का पता चलता है:
- क्रैश रेट: हर दिन के ऐसे सक्रिय उपयोगकर्ताओं का प्रतिशत जो किसी भी तरह के क्रैश का अनुभव हुआ हो.
यूज़र-पर्सीव्ड क्रैश रेट: हर दिन के सक्रिय उपयोगकर्ताओं का प्रतिशत आपके ऐप्लिकेशन का सक्रिय रूप से इस्तेमाल करने के दौरान, जिन्हें कम से कम एक बार क्रैश की गड़बड़ी का सामना करना पड़ा (यूज़र-पर्सीव्ड क्रैश). ऐसा माना जाता है कि ऐप्लिकेशन का इस्तेमाल किया जा रहा है अगर इसमें कोई गतिविधि दिखाई जा रही है या फ़ोरग्राउंड सेवा का इस्तेमाल करना होगा.
एक से ज़्यादा क्रैश रेट: हर दिन के ऐसे सक्रिय उपयोगकर्ताओं का प्रतिशत जो कम से कम दो क्रैश का सामना करना पड़ा.
रोज़ सक्रिय उपयोगकर्ता, आपके ऐप्लिकेशन का इस्तेमाल करने वाला यूनीक उपयोगकर्ता होता है और कई सेशन में एक ही दिन में इस्तेमाल किए जा सकते हैं. अगर कोई उपयोगकर्ता आपके ऐप्लिकेशन का इस्तेमाल एक दिन में एक से ज़्यादा डिवाइस पर करता है, तो हर डिवाइस उस दिन सक्रिय उपयोगकर्ताओं की संख्या के हिसाब से डेटा दिखाता है. अगर एक दिन में कई उपयोगकर्ता एक ही डिवाइस का इस्तेमाल करते हैं, तो इसे एक सक्रिय उपयोगकर्ता के तौर पर गिना जाता है.
यूज़र-पर्सीव्ड क्रैश रेट, सबसे ज़रूरी होता है. इसका मतलब है कि यह Google Play पर आपके ऐप्लिकेशन को खोजे जाने लायक बनाया जा सकता है. यह ज़रूरी है, क्योंकि यह क्रैश हो जाता है की गिनती हमेशा तब होती है, जब उपयोगकर्ता ऐप्लिकेशन के साथ जुड़ा रहता है. इस वजह से समस्या है.
Play ने इस मेट्रिक पर, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के दो थ्रेशोल्ड तय किए हैं:
- ऐप्लिकेशन की खराब परफ़ॉर्मेंस का थ्रेशोल्ड: हर दिन के सक्रिय उपयोगकर्ताओं का कम से कम 1.09% सभी डिवाइस मॉडल पर यूज़र-पर्सीव्ड क्रैश का अनुभव हुआ हो.
- हर डिवाइस के हिसाब से ऐप्लिकेशन की खराब परफ़ॉर्मेंस का थ्रेशोल्ड: हर दिन के सक्रिय उपयोगकर्ताओं में से कम से कम 8% एक ही डिवाइस मॉडल के लिए यूज़र-पर्सीव्ड क्रैश का अनुभव हुआ हो.
अगर आपके ऐप्लिकेशन ने ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड को पार कर लिया है, तो और सभी डिवाइसों पर कम खोजे जाने लायक. अगर आपके ऐप्लिकेशन ने हर डिवाइस पर खराब परफ़ॉर्मेंस की सीमा पार कर ली है कम होने की संभावना होती है, तो कुछ डिवाइसों पर साथ ही, आपके स्टोर पेज पर एक चेतावनी दिख सकती है.
'Android की ज़रूरी जानकारी' की मदद से, आपको सूचना मिल सकती है Play Console जब आपका ऐप्लिकेशन बहुत ज़्यादा क्रैश दिखाता है.
Google Play, 'Android की ज़रूरी जानकारी' का डेटा कैसे इकट्ठा करता है, इस बारे में जानने के लिए Play Console दस्तावेज़.
क्रैश का विश्लेषण करें
जब आपको यह पता चल जाएगा कि आपका ऐप्लिकेशन क्रैश होने की रिपोर्ट कर रहा है, तो अगला कदम उनके बारे में पता लगाना है. क्रैश का समाधान करना मुश्किल हो सकता है. हालांकि, अगर आप इसकी असल वजह का पता लगा पाएं, तो तो आपको उसका समाधान मिल सकता है.
कई वजहों से आपके ऐप्लिकेशन में क्रैश हो सकता है. इसकी कुछ वजहें ये हैं जैसे, शून्य या खाली स्ट्रिंग की जांच करना, लेकिन बाकी वैल्यू काफ़ी होती हैं सूक्ष्म, जैसे किसी API में अमान्य तर्क पास करना या जटिल मल्टीथ्रेड इंटरैक्शन.
Android पर क्रैश होने पर स्टैक ट्रेस बनता है, जो क्रैश होने के समय तक, नेस्ट किए हुए फ़ंक्शन आपके प्रोग्राम में कॉल करते रहते हैं. आप क्रैश स्टैक ट्रेस इसमें देखें Android की ज़रूरी जानकारी.
स्टैक ट्रेस को पढ़ने का तरीका
क्रैश की समस्या को ठीक करने के लिए सबसे पहले, उस जगह की पहचान करें जहां वह क्रैश होता है. आप अगर Google Play का इस्तेमाल किया जा रहा है, तो रिपोर्ट की जानकारी में मौजूद स्टैक ट्रेस का इस्तेमाल करें कंसोल या logcat टूल का आउटपुट. अगर आपको स्टैक ट्रेस उपलब्ध नहीं है. आपको स्थानीय तौर पर ऐप्लिकेशन के बंद होने की गड़बड़ी को फिर से देखना चाहिए, इसके लिए, ऐप्लिकेशन की मैन्युअल तरीके से जांच की जा सकती है या उन उपयोगकर्ताओं से संपर्क किया जा सकता है जिन पर इस समस्या का असर पड़ा है. Logcat का उपयोग करके इसे फिर से बनाएं.
नीचे दिया गया ट्रेस, Java का इस्तेमाल करके बनाए गए ऐप्लिकेशन के क्रैश होने का उदाहरण दिखाता है प्रोग्रामिंग भाषा:
--------- beginning of crash
AndroidRuntime: FATAL EXCEPTION: main
Process: com.android.developer.crashsample, PID: 3686
java.lang.NullPointerException: crash sample
at com.android.developer.crashsample.MainActivity$1.onClick(MainActivity.java:27)
at android.view.View.performClick(View.java:6134)
at android.view.View$PerformClick.run(View.java:23965)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6440)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:746)
--------- beginning of system
स्टैक ट्रेस, दो तरह की ऐसी जानकारी दिखाता है जो किसी क्रैश:
- किस तरह का अपवाद है.
- कोड का वह सेक्शन जहां अपवाद मिलता है.
आम तौर पर, जिस तरह का अपवाद दिया जाता है उससे इस बात का पुख्ता संकेत मिलता है कि असल में क्या हुआ
गलत. देखें कि क्या यह
IOException,
OutOfMemoryError
या अपवाद की क्लास से जुड़े दस्तावेज़ देखें.
सोर्स फ़ाइल की क्लास, मेथड, फ़ाइल, और लाइन नंबर, जहां अपवाद 'थ्रेड' को स्टैक ट्रेस की दूसरी लाइन में नहीं दिखाया जाता है. हर उस फ़ंक्शन के लिए जो कॉल किया गया था, तो दूसरी लाइन पिछली कॉल साइट (जिसे स्टैक फ़्रेम कहा जाता है) दिखाती है. स्टैक पर ऊपर-नीचे जाकर और कोड की जांच करके, आप किसी ऐसे स्थान को खोज सकते हैं गलत वैल्यू दी जा रही है. अगर आपका कोड स्टैक ट्रेस में नहीं दिखता है, तो शायद आपने किसी एसिंक्रोनस पैरामीटर में अमान्य पैरामीटर पास किया है कार्रवाई. मैसेज की हर लाइन की जांच करके अक्सर यह पता लगाया जा सकता है कि क्या हुआ इस्तेमाल की गई किसी भी एपीआई क्लास को ढूंढना है. साथ ही, यह पुष्टि करना है कि पास किए गए पैरामीटर सही थे, और आपने उसे ऐसे स्थान से कॉल किया था जो अनुमति है.
C और C++ कोड वाले ऐप्लिकेशन के स्टैक ट्रेस भी इसी तरह से काम करते हैं.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/foo/bar:10/123.456/78910:user/release-keys'
ABI: 'arm64'
Timestamp: 2020-02-16 11:16:31+0100
pid: 8288, tid: 8288, name: com.example.testapp >>> com.example.testapp <<<
uid: 1010332
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference
x0 0000007da81396c0 x1 0000007fc91522d4 x2 0000000000000001 x3 000000000000206e
x4 0000007da8087000 x5 0000007fc9152310 x6 0000007d209c6c68 x7 0000007da8087000
x8 0000000000000000 x9 0000007cba01b660 x10 0000000000430000 x11 0000007d80000000
x12 0000000000000060 x13 0000000023fafc10 x14 0000000000000006 x15 ffffffffffffffff
x16 0000007cba01b618 x17 0000007da44c88c0 x18 0000007da943c000 x19 0000007da8087000
x20 0000000000000000 x21 0000007da8087000 x22 0000007fc9152540 x23 0000007d17982d6b
x24 0000000000000004 x25 0000007da823c020 x26 0000007da80870b0 x27 0000000000000001
x28 0000007fc91522d0 x29 0000007fc91522a0
sp 0000007fc9152290 lr 0000007d22d4e354 pc 0000007cba01b640
backtrace:
#00 pc 0000000000042f89 /data/app/com.example.testapp/lib/arm64/libexample.so (com::example::Crasher::crash() const)
#01 pc 0000000000000640 /data/app/com.example.testapp/lib/arm64/libexample.so (com::example::runCrashThread())
#02 pc 0000000000065a3b /system/lib/libc.so (__pthread_start(void*))
#03 pc 000000000001e4fd /system/lib/libc.so (__start_thread)
अगर आपको नेटिव स्टैक ट्रेस में क्लास और फ़ंक्शन-लेवल की जानकारी नहीं दिखती, तो शायद आपको यह काम करना पड़े नेटिव डीबग सिंबल वाली फ़ाइल जनरेट करना और उसे Google Play Console पर अपलोड करें. ज़्यादा जानकारी के लिए, यह देखें क्रैश स्टैक ट्रेस को डिकोड करना. नेटिव क्रैश के बारे में सामान्य जानकारी के लिए, इसे देखें नेटिव क्रैश का पता लगाना.
क्रैश की समस्या को फिर से जनरेट करने के लिए सलाह
ऐसा भी हो सकता है कि आप समस्या को पूरी तरह से एम्युलेटर या आपके डिवाइस को आपके कंप्यूटर से कनेक्ट करता है. डेवलपमेंट एनवायरमेंट को बैंडविथ, मेमोरी, और स्टोरेज जैसे ज़्यादा संसाधन मिलते हैं. इसका इस्तेमाल करें किस तरह का अपवाद है, जिससे यह तय किया जा सकता है कि वह संसाधन क्या हो सकता है जिसकी संभावना कम है या Android के वर्शन, डिवाइस टाइप या ऐप्लिकेशन के Android वर्शन के बीच का वर्शन है.
मेमोरी की गड़बड़ियां
अगर आपके पास
OutOfMemoryError,
इसके बाद, टेस्ट करने के लिए कम मेमोरी क्षमता वाला एम्युलेटर बनाया जा सकता है. इमेज
2 में एवीडी मैनेजर की सेटिंग दिखती हैं. इसकी मदद से, यह तय किया जा सकता है कि
डिवाइस.
दूसरा डायग्राम. एवीडी मैनेजर में मेमोरी की सेटिंग
नेटवर्किंग अपवाद
चूंकि उपयोगकर्ता अक्सर मोबाइल या वाई-फ़ाई नेटवर्क कवरेज से बाहर जाते हैं, इसलिए ऐप्लिकेशन नेटवर्क के अपवादों को आम तौर पर गड़बड़ी नहीं माना जाना चाहिए, लेकिन उम्मीद के मुताबिक काम करने की सामान्य स्थिति से अलग होता है.
अगर आपको नेटवर्क अपवाद की ज़रूरत हो, जैसे कि
UnknownHostException,
तब हवाई जहाज़ मोड चालू करके देखें, जब आपका एप्लिकेशन
नेटवर्क.
दूसरा विकल्प यह है कि एम्युलेटर में नेटवर्क की क्वालिटी को इतना कम किया जाए
नेटवर्क स्पीड एम्युलेशन और/या नेटवर्क देरी को चुनना. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए
एवीडी मैनेजर पर स्पीड और इंतज़ार का समय से जुड़ी सेटिंग या एम्युलेटर को चालू किया जा सकता है
-netdelay और -netspeed फ़्लैग के साथ, जैसा कि यहां दिखाया गया है
कमांड लाइन का उदाहरण:
emulator -avd [your-avd-image] -netdelay 20000 -netspeed gsm
यह उदाहरण सभी नेटवर्क अनुरोधों और अपलोड पर 20 सेकंड की देरी सेट करता है और डाउनलोड स्पीड 14.4 केबीपीएस होनी चाहिए. कमांड-लाइन के विकल्पों के बारे में ज़्यादा जानकारी पाने के लिए एम्युलेटर के लिए, देखें कमांड लाइन से एम्युलेटर शुरू करें.
लॉगकैट के साथ पढ़ना
जब आपके पास क्रैश को फिर से देखने के चरणों की जानकारी हो, तब आप इस तरह के टूल का इस्तेमाल कर सकते हैं:
ज़्यादा जानकारी के लिए logcat.
Logcat आउटपुट आपको दिखाएगा कि आपने कौन-कौनसे लॉग मैसेज प्रिंट किए हैं.
का इस्तेमाल किया जा सकता है. अतिरिक्त सुविधाओं को बंद करना न भूलें
Log के स्टेटमेंट
को जोड़ा गया है, क्योंकि उन्हें प्रिंट करने से सीपीयू और बैटरी की बर्बादी होती है. ऐसा तब होता है, जब आपका ऐप्लिकेशन
दौड़ने.
शून्य पॉइंटर अपवादों की वजह से होने वाले क्रैश को रोकें
शून्य पॉइंटर के अपवाद (रनटाइम में होने वाली गड़बड़ी के टाइप से पहचाना जाता है
NullPointerException) तब होती है, जब आप किसी ऐसे ऑब्जेक्ट को ऐक्सेस करने की कोशिश करते हैं जो
अमान्य होता है. आम तौर पर, इसके तरीकों का इस्तेमाल करके या सदस्यों तक पहुंचा जा सकता है. शून्य पॉइंटर
अपवाद, Google Play पर ऐप्लिकेशन के क्रैश होने की सबसे बड़ी वजह हैं. इसका मकसद
शून्य का मतलब है कि ऑब्जेक्ट मौजूद नहीं है. उदाहरण के लिए,
बनाए या असाइन किए गए हों. शून्य पॉइंटर के अपवादों से बचने के लिए, आपको पक्का करना होगा कि
कि जिन ऑब्जेक्ट रेफ़रंस के साथ काम किया जा रहा है वे कॉल करने से पहले शून्य नहीं हैं
या सदस्यों को ऐक्सेस करने की कोशिश की जा रही हो. अगर ऑब्जेक्ट का रेफ़रंस यह है
शून्य, इस केस को अच्छी तरह से हैंडल करें (उदाहरण के लिए, परफ़ॉर्म करने से पहले किसी तरीके से बाहर निकलें
ऑब्जेक्ट के रेफ़रंस पर कोई भी कार्रवाई करने और डीबग लॉग में जानकारी लिखने के लिए.
क्योंकि आप हर तरीके के हर पैरामीटर के लिए शून्य जांच नहीं चाहते हैं कॉल किया है, तो आप बताने के लिए IDE या ऑब्जेक्ट के टाइप पर भरोसा कर सकते हैं अमान्य है.
Java प्रोग्रामिंग भाषा
नीचे दिए गए सेक्शन, Java प्रोग्रामिंग भाषा पर लागू होते हैं.
समय से जुड़ी चेतावनियों को कंपाइल करें
अपने तरीकों के बारे में बताएं पैरामीटर और इसके साथ मान वापस करते हैं
@Nullable और
कंपाइल टाइम पाने के लिए @NonNull
चेतावनी मिली है. इन चेतावनियों से आपको एक शून्य ऑब्जेक्ट मिलने की उम्मीद होती है:
ये शून्य जांच उन ऑब्जेक्ट के लिए होती हैं जिनके बारे में आपको पता है कि वे शून्य हो सकते हैं. एक अपवाद
@NonNull ऑब्जेक्ट आपके कोड में किसी ऐसी गड़बड़ी का संकेत है जिसे
समाधान किया गया है.
समय की गड़बड़ियां कंपाइल करें
शून्य वैल्यू वाली वैल्यू सही होनी चाहिए. इसलिए, इसे इस्तेमाल किए जा रहे टाइप में जोड़ा जा सकता है
ताकि शून्य के लिए कंपाइल टाइम की जांच की जा सके. अगर आपको पता है कि कोई ऑब्जेक्ट
शून्य हो और शून्य होने वाली वैल्यू को हैंडल किया जाना चाहिए, तो आप इसे इस तरह के किसी ऑब्जेक्ट में रैप कर सकते हैं
Optional.
आपको हमेशा ऐसे टाइप को प्राथमिकता देनी चाहिए जो शून्य की वैल्यू के बारे में बताते हों.
Kotlin
Kotlin में,
शून्य वैल्यू करना
टाइप सिस्टम का हिस्सा है. उदाहरण के लिए, किसी वैरिएबल का एलान
शून्य या शून्य के लायक के तौर पर शुरू होता है. बिना वैल्यू वाले टाइप, ? से मार्क किए गए हैं:
// non-null
var s: String = "Hello"
// null
var s: String? = "Hello"
शून्य वैल्यू वाले वैरिएबल के लिए, शून्य वैल्यू और शून्य किए जा सकने वाले वैरिएबल असाइन नहीं किए जा सकते शून्य के तौर पर इस्तेमाल किए जाने से पहले, शून्य हो जाने की जांच करना ज़रूरी है.
अगर आपको खाली सेल को साफ़ तौर पर नहीं देखना है, तो ?. सेफ़ कॉल का इस्तेमाल किया जा सकता है
ऑपरेटर:
val length: Int? = string?.length // length is a nullable int
// if string is null, then length is null
सबसे सही तरीका यह है कि आप किसी शून्य वाले ऑब्जेक्ट के लिए, शून्य केस का पता लगाएं,
या आपका ऐप्लिकेशन अनचाही स्थितियों में पहुंच सकता है. अगर आपका ऐप्लिकेशन क्रैश नहीं होता है, तो
NullPointerException इस्तेमाल करते हैं, तो आपको पता नहीं चलेगा कि ये गड़बड़ियां मौजूद हैं.
शून्य की जांच करने के लिए, यहां कुछ तरीके दिए गए हैं:
ifचेकval length = if(string != null) string.length else 0स्मार्ट-कास्ट और शून्य की जांच की वजह से, Kotlin कंपाइलर को पता होता है कि स्ट्रिंग मान शून्य नहीं है, इसलिए यह आपको सीधे संदर्भ का इस्तेमाल करने देता है, इसके लिए, आपको सुरक्षित कॉल ऑपरेटर की ज़रूरत नहीं होती.
-
यह ऑपरेटर आपको यह बताने की अनुमति देता है कि "अगर ऑब्जेक्ट शून्य नहीं है, तो ऑब्जेक्ट; अगर ऐसा नहीं है, तो कुछ और वापस करें".
val length = string?.length ?: 0
आपको Kotlin में अब भी NullPointerException मिल सकता है. सबसे ज़्यादा
सामान्य स्थितियां:
- जब साफ़ तौर पर
NullPointerExceptionफेंका जा रहा हो. - जब आप
शून्य दावे
!!ऑपरेटर के साथ काम करता है. यह ऑपरेटर किसी भी वैल्यू को बिना शून्य वाले टाइप में बदल देता है, वैल्यू शून्य होने पर,NullPointerException. - किसी प्लैटफ़ॉर्म टाइप के शून्य रेफ़रंस को ऐक्सेस करते समय.
प्लैटफ़ॉर्म के टाइप
प्लैटफ़ॉर्म के टाइप, Java से आने वाले ऑब्जेक्ट की जानकारी होते हैं. इन तरीकों का खास तौर पर इलाज किया जाता है; शून्य की जांच लागू करने के लिए नहीं की जाती है. इसलिए, शून्य के अलावा वाली गारंटी Java. प्लैटफ़ॉर्म टाइप की जानकारी ऐक्सेस करने पर Kotlin, कंपाइल नहीं करता है समय की गड़बड़ियों को देख सकते हैं, लेकिन इन रेफ़रंस से रनटाइम की गड़बड़ियां हो सकती हैं. नीचे दी गई जानकारी देखें Kotlin दस्तावेज़ से उदाहरण:
val list = ArrayList<String>() // non-null (constructor result) list.add("Item")
val size = list.size // non-null (primitive int) val item = list[0] // platform
type inferred (ordinary Java object) item.substring(1) // allowed, may throw an
// exception if item == null
जब Kotlin को प्लैटफ़ॉर्म वैल्यू असाइन की जाती है, तब Kotlin टाइप अनुमान पर निर्भर करता है
वैरिएबल के लिए या आपके पास यह तय करने का विकल्प है कि किस टाइप का इस्तेमाल करें. यह पक्का करने का सबसे अच्छा तरीका कि
Java से आने वाले रेफ़रंस की शून्य होने की सही स्थिति, शून्य होने की क्षमता का इस्तेमाल करना है
आपके Java कोड में एनोटेशन (उदाहरण के लिए, @Nullable) है. Kotlin कंपाइलर
इन रेफ़रंस को, असल शून्य या शून्य न किए जा सकने वाले टाइप के तौर पर दिखाएगा, न कि
प्लैटफ़ॉर्म के टाइप के बारे में ज़्यादा जानें.
ज़रूरत के हिसाब से, Java Jetpack API को @Nullable या @NonNull के साथ एनोटेट किया गया है,
इसलिए, यहां
Android 11 का SDK टूल.
इस SDK टूल से आने वाले जिन टाइप का इस्तेमाल Kotlin में किया जाता है उन्हें इस तरह दिखाया जाएगा
शून्य या शून्य के अलावा शून्य होने वाले टाइप के हिसाब से.
Kotlin के टाइप सिस्टम की वजह से, हमने देखा है कि ऐप्लिकेशन में
NullPointerException क्रैश. उदाहरण के लिए, Google Home ऐप्लिकेशन को 30% व्यू मिले
उस साल के दौरान, शून्य पॉइंटर अपवादों की वजह से होने वाले क्रैश की संख्या में हुई कमी
नए फ़ीचर डेवलपमेंट को Kotlin में माइग्रेट किया.