Android Lint क्या है और यह आपको समर्थित कोड लिखने में कैसे मदद करता है

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

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

नमस्ते नमस्ते

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

लेकिन कभी-कभी हमें अपने कोड में विशिष्ट समस्याओं को खोजने की आवश्यकता होती है जो इन मौजूदा चेक द्वारा कवर नहीं की जाती हैं।

हैलो कस्टम चेक लिंट

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

लिंट उपयोगकर्ता चेक को मानक जावा (या कोटलिन) मॉड्यूल के भाग के रूप में लिखा जाता है। आरंभ करने का सबसे आसान तरीका एक साधारण ग्रेडल-आधारित प्रोजेक्ट बनाना है (इसमें एंड्रॉइड प्रोजेक्ट होना आवश्यक नहीं है)।

फिर लिंट निर्भरता जोड़ें। अपने मॉड्यूल के build.gradle फ़ाइल में जोड़ें:

 compileOnly "com.android.tools.lint:lint-api:$lintVersion" compileOnly "com.android.tools.lint:lint-checks:$lintVersion" 

अब एक चाल है जो मैंने इस विषय पर शोध करते समय सीखी। lintVersion को gradlePluginVersion + 23.0.0 lintVersion होना चाहिए। gradlePluginVersion प्रोजेक्ट स्तर पर build.gradle फ़ाइल में परिभाषित एक चर है। और फिलहाल, नवीनतम स्थिर संस्करण 3.3.0 है। इसका मतलब है कि lintVersion होना चाहिए।

प्रत्येक लिंट चेक में 4 भाग होते हैं:

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

कार्यान्वयन

चलो हमारे कस्टम सत्यापन के लिए एक कार्यान्वयन बनाकर शुरू करते हैं। प्रत्येक कार्यान्वयन में एक डिटेक्टर और एक क्षेत्र को लागू करने वाले एक वर्ग होता है।

 val correctClickListenerImplementation = Implementation(CorrectClickListenerDetector::class.java, Scope.JAVA_FILE_SCOPE) 

याद रखें कि Scope.JAVA_FILE_SCOPE भी Scope.JAVA_FILE_SCOPE वर्गों के लिए काम करेगा।

समस्या

अगला कदम समस्या को निर्धारित करने के लिए इस कार्यान्वयन का उपयोग करना है। प्रत्येक समस्या में कई भाग होते हैं:

• आईडी एक विशिष्ट पहचानकर्ता है।
• विवरण - समस्या का एक संक्षिप्त (5-6 शब्द) कथन।
• स्पष्टीकरण यह कैसे ठीक करने के बारे में एक सुझाव के साथ एक समस्या का पूरा विवरण।
• श्रेणी - समस्या की श्रेणी (प्रदर्शन, अनुवाद, सुरक्षा, आदि)।
• प्राथमिकता - 1 से 10 की सीमा में समस्या का महत्व, जहां 10 सबसे अधिक है। इसका उपयोग लिंट के लॉन्च होने पर बनाई गई रिपोर्ट में समस्याओं को हल करने के लिए किया जाएगा।
• गंभीरता - समस्या की गंभीरता (घातक, त्रुटि, चेतावनी, सूचना या अनदेखी)।
• एक कार्यान्वयन एक कार्यान्वयन है जिसका उपयोग इस समस्या का पता लगाने के लिए किया जाएगा।

 val ISSUE_CLICK_LISTENER = Issue.create( id = "UnsafeClickListener", briefDescription = "Unsafe click listener", explanation = """" This check ensures you call click listener that is throttled instead of a normal one which does not prevent double clicks. """.trimIndent(), category = Category.CORRECTNESS, priority = 6, severity = Severity.WARNING, implementation = correctClickListenerImplementation ) 

डिटेक्टर

लिंट एपीआई प्रत्येक क्षेत्र के लिए इंटरफेस प्रदान करता है जिसे आप कार्यान्वयन में परिभाषित कर सकते हैं। इनमें से प्रत्येक इंटरफेस उन तरीकों को प्रदान करता है जिन्हें आप कोड के उन हिस्सों को ओवरराइड और एक्सेस कर सकते हैं जो आपकी रुचि रखते हैं।

• UastScanner - जावा या कोटलिन फाइलें (UAST - Unified Abstract Syntax Tree (रूसी एकीकृत सार सिंटैक्स ट्री ))।
• क्लासस्कैनर - संकलित फाइलें ( बायटेकोड )।
• BinaryResourceScanner - द्विआधारी संसाधन जैसे बिटमैप्स या res/raw फाइलें।
• ResourceFolderScanner - संसाधन फ़ोल्डर (उनमें विशिष्ट फ़ाइलें नहीं)।
• XmlScanner - XML ​​फ़ाइलें।
• GradleScanner - ग्रेड फाइल।
• OtherFileScanner - बाकी सब कुछ।

इसके अलावा, Detector वर्ग एक आधार वर्ग है जिसमें उपरोक्त प्रत्येक इंटरफेस द्वारा प्रदान की गई सभी विधियों का खाली कार्यान्वयन है, इसलिए आपको केवल एक विधि की आवश्यकता होने पर पूर्ण इंटरफ़ेस को लागू करने की आवश्यकता नहीं है।

अब हम एक डिटेक्टर को लागू करने के लिए तैयार हैं जो ऑब्जेक्ट के लिए सही विधि कॉल की जांच करेगा।

 private const val REPORT_MESSAGE = "Use setThrottlingClickListener" /** *   ,        *     ,      . */ class CorrectClickListenerDetector : Detector(), Detector.UastScanner { /** * ,  ,      . *         , *          , *      ,   . */ override fun getApplicableUastTypes(): List<Class<out UElement>>? { return listOf<Class<out UElement>>(UCallExpression::class.java) } /** *      UAST,    , *    UAST   .    UElementHandler, *   ,     , *    ,  , , ,   .. *        ,    *    .     —  ,   *   ,    ,       . */ override fun createUastHandler(context: JavaContext): UElementHandler? { return object: UElementHandler() { override fun visitCallExpression(node: UCallExpression) { if (node.methodName != null && node.methodName?.equals("setOnClickListener", ignoreCase = true) == true) { context.report(ISSUE_CLICK_LISTENER, node, context.getLocation(node), REPORT_MESSAGE, createFix()) } } } } /** *    ,    *   IDE,      . */ private fun createFix(): LintFix { return fix().replace().text("setOnClickListener").with("setThrottlingClickListener").build() } } 

रजिस्ट्री

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

 class MyIssueRegistry : IssueRegistry() { override val issues: List<Issue> = listOf(ISSUE_CLICK_LISTENER) } 

build.gradle मॉड्यूल स्तर में:

 jar { manifest { attributes("Lint-Registry-v2": "co.infinum.lint.MyIssueRegistry") } } 

जहां co.infinum.lint क्लास MyIssueRegistry का पैकेज है। अब आप gradlew स्क्रिप्ट का उपयोग करके jar कार्य को चला सकते हैं, और लाइब्रेरी build/libs निर्देशिका में दिखाई देनी चाहिए।

यहाँ एक लिंट उपयोगकर्ता की जाँच का एक और उदाहरण है, जहाँ आप देख सकते हैं कि XML फ़ाइलों को कैसे संसाधित किया जाए।

के उपयोग

आपका नया लिंट चेक प्रोजेक्ट में उपयोग के लिए तैयार है। यदि यह चेक सभी परियोजनाओं पर लागू किया जा सकता है, तो आप इसे ~/.android/lint फ़ोल्डर में डाल सकते हैं (यदि यह पहले से मौजूद नहीं है तो आप इसे बना सकते हैं)।

इसके अलावा, आप अपने प्रोजेक्ट में एक अलग मॉड्यूल में अपना चेक डाल सकते हैं और इस मॉड्यूल को किसी भी अन्य निर्भरता की तरह सक्षम कर सकते हैं lintChecks विधि का उपयोग कर।

क्या यह इसके लायक है?

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