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 i zasobów) możesz zauważyć podobną poprawę wydajności:

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 ~9 s ~2,5 s
Zmiana 1 wiersza w kodzie Java (zmiana implementacji) ~2 min 15 s ~29 s ~6,4 s

Niektóre z tych zmian powodują błędy w dotychczasowych kompilacjach. Dlatego przed użyciem nowej wtyczki zastanów się,
czy warto poświęcić czas na migrację projektu.

Jeśli nie zauważysz opisanej powyżej poprawy wydajności, zgłoś błąd i dołącz ślad kompilacji wygenerowany 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 o aktualizowaniu 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 teraz usunąć właściwość android.buildToolsVersion.

3.0.1 (listopad 2017 r.)

Ta niewielka aktualizacja zapewnia obsługę Android Studio 3.0.1 i zawiera ogólne poprawki błędów oraz ulepszenia wydajności.

Optymalizacje

  • Lepsza równoległość w projektach wielomodułowych dzięki szczegółowemu grafowi zadań.
  • Podczas wprowadzania zmian w zależności Gradle przyspiesza kompilację, nie kompilując ponownie modułów, które nie mają dostępu do interfejsu API tej zależności. Należy ograniczyć zależności, które ujawniają swoje interfejsy API innym modułom, używając nowych konfiguracji zależności Gradle: implementation, api, compileOnly i runtimeOnly.
  • Szybsze kompilacje przyrostowe dzięki dexowaniu poszczególnych klas. Każda klasa jest teraz kompilowana do osobnych plików DEX, a ponownie konwertowane są tylko zmodyfikowane klasy. Możesz też oczekiwać szybszego kompilowania aplikacji, które mają ustawioną wartość minSdkVersion na 20 lub mniejszą i używają starszej wersji multi-dex.
  • Zwiększyliśmy szybkość kompilacji dzięki optymalizacji niektórych zadań pod kątem używania danych wyjściowych z 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 AAPT2 napotkasz 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, uruchamiając ./gradlew --stop z wiersza poleceń.

Nowe funkcje

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

  • Dodaliśmy obsługę przeprowadzania testów za pomocą Android Test Orchestrator, co pozwala na uruchamianie każdego testu aplikacji w ramach własnego wywołania instrumentacji. Ponieważ każdy test jest uruchamiany we własnej instancji instrumentacji, żaden stan udostępniany między testami nie kumuluje się w procesorze ani pamięci urządzenia. Nawet jeśli jeden test ulegnie awarii, spowoduje to wyłączenie tylko jego instancji instrumentacji, więc pozostałe testy będą nadal 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ść jest ustawiona na HOST, co wyłącza orkiestrację na urządzeniu i jest standardową metodą przeprowadzania testów.

    Dynamiczny

            android {
          testOptions {
            execution 'ANDROID_TEST_ORCHESTRATOR'
          }
        }

    Kotlin

            android {
          testOptions {
            execution = "ANDROID_TEST_ORCHESTRATOR"
          }
        }

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

    Dynamiczny

            dependencies {
          androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
          ...
        }

    Kotlin

            dependencies {
          androidTestUtil("com.android.support.test:orchestrator:1.0.0")
          ...
        }

  • Dodaliśmy testOptions.unitTests.includeAndroidResources, aby obsługiwać testy jednostkowe, które wymagają zasobów Androida, takich jak Roboelectric. Gdy ustawisz tę właściwość na true, wtyczka będzie scalać zasoby, komponenty i pliki manifestu przed uruchomieniem testów jednostkowych. Testy mogą następnie sprawdzać com/android/tools/test_config.properties w ścieżce klasy pod kątem tych kluczy:

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

      Uwaga: w przypadku modułów biblioteki scalone zasoby nie zawierają zasobów zależności (patrz 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 wszystkie 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.

  • thought Obsługa czcionek jako zasobów (nowa funkcja wprowadzona w Androidzie 8.0, poziom interfejsu API 26).
  • Obsługa pakietów APK dla konkretnych języków w pakiecie SDK aplikacji błyskawicznych na Androida w wersji 1.1 i nowszych.

  • Możesz teraz zmienić katalog wyjściowy zewnętrznego projektu kompilacji natywnej, jak pokazano poniżej:

    Dynamiczny

            android {
            ...
            externalNativeBuild {
                // For ndk-build, instead use the ndkBuild block.
                cmake {
                    ...
                    // Specifies a relative path for outputs from external C/C++
                    // 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 C/C++
                    // 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 utworzenie pliku JAR, który definiuje niestandardowe reguły analizy statycznej, i umieszczenie go w pakiecie w projektach AAR i APK.

    Niestandardowe reguły analizy kodu 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ą następnie korzystać z projektu lint za pomocą konfiguracji lintChecks:

    Dynamiczny

            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 w wersji 3.0.0 usuwa niektóre interfejsy API, więc jeśli ich używasz, kompilacja nie powiedzie się. 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żdego wariantu. Więcej informacji znajdziesz w artykule o zmianach 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.
  • Teraz możesz włączyć lub wyłączyć kompresję plików PNG w bloku buildTypes, jak pokazano poniżej. Kompresja plików PNG jest domyślnie włączona we wszystkich kompilacjach z wyjątkiem kompilacji do debugowania, ponieważ wydłuża czas kompilacji projektów zawierających wiele plików PNG. Aby skrócić czas kompilacji innych typów, wyłącz kompresowanie plików PNG lub przekonwertuj obrazy do formatu WebP.

    Dynamiczny

          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 cele wykonywalne, które konfigurujesz w zewnętrznych projektach CMake.
  • Teraz musisz dodać procesory adnotacji do ścieżki klasy procesora, używając konfiguracji zależności annotationProcessor.
  • Korzystanie z wycofanego elementu ndkCompile jest teraz bardziej ograniczone. Zamiast tego należy przejść na CMake lub ndk-build, aby skompilować kod natywny, który chcesz umieścić w pakiecie APK. Więcej informacji znajdziesz w artykule Migracja z ndkcompile.