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. Zdecydowanie zalecamy poprawienie wszystkich błędów wykrytych przez linter przed opublikowaniem aplikacji.
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ć do kodu adnotacje.
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ą strukturalną 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ż obniżyć poziom ważności problemu, aby pominąć problemy, które nie są istotne dla Twojego projektu, lub zwiększyć poziom ważności, aby wyróżnić konkretne problemy.
Narzędzie lint sprawdza pliki źródłowe projektu Androida pod kątem potencjalnych błędów i możliwości optymalizacji pod kątem poprawności, bezpieczeństwa, wydajności, użyteczności, ułatwień dostępu i międzynarodowości. 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 Androida Studio. Ostrzeżenia i błędy możesz wyświetlić na 2 sposoby:
- jako tekst wyskakujący w oknie edytora. Gdy lint znajdzie problem, wyróżni problem żółtym kolorem. W przypadku poważniejszych problemów kod jest podkreślony na czerwono.
- W oknie Wyniki kontroli kliknij Kod > Sprawdź kod.
Uwaga: gdy kod jest kompilowany w Android Studio, dodatkowe sprawdzanie kodu 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, jak narzędzie lint przetwarza pliki źródłowe aplikacji.
- Pliki źródłowe aplikacji
- Pliki źródłowe to pliki, które składają się na projekt na Androida, w tym pliki Kotlin, Java i XML, ikony oraz pliki konfiguracyjne ProGuard.
- 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 do sprawdzania kodu
- 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
lintz poziomu wiersza poleceń, wyniki zostaną zapisane w folderzebuild/. Więcej informacji znajdziesz w sekcji Ręczne uruchamianie inspekcji.
Uruchamianie lint z poziomu 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.
- W systemie 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.
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, aby uruchamiać lint w ramach kompilacji ciągłej integracji, aby wyświetlać najnowsze kontrole lint podczas kompilowania dotychczasowego kodu źródłowego.
Więcej informacji o uruchamianiu zadań Gradle z poziomu wiersza poleceń znajdziesz w artykule Tworzenie aplikacji z poziomu wiersza poleceń.
Uruchamianie lint za pomocą samodzielnego 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, pojawi 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
Przykładowy wynik zawiera 4 ostrzeżenia i brak błędów.
2 ostrzeżenia dotyczące pliku AndroidManifest.xml projektu:
ManifestOrderUsesMinSdkAttributes
Preferences.xml: UnusedResources.
Jedno ostrzeżenie dotyczy katalogu res:
IconMissingDensityFolder.
Konfigurowanie linta w celu pomijania ostrzeżeń
Domyślnie, gdy uruchamiasz skanowanie lint, narzędzie sprawdza wszystkie problemy obsługiwane przez lint. Możesz też ograniczyć problemy, które ma sprawdzać lint, oraz przypisać problemom poziomy ważności. Możesz na przykład wyłączyć sprawdzanie lint w przypadku określonych problemów, które nie są istotne dla Twojego projektu, oraz skonfigurować lint tak, aby zgłaszanie problemów niekrytycznych odbywało się na niższym poziomie ważności.
Poziomy ważności:
enabledisablelubignoreinformationalwarningerrorfatal
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 sprawdzania błędów w plikach typu lint możesz określić w pliku lint.xml. Jeśli tworzysz ten plik ręcznie, umieść go w katalogu głównym projektu Androida.
Plik lint.xml składa się z otaczającego 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 błędów w przypadku 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 zgłaszane są 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 linta w przypadku konkretnej klasy lub metody w projekcie Androida, dodaj do tego kodu adnotację @SuppressLint.
Z tego przykładu dowiesz się, jak wyłączyć sprawdzanie błędów w metodzie onCreate w przypadku problemu NewApi. Narzędzie lint nadal sprawdza, czy w innych metodach tej klasy występuje problemNewApi.
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ć w przypadku dowolnego komponentu. 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 problemów z lint 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 jest zadeklarowany. 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 rozdzielonym przecinkami. Na 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 do wcześniejszych wersji i rozwiązywania wszystkich dotychczasowych problemów.
Aby utworzyć zrzut domyślny, 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 bazowej. 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: Wyjściem jest wydrukowanie lokalizacji 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. Zestaw bieżących problemów nazywany jest wartością bazową. 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 o wartościach domyślnych
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 początkowe są włączone, gdy w IDE uruchamiasz inspekcje w trybie zbiorczym, ale są ignorowane w przypadku kontroli w edytorze, które działają 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 podczas wprowadzania zmian w kodzie.
Ręczne uruchamianie 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) w ten sposób:
- W widoku Android otwórz projekt i wybierz projekt, folder lub plik, który chcesz przeanalizować.
- Na pasku menu kliknij Kod > Sprawdź kod.
W oknie Określ zakres sprawdzania 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.
- Gdy wybierzesz więcej niż jeden projekt, plik lub katalog, w oknie Określ zakres inspekcji będzie zaznaczony przycisk radiowy 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 kontroli wyświetl wyniki kontroli, rozwijając i wybierając kategorie, typy lub problemy związane z błędami.
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 kontroli 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żyć. - 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.
- Scratches and Consoles: tylko te pliki i konsole, które są 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.
- Kliknij OK.
Jeśli w przypadku projektu masz skonfigurowany system kontroli wersji, możesz też ograniczyć wyszukiwanie do plików, które zostały zmodyfikowane.
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 kliknij Zakres niestandardowy.
Kliknij 3 kropki obok listy 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.
Zarówno zakres lokalny, jak i wspólny są używane w projekcie w funkcji Sprawdzanie kodu. 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ć 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 rekursywnie: uwzględnia ten folder i jego pliki, a także jego podfoldery i pliki w nich.
- Wyklucz: wyklucz ten folder i jego pliki, ale nie wykluczaj żadnych jego podfolderów.
- Wyklucz rekursywnie: wyklucz ten folder i jego pliki, a także jego podfoldery i pliki.
Rysunek 10 pokazuje, że uwzględniono folder main oraz że foldery java i res są uwzględniane rekurencyjnie. Niebieski kolor wskazuje folder częściowo uwzględniony, a zielony – foldery i pliki uwzględnione rekurencyjnie.
Rysunek 10. Przykładowy wzór zakresu niestandardowego. - Jeśli wybierzesz folder java i klikniesz Wyklucz rekursywnie, folder java oraz wszystkie foldery i pliki w nim nie będą już wyróżnione na zielono.
- 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.