Wtyczka Androida do obsługi Gradle w wersji 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 przykładowym projekcie szkieletowym z około 130 modułami i dużą liczbą zależności zewnętrznych (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 w wersji 2.3.0 lub nowszej i Gradle w wersji 3.3 lub nowszej Wtyczka Androida w wersji 3.0.0 lub nowszej i Gradle w wersji 4.1 lub nowszej
Konfiguracja (np. uruchomienie ./gradlew --help) ~2 min ~9 s ~2,5 s
1-wierszowa zmiana w języku Java (zmiana implementacji) ~2 min 15 s ~29 s ~6,4 s

Niektóre z tych zmian powodują, że dotychczasowe kompilacje przestają działać. Dlatego przed użyciem nowej wtyczki warto rozważyć
nakład pracy związany z migracją projektu.

Jeśli nie zauważysz opisanych powyżej ulepszeń wydajności, zgłoś błąd i dołącz ślad kompilacji za pomocą profilera Gradle.

Ta wersja wtyczki Androida wymaga:

Wersja minimalna Wersja domyślna Uwagi
Gradle 4.1 4.1 Więcej informacji znajdziesz w artykule Aktualizowanie Gradle.
Narzędzia do kompilacji pakietu SDK 26.0.2 26.0.2 Zainstaluj lub skonfiguruj narzędzia SDK do kompilacji. Dzięki tej aktualizacji nie musisz już określać wersji narzędzi do kompilacji – wtyczka domyślnie używa minimalnej wymaganej wersji. Możesz więc teraz usunąć właściwość android.buildToolsVersion.

3.0.1 (listopad 2017 r.)

Jest to niewielka aktualizacja, która obsługuje Androida Studio 3.0.1 i zawiera ogólne poprawki błędów oraz ulepszenia wydajności.

Optymalizacje

  • Lepsza równoległość w przypadku projektów wielomodułowych dzięki szczegółowemu grafowi zadań.
  • Podczas wprowadzania zmian w zależności Gradle wykonuje szybsze kompilacje, ponieważ nie kompiluje ponownie modułów, które nie mają dostępu do interfejsu API tej zależności. Ogranicz, które zależności udostępniają swoje interfejsy API innym modułom, używając nowych konfiguracji zależności Gradle: implementation, api, compileOnly i runtimeOnly.
  • Szybsze przyrostowe kompilowanie dzięki indeksowaniu DEX dla poszczególnych klas. Każda klasa jest teraz kompilowana do osobnych plików DEX, a ponownie indeksowane są tylko klasy, które zostały zmodyfikowane. Możesz też oczekiwać większej szybkości kompilacji w przypadku aplikacji, w których parametr minSdkVersion ma wartość 20 lub mniejszą i które korzystają z starszego multi-dexu.
  • Zwiększyliśmy szybkość kompilacji, optymalizując niektóre zadania pod kątem korzystania z wyników zapisanych w pamięci podręcznej. Aby skorzystać z tej optymalizacji, musisz najpierw włączyć pamięć podręczną kompilacji Gradle.
  • Ulepszone przyrostowe przetwarzanie zasobów za pomocą AAPT2, które jest teraz domyślnie włączone. Jeśli podczas korzystania z narzędzia AAPT2 wystąpią problemy, zgłoś błąd. Możesz też wyłączyć AAPT2, ustawiając android.enableAapt2=false w pliku gradle.properties i ponownie uruchamiając demona Gradle, wpisując ./gradlew --stop w wierszu poleceń.

Nowe funkcje

  • Zarządzanie zależnościami z uwzględnieniem wariantów. Podczas tworzenia określonej wersji modułu wtyczka automatycznie dopasowuje wersje zależności modułu biblioteki lokalnej do wersji tworzonego modułu.
  • Zawiera nową wtyczkę modułu funkcji, która obsługuje aplikacje błyskawiczne na Androida i pakiet SDK do aplikacji błyskawicznych na Androida (możesz go pobrać za pomocą menedżera SDK). Więcej informacji o tworzeniu modułów funkcji za pomocą nowej wtyczki znajdziesz w artykule Struktura aplikacji natychmiastowej z wieloma funkcjami.
  • Wbudowana obsługa niektórych funkcji języka Java 8 i bibliotek Java 8. Jack jest już przestarzały i nie jest już wymagany. Aby korzystać z ulepszonej obsługi języka Java 8 wbudowanej w domyślny łańcuch narzędzi, musisz najpierw wyłączyć Jacka. Więcej informacji znajdziesz w artykule Korzystanie z funkcji języka Java 8.

  • Dodaliśmy obsługę przeprowadzania testów za pomocą Android Test Orchestrator, co umożliwia uruchamianie każdego testu aplikacji w ramach własnego wywołania Instrumentation. Każdy test jest uruchamiany we własnej instancji Instrumentation, więc żaden wspólny stan między testami nie gromadzi się na procesorze ani w pamięci urządzenia. Nawet jeśli jeden test ulegnie awarii, spowoduje to wyłączenie tylko jego własnej instancji narzędzia Instrumentation, więc pozostałe testy nadal będą działać.

    • Dodano testOptions.execution, aby określić, czy używać orkiestracji testów na urządzeniu. Jeśli chcesz użyć narzędzia Android Test Orchestrator, musisz określić ANDROID_TEST_ORCHESTRATOR, jak pokazano poniżej. Domyślnie ta właściwość ma wartość HOST, która wyłącza orkiestrację na urządzeniu i jest standardową metodą przeprowadzania testów.

    Groovy

            android {
          testOptions {
            execution 'ANDROID_TEST_ORCHESTRATOR'
          }
        }

    Kotlin

            android {
          testOptions {
            execution = "ANDROID_TEST_ORCHESTRATOR"
          }
        }

  • Nowa konfiguracja zależności androidTestUtil umożliwia zainstalowanie innego testowego pliku APK przed uruchomieniem testów z instrumentacją, np. Android Test Orchestrator:

    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 obsługiwać testy jednostkowe, które wymagają zasobów Androida, np. Roboelectric. Jeśli ustawisz tę właściwość na true, wtyczka przed uruchomieniem testów jednostkowych połączy zasoby, komponenty i pliki manifestu. Testy mogą następnie sprawdzać com/android/tools/test_config.properties w ścieżce klas pod kątem tych kluczy:

    • android_merged_assets: ścieżka bezwzględna do katalogu scalonych komponentów.

      Uwaga: w przypadku modułów biblioteki scalone zasoby nie zawierają zasobów zależności (zobacz problem nr 65550419).

    • android_merged_manifest: ścieżka bezwzględna do pliku manifestu łączonego.

    • android_merged_resources: ścieżka bezwzględna do katalogu scalonych zasobów, który zawiera wszystkie zasoby z modułu i wszystkich jego zależności.

    • android_custom_package: nazwa pakietu końcowej klasy R. Jeśli dynamicznie modyfikujesz identyfikator aplikacji, ta nazwa pakietu może nie pasować do atrybutu package w pliku manifestu aplikacji.

  • Obsługa czcionek jako zasobów (nowa funkcja wprowadzona w Androidzie 8.0 (poziom 26 interfejsu API)).
  • Obsługa plików APK w określonych językach w przypadku pakietu SDK aplikacji błyskawicznych na Androida w wersji 1.1 lub nowszej.

  • Możesz teraz zmienić katalog wyjściowy zewnętrznego projektu kompilacji natywnej, 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 tworzenia projektów natywnych w Android Studio możesz teraz używać CMake w wersji 3.7 lub nowszej.

  • Nowa konfiguracja zależności lintChecks umożliwia tworzenie pliku JAR, który definiuje niestandardowe reguły lint, i pakowanie go w projektach AAR i APK.

    Niestandardowe reguły lint muszą należeć do osobnego projektu, który generuje pojedynczy plik JAR i zawiera tylko zależności compileOnly. Inne moduły aplikacji i biblioteki mogą wtedy zależeć od projektu lint przy użyciu konfiguracji lintChecks:

    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 działaniu

  • Wtyczka Androida w wersji 3.0.0 usuwa niektóre interfejsy API, więc jeśli ich używasz, kompilacja się nie powiedzie. Nie możesz już na przykład używać interfejsu Variants API do uzyskiwania dostępu do obiektów outputFile() ani używać processManifest.manifestOutputFile() do pobierania pliku manifestu dla każdej wersji. Więcej informacji znajdziesz w sekcji Zmiany w interfejsie API.
  • Nie musisz już określać wersji narzędzi do kompilacji (możesz więc usunąć właściwość android.buildToolsVersion). Domyślnie wtyczka automatycznie używa minimalnej wymaganej wersji narzędzi do kompilacji dla używanej wersji wtyczki Androida.
  • Włączanie i wyłączanie kompresji PNG odbywa się teraz w bloku buildTypes, jak pokazano poniżej. Kompresja PNG jest domyślnie włączona we wszystkich kompilacjach z wyjątkiem kompilacji debugowania, ponieważ wydłuża czas kompilacji projektów zawierających wiele plików PNG. Aby skrócić czas kompilacji innych typów kompilacji, wyłącz kompresję PNG lub przekonwertuj 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 wykonywalne elementy docelowe, które konfigurujesz w zewnętrznych projektach CMake.
  • Musisz teraz dodać procesory adnotacji do ścieżki klasy procesora za pomocą konfiguracji zależności annotationProcessor.
  • Używanie wycofanej funkcji ndkCompile jest teraz bardziej ograniczone. Zamiast tego przenieś się na CMake lub ndk-build, aby kompilować kod natywny, który chcesz spakować do pliku APK. Więcej informacji znajdziesz w artykule Migracja z ndk-compile.