Ulepszanie kodu za pomocą sprawdzania lintków

Oprócz przeprowadzenia testów kompilacji mających na celu sprawdzenie, czy aplikacja spełnia wymagania funkcjonalne, należy także uruchomić kod za pomocą narzędzia Lint, aby upewnić się, że nie zawiera on żadnych problemów strukturalnych. Narzędzie Lint pomaga znaleźć słabo uporządkowany kod, który może negatywnie wpływać na niezawodność i wydajność aplikacji na Androida oraz utrudniać zarządzanie kodem. Przed opublikowaniem aplikacji zdecydowanie zalecamy poprawienie wszystkich błędów wykrytych przez lint.

Jeśli na przykład pliki zasobów XML zawierają nieużywane przestrzenie nazw, zajmują one miejsce i wymagają niepotrzebnego przetwarzania. Inne problemy strukturalne, takie jak użycie wycofanych elementów lub wywołania interfejsu API, które nie są obsługiwane przez docelowe wersje interfejsu API, mogą powodować nieprawidłowe działanie kodu. Lint pomoże Ci rozwiązać te problemy.

Aby poprawić skuteczność lintowania, możesz też dodać adnotacje do kodu.

Omówienie

Android Studio udostępnia narzędzie do skanowania kodu o nazwie lint, które pomaga identyfikować i rozwiązywać problemy z jakością strukturalną kodu bez konieczności uruchamiania aplikacji czy pisania elementów testowych. Każdy problem wykryty przez narzędzie jest raportowany razem z opisem i o poziomie ważności, dzięki czemu można skupić się na najważniejszych ulepszeniach, które należy wprowadzić. Możesz też zmniejszyć wagę problemu, aby zignorować problemy, które nie mają związku z Twoim projektem, lub zwiększyć wagę, aby wyróżnić konkretne problemy.

Narzędzie Lint sprawdza pliki źródłowe projektu na Androida pod kątem potencjalnych błędów i ulepszenia optymalizacji pod kątem poprawności, bezpieczeństwa, wydajności, łatwości obsługi, ułatwień dostępu i internacjonalizacji. Jeśli korzystasz z Android Studio, skonfigurowane kontrole lint i IDE są przeprowadzane podczas tworzenia aplikacji. Możesz jednak przeprowadzić inspekcje ręcznie lub uruchomić lint z poziomu wiersza poleceń zgodnie z opisem na tej stronie.

Wbudowane narzędzie Lint sprawdza kod podczas korzystania z Android Studio. Ostrzeżenia i błędy możesz wyświetlić na 2 sposoby:

  • Jako tekst w wyskakującym okienku w oknie edytora. Gdy lint znajdzie problem, podświetla go na żółto. W poważniejszych przypadkach kod jest podkreślany na czerwono.
  • Kliknij Kod > Zbadaj kod w oknie Inspection Results (Wyniki inspekcji) w oknie lintowania.

Uwaga: po skompilowaniu kodu w Android Studio przeprowadzane są dodatkowe inspekcje kodu IntelliJ, aby usprawnić jego weryfikację.

Rysunek 1 pokazuje, jak narzędzie Lint przetwarza pliki źródłowe aplikacji.

Proces skanowania kodu za pomocą narzędzia Lint.
Rysunek 1. Procedura skanowania kodu za pomocą narzędzia Lint.
Pliki źródłowe aplikacji
Pliki źródłowe składają się z plików tworzących projekt na Androida, w tym plików, ikon oraz plików konfiguracji ProGuard i plików Kotlin, Java i XML.
Plik lint.xml
Plik konfiguracji umożliwiający określenie wszelkich lintowania, które chcesz wykluczyć, oraz dostosowanie poziomów ważności problemów.
Narzędzie Linter
Narzędzie do skanowania statycznego kodu, które możesz uruchomić w projekcie Androida z poziomu wiersza poleceń lub w Android Studio. Narzędzie Lint uwzględnia problemy z kodem strukturalnym, które mogą mieć wpływ na jakość i wydajność aplikacji na Androida.
Wyniki sprawdzania lintowania
Wyniki narzędzia Lint możesz wyświetlić w konsoli lub w oknie Wyniki inspekcji w Android Studio. Jeśli uruchomisz lint z poziomu wiersza poleceń, wyniki zostaną zapisane w folderze build/. Więcej informacji znajdziesz w sekcji o ręcznym przeprowadzaniu inspekcji.

Uruchamianie lint z wiersza poleceń

Jeśli używasz Android Studio lub Gradle, użyj opakowań Gradle, aby wywołać w projekcie zadanie lint. W tym celu wpisz jedno z tych poleceń z katalogu głównego projektu:

  • W systemie Windows:
    gradlew lint
    
  • W systemie Linux lub macOS:
    ./gradlew lint
    

Zostaną wyświetlone dane wyjściowe podobne do tych:

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

Po zakończeniu sprawdzania narzędzie lint udostępnia ścieżki do wersji XML i HTML raportu lint. Możesz wtedy przejść do raportu HTML i otworzyć go w przeglądarce, jak widać na rysunku 2.

Przykładowy raport HTML lint
Rysunek 2. Przykładowy raport HTML lint.

Jeśli Twój projekt obejmuje warianty kompilacji, Lint sprawdza tylko wariant domyślny. Jeśli chcesz uruchomić lint na innym wariancie, musisz zapisać nazwę wariantu wielką literą i poprzedzić ją prefiksem lint.

./gradlew lintRelease

Aby dowiedzieć się więcej o uruchamianiu zadań Gradle z poziomu wiersza poleceń, przeczytaj artykuł Tworzenie aplikacji z poziomu wiersza poleceń.

Uruchom Lint za pomocą oddzielnego narzędzia

Jeśli nie używasz Android Studio ani Gradle, zainstaluj narzędzia wiersza poleceń Android Studio, aby użyć samodzielnego narzędzia Lint. Znajdź narzędzie Lint na stronie android_sdk/cmdline-tools/version/bin/lint.

Uwaga: jeśli spróbujesz uruchomić samodzielne narzędzie w projekcie Gradle, wyświetli się błąd. Do uruchamiania linta w projekcie Gradle należy zawsze używać narzędzia gradle lint (w systemie Windows) lub ./gradlew lint (w systemie macOS lub Linux).

Aby uruchomić lint na liście plików w katalogu projektu, użyj tego polecenia:

lint [flags] <project directory>

Możesz na przykład uruchomić podane niżej polecenie, aby przeskanować pliki znajdujące się w katalogu myproject i jego podkatalogach. Identyfikator problemu MissingPrefix umożliwia narzędziu lint skanowanie tylko w poszukiwaniu atrybutów XML, w których brakuje prefiksu przestrzeni nazw Androida.

lint --check MissingPrefix myproject 

Aby wyświetlić pełną listę flag i argumentów wiersza poleceń obsługiwanych przez narzędzie, użyj tego polecenia:

lint --help

Poniższy przykład pokazuje dane wyjściowe konsoli po uruchomieniu polecenia lint w odniesieniu do projektu o nazwie Earthquake:

$ 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

W przykładowych danych wyjściowych zobaczysz 4 ostrzeżenia i brak błędów.

2 ostrzeżenia odnoszą się do pliku AndroidManifest.xml projektu:

  • ManifestOrder
  • UsesMinSdkAttributes
Jedno ostrzeżenie dotyczy pliku układu Preferences.xml: UnusedResources.

Jedno ostrzeżenie dotyczy katalogu res: IconMissingDensityFolder.

Konfigurowanie lint do pomijania ostrzeżeń

Domyślnie po uruchomieniu skanowania narzędzie sprawdza, czy nie występują w nim wszystkie problemy. Możesz też ograniczyć problemy do sprawdzania przez lint, a także przypisywać do nich poziomy ważności. Możesz na przykład wyłączyć sprawdzanie lintowania w przypadku konkretnych problemów, które nie mają związku z Twoim projektem, i skonfigurować lint do zgłaszania problemów niekrytycznych na niższym poziomie.

Poziomy ważności:

  • enable
  • disable lub ignore
  • informational
  • warning
  • error
  • fatal

Sprawdzanie lintowania można skonfigurować na różnych poziomach:

  • Globalnie (cały projekt)
  • Moduł projektu
  • Moduł produkcyjny
  • Przetestuj moduł
  • Otwórz pliki
  • Hierarchia klas
  • Zakresy systemu kontroli wersji (VCS)

Konfigurowanie pliku lint

Preferencje dotyczące sprawdzania lint możesz określić w pliku lint.xml. Jeśli tworzysz ten plik ręcznie, umieść go w katalogu głównym projektu na Androida.

Plik lint.xml składa się z otaczającego go tagu nadrzędnego <lint>, który zawiera co najmniej 1 element podrzędny <issue>. Lint definiuje unikalną wartość atrybutu id dla każdego elementu <issue>:

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

Aby zmienić poziom ważności problemu lub wyłączyć sprawdzanie lintowania problemu, ustaw atrybut ważności w tagu <issue>.

Wskazówka: aby zobaczyć pełną listę problemów obsługiwanych przez lint, wraz z odpowiednimi identyfikatorami problemów, uruchom polecenie lint --list.

Przykładowy plik lint.xml

Ten przykład pokazuje zawartość pliku 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>

Ten przykład pokazuje, jak są zgłaszane różne typy problemów. Sprawdzanie IconMissingDensityFolder jest całkowicie wyłączone, a kontrola ObsoleteLayoutParam jest wyłączona tylko w plikach określonych w załączonych deklaracji <ignore ... />.

Skonfiguruj sprawdzanie lint dla plików źródłowych Kotlin, Java i XML

Możesz wyłączyć sprawdzanie lintowania plików źródłowych Kotlin, Java i XML w oknie Preferencje:

  1. Wybierz Plik > Ustawienia (w Windows) lub Android Studio > Ustawienia (w systemach macOS i Linux).
  2. Kliknij Edytor > Kontrole.
  3. Aby wyłączyć tę funkcję, odznacz odpowiedni plik źródłowy.

Możesz je ustawić dla IDE lub dla poszczególnych projektów, wybierając odpowiedni profil.

Skonfiguruj sprawdzanie lint w Javie lub Kotlinie

Aby wyłączyć sprawdzanie lintowania w przypadku klasy lub metody w projekcie Androida, dodaj do tego kodu adnotację @SuppressLint.

Poniższy przykład pokazuje, jak w metodzie onCreate wyłączyć sprawdzanie lintowania w przypadku problemu NewApi. Narzędzie Lint nadal szuka problemu z NewApi w innych metodach tej klasy.

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);

To samo można zrobić na każdym elemencie kompozycyjnym. Ten fragment kodu pokazuje, jak wyłączyć sprawdzanie NewApi w dowolnym elemencie kompozycyjnym.

Kotlin

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

Poniższy przykład pokazuje, jak wyłączyć sprawdzanie lintowania w przypadku problemu ParserError w klasie FeedProvider:

Kotlin

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

Java

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

Aby pominąć sprawdzanie wszystkich błędów w pliku, użyj słowa kluczowego all:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

Tej samej adnotacji możesz używać do pomijania kontroli lintowania w dowolnej funkcji kompozycyjnej.

Skonfiguruj sprawdzanie lint w pliku XML

Aby wyłączyć sprawdzanie lint w określonych sekcjach plików XML, użyj atrybutu tools:ignore. Umieść tę wartość przestrzeni nazw w pliku lint.xml, aby narzędzie lint rozpoznało atrybut:

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

Przykład poniżej pokazuje, jak wyłączyć sprawdzanie lintowania w przypadku problemu UnusedResources w elemencie <LinearLayout> pliku układu XML. Atrybut ignore jest dziedziczony przez elementy podrzędne elementu nadrzędnego, w którym zadeklarowano atrybut. W tym przykładzie kontrola lintowania jest również wyłączona dla elementu podrzędnego <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>

Aby wyłączyć więcej niż 1 problem, podaj listę rozdzielonych przecinkami problemy, które chcesz wyłączyć. Przykład:

tools:ignore="NewApi,StringFormatInvalid"

Aby pominąć sprawdzanie pod kątem wszystkich problemów z lintem w elemencie XML, użyj słowa kluczowego all:

tools:ignore="all"

Konfigurowanie opcji lintowania przy użyciu Gradle

Wtyczka na Androida do Gradle pozwala skonfigurować określone opcje lintowania, na przykład to, które testy mają być uruchamiane, a które ignorowane, przy użyciu bloku lint{} w pliku build.gradle na poziomie modułu.

Poniższy fragment kodu zawiera niektóre z właściwości, które możesz skonfigurować:

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
    }
}
...

Odlotowe

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
    }
}
...

Wszystkie metody lintowania, które zastępują dany poziom ważności problemu, przestrzegają kolejności konfiguracji. Na przykład ustawienie problemu jako krytycznego w finalizeDsl() zastępuje jego wyłączenie w głównej DSL.

Utwórz punkt odniesienia dla ostrzeżeń

Możesz zrobić zrzut bieżącego zestawu ostrzeżeń w projekcie, a potem użyć go jako punktu odniesienia przy przyszłych inspekcjach, aby zgłaszane były tylko nowe problemy. Zrzut bazowy pozwala zacząć używać lint do niepowodzenia kompilacji bez konieczności cofania się i rozwiązywania wszystkich dotychczasowych problemów.

Aby utworzyć zrzut podstawowy, zmodyfikuj plik build.gradle projektu w ten sposób:

Kotlin

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

Odlotowe

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

Gdy po raz pierwszy dodasz ten wiersz, tworzony jest plik lint-baseline.xml, aby określić punkt odniesienia. Od tej pory narzędzia odczytują plik tylko w celu określenia punktu odniesienia. Jeśli chcesz utworzyć nowy element bazowy, ręcznie usuń plik i uruchom lint ponownie, aby go odtworzyć.

Następnie uruchom lint w IDE, wybierając Kod > Sprawdź kod lub w wierszu poleceń w podany niżej sposób. W danych wyjściowych zostanie podana lokalizacja pliku lint-baseline.xml. Lokalizacja pliku konfiguracji może się różnić od tej widocznej tutaj:

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

Uruchomienie polecenia lint spowoduje zarejestrowanie wszystkich bieżących problemów w pliku lint-baseline.xml. Zbiór bieżących problemów jest nazywany punktem odniesienia. Plik lint-baseline.xml możesz sprawdzić w kontroli wersji, jeśli chcesz udostępnić go innym.

Dostosuj element bazowy

Jeśli do punktu odniesienia chcesz dodać tylko niektóre typy problemów, określ problemy do dodania, edytując plik build.gradle projektu w ten sposób:

Kotlin

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

Odlotowe

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

Jeśli po utworzeniu punktu odniesienia dodasz do bazy kodu nowe ostrzeżenia, lint będzie wyświetlać tylko te nowo wprowadzone błędy.

Ostrzeżenie dotyczące punktu odniesienia

Gdy będzie stosowana wartość bazowa, pojawi się ostrzeżenie informujące, że co najmniej 1 problem został odfiltrowany, ponieważ jest wymieniony w nim. To ostrzeżenie pomaga zapamiętać, że masz skonfigurowaną wartość podstawową i że w pewnym momencie trzeba rozwiązać wszystkie problemy.

To ostrzeżenie zawiera też informacje o problemach, które nie są już zgłaszane. Dzięki tym informacjom dowiesz się, czy problemy zostały naprawione. Dzięki temu możesz opcjonalnie odtworzyć punkt odniesienia, aby uniknąć niewykrycia błędu.

Uwaga: podczas przeprowadzania inspekcji w trybie wsadowym w IDE podstawy są włączone, ale są ignorowane w przypadku kontroli w edytorze, które są przeprowadzane w tle, gdy edytujesz plik. Wynika to z faktu, że wartości podstawowe powinny być stosowane w sytuacjach, gdy baza kodu zawiera dużą liczbę ostrzeżeń, ale problemy trzeba rozwiązywać lokalnie po dotknięciu kodu.

Ręczne przeprowadzanie inspekcji

Aby ręcznie uruchomić skonfigurowany lint i inne kontrole IDE, wybierz Kod > Zbadaj kod. Wyniki inspekcji pojawią się w oknie Wyniki inspekcji.

Ustaw zakres i profil inspekcji

Wybierz pliki do analizy (zakres kontroli) i kontrole, które chcesz przeprowadzić (profil inspekcji) w ten sposób:

  1. W widoku Androida otwórz projekt i wybierz projekt, folder lub plik do analizy.
  2. Na pasku menu wybierz Kod > Zbadaj kod.
  3. W oknie Określ zakres inspekcji sprawdź ustawienia.

    Określ zakres inspekcji
    Rysunek 3. Sprawdź ustawienia zakresu inspekcji.

    Opcje wyświetlane w oknie Określ zakres inspekcji zależą od tego, czy został wybrany projekt, folder czy plik:

    • Gdy wybierzesz 1 projekt, plik lub katalog, w oknie Określ zakres inspekcji pojawi się ścieżka do wybranego projektu, pliku lub katalogu.
    • Jeśli wybierzesz więcej niż 1 projekt, plik lub katalog, w oknie Określ zakres inspekcji pojawi się przycisk Wybrane pliki.

    Aby zmienić elementy do sprawdzenia, wybierz jeden z pozostałych przycisków. Opis wszystkich możliwych pól w oknie Określ zakres inspekcji znajdziesz w sekcji Określ zakres inspekcji.

  4. W sekcji Profil inspekcji wybierz profil, którego chcesz użyć.
  5. Aby przeprowadzić kontrolę, kliknij OK.

    Rysunek 4 przedstawia wyniki testu lint i innych IDE z uruchomienia Zbadaj kod:

    Wybierz problem, aby zobaczyć jego rozwiązanie.
    Rysunek 4. Wyniki inspekcji. Wybierz problem, aby zobaczyć jego rozwiązanie.
  6. W panelu Wyniki inspekcji wyświetl wyniki inspekcji, rozwijając i wybierając kategorie błędów, typy lub problemy.

    W panelu Raport inspekcji wyświetla się raport z inspekcji dotyczący kategorii, typu lub problemu wybranego w panelu Wyniki kontroli oraz nazwa i lokalizacja błędu. W razie potrzeby raport z kontroli zawiera inne informacje, np. podsumowanie problemu, które mogą pomóc w jego rozwiązaniu.

  7. W widoku drzewa Wyniki inspekcji kliknij prawym przyciskiem kategorię, typ lub problem, aby wyświetlić menu kontekstowe.

    W zależności od kontekstu możesz:

    • Przejdź do źródła.
    • Wyklucz i uwzględnij wybrane elementy.
    • Unikaj problemów.
    • Zmień ustawienia.
    • Zarządzaj alertami dotyczącymi inspekcji.
    • Ponownie uruchom inspekcję.

Opisy przycisków paska narzędzi, elementów menu kontekstowego i pól raportu inspekcji znajdziesz w oknie narzędzia do sprawdzania wyników inspekcji.

Używanie zakresu niestandardowego

Użyj jednego z zakresów niestandardowych dostępnych w Android Studio w ten sposób:

  1. W oknie Określ zakres inspekcji wybierz Zakres niestandardowy.
  2. Kliknij listę Zakres niestandardowy, aby wyświetlić opcje:

    Wybierz zakres inspekcji
    Rysunek 5. Wybierz zakres niestandardowy, którego chcesz używać.
    • Wszystkie miejsca:wszystkie pliki.
    • Pliki projektu: wszystkie pliki w bieżącym projekcie.
    • Pliki źródłowe projektu: tylko pliki źródłowe w bieżącym projekcie.
    • Pliki produkcyjne projektu: tylko pliki produkcyjne w bieżącym projekcie.
    • Pliki testowe projektu: tylko pliki testowe w bieżącym projekcie.
    • Zarysowania i konsole: tylko pliki referencyjne i konsole otwarte w bieżącym projekcie.
    • Ostatnio wyświetlane pliki: tylko ostatnio wyświetlane pliki w bieżącym projekcie.
    • Bieżący plik:zawiera tylko bieżący plik w bieżącym projekcie. Pojawia się po zaznaczeniu pliku lub folderu.
    • Wybrany katalog: tylko bieżący folder w bieżącym projekcie. Pojawia się po wybraniu folderu.
    • Hierarchia klas: gdy wybierzesz tę opcję i klikniesz OK, pojawi się okno ze wszystkimi klasami w bieżącym projekcie. W oknie użyj pola Szukaj według nazwy, aby przefiltrować i wybrać klasy do sprawdzenia. Jeśli nie filtrujesz listy klas, inspekcja kodu sprawdza wszystkie klasy.

    Jeśli w projekcie masz skonfigurowany kod VCS, możesz też ograniczyć wyszukiwanie tylko do plików, które zostały zmodyfikowane.

  3. Kliknij OK.

Tworzenie zakresu niestandardowego

Jeśli chcesz zbadać wybrane pliki i katalogi, których nie obejmuje żaden z dostępnych obecnie zakresów niestandardowych, możesz utworzyć zakres niestandardowy:

  1. W oknie Określ zakres inspekcji wybierz Zakres niestandardowy.
  2. Kliknij 3 kropki za listą Zakres niestandardowy.

    Okno określania zakresu inspekcji
    Rysunek 6. Okno Określ zakres inspekcji.

    Pojawi się okno Zakresy.

    Tworzenie zakresu niestandardowego
    Rysunek 7. Utwórz zakres niestandardowy.
  3. Aby zdefiniować nowy zakres, kliknij przycisk w lewym górnym rogu okna.
  4. Na wyświetlonej liście Dodaj zakres wybierz Lokalny.

    Na potrzeby funkcji Zbadaj kod w projekcie używane są zarówno zakresy lokalne, jak i zakresy udostępnione. Zakresu współdzielonego można też używać z innymi funkcjami projektu, które mają pole zakresu. Gdy na przykład klikniesz Edytuj ustawienia , aby zmienić ustawienia opcji Znajdź wykorzystanie, w wyświetlonym oknie pojawi się pole Zakres, w którym możesz wybrać wspólny zakres.

    Wybierz zakres udostępniony w oknie Znajdź zastosowania
    Rysunek 8. Wybierz zakres udostępniony w oknie Znajdź wykorzystanie.
  5. Nadaj zakresowi nazwę i kliknij OK.

    W panelu po prawej stronie okna Zakresy znajdują się opcje, które umożliwiają definiowanie zakresu niestandardowego.

  6. Z listy wybierz Projekt.

    Pojawi się lista dostępnych projektów.

    Uwaga: zakres niestandardowy możesz utworzyć dla projektów lub pakietów. Kroki są takie same.

  7. Rozwiń foldery projektu, wybierz, co chcesz dodać do zakresu niestandardowego, i zdecyduj, czy chcesz go uwzględnić, czy wykluczyć.

    Zdefiniuj zakres niestandardowy
    Rysunek 9. Zdefiniuj zakres niestandardowy.
    • Uwzględnij: uwzględnij ten folder i jego pliki, ale nie dodawaj żadnych jego podfolderów.
    • Uwzględnij rekursywnie: uwzględnij ten folder i jego pliki oraz jego podfoldery i ich pliki.
    • Wyklucz: wyklucz ten folder i jego pliki, ale nie wykluczaj jego podfolderów.
    • Wyklucz rekursywnie: wyklucz ten folder i jego pliki oraz jego podfoldery i ich pliki.

    Rysunek 10 pokazuje, że folder main jest dołączany oraz że foldery java i res są dołączane cyklicznie. Niebieski oznacza folder, który został częściowo uwzględniony, a zielony – foldery i pliki uwzględnione cyklicznie.

    Przykładowy wzorzec zakresu niestandardowego
    Rysunek 10. Przykładowy wzorzec zakresu niestandardowego.
    • Jeśli wybierzesz folder java i klikniesz Wyklucz rekursywnie, folder java oraz wszystkie znajdujące się w nim foldery i pliki przestaną być zielone.
    • Jeśli wybierzesz wyróżniony na zielono plik MainActivity.kt i klikniesz Wyklucz, element MainActivity.kt nie będzie podświetlony na zielono, ale cała zawartość folderu java pozostanie zielona.
  8. Kliknij OK. Zakres niestandardowy pojawi się u dołu listy.

Sprawdzanie i edytowanie profili inspekcji

Android Studio udostępnia różne profile lint i inne, które są aktualizowane w ramach aktualizacji Androida. Możesz korzystać z tych profili bez zmian lub edytować ich nazwy, opisy, wagi i zakresy. Możesz też aktywować i dezaktywować całe grupy profili lub poszczególne profile w grupie.

Aby uzyskać dostęp do ustawień Inspekcje:

  1. Wybierz Plik > Ustawienia. (w systemie Windows) lub Android Studio > Ustawienia (w systemach macOS i Linux).
  2. Kliknij Edytor > Kontrole.
  3. W panelu Kontrole wyświetlana jest lista obsługiwanych inspekcji oraz ich opisy.

    Obsługiwane kontrole i ich opisy
    Rysunek 11. Obsługiwane kontrole i ich opisy.
  4. Wybierz listę Profil, aby przełączać się między inspekcjami Default (Android Studio) i Project Default (aktywny projekt).

    Więcej informacji znajdziesz na stronie IntelliJ Zarządzanie profilami.

  5. Na liście Inspekcje w panelu po lewej stronie wybierz kategorię profilu najwyższego poziomu lub rozwiń grupę i wybierz konkretny profil.

    Po wybraniu kategorii profilu możesz edytować wszystkie kontrole w tej kategorii w ramach jednej inspekcji.

  6. Wybierz listę Pokaż działania schematu Pokaż ikonę działań schematu, aby skopiować, wyeksportować i zaimportować inspekcje, dodać do nich opisy oraz zmienić ich nazwy.
  7. Gdy skończysz, kliknij OK.