Tối ưu hóa tốc độ tạo bản dựng

Thời gian tạo bản dựng dài sẽ làm chậm quá trình phát triển. Trang này cung cấp một số kỹ thuật giúp bạn tháo gỡ khó khăn liên quan đến tốc độ tạo bản dựng.

Quy trình cải thiện tốc độ tạo bản dựng chung như sau

  1. Tối ưu hóa cấu hình bản dựng bằng cách thực hiện một số bước để mang lại lợi ích tức thì cho hầu hết các dự án Android Studio.
  2. Tạo hồ sơ bản dựng để xác định và tháo gỡ khó khăn liên quan đến dự án hoặc máy trạm của bạn.

Khi phát triển ứng dụng, bạn nên triển khai cho thiết bị chạy Android từ 7.0 (API cấp 24) trở lên bất cứ khi nào có thể. Các phiên bản nền tảng Android mới hơn sẽ triển khai cơ chế tạo bản cập nhật cho ứng dụng theo cách hiệu quả hơn, chẳng hạn như Android Runtime (ART) và dịch vụ hỗ trợ gốc cho nhiều tệp DEX.

Lưu ý: Sau bản dựng sạch đầu tiên, bạn có thể nhận thấy rằng các bản dựng tiếp theo — các bản dựng sạch và tăng dần — hoạt động nhanh hơn nhiều (ngay cả khi không sử dụng bất kỳ tính năng tối ưu hóa nào được mô tả tại trang này). Điều này là nhờ trình nền Gradle có giai đoạn khởi động hiệu suất gia tăng, tương tự như các quy trình JVM khác.

Tối ưu hóa cấu hình bản dựng

Hãy thực hiện các mẹo sau để cải thiện tốc độ tạo bản dựng cho dự án Android Studio

Luôn cập nhật các công cụ

Sau hầu hết mỗi lần cập nhật, các công cụ Android sẽ có thêm tính năng mới và khả năng tối ưu hoá bản dựng, các mẹo sau đây tại trang này sẽ giúp đảm bảo bạn đang sử dụng phiên bản mới nhất. Để tận dụng tối đa các tính năng tối ưu hoá mới nhất, hãy cập nhật các nội dung sau:

Tạo một biến thể bản dựng để phát triển

Nhiều cấu hình bạn cần khi chuẩn bị phát hành ứng dụng là không cần thiết trong khi phát triển ứng dụng. Việc bật các quy trình tạo bản dựng không cần thiết sẽ làm chậm các bản dựng sạch và tăng dần, vì vậy, hãy định cấu hình biến thể bản dựng để chỉ định cấu hình bản dựng mà bạn cần trong quá trình phát triển ứng dụng. Mẫu sau đây tạo một phiên bản dành cho "dev" và phiên bản dành cho "prod" (dành cho cấu hình phiên bản phát hành của bạn):

Groovy

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        // When building a variant that uses this flavor, the following configurations
        // override those in the defaultConfig block.
        dev {
            // To avoid using legacy multidex when building from the command line,
            // set minSdkVersion to 21 or higher. When using Android Studio 2.3 or higher,
            // the build automatically avoids legacy multidex when deploying to a device running
            // API level 21 or higher—regardless of what you set as your minSdkVersion.
            minSdkVersion 21
            versionNameSuffix "-dev"
            applicationIdSuffix '.dev'
        }

        prod {
            // If you've configured the defaultConfig block for the release version of
            // your app, you can leave this block empty and Gradle uses configurations in
            // the defaultConfig block instead. You still need to create this flavor.
            // Otherwise, all variants use the "dev" flavor configurations.
        }
    }
}

Kotlin

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        // When building a variant that uses this flavor, the following configurations
        // override those in the defaultConfig block.
        create("dev") {
            // To avoid using legacy multidex when building from the command line,
            // set minSdkVersion to 21 or higher. When using Android Studio 2.3 or higher,
            // the build automatically avoids legacy multidex when deploying to a device running
            // API level 21 or higher—regardless of what you set as your minSdkVersion.
            minSdkVersion(21)
            versionNameSuffix = "-dev"
            applicationIdSuffix = ".dev"
        }

        create("prod") {
            // If you've configured the defaultConfig block for the release version of
            // your app, you can leave this block empty and Gradle uses configurations in
            // the defaultConfig block instead. You still need to create this flavor.
            // Otherwise, all variants use the "dev" flavor configurations.
        }
    }
}

Nếu cấu hình bản dựng của bạn đã sử dụng các phiên bản sản phẩm để tạo nhiều phiên bản ứng dụng thì bạn có thể kết hợp các cấu hình "dev" và "prod" với các phiên bản đó bằng cách sử dụng các nhóm phiên bản. Ví dụ: nếu đã định cấu hình phiên bản "demo" và "full" thì bạn có thể sử dụng cấu hình mẫu sau để tạo các phiên bản kết hợp, chẳng hạn như "devdemo" và "prodFull":

Groovy

android {
    ...
    defaultConfig {...}
    buildTypes {...}

    // Specifies the flavor dimensions you want to use. The order in which you
    // list each dimension determines its priority, from highest to lowest,
    // when Gradle merges variant sources and configurations. You must assign
    // each product flavor you configure to one of the flavor dimensions.

    flavorDimensions "stage", "mode"

    productFlavors {
        dev {
            dimension "stage"
            minSdkVersion 21
            versionNameSuffix "-dev"
            applicationIdSuffix '.dev'
            ...
        }

        prod {
            dimension "stage"
            ...
        }

        demo {
            dimension "mode"
            ...
        }

        full {
            dimension "mode"
            ...
        }
    }
}

Kotlin

android {
    ...
    defaultConfig {...}
    buildTypes {...}

    // Specifies the flavor dimensions you want to use. The order in which you
    // list each dimension determines its priority, from highest to lowest,
    // when Gradle merges variant sources and configurations. You must assign
    // each product flavor you configure to one of the flavor dimensions.

    flavorDimensions("stage", "mode")

    productFlavors {
        create("dev") {
            dimension = "stage"
            minSdkVersion(21)
            versionNameSuffix = "-dev"
            applicationIdSuffix = ".dev"
            ...
        }

        create("prod") {
            dimension = "stage"
            ...
        }

        create("demo") {
            dimension = "mode"
            ...
        }

        create("full") {
            dimension = "mode"
            ...
        }
    }
}

Đồng bộ hoá dự án có một biến thể

Đồng bộ hóa dự án với cấu hình bản dựng là một bước quan trọng giúp Android Studio hiểu được cấu trúc dự án của bạn. Tuy nhiên, quá trình này có thể tốn thời gian đối với các dự án lớn. Nếu dự án của bạn sử dụng nhiều biến thể bản dựng thì Android Studio sẽ tối ưu hóa tính năng đồng bộ hóa dự án bằng cách chỉ giới hạn ở các biến thể mà bạn đang chọn.

Tính năng tối ưu hóa này được bật theo mặc định đối với tất cả dự án và bạn không còn định cấu hình tính năng này trên Android Studio phiên bản từ 4.2 trở lên được nữa.

Để bật tính năng tối ưu hóa này theo cách thủ công, bạn cần sử dụng Android Studio 3.3 trở lên với trình bổ trợ Android cho Gradle từ 3.3.0 trở lên. Nhấp vào File > Settings > Experimental > Gradle (Tệp > Cài đặt > Thử nghiệm > Gradle) (Android Studio > Preferences > Experimental > Gradle on a Mac) (Android Studio > Tuỳ chọn > Thử nghiệm > Gradle trên máy Mac) và chọn hộp đánh dấu Only sync the active variant (Chỉ đồng bộ hoá biến thể đang hoạt động).

Lưu ý: Tính năng tối ưu hoá này hỗ trợ đầy đủ các dự án chứa các ngôn ngữ Java và C++, đồng thời hỗ trợ một số tính năng dành cho Kotlin. Khi bật tính năng tối ưu hoá cho các dự án có nội dung Kotlin, tính năng đồng bộ hoá Gradle sẽ quay lại sử dụng các biến thể đầy đủ trong nội bộ.

Tránh biên dịch các tài nguyên không cần thiết

Tránh biên dịch và đóng gói các tài nguyên mà bạn không thử nghiệm (chẳng hạn như các tài nguyên bản địa hóa ngôn ngữ bổ sung và tài nguyên mật độ màn hình). Bạn có thể thực hiện điều này bằng cách chỉ xác định một tài nguyên ngôn ngữ và mật độ màn hình cho phiên bản "dev" của mình, như minh họa trong mẫu sau:

Groovy

android {
    ...
    productFlavors {
        dev {
            ...
            // The following configuration limits the "dev" flavor to using
            // English stringresources and xxhdpi screen-density resources.
            resConfigs "en", "xxhdpi"
        }
        ...
    }
}

Kotlin

android {
    ...
    productFlavors {
        create("dev") {
            ...
            // The following configuration limits the "dev" flavor to using
            // English stringresources and xxhdpi screen-density resources.
            resConfigs("en", "xxhdpi")
        }
        ...
    }
}

Tắt Crashlytics cho các bản gỡ lỗi

Nếu bạn không cần chạy báo cáo Crashlytics, hãy tăng tốc cho bản gỡ lỗi bằng cách tắt trình bổ trợ theo cách sau:

Groovy

android {
    ...
    buildTypes {
        debug {
            ext.enableCrashlytics = false
        }
    }
}

Kotlin

android {
    ...
    buildTypes {
        getByName("debug") {
            extra["enableCrashlytics"] = false
        }
    }
}

Bạn cũng cần tắt bộ công cụ Crashlytics tại thời điểm chạy cho các bản gỡ lỗi bằng cách thay đổi cách khởi tạo tính năng hỗ trợ cho Fabric trong ứng dụng, như nội dung minh hoạ dưới đây:

Kotlin

// Initializes Fabric for builds that don't use the debug build type.
Crashlytics.Builder()
        .core(CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
        .build()
        .also { crashlyticsKit ->
            Fabric.with(this, crashlyticsKit)
        }

Java

// Initializes Fabric for builds that don't use the debug build type.
Crashlytics crashlyticsKit = new Crashlytics.Builder()
    .core(new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
    .build();

Fabric.with(this, crashlyticsKit);

Tắt tính năng tạo mã bản dựng tự động

Nếu muốn sử dụng Crashlytics với các bản gỡ lỗi, bạn vẫn có thể tăng tốc các bản dựng tăng dần bằng cách không để Crashlytics cập nhật tài nguyên ứng dụng bằng mã bản dựng riêng của mỗi bản dựng. Vì mã bản dựng này được lưu trữ trong một tệp tài nguyên được tham chiếu trong tệp kê khai nên việc tắt tính năng tự động tạo mã bản dựng cũng cho phép bạn sử dụng tính năng áp dụng các thay đổi cùng với Crashlytics cho bản dựng gỡ lỗi.

Để Crashlytics không tự động cập nhật mã bản dựng, hãy thêm đoạn mã sau vào tệp build.gradle:

Groovy

android {
    ...
    buildTypes {
        debug {
            ext.alwaysUpdateBuildId = false
        }
    }
}

Kotlin

android {
    ...
    buildTypes {
        getByName("debug") {
            extra["alwaysUpdateBuildId"] = false
        }
    }
}

Để biết thêm thông tin về cách tối ưu hóa các bản dựng khi sử dụng Crashlytics, hãy tham khảo tài liệu chính thức.

Dùng các giá trị cấu hình xây dựng tĩnh cho bản gỡ lỗi

Luôn dùng giá trị tĩnh/mã hóa cứng cho các thuộc tính có trong tệp kê khai hoặc tệp tài nguyên cho loại bản gỡ lỗi.

Chẳng hạn, việc sử dụng mã phiên bản động, tên phiên bản, tài nguyên hoặc bất kỳ logic tạo bản dựng nào khác làm thay đổi tệp kê khai yêu cầu bản dựng đầy đủ cho ứng dụng mỗi khi bạn muốn chạy thay đổi – ngay cả khi thay đổi thực tế đáng ra chỉ yêu cầu hoán đổi nóng. Nếu cấu hình bản dựng của bạn yêu cầu các thuộc tính động này, hãy tách riêng các thuộc tính này thành các biến thể của bản dựng phát hành và giữ lại các giá trị tĩnh đối với bản gỡ lỗi của bạn. Để tìm hiểu ví dụ, hãy xem phần như trọng tệp build.gradle bên dưới.

Groovy

int MILLIS_IN_MINUTE = 1000 * 60
int minutesSinceEpoch = System.currentTimeMillis() / MILLIS_IN_MINUTE

android {
    ...
    defaultConfig {
        // Making either of these two values dynamic in the defaultConfig will
        // require a full app build and reinstallation because the AndroidManifest.xml
        // must be updated.
        versionCode 1
        versionName "1.0"
        ...
    }

    // The defaultConfig values above are fixed, so your incremental builds don't
    // need to rebuild the manifest (and therefore the whole app, slowing build times).
    // But for release builds, it's okay. So the following script iterates through
    // all the known variants, finds those that are "release" build types, and
    // changes those properties to something dynamic.
    applicationVariants.all { variant ->
        if (variant.buildType.name == "release") {
            variant.mergedFlavor.versionCode = minutesSinceEpoch;
            variant.mergedFlavor.versionName = minutesSinceEpoch + "-" + variant.flavorName;
        }
    }
}

Kotlin

val MILLIS_IN_MINUTE = 1000 * 60
val minutesSinceEpoch = System.currentTimeMillis() / MILLIS_IN_MINUTE

android {
    ...
    defaultConfig {
        // Making either of these two values dynamic in the defaultConfig will
        // require a full app build and reinstallation because the AndroidManifest.xml
        // must be updated.
        versionCode = 1
        versionName = "1.0"
        ...
    }

    // The defaultConfig values above are fixed, so your incremental builds don't
    // need to rebuild the manifest (and therefore the whole app, slowing build times).
    // But for release builds, it's okay. So the following script iterates through
    // all the known variants, finds those that are "release" build types, and
    // changes those properties to something dynamic.
    applicationVariants.forEach { variant ->
        if (variant.buildType.name == "release") {
            variant.mergedFlavor.versionCode = minutesSinceEpoch
            variant.mergedFlavor.versionName = minutesSinceEpoch + "-" + variant.flavorName
        }
    }
}

Sử dụng các phiên bản phần phụ thuộc tĩnh

Khi khai báo các phần phụ thuộc trong tệp build.gradle, bạn nên tránh sử dụng số phiên bản có dấu cộng ở cuối, chẳng hạn như 'com.android.tools.build:gradle:2.+'. Việc sử dụng số phiên bản động có thể dẫn đến tình trạng cập nhật phiên bản không mong muốn, gây khó khăn cho việc phân biệt các phiên bản và làm chậm các bản dựng do quá trình kiểm tra Gradle cho các bản cập nhật. Thay vào đó, bạn nên sử dụng số phiên bản tĩnh/phiên bản mã hóa cứng.

Tạo các mô-đun thư viện

Tìm mã trong ứng dụng mà bạn có thể chuyển đổi thành mô-đun thư viện Android. Việc mô-đun hóa mã theo cách này cho phép hệ thống tạo bản dựng chỉ biên dịch những mô-đun bạn sửa đổi và lưu những kết quả đó vào bộ nhớ đệm cho các bản dựng sau này. Ngoài ra, tính năng này cũng giúp cải thiện hiệu quả cho phương thức thực thi dự án song (khi bạn bật tính năng tối ưu hóa đó).

Tạo nhiệm vụ cho logic bản dựng tùy chỉnh

Sau khi bạn tạo hồ sơ bản dựng, nếu thấy rằng giai đoạn tạo bản dựng mất tương đối nhiều thời gian, hãy xem lại build.gradle tập lệnh và tìm mã mà bạn có thể đưa vào một nhiệm vụ tùy chỉnh trong Gradle. Khi bạn di chuyển một số logic tạo bản dựng vào một tác vụ thì logic này sẽ chỉ chạy khi cần thiết và kết quả có thể được lưu vào bộ nhớ đệm để dùng cho các bản dựng sau này, đồng thời, logic tạo bản dựng đó cũng có thể chạy song) nếu bạn bật phương thức thực thi dự án song). Để tìm hiểu thêm, hãy đọc tài liệu chính thức về Gradle.

Mẹo: Nếu bản dựng chứa nhiều tác vụ tùy chỉnh thì bạn có thể sắp xếp gọn gàng các tệp build.gradle bằng cách tạo các lớp tác vụ tùy chỉnh. Hãy thêm các lớp vào thư mục project-root/buildSrc/src/main/groovy/ và Gradle sẽ tự động đưa các lớp này vào classpath cho tất cả các tệp build.gradle trong dự án của bạn.

Chuyển đổi hình ảnh sang WebP

WebP là một định dạng tệp hình ảnh đem lại khả năng nén có tổn hao (như JPEG) cũng như độ trong suốt (như PNG) nhưng có thể có khả năng nén tốt hơn so với JPEG hoặc PNG. Việc giảm kích thước tệp hình ảnh mà không thực hiện thao tác nén tại thời điểm tạo bản dựng có thể giúp tăng tốc độ cho các bản dựng, đặc biệt là khi ứng dụng sử dụng nhiều tài nguyên hình ảnh. Tuy nhiên, bạn có thể thấy mức sử dụng CPU của thiết bị tăng lên đôi chút trong khi nén các hình ảnh WebP. Bằng cách sử dụng Android Studio, bạn có thể dễ dàng chuyển đổi hình ảnh sang WebP.

Tắt tính năng nén tệp PNG

Nếu không thể (hoặc không muốn) chuyển đổi hình ảnh PNG thành WebP, bạn vẫn có thể tăng tốc độ tạo bản dựng bằng cách tắt tính năng nén hình ảnh tự động mỗi khi tạo ứng dụng. Nếu bạn đang sử dụng Plugin Android 3.0.0 trở lên thì theo mặc định, tính năng nén tệp PNG sẽ chỉ tắt đối với loại bản "gỡ lỗi". Để tắt tính năng tối ưu hóa này đối với các loại bản dựng khác, hãy thêm đoạn mã sau vào tệp build.gradle:

Groovy

android {
    buildTypes {
        release {
            // Disables PNG crunching for the release build type.
            crunchPngs false
        }
    }

// If you're using an older version of the plugin, use the
// following:
//  aaptOptions {
//      cruncherEnabled false
//  }
}

Kotlin

android {
    buildTypes {
        getByName("release") {
            // Disables PNG crunching for the release build type.
            isCrunchPngs = false
        }
    }

// If you're using an older version of the plugin, use the
// following:
//  aaptOptions {
//      cruncherEnabled = false
//  }
}

Vì các loại bản dựng hoặc phiên bản sản phẩm không xác định thuộc tính này nên bạn cần thiết lập thuộc tính này theo cách thủ công thành true khi tạo phiên bản phát hành cho ứng dụng.

Sử dụng trình xử lý chú giải tăng dần

Trình bổ trợ Android cho Gradle phiên bản 3.3.0 trở lên giúp cải thiện khả năng hỗ trợ đối với quá trình xử lý chú giải gia tăng. Vì vậy, để nâng cao tốc độ tạo bản dựng tăng dần, bạn nên cập nhật trình bổ trợ Android cho Gradle và chỉ sử dụng các trình xử lý chú giải tăng dần khi có thể.

Lưu ý: Tính năng này tương thích với Gradle phiên bản 4.10.1 trở lên, trừ Gradle 5.1 (xem lỗi trong Gradle #8194).

Để bắt đầu, hãy xem bảng sau về các trình xử lý chú giải phổ biến hỗ trợ quá trình xử lý chú giải tăng dần. Để xem danh sách đầy đủ hơn, hãy xem Trạng thái hỗ trợ trong các trình xử lý chú giải phổ biến. Một số trình xử lý chú giải có thể yêu cầu thêm một số bước để bật tính năng tối ưu hoá, vì vậy, hãy nhớ tìm hiểu tài liệu về từng trình xử lý chú giải.

Ngoài ra, nếu sử dụng Kotlin trong ứng dụng, bạn cần sử dụng kapt 1.3.30 trở lên để hỗ trợ các trình xử lý chú giải tăng dần cho mã Kotlin. Hãy nhớ đọc các tài liệu chính thức để nắm được bạn có cần bật hành vi này theo cách thủ công hay không.

Lưu ý: nếu bạn phải sử dụng từ một trình xử lý chú giải không hỗ trợ các bản dựng tăng dần trở lên thì quá trình xử lý chú giải sẽ không tăng dần. Tuy nhiên, nếu dự án của bạn sử dụng kapt thì tính năng biên dịch Java vẫn sẽ tăng dần.

Hỗ trợ trình xử lý chú giải tăng dần

Tên dự ánTên lớp của trình xử lý chú giảiHỗ trợ từ...
Liên kết dữ liệuandroid.databinding.annotationprocessor.ProcessDataBindingAGP 3.5
Phòngandroidx.room.RoomProcessor2.3.0-alpha02

2.20: Sử dụng tuỳ chọn room.incremental.
ButterKnifebutterknife.compiler.ButterKnifeProcessor10.2.0
Glidecom.bumptech.glide.annotation.toolkitr.glAnnotationProcessor4.9.0
Daggerdagger.internal.codegen.ComponentProcessor2.18
Lifecycleandroidx.lifecycle.LifecycleProcessor2.2.0-alpha02
AutoServicecom.google.auto.service.processor.AutoServiceProcessor1.0-rc7
Daggerdagger.android.processor.AndroidProcessor2.18
Realmio.realm.processor.RealmProcessor5.11.0
Lomboklombok.launch.AnnotationProcessorHider$AnnotationProcessor1.16.22
Lomboklombok.launch.AnnotationProcessorHider$ClaimingProcessor1.16.22

Định cấu hình trình thu gom rác của JVM

Bạn có thể cải thiện hiệu suất của bản dựng bằng cách định cấu hình trình thu thập rác tối ưu của máy ảo mà Gradle sử dụng. Mặc dù JDK 8 được định cấu hình để sử dụng trình thu thập rác song theo mặc định nhưng JDK 9 trở lên được định cấu hình để sử dụng trình thu gom rác G1.

Để có thể cải thiện hiệu suất của bản dựng, bạn nên thử nghiệm các bản dựng Gradle bằng trình thu thập rác song. Trong gradle.properties, hãy thiết lập các điểm sau:

org.gradle.jvmargs=-XX:+UseParallelGC

Nếu có các tùy chọn khác đã được thiết lập trong trường này, hãy thêm tùy chọn mới:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

Để đo tốc độ bản dựng với các cấu hình khác nhau, hãy xem Lập hồ sơ cho bản dựng.

Dùng các lớp R không gián tiếp

Bạn nên sử dụng các lớp R không phải tạm thời để có các bản dựng nhanh hơn cho các ứng dụng có nhiều mô-đun. Làm như vậy sẽ giúp ngăn chặn tình trạng trùng lặp tài nguyên bằng cách đảm bảo rằng lớp R của mỗi mô-đun chỉ chứa tệp đối chiếu đến tài nguyên riêng của mô-đun đó mà không cần lấy các tệp đối chiếu từ các phần phụ thuộc tương ứng. Điều này dẫn đến việc xây dựng bản dựng nhanh hơn và hưởng các lợi ích tương ứng của việc tránh sử dụng tính năng biên dịch.

Bắt đầu từ Android Studio Bumblebee, các lớp R không gián tiếp được bật theo mặc định cho các dự án mới. Đối với các dự án được tạo bằng các phiên bản cũ của Studio, bạn có thể cập nhật các phiên bản đó để sử dụng lớp R không gián tiếp bằng cách chuyển đến mục Tái cấu trúc > Di chuyển sang Lớp R không gián tiếp.

Để tìm hiểu thêm về tài nguyên ứng dụng và lớp R, vui lòng xem Tổng quan về tài nguyên ứng dụng.

Tắt cờ Jetifier

Hầu hết các dự án đều sử dụng trực tiếp thư viện AndroidX, vì vậy bạn có thể gỡ bỏ cờ Jetifier để cải thiện hiệu suất xây dựng. Để gỡ bỏ chế độ kiểm tra Jetifier, hãy đặt android.enableJetifier=false trong tệp gradle.properties của bạn. Trình phân tích bản dựng có thể thực hiện quá trình kiểm tra để xem liệu cờ có thể được gỡ bỏ một cách an toàn hay không nhằm giúp dự án của bạn đạt hiệu suất bản dựng tốt hơn đồng thời di chuyển khỏi các Thư viện hỗ trợ Android không được duy trì. Để tìm hiểu thêm về Trình phân tích bản dựng, vui lòng xem bài viết Khắc phục sự cố về hiệu suất bản dựng.

Sử dụng tính năng lưu cấu hình vào bộ nhớ đệm (thử nghiệm)

Lưu cấu hình vào bộ nhớ đệm là một tính năng thử nghiệm cho phép Gradle ghi lại thông tin về biểu đồ tác vụ của bản dựng và sử dụng lại thông tin đó trong các bản dựng tiếp theo, theo đó Gradle không cần phải định cấu hình lại cho toàn bộ bản dựng. Để bật tính năng lưu cấu hình vào bộ nhớ đệm, hãy làm theo các bước sau:

  1. Kiểm tra để đảm bảo tất cả các trình bổ trợ của dự án đều tương thích. Sử dụng Trình phân tích bản dựng để kiểm tra xem dự án của bạn có tương thích với tính năng lưu cấu hình vào bộ nhớ đệm hay không. Trình này sẽ chạy một chuỗi các bản thử nghiệm để xác định xem tính năng này có thể được bật cho dự án hay không. Bạn cũng có thể xem vấn đề #13490 để biết danh sách các trình bổ trợ được hỗ trợ.
  2. Thêm mã sau vào tệp gradle.properties:

      org.gradle.unsafe.configuration-cache=true
      # Use this flag sparingly, in case some of the plugins are not fully compatible
      org.gradle.unsafe.configuration-cache-problems=warn

  3. Khi bật tính năng lưu cấu hình vào bộ nhớ đệm, kết quả của bản dựng sẽ là Calculating task graph as no configuration cache is available for tasks khi bạn khởi chạy dự án lần đầu. Trong các lần chạy tiếp theo, kết quả bản dựng sẽ là Reusing configuration cache.
Để tìm hiểu thêm về tính năng lưu cấu hình vào bộ nhớ đệm, hãy xem bài đăng trên blog Tìm hiểu chuyên sâu về bộ nhớ đệm của cấu hìnhtài liệu về lưu cấu hình vào bộ nhớ đệm của Gradle.