लिंट जांच की मदद से अपने कोड को बेहतर बनाना

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

उदाहरण के लिए, अगर आपकी एक्सएमएल संसाधन फ़ाइलों में ऐसे नेमस्पेस हैं जिनका इस्तेमाल नहीं किया गया है, तो इससे स्टोरेज का इस्तेमाल होता है और प्रोसेसिंग में ज़्यादा समय लगता है. स्ट्रक्चर से जुड़ी अन्य समस्याओं की वजह से, कोड सही तरीके से काम नहीं कर सकता. जैसे, ऐसे एलिमेंट का इस्तेमाल करना जो अब काम नहीं करते या टारगेट एपीआई वर्शन के साथ काम न करने वाले एपीआई कॉल. Lint की मदद से, इन समस्याओं को ठीक किया जा सकता है.

लिंटिंग की परफ़ॉर्मेंस को बेहतर बनाने के लिए, अपने कोड में एनोटेशन जोड़े जा सकते हैं.

खास जानकारी

Android Studio में lint नाम का कोड स्कैनिंग टूल उपलब्ध होता है. इसकी मदद से, ऐप्लिकेशन को चलाए बिना या टेस्ट केस लिखे बिना, कोड के स्ट्रक्चर की क्वालिटी से जुड़ी समस्याओं की पहचान की जा सकती है और उन्हें ठीक किया जा सकता है. टूल से पता चली हर समस्या की शिकायत, जानकारी वाले मैसेज और गंभीरता के लेवल के साथ की जाती है. इससे, आपको उन ज़रूरी सुधारों को प्राथमिकता देने में मदद मिलती है जिन्हें करना ज़रूरी है. आपके पास किसी समस्या की गंभीरता के लेवल को कम करने का विकल्प भी होता है, ताकि आप अपने प्रोजेक्ट से जुड़ी समस्याओं को अनदेखा कर सकें. इसके अलावा, किसी समस्या को हाइलाइट करने के लिए, उसकी गंभीरता का लेवल बढ़ाया जा सकता है.

लिंट टूल, आपके Android प्रोजेक्ट की सोर्स फ़ाइलों में संभावित गड़बड़ियों की जांच करता है. साथ ही, सही होने, सुरक्षा, परफ़ॉर्मेंस, इस्तेमाल करने में आसानी, सुलभता, और अंतरराष्ट्रीय स्तर पर उपलब्ध कराने के लिए, ऑप्टिमाइज़ेशन में सुधार करता है. Android Studio का इस्तेमाल करते समय, ऐप्लिकेशन बनाने पर, कॉन्फ़िगर की गई lint और IDE की जांच की सुविधाएं काम करती हैं. हालांकि, इस पेज पर बताए गए तरीके से, जांच को मैन्युअल तरीके से चलाया जा सकता है या कमांड-लाइन से lint को चलाया जा सकता है.

Android Studio का इस्तेमाल करते समय, पहले से मौजूद लिंट टूल आपके कोड की जांच करता है. चेतावनियां और गड़बड़ियां दो तरीकों से देखी जा सकती हैं:

  • एडिटर विंडो में पॉप-अप टेक्स्ट के तौर पर. जब लिंट को कोई समस्या मिलती है, तो वह समस्या वाले कोड को पीले रंग में हाइलाइट करता है. गंभीर समस्याओं के लिए, यह कोड को लाल रंग से अंडरलाइन करता है.
  • कोड > कोड की जांच करें पर क्लिक करने पर, लिंट की जांच के नतीजे विंडो में.

ध्यान दें: जब आपका कोड Android Studio में कंपाइल किया जाता है, तो कोड की समीक्षा को आसान बनाने के लिए, IntelliJ कोड की जांच करने वाली अतिरिक्त प्रोसेस शुरू होती है. Android Studio को जितना हो सके उतना अप-टू-डेट रखें, ताकि यह पक्का किया जा सके कि लिंट के सबसे नए नियम और जांच की सुविधाएं उपलब्ध हों.

पहली इमेज में दिखाया गया है कि lint टूल, ऐप्लिकेशन की सोर्स फ़ाइलों को कैसे प्रोसेस करता है.

lint टूल की मदद से कोड स्कैन करने का वर्कफ़्लो.
पहला डायग्राम. लिंट टूल की मदद से कोड स्कैन करने का वर्कफ़्लो.
ऐप्लिकेशन की सोर्स फ़ाइलें
सोर्स फ़ाइलों में वे फ़ाइलें होती हैं जिनसे आपका Android प्रोजेक्ट बनता है. इनमें Kotlin, Java, और एक्सएमएल फ़ाइलें, आइकॉन, और ProGuard कॉन्फ़िगरेशन फ़ाइलें शामिल हैं.
lint.xml फ़ाइल
यह एक कॉन्फ़िगरेशन फ़ाइल है. इसका इस्तेमाल, उन सभी लिंट जांचों को बताने के लिए किया जा सकता है जिन्हें आपको बाहर रखना है. साथ ही, समस्या की गंभीरता के लेवल को पसंद के मुताबिक बनाने के लिए भी इसका इस्तेमाल किया जा सकता है.
लिंट टूल
स्टैटिक कोड स्कैनिंग टूल, जिसे कमांड लाइन या Android Studio से अपने Android प्रोजेक्ट पर चलाया जा सकता है. लिंट टूल, कोड के स्ट्रक्चर से जुड़ी उन समस्याओं की जांच करता है जिनसे आपके Android ऐप्लिकेशन की क्वालिटी और परफ़ॉर्मेंस पर असर पड़ सकता है.
लिंट की जांच के नतीजे
Android Studio में, लिंट की जांच के नतीजे, कंसोल या जांच के नतीजे विंडो में देखे जा सकते हैं. कमांड लाइन से lint चलाने पर, नतीजे build/ फ़ोल्डर में लिखे जाते हैं. ज़्यादा जानकारी के लिए, मैन्युअल तरीके से जांच करने के बारे में बताने वाला सेक्शन देखें.

कमांड लाइन से lint चलाना

अगर Android Studio या Gradle का इस्तेमाल किया जा रहा है, तो अपने प्रोजेक्ट के लिए lint टास्क को शुरू करने के लिए, Gradle wrapper का इस्तेमाल करें. इसके लिए, अपने प्रोजेक्ट की रूट डायरेक्ट्री से इनमें से कोई एक कमांड डालें:

ध्यान दें: लिंट के सबसे नए नियमों का इस्तेमाल करने के लिए, Android Gradle प्लग इन को जितना हो सके उतना अप-टू-डेट रखें.

  • Windows पर: 
    gradlew lint
  • Linux या macOS पर: 
    ./gradlew lint

आपको इससे मिलता-जुलता आउटपुट दिखेगा:

> Task :app:lintDebug
Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results-debug.html

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

एचटीएमएल लिंट रिपोर्ट का सैंपल
दूसरी इमेज. एचटीएमएल लिंट रिपोर्ट का सैंपल.

अगर आपके प्रोजेक्ट में बिल्ड के वैरिएंट शामिल हैं, तो लिंट सिर्फ़ डिफ़ॉल्ट वैरिएंट की जांच करता है. अगर आपको किसी दूसरे वैरिएंट पर लिंट चलाना है, तो आपको वैरिएंट के नाम को कैपिटल लेटर में लिखना होगा और उसके आगे lint लगाना होगा. 

./gradlew lintRelease

ध्यान दें: Lint, आपके बिल्ड के हिस्से के तौर पर अपने-आप नहीं चलता. हमारा सुझाव है कि आप कंटिन्यूअस इंटिग्रेशन बिल्ड के हिस्से के तौर पर, लिंट को साफ़ तौर पर चलाएं, ताकि आपको अपने मौजूदा सोर्स कोड को बिल्ड करते समय, लिंट की नई जांचें दिखें.

कमांड लाइन से Gradle टास्क चलाने के बारे में ज़्यादा जानने के लिए, कमांड लाइन से अपना ऐप्लिकेशन बनाएं लेख पढ़ें.

स्टैंडअलोन टूल का इस्तेमाल करके, lint चलाना

अगर Android Studio या Gradle का इस्तेमाल नहीं किया जा रहा है, तो स्टैंडअलोन लिंट टूल का इस्तेमाल करने के लिए, Android SDK के कमांड-लाइन टूल इंस्टॉल करें. android_sdk/cmdline-tools/version/bin/lint पर जाकर, लिंट टूल ढूंढें.

ध्यान दें: अगर किसी Gradle प्रोजेक्ट पर स्टैंडअलोन टूल को चलाने की कोशिश की जाती है, तो आपको गड़बड़ी का मैसेज दिखता है. Gradle प्रोजेक्ट पर lint चलाने के लिए, आपको हमेशा gradle lint (Windows पर) या ./gradlew lint (macOS या Linux पर) का इस्तेमाल करना चाहिए.

प्रोजेक्ट डायरेक्ट्री में मौजूद फ़ाइलों की सूची के लिए, लिंट चलाने के लिए यह कमांड इस्तेमाल करें:

lint [flags] <project directory>

उदाहरण के लिए, myproject डायरेक्ट्री और उसकी सबडायरेक्ट्री में मौजूद फ़ाइलों को स्कैन करने के लिए, यह कमांड दिया जा सकता है. समस्या का आईडी MissingPrefix लिंट को सिर्फ़ उन एक्सएमएल एट्रिब्यूट को स्कैन करने के लिए कहता है जिनमें Android नेमस्पेस प्रीफ़िक्स मौजूद नहीं है.

lint --check MissingPrefix myproject

इस टूल के साथ काम करने वाले फ़्लैग और कमांड-लाइन आर्ग्युमेंट की पूरी सूची देखने के लिए, इस कमांड का इस्तेमाल करें:

lint --help

यहां दिए गए उदाहरण में, 'भूकंप' नाम के प्रोजेक्ट के लिए, lint कमांड चलाने पर कंसोल का आउटपुट दिखाया गया है: 

$ lint Earthquake

Scanning Earthquake: ...............................................................................................................................
Scanning Earthquake (Phase 2): .......
AndroidManifest.xml:23: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder]
  <uses-sdk android:minSdkVersion="7" />
  ^
AndroidManifest.xml:23: Warning: <uses-sdk> tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
  <uses-sdk android:minSdkVersion="7" />
  ^
res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings

उदाहरण के तौर पर दिए गए आउटपुट में चार चेतावनियां और कोई गड़बड़ी नहीं है.

प्रोजेक्ट की AndroidManifest.xml फ़ाइल से जुड़ी दो चेतावनियां:

  • ManifestOrder
  • UsesMinSdkAttributes
Preferences.xml लेआउट फ़ाइल: UnusedResources से जुड़ी एक चेतावनी.

एक चेतावनी res डायरेक्ट्री से जुड़ी है: IconMissingDensityFolder.

चेतावनियों को रोकने के लिए, lint को कॉन्फ़िगर करना

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

गंभीरता के लेवल ये हैं:

  • enable
  • disable या ignore
  • informational
  • warning
  • error
  • fatal

अलग-अलग लेवल के लिए, लिंट की जांच को कॉन्फ़िगर किया जा सकता है:

  • दुनिया भर में (पूरा प्रोजेक्ट)
  • प्रोजेक्ट मॉड्यूल
  • प्रोडक्शन मॉड्यूल
  • टेस्ट मॉड्यूल
  • फ़ाइलें खोलो
  • क्लास की हैरारकी
  • वर्शन कंट्रोल सिस्टम (वीसीएस) के दायरे

लिंट फ़ाइल कॉन्फ़िगर करना

lint.xml फ़ाइल में, लिंट की जांच से जुड़ी अपनी प्राथमिकताएं तय की जा सकती हैं. अगर यह फ़ाइल मैन्युअल तरीके से बनाई जा रही है, तो इसे अपने Android प्रोजेक्ट की रूट डायरेक्ट्री में रखें.

lint.xml फ़ाइल में एक <lint> पैरंट टैग होता है, जिसमें एक या एक से ज़्यादा चाइल्ड <issue> एलिमेंट होते हैं. Lint, हर <issue> के लिए एक यूनीक id एट्रिब्यूट वैल्यू तय करता है:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- list of issues to configure -->
</lint>

किसी समस्या की गंभीरता का लेवल बदलने या समस्या के लिए लिंट की जांच बंद करने के लिए, <issue> टैग में गंभीरता एट्रिब्यूट सेट करें.

सलाह: जिन समस्याओं के लिए लिंट की सुविधा काम करती है और उनके आईडी की पूरी सूची देखने के लिए, lint --list कमांड चलाएं.

lint.xml फ़ाइल का सैंपल

इस उदाहरण में, lint.xml फ़ाइल का कॉन्टेंट दिखाया गया है:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Disable the IconMissingDensityFolder check in this project -->
    <issue id="IconMissingDensityFolder" severity="ignore" />

    <!-- Ignore the ObsoleteLayoutParam issue in the specified files -->
    <issue id="ObsoleteLayoutParam">
        <ignore path="res/layout/activation.xml" />
        <ignore path="res/layout-xlarge/activation.xml" />
    </issue>

    <!-- Ignore the UselessLeaf issue in the specified file -->
    <issue id="UselessLeaf">
        <ignore path="res/layout/main.xml" />
    </issue>

    <!-- Change the severity of hardcoded strings to "error" -->
    <issue id="HardcodedText" severity="error" />
</lint>

इस उदाहरण में बताया गया है कि अलग-अलग तरह की समस्याओं की शिकायत कैसे की जाती है. IconMissingDensityFolder जांच पूरी तरह से बंद है और ObsoleteLayoutParam जांच सिर्फ़ उन फ़ाइलों में बंद है जिनके बारे में <ignore ... /> एलान में बताया गया है.

Kotlin, Java, और एक्सएमएल सोर्स फ़ाइलों के लिए, लिंट की जांच करने की सुविधा कॉन्फ़िगर करना

प्राथमिकताएं डायलॉग में जाकर, Kotlin, Java, और एक्सएमएल सोर्स फ़ाइलों के लिए, लिंट की जांच की सुविधा को बंद किया जा सकता है:

  1. Windows पर, फ़ाइल > सेटिंग या macOS या Linux पर, Android Studio > प्राथमिकताएं चुनें.
  2. एडिटर > जांच चुनें.
  3. बंद करने के लिए, सही सोर्स फ़ाइल से चुने हुए का निशान हटाएं.

इन्हें IDE या अलग-अलग प्रोजेक्ट के लिए सेट किया जा सकता है. इसके लिए, सही प्रोफ़ाइल चुनें.

Java या Kotlin में, लिंट की जांच करने की सुविधा को कॉन्फ़िगर करना

अपने Android प्रोजेक्ट में किसी क्लास या तरीके के लिए, लिंट की जांच करने की सुविधा बंद करने के लिए, उस कोड में @SuppressLint एनोटेशन जोड़ें.

यहां दिए गए उदाहरण में, onCreate तरीके में NewApi समस्या के लिए, लिंट की जांच बंद करने का तरीका बताया गया है. लिंट टूल, इस क्लास के अन्य तरीकों में NewApi की समस्या की जांच करता रहता है.

Kotlin

@SuppressLint("NewApi")
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main)

Java

@SuppressLint("NewApi")
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

ऐसा किसी भी Composable पर किया जा सकता है. नीचे दिए गए कोड स्निपेट में, किसी भी Composable पर NewApi की जांच करने की सुविधा को बंद करने का तरीका बताया गया है.

Kotlin

  @SuppressLint("NewApi")
  @Composable
  fun MyComposable{
    ...
  }

यहां दिए गए उदाहरण में, FeedProvider क्लास में ParserError की समस्या के लिए, लिंट की जांच बंद करने का तरीका बताया गया है:

Kotlin

@SuppressLint("ParserError")
class FeedProvider : ContentProvider() {

Java

@SuppressLint("ParserError")
public class FeedProvider extends ContentProvider {

फ़ाइल में मौजूद सभी लिंट समस्याओं की जांच को रोकने के लिए, all कीवर्ड का इस्तेमाल करें:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

किसी भी Composable फ़ंक्शन पर लिंट की जांच को रोकने के लिए, उसी एनोटेशन का इस्तेमाल किया जा सकता है.

एक्सएमएल में लिंट की जांच करने की सुविधा कॉन्फ़िगर करना

अपनी एक्सएमएल फ़ाइलों के खास सेक्शन के लिए, लिंट की जांच बंद करने के लिए tools:ignore एट्रिब्यूट का इस्तेमाल करें. lint.xml फ़ाइल में नेमस्पेस की यह वैल्यू डालें, ताकि लिंट टूल इस एट्रिब्यूट को पहचान सके: 

namespace xmlns:tools="http://schemas.android.com/tools"

यहां दिए गए उदाहरण में, एक्सएमएल लेआउट फ़ाइल के <LinearLayout> एलिमेंट में UnusedResources समस्या के लिए, लिंट की जांच बंद करने का तरीका बताया गया है. ignore एट्रिब्यूट को उस पैरंट एलिमेंट के चाइल्ड एलिमेंट से इनहेरिट किया जाता है जहां एट्रिब्यूट का एलान किया गया है. इस उदाहरण में, चाइल्ड <TextView> एलिमेंट के लिए भी लिंट की जांच बंद है: 

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    tools:ignore="UnusedResources" >

    <TextView
        android:text="@string/auto_update_prompt" />
</LinearLayout>

एक से ज़्यादा समस्याओं को बंद करने के लिए, उन समस्याओं की सूची बनाएं जिन्हें बंद करना है. सूची में, समस्याओं को कॉमा लगाकर अलग करें. उदाहरण के लिए:

tools:ignore="NewApi,StringFormatInvalid"

एक्सएमएल एलिमेंट में मौजूद सभी लिंट समस्याओं की जांच को रोकने के लिए, all कीवर्ड का इस्तेमाल करें:

tools:ignore="all"

Gradle की मदद से, lint के विकल्पों को कॉन्फ़िगर करना

Android Gradle प्लग इन की मदद से, कुछ lint विकल्पों को कॉन्फ़िगर किया जा सकता है. जैसे, मॉड्यूल-लेवल की build.gradle फ़ाइल में lint{} ब्लॉक का इस्तेमाल करके, यह तय किया जा सकता है कि कौनसी जांच करनी है या किन पर ध्यान नहीं देना है.

यहां दिए गए कोड स्निपेट में, ऐसी कुछ प्रॉपर्टी दिखाई गई हैं जिन्हें कॉन्फ़िगर किया जा सकता है:

Kotlin

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable += "TypographyFractions" + "TypographyQuotes"
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable += "RtlHardcoded" + "RtlCompat" + "RtlEnabled"
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly += "NewApi" + "InlinedApi"
        // If set to true, turns off analysis progress reporting by lint.
        quiet = true
        // If set to true (default), stops the build if errors are found.
        abortOnError = false
        // If set to true, lint only reports errors.
        ignoreWarnings = true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies = true
    }
}
...

Groovy

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable 'TypographyFractions','TypographyQuotes'
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly 'NewApi', 'InlinedApi'
        // If set to true, turns off analysis progress reporting by lint.
        quiet true
        // If set to true (default), stops the build if errors are found.
        abortOnError false
        // If set to true, lint only reports errors.
        ignoreWarnings true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies true
    }
}
...

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

चेतावनियों का बेसलाइन बनाना

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

बेसलाइन स्नैपशॉट बनाने के लिए, अपने प्रोजेक्ट की build.gradle फ़ाइल में इस तरह बदलाव करें:

Kotlin

android {
    lint {
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        baseline file("lint-baseline.xml")
    }
}

पहली बार यह लाइन जोड़ने पर, आपका बेसलाइन तय करने के लिए lint-baseline.xml फ़ाइल बनाई जाती है. इसके बाद, टूल सिर्फ़ बेसलाइन तय करने के लिए फ़ाइल को पढ़ते हैं. अगर आपको नया बेसलाइन बनाना है, तो फ़ाइल को मैन्युअल तरीके से मिटाएं और उसे फिर से बनाने के लिए, लिंट को फिर से चलाएं.

इसके बाद, IDE में कोड > कोड की जांच करें को चुनकर या कमांड लाइन से, लिंट को इस तरह चलाएं. आउटपुट में lint-baseline.xml फ़ाइल की जगह की जानकारी प्रिंट होती है. आपके सेटअप के लिए, फ़ाइल की जगह यहां दिखाई गई जगह से अलग हो सकती है: 

$ ./gradlew lintDebug -Dlint.baselines.continue=true
...
Wrote XML report to file:///app/lint-baseline.xml
Created baseline file /app/lint-baseline.xml

lint को चलाने पर, lint-baseline.xml फ़ाइल में मौजूद सभी मौजूदा समस्याएं रिकॉर्ड हो जाती हैं. मौजूदा समस्याओं के सेट को बेसलाइन कहा जाता है. अगर आपको lint-baseline.xml फ़ाइल को दूसरों के साथ शेयर करना है, तो वर्शन कंट्रोल में जाकर देखें.

बेसलाइन को पसंद के मुताबिक बनाना

अगर आपको बेसलाइन में सिर्फ़ कुछ खास तरह की समस्याएं जोड़नी हैं, तो अपने प्रोजेक्ट की build.gradle फ़ाइल में बदलाव करके, जोड़ने के लिए समस्याओं की जानकारी दें. इसके लिए, यह तरीका अपनाएं:

Kotlin

android {
    lint {
        checkOnly += "NewApi" + "HandlerLeak"
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        checkOnly 'NewApi', 'HandlerLeak'
        baseline file("lint-baseline.xml")
    }
}

अगर बेसलाइन बनाने के बाद, कोडबेस में कोई नई चेतावनी जोड़ी जाती है, तो लिंट सिर्फ़ नए बग की सूची बनाता है.

बेसलाइन चेतावनी

बेसलाइन लागू होने पर, आपको जानकारी देने वाली चेतावनी मिलती है. इससे आपको पता चलता है कि एक या उससे ज़्यादा समस्याओं को फ़िल्टर कर दिया गया है, क्योंकि वे बेसलाइन में शामिल हैं. इस चेतावनी से आपको यह याद रखने में मदद मिलती है कि आपने एक बेसलाइन कॉन्फ़िगर किया है और आपको सभी समस्याओं को ठीक करना होगा.

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

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

जांच को मैन्युअल तरीके से चलाना

कॉन्फ़िगर किए गए लिंट और IDE की अन्य जांच को मैन्युअल तरीके से चलाने के लिए, कोड > कोड की जांच करें चुनें. जांच के नतीजे, जांच के नतीजे विंडो में दिखते हैं.

जांच का दायरा और प्रोफ़ाइल सेट करना

आपको जिन फ़ाइलों का विश्लेषण करना है (जांच का दायरा) और जिन जांचों को चलाना है (जांच की प्रोफ़ाइल) उन्हें इस तरह चुनें:

  1. Android व्यू में, अपना प्रोजेक्ट खोलें और वह प्रोजेक्ट, फ़ोल्डर या फ़ाइल चुनें जिसका विश्लेषण करना है.
  2. मेन्यू बार में जाकर, कोड > कोड की जांच करें को चुनें.

  3. जांच का दायरा तय करें डायलॉग में, सेटिंग की समीक्षा करें.

    जांच के दायरे की सेटिंग की समीक्षा करना
    तीसरी इमेज. जांच के दायरे की सेटिंग देखें.

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

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

    किस चीज़ की जांच करनी है, यह बदलने के लिए, कोई दूसरा रेडियो बटन चुनें. जांच के दायरे की जानकारी डायलॉग में मौजूद सभी संभावित फ़ील्ड के बारे में जानने के लिए, जांच के दायरे की जानकारी देने वाला डायलॉग देखें.

  4. जांच प्रोफ़ाइल में जाकर, वह प्रोफ़ाइल चुनें जिसका इस्तेमाल करना है.

  5. जांच करने के लिए, ठीक है पर क्लिक करें.

    चौथी इमेज में, कोड की जांच करें टूल के रन से मिले, lint और IDE की जांच के अन्य नतीजे दिखाए गए हैं:

    समस्या हल करने का तरीका देखने के लिए, कोई समस्या चुनें.
    चौथी इमेज. जांच के नतीजे. समस्या हल करने का तरीका देखने के लिए, कोई समस्या चुनें.

  6. जांच के नतीजे पैनल में, जांच के नतीजे देखें. इसके लिए, गड़बड़ी की कैटगरी, टाइप या समस्याओं को बड़ा करके चुनें.

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

  7. जांच के नतीजे पैनल के ट्री व्यू में, किसी कैटगरी, टाइप या समस्या पर राइट क्लिक करके, संदर्भ मेन्यू दिखाएं.

    संदर्भ के आधार पर, ये काम किए जा सकते हैं:

    • सोर्स पर जाएं.
    • चुने गए आइटम शामिल या बाहर करें.
    • समस्याओं को दबाना.
    • सेटिंग में बदलाव करें।
    • जांच से जुड़ी सूचनाएं मैनेज करना.
    • किसी जांच को फिर से चलाएं.

टूलबार बटन, संदर्भ मेन्यू आइटम, और जांच की रिपोर्ट के फ़ील्ड की जानकारी पाने के लिए, जांच के नतीजों की जानकारी देने वाली टूल विंडो देखें.

कस्टम स्कोप का इस्तेमाल करना

Android Studio में दिए गए कस्टम स्कोप में से किसी एक का इस्तेमाल करने के लिए, यह तरीका अपनाएं:

  1. जांच का दायरा तय करें डायलॉग में, कस्टम स्कोप चुनें.

  2. अपने विकल्प देखने के लिए, कस्टम स्कोप सूची पर क्लिक करें:

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

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

  3. ठीक है पर क्लिक करें.

कस्टम स्कोप बनाना

अगर आपको उन फ़ाइलों और डायरेक्ट्री की जांच करनी है जो उपलब्ध किसी भी कस्टम स्कोप में शामिल नहीं हैं, तो कस्टम स्कोप बनाया जा सकता है:

  1. जांच का दायरा तय करें डायलॉग में, कस्टम स्कोप चुनें.

  2. कस्टम स्कोप सूची के बाद मौजूद तीन बिंदुओं पर क्लिक करें.

    जांच के दायरे की जानकारी देने वाला डायलॉग
    छठी इमेज. 'इंस्पेक्शन का दायरा' डायलॉग बॉक्स में जानकारी दें.

    आपको दायरे वाला डायलॉग दिखेगा.

    कस्टम स्कोप बनाना
    सातवीं इमेज. कस्टम स्कोप बनाएं.
  3. नया स्कोप तय करने के लिए, डायलॉग बॉक्स के सबसे ऊपर बाईं ओर मौजूद बटन पर क्लिक करें.
  4. इसके बाद, दायरा जोड़ें सूची में जाकर, स्थानीय चुनें.

    कोड की जांच करें सुविधा के लिए, प्रोजेक्ट में लोकल और शेयर किए गए स्कोप, दोनों का इस्तेमाल किया जाता है. शेयर किया गया स्कोप, प्रोजेक्ट की उन अन्य सुविधाओं के साथ भी इस्तेमाल किया जा सकता है जिनमें स्कोप फ़ील्ड होता है. उदाहरण के लिए, इस्तेमाल के उदाहरण ढूंढें की सेटिंग बदलने के लिए, सेटिंग में बदलाव करें पर क्लिक करने पर, दिखने वाले डायलॉग में एक दायरा फ़ील्ड होता है. यहां शेयर किया गया दायरा चुना जा सकता है.

    &#39;इस्तेमाल का पता लगाएं&#39; डायलॉग से, शेयर किया गया स्कोप चुनें
    आठवीं इमेज. इस्तेमाल के उदाहरण ढूंढें डायलॉग बॉक्स से, शेयर किया गया दायरा चुनें.
  5. स्कोप को कोई नाम दें और ठीक है पर क्लिक करें.

    स्कोप डायलॉग बॉक्स के दाएं पैनल में, ऐसे विकल्प दिखते हैं जिनकी मदद से कस्टम स्कोप तय किया जा सकता है.

  6. सूची में से, प्रोजेक्ट चुनें.

    इसके बाद, आपको उपलब्ध प्रोजेक्ट की सूची दिखेगी.

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

  7. प्रोजेक्ट फ़ोल्डर को बड़ा करें और चुनें कि कस्टम स्कोप में क्या जोड़ना है. साथ ही, चुनें कि उसे शामिल करना है या बाहर रखना है.

    कस्टम स्कोप तय करना
    नौवीं इमेज. कस्टम स्कोप तय करें.
    • शामिल करें: इस फ़ोल्डर और उसकी फ़ाइलों को शामिल करें, लेकिन इसके किसी भी सब-फ़ोल्डर को शामिल न करें.
    • बार-बार शामिल करें: इस फ़ोल्डर और उसकी फ़ाइलों के साथ-साथ, उसके सब-फ़ोल्डर और उनकी फ़ाइलों को भी शामिल करें.
    • शामिल न करें: इस फ़ोल्डर और उसकी फ़ाइलों को शामिल न करें. हालांकि, इसके किसी भी सब-फ़ोल्डर को शामिल करें.
    • बार-बार शामिल न करें: इस फ़ोल्डर और उसकी फ़ाइलों के साथ-साथ, उसके सब-फ़ोल्डर और उनकी फ़ाइलों को शामिल न करें.

    फ़िगर 10 में दिखाया गया है कि main फ़ोल्डर शामिल है. साथ ही, java और res फ़ोल्डर को बार-बार शामिल किया गया है. नीले रंग से, कुछ हिस्से में शामिल किए गए फ़ोल्डर का पता चलता है. वहीं, हरे रंग से, बार-बार शामिल किए गए फ़ोल्डर और फ़ाइलों का पता चलता है.

    कस्टम स्कोप के लिए पैटर्न का उदाहरण
    10वीं इमेज. कस्टम स्कोप के लिए पैटर्न का उदाहरण.
    • java फ़ोल्डर को चुनने और बार-बार बाहर रखें पर क्लिक करने पर, java फ़ोल्डर और उसमें मौजूद सभी फ़ोल्डर और फ़ाइलों पर हरे रंग से हाइलाइट करने की सुविधा बंद हो जाती है.
    • अगर हरे रंग से हाइलाइट की गई MainActivity.kt फ़ाइल को चुना जाता है और फिर बाहर रखें पर क्लिक किया जाता है, तो MainActivity.kt अब हरे रंग से हाइलाइट नहीं होती. हालांकि, java फ़ोल्डर में मौजूद बाकी सभी फ़ाइलें हरे रंग से हाइलाइट रहती हैं.
  8. ठीक है पर क्लिक करें. कस्टम स्कोप, सूची में सबसे नीचे दिखता है.

जांच प्रोफ़ाइलों की समीक्षा करना और उनमें बदलाव करना

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

जांच की सेटिंग ऐक्सेस करने के लिए:

  1. फ़ाइल > सेटिंग चुनें. (Windows पर) या Android Studio > प्राथमिकताएं (macOS या Linux पर) पर जाएं.
  2. एडिटर > जांच चुनें.

  3. निरीक्षण पैनल में, काम करने वाले निरीक्षण और उनके बारे में जानकारी की सूची दिखती है.

    इस्तेमाल किए जा सकने वाले इंस्पेक्शन और उनकी जानकारी
    11वां डायग्राम. काम करने वाले इंस्पेक्शन और उनके ब्यौरे.

  4. डिफ़ॉल्ट (Android Studio) और प्रोजेक्ट डिफ़ॉल्ट (चालू प्रोजेक्ट) जांचों के बीच टॉगल करने के लिए, प्रोफ़ाइल सूची चुनें.

    ज़्यादा जानकारी के लिए, IntelliJ का प्रोफ़ाइलें मैनेज करें पेज देखें.

  5. बाईं ओर मौजूद पैनल में, जांच सूची में, प्रोफ़ाइल की किसी टॉप-लेवल कैटगरी को चुनें या किसी ग्रुप को बड़ा करके कोई खास प्रोफ़ाइल चुनें.

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

  6. जांचों को कॉपी करने, उनका नाम बदलने, जानकारी जोड़ने, एक्सपोर्ट करने, और इंपोर्ट करने के लिए, स्कीमा ऐक्शन दिखाएं स्कीमा ऐक्शन आइकॉन दिखाना सूची चुनें.
  7. इसके बाद, ठीक है पर क्लिक करें.