Wtyczka Androida do obsługi Gradle 3.0.0 (październik 2017 r.)
Wtyczka Androida do obsługi Gradle w wersji 3.0.0 zawiera wiele zmian, które mają na celu rozwiązanie problemów z wydajnością dużych projektów.
Na przykład w szkieletowym projekcie z około 130 modułami i dużą liczbą zewnętrznych zależności (ale bez kodu ani zasobów) możesz zauważyć poprawę wydajności podobną do tej:
Wersja wtyczki Androida + wersja Gradle | Wtyczka Androida 2.2.0 + Gradle 2.14.1 | Wtyczka Androida 2.3.0 + Gradle 3.3 | Wtyczka Androida 3.0.0 + Gradle 4.1 |
---|---|---|---|
Konfiguracja (np. uruchamianie ./gradlew --help ) |
~2 min | ok. 9 s | około 2,5 s |
Zmiana w Javie (1 wiersz kodu) | ok. 2 min 15 s | około 29 s | ~6,4 s |
Niektóre z tych zmian powodują nieprawidłowe działanie dotychczasowych wersji. Zanim zaczniesz używać nowego wtyczki, zastanów się, ile
wysiłku będziesz musiał włożyć w migrację projektu.
Jeśli nie zauważysz opisanych wyżej ulepszeń wydajności, zgłoś błąd, dołączając ślad kompilacji utworzony za pomocą Profilera Gradle.
Ta wersja wtyczki na Androida wymaga:
Minimalna wersja | Wersja domyślna | Uwagi | |
---|---|---|---|
Gradle | 4.1 | 4.1 | Więcej informacji znajdziesz w artykule Aktualizowanie Gradle. |
Narzędzia do kompilowania pakietu SDK | 26.0.2 | 26.0.2 | Zainstaluj lub skonfiguruj narzędzia do kompilowania pakietu SDK. Dzięki tej aktualizacji nie musisz już określać wersji narzędzi do kompilacji – wtyczka domyślnie używa minimalnej wymaganej wersji. Możesz teraz usunąć właściwość android.buildToolsVersion. |
3.0.1 (listopad 2017 r.)
To drobna aktualizacja, która zapewnia obsługę Android Studio 3.0.1. Zawiera ona ogólne poprawki błędów i ulepszenia wydajności.
Optymalizacje
- Lepsza równoległość w przypadku projektów wielomodułowych dzięki szczegółowemu grafowi zadań.
- Gdy wprowadzasz zmiany w zależności, Gradle wykonuje kompilację szybciej, ponieważ nie kompiluje ponownie modułów, które nie mają dostępu do interfejsu API tej zależności.
Należy ograniczyć, które zależności mogą udostępniać interfejsy API innym modułom, korzystając z nowych konfiguracji zależności Gradle:
implementation
,api
,compileOnly
iruntimeOnly
. - Szybsze kompilowanie przyrostowe dzięki dekodowaniu na poziomie klasy. Każda klasa jest teraz kompilowana w osobne pliki DEX, a tylko zmodyfikowane klasy są ponownie deksomizowane. Szybkość kompilacji powinna się też zwiększyć w przypadku aplikacji, w których parametr
minSdkVersion
ma wartość 20 lub niższą i które korzystają z starszego wieloprocesorowego dekodera. - Zwiększona szybkość kompilacji dzięki optymalizacji niektórych zadań pod kątem używania wyjściowych danych w pamięci podręcznej. Aby skorzystać z tej optymalizacji, musisz najpierw włączyć pamięć podręczną kompilacji Gradle.
- Ulepszone stopniowe przetwarzanie zasobów za pomocą AAPT2, które jest teraz domyślnie włączone. Jeśli podczas korzystania z AAPT2 wystąpią problemy, zgłoś błąd. Możesz też wyłączyć AAPT2, ustawiając wartość
android.enableAapt2=false
w plikugradle.properties
i ponownie uruchamiając demona Gradle, uruchamiając./gradlew --stop
z poziomu wiersza poleceń.
Nowe funkcje
- Zarządzanie zależnościami z uwzględnieniem wariantów. Podczas tworzenia określonej wersji modułu wtyczka automatycznie dopasowuje warianty zależności modułu biblioteki lokalnej do wersji modułu, który tworzysz.
- Zawiera nowy wtyczkę modułu funkcji, która obsługuje aplikacje błyskawiczne na Androida i pakiet SDK aplikacji błyskawicznych na Androida (który można pobrać za pomocą menedżera pakietu SDK). Więcej informacji o tworzeniu modułów funkcji za pomocą nowego wtyczki znajdziesz w artykule Struktura aplikacji błyskawicznej z większą liczbą funkcji.
- Wbudowane wsparcie dla niektórych funkcji języka Java 8 i bibliotek Java 8. Jack jest teraz wycofany i nie jest już wymagany. Najpierw wyłącz Jacka, aby korzystać z ulepszonej obsługi Javy 8 wbudowanej w domyślny zestaw narzędzi. Więcej informacji znajdziesz w artykule Korzystanie z funkcji językowych Java 8.
-
Dodano obsługę uruchamiania testów za pomocą Android Test Orchestrator, która umożliwia uruchamianie każdego testu aplikacji w ramach jego własnego wywołania narzędzia Instrumentation. Każdy test jest uruchamiany w ramach własnego wystąpienia narzędzia do pomiaru wydajności, więc stan wspólny dla testów nie gromadzi się w pamięci ani na procesorze urządzenia. Nawet jeśli jeden test ulegnie awarii, spowoduje to wyłączenie tylko jego instancji narzędzia Instrumentation, więc pozostałe testy będą nadal działać.
- Dodano parametr
testOptions.execution
, aby określić, czy ma być używana koordynacja testów na urządzeniu. Jeśli chcesz korzystać z Android Test Orchestrator, musisz podać parametrANDROID_TEST_ORCHESTRATOR
, jak pokazano poniżej. Domyślnie ta właściwość ma wartośćHOST
, która wyłącza sterowanie na urządzeniu. Jest to standardowa metoda uruchamiania testów.
Groovy
android { testOptions { execution 'ANDROID_TEST_ORCHESTRATOR' } }
Kotlin
android { testOptions { execution = "ANDROID_TEST_ORCHESTRATOR" } }
- Dodano parametr
-
Nowa konfiguracja zależności
androidTestUtil
umożliwia zainstalowanie innego pomocniczego pakietu APK do testów, takiego jak Android Test Orchestrator, przed uruchomieniem testów pomiarowych:Groovy
dependencies { androidTestUtil 'com.android.support.test:orchestrator:1.0.0' ... }
Kotlin
dependencies { androidTestUtil("com.android.support.test:orchestrator:1.0.0") ... }
-
Dodano
testOptions.unitTests.includeAndroidResources
, aby umożliwić testy jednostkowe, które wymagają zasobów Androida, takich jak Roboelectric. Gdy ustawisz tę właściwość natrue
, wtyczka złączy zasoby, komponenty i manifest przed uruchomieniem testów jednostkowych. Testy mogą następnie sprawdzać wartośćcom/android/tools/test_config.properties
w ścieżce klasyfikacji w celu uzyskania tych kluczy:-
android_merged_assets
: bezwzględna ścieżka do katalogu scalonych komponentów.Uwaga: w przypadku modułów bibliotek scalone zasoby nie zawierają zasobów zależności (patrz problem #65550419).
-
android_merged_manifest
: bezwzględna ścieżka do scalonego pliku manifestu. -
android_merged_resources
: bezwzględna ścieżka do katalogu scalonych zasobów, który zawiera wszystkie zasoby z modułu i wszystkie jego zależności. -
android_custom_package
: nazwa pakietu ostatniej klasy R. Jeśli dynamicznie modyfikujesz identyfikator aplikacji, nazwa pakietu może nie odpowiadać atrybuciepackage
w pliku manifestu aplikacji.
-
- Obsługa czcionek jako zasobów (jest to nowa funkcja wprowadzona w Androidzie 8.0 (poziom API 26)).
- Obsługa plików APK w różnych językach w pakiecie SDK aplikacji błyskawicznych na Androida w wersji 1.1 lub nowszej.
-
Możesz teraz zmienić katalog wyjściowy dla projektu kompilacji natywnych zewnętrznych, jak pokazano poniżej:
Groovy
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory "./outputs/cmake" } } }
Kotlin
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory = "./outputs/cmake" } } }
- Podczas kompilowania projektów natywnych w Android Studio możesz teraz używać CMake 3.7 lub nowszej wersji.
-
Nowa konfiguracja zależności
lintChecks
umożliwia tworzenie pliku JAR z definicją niestandardowych reguł lint i pakowanie go w projektach AAR i APK.Niestandardowe reguły lint muszą należeć do osobnego projektu, który generuje jeden plik JAR i zawiera tylko zależności
compileOnly
. Inne moduły aplikacji i biblioteki mogą zależeć od projektu linta korzystającego z konfiguracjilintChecks
:Groovy
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks project(':lint-checks') }
Kotlin
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks(project(":lint-checks")) }
Zmiany w zachowaniu
- Wtyczka Androida 3.0.0 usuwa niektóre interfejsy API, a jeśli ich używasz, kompilacja nie będzie działać prawidłowo. Nie możesz na przykład używać interfejsu Variants API do uzyskiwania dostępu do obiektów
outputFile()
ani do pobierania pliku manifestu dla każdej wersji za pomocą atrybutuprocessManifest.manifestOutputFile()
. Aby dowiedzieć się więcej, przeczytaj artykuł Zmiany w interfejsie API. - Nie musisz już określać wersji dla narzędzi do kompilacji (możesz teraz usunąć właściwość
android.buildToolsVersion
). Domyślnie wtyczka automatycznie używa minimalnej wymaganej wersji narzędzi do kompilowania dla wersji używanej przez Ciebie wtyczki Android. - Teraz możesz włączyć lub wyłączyć kompresję PNG w bloku
buildTypes
, jak pokazano poniżej. Kompresowanie PNG jest domyślnie włączone we wszystkich wersjach, z wyjątkiem wersji debugowych, ponieważ wydłuża czas kompilacji projektów zawierających wiele plików PNG. Aby skrócić czas kompilacji w przypadku innych typów kompilacji, wyłącz kompresję PNG lub konwertuj obrazy do formatu WebP.Groovy
android { buildTypes { release { // Disables PNG crunching for the release build type. crunchPngs false } } }
Kotlin
android { buildTypes { release { // Disables PNG crunching for the release build type. isCrunchPngs = false } } }
- Wtyczka Androida automatycznie tworzy teraz docelowe pliki wykonywalne skonfigurowane w zewnętrznych projektach CMake.
- Teraz musisz dodać procesory adnotacji do ścieżki klas procesora za pomocą konfiguracji zależności
annotationProcessor
. - Korzystanie z wycofanej właściwości
ndkCompile
jest teraz bardziej ograniczone. Zamiast tego użyj CMake lub ndk-build do skompilowania kodu natywnego, który chcesz zapakować do pliku APK. Więcej informacji znajdziesz w artykule Przejście z ndkcompile.