Ta strona została przetłumaczona przez Cloud Translation API.

Ulepszanie kodu za pomocą sprawdzania lintków

Oprócz testowania kompilacji, aby sprawdzić, czy aplikacja spełnia wymagania funkcjonalne, warto też przepuścić kod przez narzędzie lint, aby upewnić się, że nie ma w nim problemów strukturalnych. Narzędzie lint pomaga znaleźć źle sformatowany kod, który może wpływać na niezawodność i wydajność aplikacji na Androida oraz utrudniać utrzymanie kodu. 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żywanie przestarzałych elementów lub wywołań interfejsu API, które nie są obsługiwane przez docelowe wersje interfejsu API, mogą powodować nieprawidłowe działanie kodu. Lint może pomóc Ci w usunięciu tych problemów.

Aby poprawić wydajność lintingu, możesz też dodać adnotacje do kodu.

Omówienie

Android Studio udostępnia narzędzie do skanowania kodu o nazwie lint, które może pomóc w identyfikowaniu i poprawianiu problemów z jakością struktury kodu bez konieczności uruchamiania aplikacji lub pisania przypadków testowych. Każdy problem wykryty przez narzędzie jest raportowany wraz z opisem i poziomem ważności, aby umożliwić Ci ustawienie priorytetów w przypadku kluczowych ulepszeń, 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 usprawnień optymalizacji pod kątem poprawności, bezpieczeństwa, wydajności, łatwości obsługi, ułatwień dostępu i internacjonalizacji. Podczas kompilowania aplikacji w Android Studio przeprowadzane są inspekcje skonfigurowanego narzędzia lint i IDE. Możesz jednak uruchamiać inspekcje ręcznie lub uruchamiać lint z poziomu wiersza poleceń, jak opisano 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 wyskakujący w oknie edytora. Gdy ltr znajdzie problem, podświetla problematyczny kod na żółto. W poważniejszych przypadkach kod jest podkreślany na czerwono.
W oknie Wyniki kontroli kliknij Kod > Sprawdź kod.

Uwaga: gdy kod jest kompilowany w Android Studio, dodatkowe sprawdzanie kodu w IntelliJ jest wykonywane w celu usprawnienia sprawdzania kodu. Upewnij się, że Android Studio jest jak najbardziej aktualne, aby mieć dostęp do najnowszych reguł i sprawdzeń lint.

Rysunek 1 przedstawia sposób przetwarzania plików źródłowych aplikacji przez narzędzie lint.

Przepływ pracy polegający na skanowaniu kodu za pomocą narzędzia lint. — **Rysunek 1.** Przepływ pracy dotyczący 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, za pomocą którego możesz określić, jakie kontrole lint chcesz wykluczyć, oraz dostosować poziomy ważności problemów.
Narzędzie Linter: Narzędzie do skanowania kodu stałego, które możesz uruchomić w projekcie Androida z wiersza poleceń lub w Android Studio. Narzędzie lint sprawdza kod pod kątem problemów strukturalnych, które mogą wpływać na jakość i wydajność aplikacji na Androida.
Wyniki sprawdzania kodu: Wyniki 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 Ręczne uruchamianie inspekcji.

Uruchamianie lint z wiersza poleceń

Jeśli używasz Android Studio lub Gradle, uruchom zadanie lint w projekcie, wpisując w katalogu głównym projektu jedno z tych poleceń:

Uwaga: aby korzystać z najnowszych reguł lint, utrzymuj wtyczkę Androida do obsługi Gradle w jak najbardziej aktualnej wersji.

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

Powinny się wyświetlić 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 raportu lint w formacie XML i HTML. Następnie możesz przejść do raportu HTML i otworzyć go w przeglądarce, jak pokazano na rysunku 2.

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

Jeśli Twój projekt zawiera warianty kompilacji, lint sprawdza tylko wariant domyślny. Jeśli chcesz uruchomić lint na innym wariancie, musisz użyć wielkiej litery w nazwie wariantu i dodać do niej prefiks lint.

./gradlew lintRelease

Uwaga: Lint nie jest uruchamiany automatycznie w ramach kompilacji. Zdecydowanie zalecamy jawne uruchamianie lint w ramach kompilacji w trybie ciągłej integracji, aby podczas tworzenia istniejącego kodu źródłowego były wyświetlane najnowsze kontrole linta.

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ń pakietu Android SDK, aby korzystać z samodzielnego narzędzia lint. Znajdź narzędzie do sprawdzania kodu źródłowego 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. Aby uruchomić lint w projekcie Gradle, zawsze używaj gradle lint (w Windows) lub ./gradlew lint (w macOS lub Linux).

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

lint [flags] <project directory>

Aby przeskanować pliki w katalogu myproject i jego podkatalogach, możesz na przykład wydać to polecenie: Identyfikator problemu MissingPrefixmówi, że lint ma skanować tylko atrybuty XML, w których brakuje prefiksu przestrzeni nazw Androida.

lint --check MissingPrefix myproject

Aby wyświetlić pełną listę obsługiwanych przez narzędzie flag i argumentów wiersza poleceń, uruchom to polecenie:

lint --help

Ten przykład pokazuje dane wyjściowe konsoli po uruchomieniu polecenia lint w przypadku 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 dotyczące pliku AndroidManifest.xml projektu:

ManifestOrder
UsesMinSdkAttributes

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, które ma sprawdzać lint, oraz przypisać problemom poziomy ważności. Możesz na przykład powstrzymać sprawdzanie lintu 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

Możesz skonfigurować sprawdzanie błędów na różnych poziomach:

Globalnie (cały projekt)
Moduł projektu
Moduł produkcji
Moduł testowy
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 określa 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 wyświetlić pełną listę problemów obsługiwanych przez lint i odpowiadające im identyfikatory 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 sprawdzanie ObsoleteLayoutParam jest wyłączone tylko w plikach określonych w załączonych deklaracjach <ignore ... />.

Konfigurowanie sprawdzania lint w przypadku plików źródłowych Kotlina, Javy i XML

W oknie Ustawienia możesz wyłączyć sprawdzanie lint w przypadku plików źródłowych Kotlin, Java i XML:

Wybierz Plik > Ustawienia (w Windows) lub Android Studio > Preferencje (w macOS lub Linuxie).
Kliknij Edytor > Inspekcje.
Aby wyłączyć tę opcję, odznacz odpowiedni plik źródłowy.

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

Konfigurowanie sprawdzania błędów lint w języku Java lub Kotlin

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 przypadku dowolnej składowej.

Kotlin

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

Z tego przykładu dowiesz się, jak wyłączyć sprawdzanie lint 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")

Możesz użyć tej samej adnotacji, aby pominąć kontrole lint w przypadku dowolnej funkcji kompozytowanej.

Konfigurowanie sprawdzania błędów w kodzie XML

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

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

Z przykładu poniżej dowiesz się, jak wyłączyć sprawdzanie lint dla problemu UnusedResources w elemencie <LinearLayout> w pliku XML z poziomu układu. Atrybut ignore jest dziedziczony przez elementy podrzędne elementu nadrzędnego, w którym zadeklarowano atrybut. W tym przykładzie sprawdzanie błędów jest też wyłączone w przypadku 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ę problemów do wyłączenia w ciągu rozdzielanym przecinkami. Przykład:

tools:ignore="NewApi,StringFormatInvalid"

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

tools:ignore="all"

Konfigurowanie opcji lint za pomocą Gradle

Wtyczka Androida do obsługi Gradle umożliwia konfigurowanie niektórych opcji lint, na przykład sprawdzania do wykonania lub zignorowania, za pomocą bloku lint{} w pliku build.gradle na poziomie modułu.

Ten fragment kodu pokazuje niektóre 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
    }
}
...

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

Wszystkie metody lint, które zastępują dany poziom wagi problemu, przestrzegają kolejności konfiguracji. Na przykład ustawienie problemu jako krytycznego w finalizeDsl() zastępuje wyłączenie w głównym pliku DSL.

Tworzenie wartości odniesienia dla ostrzeżeń

Możesz wykonać zrzut ekranu bieżącego zestawu ostrzeżeń w projekcie, a następnie użyć go jako punktu odniesienia do przyszłych inspekcji, aby zgłaszane były tylko nowe problemy. Zrzut bazowy umożliwia użycie lint do anulowania kompilacji bez konieczności wracania 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")
    }
}

Groovy

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

Gdy po raz pierwszy dodajesz ten wiersz, tworzony jest plik lint-baseline.xml, który służy do określenia wartości wyjściowej. Od tego momentu narzędzia tylko odczytują plik, aby określić wartość bazową. Jeśli chcesz utworzyć nowy punkt odniesienia, ręcznie usuń plik i ponownie uruchom lint, aby go utworzyć.

Następnie uruchom lint w IDE, wybierając Kod > Sprawdź kod lub z poziomu wiersza poleceń w ten sposób: W danych wyjściowych zostanie podana lokalizacja pliku lint-baseline.xml. Lokalizacja pliku w przypadku Twojej konfiguracji może być inna niż ta widoczna tutaj:

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

Uruchomienie lint powoduje zapisanie wszystkich bieżących problemów w pliku lint-baseline.xml. Zbiór bieżących problemów jest nazywany punktem odniesienia. Jeśli chcesz udostępnić plik lint-baseline.xml innym osobom, możesz go dodać do kontroli wersji.

Dostosowywanie wartości wyjściowej

Jeśli chcesz dodać do bazy tylko określone typy problemów, określ, które problemy mają zostać dodane, edytując plik build.gradle projektu w ten sposób:

Kotlin

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

Groovy

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

Jeśli po utworzeniu bazy porównawczej dodasz do bazy kodu nowe ostrzeżenia, lint wyświetli tylko nowe błędy.

Ostrzeżenie dotyczące punktu odniesienia

Gdy obowiązuje wartość referencyjna, otrzymasz ostrzeżenie informacyjne, że co najmniej 1 problem został odfiltrowany, ponieważ jest wymieniony w wartości referencyjnej. To ostrzeżenie przypomina, że masz skonfigurowaną wartość bazową i że w pewnym momencie musisz rozwiązać wszystkie problemy.

To ostrzeżenie informacyjne śledzi też problemy, które nie są już zgłaszane. Te informacje pozwalają Ci sprawdzić, czy problemy zostały rzeczywiście rozwiązane. Możesz też ponownie utworzyć bazę odniesienia, aby zapobiec ponownemu wystąpieniu błędu.

Uwaga: wartości domyślne są włączone podczas wykonywania inspekcji w trybie zbiorczym w IDE, ale są ignorowane w przypadku kontroli w edytorze, które są wykonywane w tle podczas edycji pliku. Dzieje się tak, ponieważ wartości domyślne są przeznaczone do sytuacji, gdy baza kodu ma dużą liczbę ostrzeżeń, ale chcesz rozwiązać problemy lokalnie, gdy wprowadzasz zmiany w kodzie.

Ręczne przeprowadzanie inspekcji

Aby ręcznie uruchomić skonfigurowane narzędzie lint i inne inspekcje IDE, kliknij Kod > Sprawdzanie kodu. Wyniki kontroli pojawią się w oknie Wyniki kontroli.

Ustawianie zakresu i profilu inspekcji

Wybierz pliki, które chcesz analizować (zakres inspekcji), oraz inspekcje, które chcesz przeprowadzić (profil inspekcji). Aby to zrobić:

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

Rysunek 3. Sprawdź ustawienia zakresu inspekcji.

Opcje widoczne w oknie Określ zakres inspekcji różnią się w zależności od tego, czy wybrano projekt, folder czy plik:
- Gdy wybierzesz jeden projekt, plik lub katalog, w oknie Określ zakres inspekcji wyświetli 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ć element do sprawdzenia, wybierz jeden z pozostałych przycisków opcji. Aby dowiedzieć się więcej o wszystkich polach w oknie Określanie zakresu kontroli, zapoznaj się z artykułem Okno Określanie zakresu kontroli.
W sekcji Profil inspekcji wybierz profil, którego chcesz użyć.
Aby rozpocząć inspekcję, kliknij OK.

Rysunek 4 przedstawia wyniki kontroli lint i innych kontroli IDE z uruchomionego narzędzia Sprawdzanie kodu:

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

Na panelu Raport z sprawdzeń wyświetlany jest raport z sprawdzeń dotyczący kategorii błędów, typu lub problemu wybranego na panelu Wyniki sprawdzenia. Zawiera on nazwę i lokalizację błędu. W stosownych przypadkach raport z przeskanowania zawiera inne informacje, takie jak podsumowanie problemu, które ułatwia jego rozwiązanie.
W widoku drzewa panelu Wyniki inspekcji kliknij prawym przyciskiem myszy kategorię, typ lub problem, aby wyświetlić menu kontekstowe.

W zależności od kontekstu możesz:
- Przejdź do źródła.
- Wykluczanie i uwzględnianie wybranych elementów.
- Problemy z tłumieniem.
- Zmień ustawienia.
- Zarządzaj alertami dotyczącymi kontroli.
- Przeprowadź ponownie inspekcję.

Opisów przycisków na pasku narzędzi, elementów menu kontekstowego i pól raportu inspekcji szukaj w oknie narzędzia Wyniki inspekcji.

Używanie zakresu niestandardowego

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

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

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 z bieżącego projektu.
- 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: tylko bieżący plik w bieżącym projekcie. Pojawia się, gdy wybierzesz plik lub folder.
- Wybrany katalog: tylko bieżący folder w bieżącym projekcie. Pojawia się, gdy masz wybrany folder.
- Hierarchia klas: po wybraniu tej opcji i kliknięciu OK pojawi się okno ze wszystkimi klasami w bieżącym projekcie. W oknie użyj pola Szukaj według nazwy, aby filtrować i wybierać klasy do sprawdzenia. Jeśli nie przefiltrujesz listy zajęć, inspekcja kodu sprawdzi wszystkie zajęcia.

Jeśli w przypadku projektu masz skonfigurowany system kontroli wersji, możesz też ograniczyć wyszukiwanie do plików, które zostały zmodyfikowane.

Kliknij OK.

Tworzenie zakresu niestandardowego

Jeśli chcesz sprawdzić wybrane pliki i katalogi, które nie są objęte żadnym z dostępnych zakresów niestandardowych, możesz utworzyć zakres niestandardowy:

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

Rysunek 6. Okno Określ zakres inspekcji.

Pojawi się okno Zakresy.

Rysunek 7. Utwórz zakres niestandardowy.
Aby zdefiniować nowy zakres, w lewym górnym rogu okna kliknij przycisk .
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. Zakres wspólny można też używać z innymi funkcjami projektu, które mają pole zakresu. Gdy na przykład klikniesz Edytuj ustawienia , aby zmienić ustawienia Znajdź użycia, w wyświetlonym oknie dialogowym pojawi się pole Zakres, w którym możesz wybrać wspólny zakres.

Rysunek 8. W oknie Znajdź użycia wybierz zakres udostępniania.
Nadaj zakresowi nazwę i kliknij OK.
Prawa część okna Zakresy wypełnia się opcjami, które umożliwiają zdefiniowanie zakresu niestandardowego.
Z listy wybierz Projekt.
Pojawi się lista dostępnych projektów.

Uwaga: możesz utworzyć niestandardowy zakres dla projektów lub pakietów. Procedura jest taka sama.
Rozwiń foldery projektu, wybierz, co chcesz dodać do zakresu niestandardowego, i określ, czy ma być to uwzględnione, czy wykluczone.

Rysunek 9. Zdefiniuj zakres niestandardowy.
- Uwzględnij: ten folder i jego pliki, ale nie uwzględniaj żadnych jego podfolderów.
- Uwzględnij rekurencyj: uwzględnij ten folder i jego pliki oraz jego podfoldery i ich pliki.
- Wyklucz: wyklucz ten folder i jego pliki, ale nie wykluczaj żadnych jego podfolderów.
- Wyklucz rekursywnie: wyklucz ten folder i jego pliki oraz jego podfoldery i ich pliki.
Rysunek 10 pokazuje, że uwzględniono folder main oraz że foldery java i res są uwzględniane rekurencyjnie. Niebieski oznacza folder, który został częściowo uwzględniony, a zielony – foldery i pliki uwzględnione cyklicznie.

Rysunek 10. Przykładowy wzór dla zakresu niestandardowego.
- Jeśli wybierzesz folder java i klikniesz Wyklucz rekursywnie, zielone podświetlenie zniknie z folderu java oraz wszystkich folderów i plików w jego obrębie.
- Jeśli wybierzesz wyróżniony na zielono plik MainActivity.kt i klikniesz Wyklucz, plik MainActivity.kt nie będzie już wyróżniony na zielono, ale wszystko inne w folderze java pozostanie wyróżnione na zielono.
Kliknij OK. Zakres niestandardowy pojawi się u dołu listy.

Sprawdzanie i edytowanie profili kontroli

Android Studio zawiera kilka profili lint i innych profili inspekcji, które są aktualizowane wraz z aktualizacjami Androida. Możesz używać tych profili w niezmienionej postaci 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 otworzyć ustawienia Inspekcji:

Wybierz Plik > Ustawienia. (w Windows) lub Android Studio > Preferencje (w macOS lub Linux).
Kliknij Edytor > Inspekcje.
Panel Inspekcje zawiera listę obsługiwanych inspekcji i ich opisów.

Rysunek 11. Obsługiwane inspekcje i ich opisy.
Wybierz listę Profil, aby przełączać się między inspekcjami Domyślna (Android Studio) i Domyślna w projekcie (aktywnego projektu).

Więcej informacji znajdziesz na stronie Zarządzanie profilami w IntelliJ.
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 inspekcje w tej kategorii jako jedną inspekcję.
Wybierz listę Pokaż działania schematu , aby kopiować, zmieniać nazwy, dodawać opisy, eksportować i importować inspekcje.
Gdy skończysz, kliknij OK.