Mastering Gradle dla Androida: zadania Gradle i Kotlin

Wideo: Flutter upload image to rest API | flutter coding

Zawartość

Eksplorowanie plików kompilacji Gradle
1. settings.gradle
2. build.gradle (poziom projektu)
3. build.gradle (poziom modułu)
Deklarowanie zależności Twojego projektu: biblioteki lokalne
Dodawanie zależności kompilacji: zdalne repozytoria
Łączenie ze zdalnym repozytorium
Deklarowanie zdalnej zależności
Generowanie wielu plików APK: jak tworzyć warianty kompilacji
Tworzenie niestandardowego zadania Gradle
Budowanie projektu za pomocą opakowania Gradle
Jakie inne zadania Gradle są dostępne?
Lepsze wykorzystanie Gradle: dodawanie wtyczek
Gradle Kotlin DSL
Podsumowując

Zamiast Java, XML lub Kotlin, te pliki kompilacji Gradle korzystają z języka specyficznego dla domeny (DSL) opartego na Groovy. Jeśli nie znasz Groovy, przyjrzymy się każdemu z tych plików kompilacji Gradle, więc pod koniec tego artykułu będziesz swobodnie czytać i pisać prosty kod Groovy.

Gradle ma na celu ułatwić Ci życie, zapewniając zestaw domyślnych ustawień, których często możesz używać przy minimalnej ręcznej konfiguracji - gdy jesteś gotowy do zbudowania projektu, po prostu naciśnij przycisk „Uruchom” w Android Studio, a Gradle rozpocznie proces kompilacji dla Was.

Pomimo podejścia „konwencji nad konfiguracją” firmy Gradle, jeśli ustawienia domyślne nie spełniają Twoich potrzeb, możesz dostosować, skonfigurować i rozszerzyć proces kompilacji, a nawet dostosować ustawienia Gradle, aby wykonywać bardzo konkretne zadania.

Ponieważ skrypty Gradle są zawarte w ich własnych plikach, możesz zmodyfikować proces kompilacji aplikacji w dowolnym momencie, bez konieczności dotykania kodu źródłowego aplikacji. W tym samouczku będziemy modyfikować proces kompilacji za pomocą smaków, wariantów kompilacji i niestandardowego zadania Gradle - wszystko bez zawsze dotykając naszego kodu aplikacji.

Eksplorowanie plików kompilacji Gradle

Za każdym razem, gdy tworzysz projekt, Android Studio generuje tę samą kolekcję plików kompilacji Gradle. Nawet jeśli zaimportujesz istniejący projekt do Android Studio, będzie on działać nadal utwórz dokładnie te same pliki Gradle i dodaj je do swojego projektu.

Aby lepiej zrozumieć składnię Gradle i Groovy, spójrzmy wiersz po wierszu na każdy plik kompilacji Gradle na Androida.

1. settings.gradle

W pliku settings.gradle zdefiniujesz wszystkie moduły aplikacji według nazwy, używając słowa kluczowego „włącz”. Na przykład, jeśli masz projekt składający się z „aplikacji” i „secondModule”, wtedy plik settings.gradle wyglądałby mniej więcej tak:

obejmują: app,: secondmodule rootProject.name = MyProject

W zależności od wielkości projektu ten plik może być znacznie dłuższy.

Podczas procesu kompilacji Gradle zbada zawartość pliku settings.gradle projektu i zidentyfikuje wszystkie moduły, które musi uwzględnić w procesie kompilacji.

2. build.gradle (poziom projektu)

Plik build.gradle na poziomie projektu znajduje się w katalogu głównym projektu i zawiera ustawienia, które zostaną zastosowane wszystko twoje moduły (zwane również przez Gradle „projektami”).

Tego pliku należy użyć do zdefiniowania wtyczek, repozytoriów, zależności i opcji konfiguracji, które mają zastosowanie do każdego modułu w całym projekcie Android. Pamiętaj, że jeśli zdefiniujesz jakieś zadania Gradle w pliku build.gradle na poziomie projektu, nadal możesz zastąpić lub rozszerzyć te zadania dla poszczególnych modułów, edytując ich odpowiednie na poziomie modułu plik build.gradle.

Typowy plik build.gradle na poziomie projektu będzie wyglądał mniej więcej tak:

buildscript {repositories {google () jcenter ()} dependencies {classpath com.android.tools.build:gradle:3.5.0-alpha06 // UWAGA: Nie umieszczaj tutaj zależności aplikacji; należą one // w poszczególnych plikach build.gradle modułu}} allprojects {repositories {google () jcenter ()}} zadanie czyste (wpisz: Usuń) {usuń rootProject.buildDir}

Ten plik build.gradle na poziomie projektu jest podzielony na następujące bloki:

Buildscript. Zawiera ustawienia wymagane do wykonania kompilacji.
Repozytoria. Gradle jest odpowiedzialny za zlokalizowanie zależności projektu i udostępnienie ich w kompilacji. Jednak nie wszystkie zależności pochodzą z tego samego repozytorium, więc musisz zdefiniować wszystkie repozytoria, które Gradle powinien przeszukać, aby odzyskać zależności projektu.
Zależności Ta sekcja zawiera zależności wtyczek, które są pobierane i przechowywane w lokalnej pamięci podręcznej. Powinieneś nie zdefiniuj dowolne zależności modułów w tym bloku.
Wszystkie projekty. Tutaj zdefiniujesz repozytoria, które powinny być dostępne wszystko modułów twojego projektu.

3. build.gradle (poziom modułu)

Jest to plik build.gradle na poziomie modułu, który jest obecny w każdym module w całym projekcie. Jeśli Twój projekt na Androida składa się z wielu modułów, będzie również składał się z wielu plików build.gradle na poziomie modułu.

Każdy plik build.gradle na poziomie modułu zawiera nazwę pakietu projektu, nazwę wersji i kod wersji, a także minimalny i docelowy zestaw SDK dla tego konkretnego modułu.

Plik build.gradle na poziomie modułu może również mieć swój własny unikalny zestaw instrukcji kompilacji i zależności. Na przykład, jeśli tworzysz aplikację ze składnikiem Wear OS, twój projekt Android Studio będzie składał się z osobnego modułu smartfona / tabletu i modułu Wear - ponieważ są one przeznaczone na zupełnie inne urządzenia, te moduły mają drastycznie różne zależności!

Podstawowy plik build.gradle na poziomie modułu zwykle będzie wyglądał mniej więcej tak:

zastosuj wtyczkę: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner prog. getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} dependencies {implementacja fileTree (reż: libs, include:) implementacja androidx.appcompat: appcompat: 1.0.2 implementacja androidx.constraintlayout: constraintlayout: 1.1. 3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: rdzeń espresso: 3.1.1}

Przyjrzyjmy się bliżej każdej z tych sekcji:

zastosuj wtyczkę. To jest lista wtyczek wymaganych do zbudowania tego modułu. Wtyczka com.android.application jest niezbędna do skonfigurowania procesu kompilacji specyficznego dla Androida, więc jest ona dodawana automatycznie.
android. W tym miejscu należy umieścić wszystkie opcje specyficzne dla platformy.
compileSdkVersion. Jest to poziom API, z którym ten moduł jest skompilowany. Nie można używać funkcji interfejsu API wyższych niż ta wartość.
buildToolsVersion. Wskazuje wersję kompilatora. W wersji 3.0.0 i nowszej buildToolsVersion jest opcjonalny; jeśli nie określisz wartości buildToolsVersion, wówczas Android Studio domyślnie przyjmuje najnowszą wersję Narzędzi do budowania.
defaultConfig. Zawiera opcje, które zostaną zastosowane do wszystkich wersji kompilacji aplikacji, takich jak kompilacje debugowania i wydania.
applicationId. To unikalny identyfikator Twojej aplikacji.
minSdkVersion. Ten parametr określa najniższy poziom API obsługiwany przez ten moduł.
targetSdkVersion. Jest to maksymalny poziom interfejsu API, na którym przetestowano twoją aplikację. Najlepiej byłoby przetestować aplikację przy użyciu najnowszego interfejsu API, co oznacza, że wartość targetSdkVersion zawsze będzie równa wartości compileSdkVersion.
versionCode. Jest to wartość liczbowa dla wersji aplikacji.
versionName. Jest to przyjazny dla użytkownika ciąg znaków reprezentujący wersję aplikacji.
buildTypes. Domyślnie Android obsługuje dwa typy kompilacji: debugowanie i wydanie. Możesz użyć bloków „debugowania” i „wydania”, aby określić ustawienia specyficzne dla aplikacji.
zależności. W tym miejscu zdefiniujesz biblioteki, od których ten moduł będzie zależał.

Deklarowanie zależności Twojego projektu: biblioteki lokalne

Możesz udostępnić dodatkową funkcjonalność swoim projektom na Androida, dodając jedną lub więcej zależności projektu. Zależności te mogą być lokalne lub mogą być przechowywane w zdalnym repozytorium.

Aby zadeklarować zależność od lokalnego pliku JAR, musisz dodać ten plik JAR do katalogu „libs” projektu.

Następnie możesz zmodyfikować plik build.gradle na poziomie modułu, aby zadeklarować zależność od tego pliku. Na przykład tutaj deklarujemy zależność od JAR „mylibrary”.

pliki implementacyjne (libs / mylibrary.jar)

Alternatywnie, jeśli twój folder „libs” zawierał kilka plików JAR, łatwiej byłoby po prostu stwierdzić, że Twój projekt zależy od wszystkich plików znajdujących się w folderze „libs”, na przykład:

plik implementacyjny Drzewo (reż: libs, include:)

Dodawanie zależności kompilacji: zdalne repozytoria

Jeśli biblioteka znajduje się w zdalnym repozytorium, musisz wykonać następujące kroki:

Zdefiniuj repozytorium, w którym znajduje się ta zależność.
Zadeklaruj indywidualną zależność.

Łączenie ze zdalnym repozytorium

Pierwszym krokiem jest poinformowanie Gradle, które repozytorium (lub repozytoria) musi sprawdzić, aby odzyskać wszystkie zależności projektu. Na przykład:

repozytoria {google () jcenter ()}}

W tym przypadku wiersz „jcenter ()” zapewnia, że Gradle sprawdzi repozytorium JCenter, które jest bezpłatnym repozytorium publicznym hostowanym na bintray.

Alternatywnie, jeśli Ty lub Twoja organizacja prowadzicie osobiste repozytorium, powinniście dodać adres URL tego repozytorium do deklaracji zależności. Jeśli repozytorium jest chronione hasłem, musisz również podać dane logowania, na przykład:

repozytoria {mavenCentral () maven {// Skonfiguruj docelowy adres URL // url "http://repo.mycompany.com/myprivaterepo"} maven {poświadczenia {nazwa użytkownika myUsername hasło myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Jeśli zależność występuje w wielu repozytoriach, to Gradle wybierze „najlepszą” wersję tej zależności, na podstawie czynników takich jak wiek każdego repozytorium i wersja statyczna.

Deklarowanie zdalnej zależności

Następnym krokiem jest zadeklarowanie zależności w pliku build.gradle na poziomie modułu. Dodajesz te informacje do bloku „zależności”, korzystając z jednego z poniższych:

Realizacja. Jest to normalna zależność, której potrzebujesz za każdym razem, gdy budujesz projekt. Zależność „implementacyjna” będzie obecna w całym wszystko twoje kompilacje.
Testimplementation. Jest to zależność wymagana do skompilowania źródła testowego aplikacji i uruchomienia testów opartych na JVM. Gdy oznaczysz zależność jako „Testimplementation”, Gradle będzie wiedział, że nie musi uruchamiać zadań dla tej zależności podczas normalnej kompilacji, co może skrócić czas kompilacji.
Androidtestimplementation. Jest to zależność wymagana podczas uruchamiania testów na urządzeniu, na przykład framework Espresso jest powszechnym „testem na Androida”.

Zdalną zależność definiujemy za pomocą jednego z powyższych słów kluczowych, a następnie atrybutów grupy, nazwy i wersji zależności, na przykład:

zależności {implementacja fileTree (reż: libs, include:) implementacja androidx.appcompat: appcompat: 1.0.2 implementacja androidx.constraintlayout: constraintlayout: 1.1.3 test Implementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Generowanie wielu plików APK: jak tworzyć warianty kompilacji

Czasami może być konieczne utworzenie wielu wersji aplikacji. Na przykład możesz chcieć wydać wersję bezpłatną i płatną, która zawiera dodatkowe funkcje.

Jest to zadanie kompilacji, w którym Gradle może ci pomóc, więc spójrzmy, jak zmodyfikujesz proces kompilacji, aby utworzyć wiele plików APK z jednego projektu:

Otwórz plik strings.xml i usuń oryginalny ciąg nazwy aplikacji.
Następnie zdefiniuj nazwy każdego smaku produktu, który chcesz utworzyć; w tym przypadku używam:

Moja darmowa aplikacja Moja płatna aplikacja

Otwórz plik AndroidManifest.xml i zamień android: label = ”@ string / nazwa_aplikacji” na:

android: label = "$ {appName}"

Otwórz plik build.gradle na poziomie modułu i dodaj następujące elementy do bloku „android”:

flavDimensions „tryb” productFlavours {free {wymiar "tryb" applicationIdSuffix ".free" manifestPlaceholder =} płatny {wymiar "tryb" applicationIdSuffix ".paid" manifestPlaceholder =}}}

Podzielmy się tym, co się tutaj dzieje:

smak Wymiary. Wtyczka dla Androida tworzy warianty kompilacji, łącząc smaki z różnych wymiarów. Tutaj tworzymy wymiar smaku składający się z „darmowej” i „płatnej” wersji naszej aplikacji. W oparciu o powyższy kod, Gradle wygeneruje cztery warianty kompilacji: paidDebug, paidRelease, freeDebug i freeRelease.
produkt Smaki. Określa listę smaków i ich ustawień, które w powyższym kodzie są „płatne” i „darmowe”.
Darmowe / płatne. Są to nazwy naszych dwóch smaków produktów.
Wymiar. Musimy określić wartość parametru „wymiar”; w tym przypadku używam „trybu”.
applicationIdSuffix. Ponieważ chcemy utworzyć wiele wersji naszej aplikacji, musimy nadać każdemu pakietowi APK unikalny identyfikator aplikacji.
manifestPlaceholder. Każdy projekt ma jeden plik manifestu zawierający ważne informacje o konfiguracji projektu. Podczas tworzenia wielu wariantów kompilacji zazwyczaj chcesz zmodyfikować niektóre z tych manifestów w czasie kompilacji. Możesz użyć plików kompilacji Gradle, aby określić unikalne wpisy manifestu dla każdego wariantu kompilacji, które zostaną następnie wstawione do manifestu podczas kompilacji. W powyższym kodzie modyfikujemy wartość „appName” w zależności od tego, czy Gradle tworzy bezpłatną, czy płatną wersję naszej aplikacji.

Tworzenie niestandardowego zadania Gradle

Czasami może być konieczne dostosowanie procesu kompilacji za pomocą Gradle zadania.

Zadanie to nazwana kolekcja działań, które Gradle wykona podczas wykonywania kompilacji, na przykład generowanie Javadoc. Gradle domyślnie obsługuje wiele zadań, ale możesz także tworzyć zadania niestandardowe, które mogą się przydać, jeśli masz na myśli bardzo szczegółowy zestaw instrukcji kompilacji.

W tej sekcji utworzymy niestandardowe zadanie Gradle, które będzie przeprowadzać iterację we wszystkich wariantach kompilacji naszego projektu (paidDebug, paidRelease, freeDebug i freeRelease), utworzy datę i godzinę, a następnie doda te informacje do każdego wygenerowanego pakietu APK.

Otwórz plik build.gradle na poziomie modułu i dodaj następujące elementy:

zadanie addDateAndTime () {// Iteruj przez wszystkie wyjściowe warianty kompilacji // android.applicationVariants.all {wariant -> // Iteruj przez wszystkie pliki APK // variant.outputs.all {wyjście -> // Utwórz instancję bieżąca data i godzina, w określonym formacie // def dateAndTime = new Date (). format („rrrr-MM-dd: GG-mm”) // Dołącz tę informację do nazwy pliku APK // def nazwa_pliku = wariant. name + "_" + dateAndTime + ".apk" output.outputFileName = nazwa pliku}}}

Następnie musimy powiedzieć Gradle'owi kiedy powinien wykonać to zadanie. Podczas kompilacji Gradle identyfikuje wszystko, co musi pobrać i wszystkie zadania, które musi wykonać, i układa je w Directed Acyclic Graph (DAG). Następnie Gradle wykona wszystkie te zadania, zgodnie z kolejnością zdefiniowaną w DAG.

W mojej aplikacji użyję metody „whenReady”, która gwarantuje, że nasze zadanie zostanie wywołane, gdy DAG zostanie zapełnione, a Gradle jest gotowy do rozpoczęcia wykonywania swoich zadań.

Dodaj następujące elementy do pliku build.gradle na poziomie modułu:

// Wykonaj to zadanie // gradle.taskGraph.whenReady {addDateAndTime}

Postawmy nasze niestandardowe zadanie i nasz kod wersji kompilacji do testu, budując ten projekt za pomocą polecenia Gradle.

Budowanie projektu za pomocą opakowania Gradle

Wydajesz polecenia Gradle za pomocą opakowania Gradle („gradlew”). Ten skrypt jest preferowanym sposobem rozpoczęcia kompilacji Gradle, ponieważ uniezależnia wykonanie kompilacji od twojej wersji Gradle. Ta separacja może być przydatna, jeśli współpracujesz z innymi, którzy niekoniecznie mają zainstalowaną tę samą wersję Gradle.

Wydając polecenia otoki Gradle, użyjesz „gradlew” dla systemów operacyjnych uniksopodobnych, w tym macOS, i „gradlew.bat” dla Windows. Mam komputer Mac, więc będę używać poleceń „gradlew”.

Możesz wydawać polecenia Gradle z poziomu Android Studio:

Na pasku narzędzi Android Studio wybierz „Widok> Narzędzia Windows> Terminal”. Spowoduje to otwarcie panelu Terminal u dołu okna IDE.
Wpisz następujące polecenie w terminalu:

./gradlew build

Android Studio powinien wyglądać mniej więcej tak:

Naciśnij klawisz „Enter” na klawiaturze. Gradle teraz zbuduje twój projekt.

Gradle przechowuje wszystkie wygenerowane pliki APK w katalogu aplikacji / build / Output / apk twojego projektu, więc przejdź do tego katalogu. Folder „APK” powinien zawierać kilka folderów i podfolderów; upewnij się, że Gradle wygenerował pakiet APK dla każdego wariantu kompilacji oraz że do każdego pliku dodano poprawną datę i godzinę.

Jakie inne zadania Gradle są dostępne?

Oprócz dowolnych niestandardowych zadań, które możesz utworzyć, Gradle obsługuje listę gotowych zadań gotowych do użycia. Jeśli chcesz zobaczyć, jakie zadania są dostępne, to:

Otwórz okno Terminal Android Studio, jeśli nie jest jeszcze otwarte (wybierając „Widok> Narzędzia Windows> Terminal” z paska narzędzi Android Studio).
Wpisz następujące polecenie w terminalu:

./gradlew -q zadania

Naciśnij klawisz „Enter” na klawiaturze.

To zadanie „zadań” zostanie teraz uruchomione i po kilku chwilach Terminal wyświetli listę wszystkich zadań dostępnych dla tego projektu, wraz z krótkim opisem każdego zadania.

Lepsze wykorzystanie Gradle: dodawanie wtyczek

Gradle jest dostarczany z wstępnie zainstalowaną liczbą wtyczek, ale możesz dodatkowo rozszerzyć Grade, dodając nowe wtyczki. Wtyczki te udostępniają nowe zadania dla projektów Androida, na przykład wtyczka Java zawiera zadania, które pozwalają kompilować kod źródłowy Java, uruchamiać testy jednostkowe i tworzyć plik JAR, taki jak „compileJava”, „compileText”, „jar” „Javadoc” i „clean”.

Aby zastosować wtyczkę, dodaj deklarację „zastosuj wtyczkę” do pliku build.gradle na poziomie modułu, a następnie nazwę wtyczki. Na przykład tutaj stosujemy wtyczkę Java:

zastosuj wtyczkę: java

Jeśli chcesz się dowiedzieć, jakie wtyczki są dostępne, sprawdź wyszukiwanie wtyczek Gradle, która zapewnia kompleksowy rejestr wtyczek Gradle.

Gradle Kotlin DSL

Domyślnie będziesz pisać skrypty kompilacji Gradle za pomocą Groovy DSL, ale jeśli jesteś jednym z wielu programistów, którzy przyjęli Kotlin dla Androida, możesz zamiast tego napisać skrypty kompilacji w Kotlinie.

W przeciwieństwie do Groovy, Kotlin jest statycznym językiem programowania, więc jeśli przełączysz się, pliki kompilacji będą zgodne z funkcjami autouzupełniania i nawigacji w kodzie źródłowym Android Studio. Ponadto przejście z Groovy na Kotlin oznacza, że będziesz używać tego samego języka programowania w całym projekcie, co może ułatwić programowanie - szczególnie jeśli nie znasz zbytnio Groovy!

Jeśli chcesz zacząć pisać logikę kompilacji w Kotlin, musisz skonfigurować DSL Gradle Kotlin i postępować zgodnie z instrukcjami w przewodniku migracji.

Podsumowując

W tym artykule przeanalizowaliśmy narzędzie do automatyzacji kompilacji i zarządzania zależnościami w Android Studio. Zbadaliśmy, jak Gradle automatyzuje proces budowania od razu po wyjęciu z pudełka i jak możesz zmodyfikować proces kompilacji, edytując pliki kompilacji projektu Gradle, w tym tworząc niestandardowe zadania Gradle i generując wiele wariantów kompilacji z jednego projektu.

Czy rozszerzyłeś program Gradle o automatyzację innych części procesu budowania systemu Android? Daj nam znać w komentarzach poniżej!