🛋️ 👡 🍡 एंड्रॉयड पर कोटलिन का प्रदर्शन 🎅🏽 👘 🛳️

आइए आज उत्पादन में एंड्रॉइड पर कोटलिन के प्रदर्शन के बारे में बात करते हैं। चलो हुड के नीचे देखते हैं, मुश्किल अनुकूलन को लागू करते हैं, बाइट कोड की तुलना करते हैं। अंत में, हम गंभीरता से तुलना करेंगे और बेंचमार्क को मापेंगे।

यह लेख एप्सकॉनफ 2017 में अलेक्जेंडर स्मिरनोव की एक रिपोर्ट पर आधारित है और यह पता लगाने में मदद करेगा कि क्या कोटलिन में कोड लिखना संभव है, जो गति में जावा से नीच नहीं होगा।

स्पीकर के बारे में: पापाजॉब्स में अलेक्जेंडर स्मिरनोव सीटीओ, फेस्स में वीडियो ब्लॉग एंड्रॉइड चलाता है, और मोसड्रोइड समुदाय के आयोजकों में से एक भी है।

अपनी उम्मीदों के साथ शुरू करते हैं।

क्या आपको लगता है कि रनटाइम में कोटलिन जावा की तुलना में धीमा है? या तेज? या शायद बहुत अंतर नहीं है? आखिरकार, दोनों बाईटकोड पर काम करते हैं जो वर्चुअल मशीन हमें प्रदान करती है।

चलो ठीक है। परंपरागत रूप से, जब प्रदर्शन की तुलना करने का सवाल उठता है, तो हर कोई बेंचमार्क और विशिष्ट संख्या देखना चाहता है। दुर्भाग्य से, Android के लिए कोई JMH ( Java Microbenchmark Harness ) नहीं है, इसलिए हम यह नहीं माप सकते हैं कि यह जावा में कितना ठंडा हो सकता है। तो हम माप करने के लिए क्या कर सकते हैं, जैसा कि नीचे वर्णित है?

fun measure() : Long { val startTime = System.nanoTime() work() return System.nanoTime() - startTime } adb shell dumpsys gfxinfo %package_name%

यदि आप कभी भी इस तरह से अपने कोड को मापने की कोशिश करते हैं, तो जेएमएच डेवलपर्स में से एक उदास, रोना और सपने में आपके पास आना होगा - ऐसा कभी न करें।

एंड्रॉइड पर, आप बेंचमार्क बना सकते हैं, विशेष रूप से, Google ने पिछले साल के आई / ओ में इसका प्रदर्शन किया था। उन्होंने कहा कि उन्होंने वर्चुअल मशीन में काफी सुधार किया, इस मामले में एआरटी, और अगर एंड्रॉइड 4.1 पर एक ऑब्जेक्ट के आवंटन में लगभग 600-700 नैनोसेकंड लगे, तो आठवें संस्करण में लगभग 60 नैनोसेकंड लगेंगे। यानी वे एक आभासी मशीन में इस तरह की सटीकता के साथ इसे मापने में सक्षम थे। हम ऐसा क्यों नहीं कर सकते - हमारे पास ऐसे उपकरण नहीं हैं।

यदि हम सभी दस्तावेज़ीकरण को देखते हैं, तो केवल एक चीज जो हम पा सकते हैं, वह है ऊपर की सिफारिश, यूआई को कैसे मापें:

adb शेल dffys gfxinfo% package_name%

दरअसल, इसे इस तरह से करते हैं और अंत में देखते हैं कि यह क्या देगा। लेकिन पहले, हम यह निर्धारित करेंगे कि हम क्या मापेंगे और हम क्या कर सकते हैं।

अगला सवाल। आपको लगता है कि जब आप प्रथम श्रेणी का आवेदन करते हैं तो प्रदर्शन महत्वपूर्ण होता है।

निश्चित रूप से हर जगह।
यूआई थ्रेड।
कस्टम दृश्य + एनिमेशन।

मुझे सबसे पहला विकल्प पसंद है, लेकिन सबसे अधिक संभावना है कि यह माना जाता है कि सभी कोड को बहुत जल्दी, बहुत जल्दी से बनाना असंभव है और यह महत्वपूर्ण है कि कम से कम यूआईह्रेड या कस्टम दृश्य नहीं है। मैं भी इससे सहमत हूं - यह बहुत महत्वपूर्ण है। तथ्य यह है कि आपके अलग JSON स्ट्रीम में 10 मिलीसेकंड के लिए deserialized जाएगा अब कोई भी नोटिस नहीं करेगा।

गेस्टाल्ट मनोविज्ञान का कहना है कि जब हम झपकी लेते हैं, तो लगभग 150-300 मिलीसेकंड के लिए, मानव आंख ध्यान से बाहर होती है और यह नहीं देखती है कि वास्तव में वहां क्या हो रहा है। और फिर ये 10 मिलीसेकंड का मौसम नहीं होता है। लेकिन अगर हम जेस्टाल्ट मनोविज्ञान पर लौटते हैं, तो यह महत्वपूर्ण नहीं है कि मैं वास्तव में क्या देखता हूं और वास्तव में क्या होता है, लेकिन एक उपयोगकर्ता के रूप में जो मैं समझता हूं वह महत्वपूर्ण है।

यानी अगर हम उपयोगकर्ता को यह सोचते हैं कि उसके पास सब कुछ बहुत तेज है, लेकिन वास्तव में यह केवल खूबसूरती से पीटा जाएगा, उदाहरण के लिए, सुंदर एनीमेशन की मदद से, तो वह संतुष्ट हो जाएगा, भले ही वास्तव में ऐसा न हो।

IOS में गेस्टाल्ट साइकोलॉजी मोटिफ्स काफी समय से घूम रहे हैं। इसलिए, यदि आप एक ही प्रसंस्करण समय के साथ दो एप्लिकेशन लेते हैं, लेकिन विभिन्न प्लेटफार्मों पर, और उन्हें एक तरफ रख देते हैं, तो ऐसा लगेगा कि iOS पर सब कुछ तेज है। आईओएस में एनीमेशन थोड़ा तेज प्रक्रिया करता है, पहले एनीमेशन स्टार्टअप और कई अन्य एनिमेशन से शुरू होता है, ताकि यह सुंदर हो।

तो पहला नियम उपयोगकर्ता के बारे में सोचना है।

और दूसरे नियम के लिए, आपको अपने आप को कट्टर में डुबोने की जरूरत है।

कोटलिन स्टाइल

ईमानदारी से कोटलिन के प्रदर्शन का मूल्यांकन करने के लिए, हम इसकी तुलना जावा से करेंगे। इसलिए, यह पता चला है कि कुछ चीजों को मापना असंभव है जो केवल कोटलिन में हैं, उदाहरण के लिए:

संग्रह आपी।
विधि डिफ़ॉल्ट पैरामीटर।
डेटा कक्षाएं।
संशोधित प्रकार।
Coroutines।

संग्रह एपीआई जो कोटलिन हमें प्रदान करता है, वह बहुत ठंडा है, बहुत तेज़ है। जावा में, यह बस मौजूद नहीं है, केवल अलग-अलग कार्यान्वयन हैं। उदाहरण के लिए, लिटविट स्ट्रीम एपीआई लाइब्रेरी धीमी होगी क्योंकि यह सब कुछ कोटलिन के समान ही करती है, लेकिन ऑपरेशन के लिए एक या दो अतिरिक्त आवंटन के साथ, क्योंकि सब कुछ एक अतिरिक्त ऑब्जेक्ट में बदल जाता है।

यदि हम जावा 8 से स्ट्रीम एपीआई लेते हैं, तो यह कोटलिन कलेक्शन एपीआई की तुलना में धीमी गति से काम करेगा, लेकिन एक शर्त के साथ - संग्रह एपीआई में ऐसा कोई पक्षाघात नहीं है, अगर हम स्ट्रीम एपीआई डेटा के बड़े संस्करणों पर समानांतर सक्षम करते हैं, जावा कोटलिन कलेक्शन एपीआई को बायपास करेगा। इसलिए, हम ऐसी चीजों की तुलना नहीं कर सकते हैं, क्योंकि हम एंड्रॉइड के दृष्टिकोण से ठीक तुलना करते हैं।

दूसरी बात, जो, यह मुझे लगती है, की तुलना नहीं की जा सकती, विधि डिफ़ॉल्ट पैरामीटर है - एक बहुत ही शांत सुविधा, जो, वैसे, डार्ट में है। जब आप कुछ विधि कहते हैं, तो इसके कुछ पैरामीटर हो सकते हैं जो कुछ मूल्य ले सकते हैं, लेकिन NULL हो सकते हैं। और इसलिए, आप 10 अलग-अलग तरीके नहीं बनाते हैं, लेकिन एक विधि करते हैं और कहते हैं कि मापदंडों में से एक NULL हो सकता है, और भविष्य में इसका उपयोग बिना किसी पैरामीटर के किया जा सकता है। यानी वह देखेगा, पैरामीटर आ गया है, या वह नहीं आया है। इसमें बहुत सुविधाजनक है कि आप बहुत कम कोड लिख सकते हैं, लेकिन असुविधा यह है कि आपको इसके लिए भुगतान करना होगा। यह सिंथेटिक चीनी है: आप, एक डेवलपर के रूप में सोचते हैं कि यह एक एपीआई विधि है, लेकिन वास्तव में, हुड के तहत, लापता मापदंडों के साथ विधि का प्रत्येक रूपांतर बायटेकोड में उत्पन्न होता है। और इन तरीकों में से प्रत्येक बिट को थोड़ा जांचता है कि क्या यह पैरामीटर आ गया है। यदि यह आया है, तो ठीक है, अगर यह नहीं हुआ, तो हम थोड़ा मुखौटा बनाते हैं, और इस बिट मास्क के आधार पर, आपके द्वारा लिखा गया मूल तरीका वास्तव में कहा जाता है। बिटवाइज़ ऑपरेशंस, सभी अगर / थोड़े बहुत पैसे खर्च करते हैं, लेकिन बहुत कम हैं, और यह सामान्य है कि आपको सुविधा के लिए भुगतान करना होगा। मुझे ऐसा लगता है कि यह बिल्कुल सामान्य है।

अगला आइटम जिसकी तुलना नहीं की जा सकती है वह डेटा क्लासेस है ।

हर कोई रोता है कि जावा में ऐसे पैरामीटर हैं जिनके लिए मॉडल कक्षाएं हैं। यानी आप पैरामीटर लेते हैं और इन सभी मापदंडों के लिए अधिक विधियाँ, गेटर्स और सेटर करते हैं। यह पता चला है कि दस मापदंडों के साथ एक वर्ग के लिए, आपको अभी भी गेटर्स, बसने वालों और एक पूरे गुच्छा की अधिक आवश्यकता है। इसके अलावा, यदि आप जनरेटर का उपयोग नहीं करते हैं, तो आपको अपने हाथों से लिखना होगा, जो आम तौर पर भयानक है।

कोटलिन आपको इन सब से दूर जाने देता है। सबसे पहले, चूंकि कोटलिन में गुण हैं, इसलिए आपको गेटर्स और सेटर लिखने की आवश्यकता नहीं है। इसमें कोई वर्ग पैरामीटर नहीं है, सभी गुण हैं । किसी भी मामले में, हम ऐसा सोचते हैं। दूसरे, यदि आप लिखते हैं कि ये डेटा वर्ग हैं, तो बाकी सब चीजों का एक पूरा समूह उत्पन्न होगा। उदाहरण के लिए, बराबर (), toStrung () / hasCode (), आदि।

बेशक, इसमें कमियां भी हैं। उदाहरण के लिए, मुझे अपने डेटा वर्गों के सभी 20 मापदंडों की मेरे बराबर () में तुलना करने की आवश्यकता नहीं है, मुझे केवल तुलना करने की आवश्यकता है 3. किसी को यह सब पसंद नहीं है क्योंकि प्रदर्शन इस पर खो जाता है, और इसके अलावा, बहुत कुछ उत्पन्न होता है सेवा कार्य, और संकलित कोड काफी बड़ा है। यही है, यदि आप सब कुछ हाथ से लिखते हैं, तो आप डेटा कक्षाओं का उपयोग करने की तुलना में कम कोड होंगे।

मैं अन्य कारणों से डेटा कक्षाओं का उपयोग नहीं करता हूं। पहले, इस तरह के वर्गों और कुछ और के विस्तार पर प्रतिबंध थे। अब हर कोई इससे बेहतर है, लेकिन आदत बनी हुई है।

कोटलिन में क्या बहुत अच्छा है, और क्या यह जावा पर हमेशा से तेज होगा? यह Reified प्रकार है , जो, वैसे, Dart में भी है।

आप जानते हैं कि जब आप जेनरिक का उपयोग करते हैं, तो संकलन चरण पर प्रकार का क्षरण मिटा दिया जाता है और रनटाइम में आप नहीं जानते कि वास्तव में इस जेनेरिक का उपयोग क्या है।

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

और कॉरआउट हैं । वे बहुत शांत हैं, मैं उन्हें बहुत पसंद करता हूं, लेकिन प्रदर्शन के समय उन्हें केवल अल्फा संस्करण में शामिल किया गया था, इसलिए उनके साथ सही तुलना करना संभव नहीं था।

मैदान

तो चलिए आगे बढ़ते हैं, जावा के साथ हम जो तुलना कर सकते हैं उस पर आगे बढ़ते हैं और जो हम सामान्य रूप से प्रभावित कर सकते हैं।

 class Test { var a = 5 var b = 6 val c = B() fun work () { val d = a + b val e = ca + cb } } class B (@JvmField var a: Int = 5,var b: Int = 6)

जैसा कि मैंने कहा, हमारे पास वर्ग के लिए पैरामीटर नहीं हैं, हमारे पास गुण हैं।

हमारे पास var है, हमारे पास val है, हमारे पास एक बाहरी वर्ग है, जिसमें से एक गुण @JvmField है, और हम देखेंगे कि वास्तव में काम के साथ क्या होता है () फ़ंक्शन: हम अपने स्वयं के वर्ग के फ़ील्ड a और फ़ील्ड b के मान को जोड़ते हैं बाहरी वर्ग के फ़ील्ड a और फ़ील्ड b के मान, जो अपरिवर्तनीय फ़ील्ड c में लिखे गए हैं।

सवाल यह है कि, वास्तव में, d = a + b में कहा जाएगा। हम सभी जानते हैं कि यह संपत्ति एक बार, इस वर्ग के गेट को इस पैरामीटर के लिए बुलाया जाएगा।

  L0 LINENUMBER 10 L0 ALOAD 0 GETFIELD kotlin/Test.a : I ALOAD 0 GETFIELD kotlin/Test.b : I IADD ISTORE 1

लेकिन अगर हम bytecode को देखें, तो हम देखेंगे कि गेटफ़ील्ड वास्तव में एक्सेस किया जा रहा है। यही है, यह बायटेकोड में InvokeVirtual फ़ंक्शन के लिए कॉल नहीं है, लेकिन फ़ील्ड तक सीधी पहुंच है। शुरू में हमसे वादा किया गया कुछ भी नहीं था, कि हमारे पास सभी गुण हैं, न कि क्षेत्र। यह पता चला है कि कोटलिन हमें धोखा दे रहा है, एक प्रत्यक्ष अपील है।

क्या होता है अगर हम देखते हैं कि एक और लाइन के लिए बायटेकोड क्या उत्पन्न होता है: वैल ई = सीए + सीबी?

  L1 LINENUMBER 11 L1 ALOAD 0 GETFIELD kotlin/Test.c : Lkotlin/B; GETFIELD kotlin/Ba : I ALOAD 0 GETFIELD kotlin/Test.c : Lkotlin/B; INVOKEVIRTUAL kotlin/B.getB ()I IADD ISTORE 2

पहले, यदि आप एक निजी संपत्ति का उपयोग कर रहे थे, तो आपके पास हमेशा एक InvokeVirtual कॉल था। यदि यह एक निजी संपत्ति थी, तो गेटफिल्ड के माध्यम से इस तक पहुंच थी। GetField, InvokeVirtual की तुलना में बहुत तेज़ है, Android के विनिर्देश यह दावा करते हैं कि सीधे किसी क्षेत्र तक पहुंचना 3 से 7 गुना तेज़ है। इसलिए, यह अनुशंसा की जाती है कि आप हमेशा फ़ील्ड का उल्लेख करें, और गेटर्स या सेटर के माध्यम से नहीं। अब, विशेष रूप से आठवीं एआरटी वर्चुअल मशीन में, पहले से ही अलग-अलग नंबर होंगे, लेकिन अगर आप अभी भी 4.1 का समर्थन करते हैं, तो यह सच होगा।

इसलिए, यह पता चला है कि यह अभी भी हमारे लिए फायदेमंद है GetField, और InvokeVirtual नहीं।

अब, आप GetField को प्राप्त कर सकते हैं यदि आप अपने स्वयं के वर्ग की संपत्ति का उपयोग कर रहे हैं, या यदि यह एक सार्वजनिक संपत्ति है, तो आपको @JvmField को सेट करना होगा। फिर, बिल्टकोड में ठीक वैसा ही एक गेटफिल्ड कॉल होगा, जो 3–7 गुना तेज है।

यह स्पष्ट है कि यहां हम नैनोसेकंड में बोलते हैं और, एक सिंहासन के साथ, यह बहुत, बहुत छोटा है। लेकिन, दूसरी ओर, यदि आप इसे यूआई थ्रेड में करते हैं, उदाहरण के लिए, ऑनट्रोड विधि में आप किसी प्रकार का दृश्य एक्सेस करते हैं, तो यह प्रत्येक फ्रेम के प्रतिपादन को प्रभावित करेगा, और आप इसे थोड़ा तेज कर सकते हैं।

यदि हम सभी अनुकूलन जोड़ते हैं, तो संक्षेप में यह कुछ दे सकता है।

स्टेटिक?

स्टैटिक्स के बारे में क्या? हम सभी जानते हैं कि कोटलिन स्थैतिक में एक साथी वस्तु है। पहले, आपने संभवतः किसी प्रकार का टैग जोड़ा था, उदाहरण के लिए, सार्वजनिक स्थैतिक, अंतिम स्थैतिक, इत्यादि, यदि आप इसे कोटलिन कोड में बदलते हैं, तो आपको एक साथी ऑब्जेक्ट मिलेगा, जो कुछ इस तरह लिखेगा:

  companion object { var k = 5 fun work2() : Int = 42 }

क्या आपको लगता है कि यह प्रविष्टि जावा में मानक स्थिर अंतिम घोषणा के समान है? यह स्थिर है या नहीं?

हां, वास्तव में, कोटलिन ने घोषणा की कि यहां वह कोटलिन में है - स्थैतिक, वह वस्तु कहती है कि यह स्थिर है। वास्तव में, यह स्थिर नहीं है।

यदि हम उत्पन्न बायटेकोड को देखते हैं, तो हम निम्नलिखित देखेंगे:

  L2 LINENUMBER 21 L2 GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.getK ()I GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.work2 ()I IADD ISTORE 3

एक Test.Companion उत्पन्न होता है, एक सिंगलटन ऑब्जेक्ट जिसके लिए उदाहरण बनाया जाता है, यह उदाहरण अपने क्षेत्र में लिखा जाता है। उसके बाद, इस ऑब्जेक्ट के माध्यम से एक साथी ऑब्जेक्ट तक पहुंच होती है। वह getstatic लेता है, अर्थात, इस वर्ग का एक स्थिर उदाहरण है, और उस पर getK फ़ंक्शन invokevirtual को आमंत्रित करता है, और कार्य 2 फ़ंक्शन के लिए बिल्कुल यही है। तो हम पाते हैं कि यह स्थिर नहीं है।

यह मायने रखता है, क्योंकि पुराने JVM पर, इनवोकैस्टिक की तुलना में इनवोकैस्टिक लगभग 30% तेज था। अब, निश्चित रूप से, हॉटस्पॉट में, अनुकूलित वर्चुअलाइजेशन वास्तव में अच्छा चल रहा है, और यह लगभग अदृश्य है। फिर भी, आपको इसे ध्यान में रखने की आवश्यकता है, खासकर जब से एक अतिरिक्त आवंटन है, और 4ST1 पर एक अतिरिक्त स्थान 700 नैनोसेकंड है, बहुत अधिक है।

आइए देखें कि जावा कोड क्या है जो यदि आप बायटेकोड को रिवर्स-परिनियोजित करता है तो:

 private static int k = 5; public static final Test.Companion Companion = new Test.Companion((DefaultConstructorMarker)null); public static final class Companion { public final int getK() { return Test.k;} public final void setK(int var1) { Test.k = var1; } public final int work2() { return 42; } private Companion() { } // $FF: synthetic method public Companion(DefaultConstructorMarker $constructor_marker) { this(); } }

एक स्थिर फ़ील्ड बनाया जाता है, साथी ऑब्जेक्ट का एक स्थिर अंतिम कार्यान्वयन, गेटर्स और सेटर बनाया जाता है, और, जैसा कि आप देख सकते हैं, अंदर स्थिर क्षेत्र का उल्लेख करते हुए, एक अतिरिक्त स्थैतिक विधि प्रकट होती है। सब कुछ काफी उदास है।

हम यह सुनिश्चित कर सकते हैं कि यह स्थिर नहीं है? हम @JvmField और @JvmStatic को जोड़कर देख सकते हैं कि क्या होता है।

 val i = k + work2() companion object { @JvmField var k = 5 JvmStatic fun work2() : Int = 42 }

मैं तुरंत कहूंगा कि आप @JvmStatic से दूर नहीं होंगे, यह एक ही ऑब्जेक्ट होगा, क्योंकि यह एक साथी ऑब्जेक्ट है, इस ऑब्जेक्ट का एक अतिरिक्त आवंटन होगा और एक अतिरिक्त कॉल होगा।

 private static int k = 5; public static final Test.Companion Companion = new Test.Companion((DefaultConstructorMarker)null); public static final class Companion { @JvmStatic public final int work2() { return 42; } private Companion() {} // $FF: synthetic method public Companion(DefaultConstructorMarker $constructor_marker) { this(); } }

लेकिन कॉल केवल k के लिए बदल जाएगा, क्योंकि यह @JvmField होगा, इसे सीधे getstatic के रूप में लिया जाएगा, गेटर्स और सेटर अब उत्पन्न नहीं होंगे। लेकिन फ़ंक्शन 2 के लिए कुछ भी नहीं बदलेगा।

  L2 LINENUMBER 21 L2 GETSTATIC kotlin/Test.k : I GETSTATIC kotlin/Test.Companion : Lkotlin/Test$Companion; INVOKEVIRTUAL kotlin/Test$Companion.work2 ()I IADD ISTORE 3

कोटलिन प्रलेखन में स्थिर बनाने का दूसरा विकल्प प्रस्तावित है, इसलिए यह कहा जाता है कि हम सिर्फ एक ऑब्जेक्ट बना सकते हैं, और यह स्थिर कोड होगा।

 object A { fun test() = 53 }

वास्तव में, यह भी ऐसा नहीं है।

 L3 LINENUMBER 23 L3 GETSTATIC kotlin/A.INSTANCE : Lkotlin/A; INVOKEVIRTUAL kotlin/A.test ()I POP

यह पता चला है कि हम सिंगलेटोन से एक अस्थिर उदाहरण कॉल करते हैं, जो बनाया जाता है, और ठीक उसी आभासी तरीकों को कॉल करता है।

एकमात्र तरीका जिससे हम इनोकैस्टैटिक प्राप्त कर सकते हैं, वह है उच्च-ऑर्डर कार्य। जब हम सिर्फ कक्षा के बाहर कुछ फ़ंक्शन लिखते हैं, उदाहरण के लिए, मजेदार टेस्ट 2 को वास्तव में स्थिर कहा जाएगा।

  fun test2() = 99 L4 LINENUMBER 24 L4 INVOKESTATIC kotlin/TestKt.test2 ()I POP

इसके अलावा, सबसे दिलचस्प बात यह है कि एक वर्ग बनाया जाएगा, एक वस्तु, इस मामले में testKt, यह खुद के लिए एक ऑब्जेक्ट उत्पन्न करेगा, यह एक फ़ंक्शन उत्पन्न करेगा जो इसे इस ऑब्जेक्ट में डालता है, और अब इसे इनवोकैस्टिक कहा जाएगा।

ऐसा क्यों किया गया यह समझ से बाहर है। कई लोग इससे नाखुश हैं, लेकिन ऐसे लोग हैं जो इस तरह के कार्यान्वयन को काफी सामान्य मानते हैं। वर्चुअल मशीन के बाद से, incl। कला में सुधार हो रहा है, अब यह इतना महत्वपूर्ण नहीं है। एंड्रॉइड के आठवें संस्करण में, हॉटस्पॉट की तरह, सब कुछ अनुकूलित है, लेकिन फिर भी ये छोटी चीजें समग्र प्रदर्शन को थोड़ा प्रभावित करती हैं।

NULLABILITY

 fun test(first: String, second: String?) : String { second ?: return first return "$first $second" }

यह अगला दिलचस्प उदाहरण है। ऐसा लगता है कि हमने नोट किया है कि दूसरा अशक्त हो सकता है, और इसके साथ कुछ भी करने से पहले इसकी जांच होनी चाहिए। इस मामले में, मुझे उम्मीद है कि हमारे पास एक अगर है। जब यह कोड तैनात किया जाता है यदि दूसरा शून्य के बराबर नहीं है, तो मुझे लगता है कि निष्पादन आगे बढ़ेगा और केवल पहले आउटपुट होगा।

यह सब वास्तव में जावा कोड में कैसे प्रकट होता है? वास्तव में एक जाँच होगी।

 @NotNull public final String test(@NotNull String first,@Nullable String second) { Intrinsics.checkParameterIsNotNull(first, "first"); return second != null ? (first + " " + second) : first; }

हम शुरू में आंतरिक मिलेंगे। मान लीजिए कि मैं कहता हूं कि यह एक है

यदि एक टर्नरी ऑपरेटर में विस्तार होगा। लेकिन इसके अलावा, हालांकि हमने यह भी तय किया कि पहला पैरामीटर अशक्त नहीं हो सकता है, फिर भी इसे आंतरिक के माध्यम से जांचा जाएगा।

इंट्रिंसिक्स कोटलिन में एक आंतरिक वर्ग है जिसमें मापदंडों और जांचों का एक निश्चित समूह है। और हर बार जब आप विधि पैरामीटर को गैर-अशक्त बनाते हैं, तो यह वैसे भी इसकी जांच करता है। क्यों? फिर, कि हम इंटरोप जावा में काम करते हैं, और ऐसा हो सकता है कि आप उम्मीद करते हैं कि यह यहाँ अशक्त नहीं होगा, लेकिन जावा के साथ यह कहीं से आएगा।

यदि आप इसकी जांच करते हैं, तो यह कोड के साथ आगे बढ़ेगा, और फिर 10-20 विधि कॉल के बाद, आप एक पैरामीटर के साथ कुछ ऐसा करेंगे, हालांकि यह अशक्त नहीं हो सकता है, लेकिन किसी कारण से यह निकला। आपके लिए सब कुछ गिर जाएगा, और आप समझ नहीं पाएंगे कि वास्तव में क्या हुआ था। इस स्थिति से बचने के लिए, हर बार जब आप अशक्त पैरामीटर पास करते हैं, तब भी आपको इसकी जांच करनी होगी। और अगर यह अशक्त है, तो एक अपवाद होगा।

यह चेक भी कुछ के लायक है, और अगर उनमें से कई हैं, तो यह बहुत अच्छा नहीं होगा।

लेकिन वास्तव में, अगर हम हॉटस्पॉट के बारे में बात करते हैं, तो इन आंतरिक के 10 कॉल में लगभग चार नैनोसेकंड लगेंगे। यह बहुत, बहुत छोटा है, और आपको इस बारे में चिंता नहीं करनी चाहिए, लेकिन यह एक दिलचस्प कारक है।

पुरातन

जावा में आदिम जैसी कोई चीज होती है। कोटलिन में, जैसा कि हम सभी जानते हैं, कोई आदिम नहीं हैं, हम हमेशा वस्तुओं के साथ काम करते हैं। जावा में, वे कुछ मामूली संगणना पर वस्तुओं के लिए उच्च प्रदर्शन प्रदान करने के लिए उपयोग किए जाते हैं। दो वस्तुओं को जोड़ने के लिए दो आदिम जोड़ने की तुलना में बहुत अधिक महंगा है। एक उदाहरण पर विचार करें।

  var a = 5 var b = 6 var bOption : Int? = 6

तीन नंबर हैं, पहले दो के लिए शून्य प्रकार नहीं घटाया जाएगा, और तीसरे के बारे में हम कहते हैं कि यह अशक्त हो सकता है।

  private int a = 5; private int b = 6; @Nullable private Integer bOption = Integer.valueOf(6);

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

autoboxing

जब आप आदिम के साथ काम करते हैं और एक आदिम और गैर-आदिम के साथ एक ऑपरेशन करते हैं, तो आपको या तो उनमें से एक को आदिम में या किसी वस्तु में अनुवाद करना होगा।

और, ऐसा लगता है, यह आश्चर्य की बात नहीं है कि अगर आप कोटलिन में अशक्त और अशक्त के साथ संचालन करते हैं, तो आप प्रदर्शन में थोड़ा खो देते हैं। इसके अलावा, अगर ऐसे कई ऑपरेशन हैं, तो आप बहुत कुछ खो देते हैं।

  val a: String? = null var b = a?.isBlank() == true

देखें कि बॉक्सिंग / अनबॉक्सिंग यहां कहां होगा? मैंने भी तब तक नहीं देखा जब तक कि मैंने बायटेकोड को नहीं देखा।

 if (a != null && a.isBlank()) true else false

वास्तव में, मुझे उम्मीद थी कि इस तुलना में कुछ ऐसा होगा: यदि स्ट्रिंग अशक्त नहीं है और यदि यह खाली है, तो सही पर सेट करें, अन्यथा झूठे पर सेट करें। सब कुछ सरल लगता है, लेकिन वास्तव में निम्नलिखित कोड उत्पन्न होता है:

 String a = (String)null; boolean b = Intrinsics.areEqual(a != null ? Boolean.valueOf(StringsKt.isBlank((CharSequence)a)) : null, Boolean.valueOf(true));

चलो अंदर देखो। चर को लिया जाता है, यह CharSequence में डाला जाता है, इसे डाले जाने के बाद, जिसे कुछ समय के लिए खर्च भी किया जाता है, एक और चेक कहा जाता है - StringsKt.isBlank - यह कैसे CharSequence के लिए एक्सटेंशन फ़ंक्शन लिखा जाता है, इसलिए इसे कास्ट और भेजा जाता है। चूंकि पहली अभिव्यक्ति अशक्त हो सकती है, इसलिए यह इसे लेता है और बॉक्सिंग करता है, और इसे बूलियन.वेल्यूऑफ में लपेटता है। इसलिए, सच्चा आदिम भी एक वस्तु बन जाता है, और उसके बाद ही सत्यापन पहले से ही होता है और Intrinsics.areEqual कहा जाता है।

यह इतना आसान ऑपरेशन लगता है, लेकिन ऐसा अप्रत्याशित परिणाम है। वास्तव में, ऐसी बहुत कम चीजें हैं। लेकिन जब आप अशक्त / अशक्त नहीं हो सकते हैं, तो आप बहुत सारी ऐसी चीजें उत्पन्न कर सकते हैं, और एक ऐसी चीज जिसकी आपने कभी उम्मीद नहीं की होगी। इसलिए, मेरा सुझाव है कि आप जितनी जल्दी हो सके अश्लीलता से दूर हो जाएं। यानी जितनी जल्दी हो सके मूल्यों की प्रतिरक्षा में आएँ और अशक्त से दूर जाएँ ताकि आप जितनी जल्दी हो सके अशक्त न हो।

छोरों

अगली दिलचस्प बात।

आप सामान्य उपयोग कर सकते हैं, जो कि जावा में है, लेकिन आप नए सुविधाजनक एपीआई का उपयोग भी कर सकते हैं - सूची में तत्वों की गणना को तुरंत लिखें। , work, it - .

 list.forEach { work(it * 2) }

. , . , Google, , ArrayList for 3 , . .

, ArrayList, — foreach.

 inline fun <reified T> List<T>.foreach(crossinline action: (T) -> Unit): Unit { val size = size var i = 0 while (i < size) { action(get(i)) i++ } } list.foreach { }

API, - . , Kotlin: extension , «», reified, .. , , , crossinline. , , . 3 , Android Google.

RANGES

Ranges.

 inline fun <reified T> List<T>.foreach(crossinline action: (T) -> Unit): Unit { val size = size for(i in 0..size) { work(i * 2) } }

: Unit -. −1, until , , . , , ranges. यानी , . step. .

INTRINSICS

- Intrinsics, :

 class Test { fun concat(first: String, second: String) = "$first $second" }

Intrinsics — second, first.

 public final class Test { @NotNull public final String concat(@NotNull String first, @NotNull String second) { Intrinsics.checkParameterIsNotNull(first, "first"); Intrinsics.checkParameterIsNotNull(second, "second"); return first + " " + second; } }

, gradle. , - 4 , . Kotlin UI, , nullable, Kotlin :

kotlinc -Xno-call-assertions -Xno-param-assertions Test.kt

Intrinsics, , .

, , . — Xno-param-assertions — Intrinsics, .

, , , , , . , , , .

REDEX

, , , Proguard. , 99% , , . Android 8.0 , . , .

, Proguard, Facebook, Redex . -, , . , Jvm Fields , .

, Redex . , , , Proguard, , . Redex 7% APK. , .