이 페이지는 Cloud Translation API를 통해 번역되었습니다.

빌드 프로파일링

크기가 큰 프로젝트나 많은 맞춤 빌드 로직이 구현된 프로젝트에서는 병목 현상을 찾아내기 위해 빌드 프로세스를 더 자세히 들여다봐야 할 수 있습니다. 그렇게 하려면 Gradle이 빌드 수명 주기의 각 단계와 각 빌드 작업을 실행하는 데 얼마나 시간이 걸리는지를 프로파일링하면 됩니다. 예를 들어, 빌드 프로필에 Gradle이 프로젝트를 구성하는 데 너무 많은 시간을 소모한다고 나타난다면 빌드 프로필에서 맞춤 빌드 로직을 구성 단계에서 삭제하라고 제안할 수 있습니다. 또한 mergeDevDebugResources 작업이 빌드 시간의 상당 부분을 차지하는 경우 WebP로 이미지를 변환하거나 PNG 크런칭을 사용 중지하라고 표시할 수도 있습니다.

Android 스튜디오 4.0 이상을 사용하는 경우 빌드 성능 문제를 조사하는 가장 좋은 방법은 빌드 분석 도구를 사용하는 것입니다.

또한 Android 스튜디오 외부에서 빌드를 프로파일링하는 옵션은 두 가지가 있습니다.

독립형 gradle-profiler 도구: 빌드를 심층 분석하는 강력한 도구입니다.
Gradle --profile 옵션: Gradle 명령줄에서 사용할 수 있는 편리한 도구입니다.

독립형 `gradle-profiler` 도구 사용

최적의 빌드 속도를 제공하는 프로젝트 설정을 찾으려면 Gradle 빌드의 프로파일링 및 벤치마킹 정보를 수집하는 도구인 Gradle Profiler를 사용해야 합니다. Gradle Profiler를 사용하면 빌드 시나리오를 만들고 여러 번 실행할 수 있어 결과 간의 높은 편차를 방지하고 결과의 재현을 보장합니다.

벤치마킹 모드는 클린 및 증분 빌드 정보를 수집하는 데 사용해야 하는 반면 프로파일링 모드는 CPU 스냅샷 등 실행에 관한 더 상세한 정보를 수집하는 데 사용할 수 있습니다.

벤치마킹을 위한 프로젝트 설정에는 다음이 포함될 수 있습니다.

플러그인 버전
Gradle 버전
JVM 설정(힙 크기, permgen 크기, 가비지 컬렉션 등)
Gradle 작업자 수(org.gradle.workers.max)
추가로 성능을 최적화하기 위한 플러그인별 옵션

시작하기

이 안내에 따라 Gradle Profiler를 설치합니다.
gradle-profiler --benchmark --project-dir <root-project> :app:assembleDebug를 실행합니다.

이렇게 하면 완전한 최신 빌드를 벤치마킹합니다. --benchmark가 중간에 프로젝트를 변경하지 않고 작업을 여러 번 실행하기 때문입니다. 그러면 profile-out/ 디렉터리 아래에 빌드 시간을 보여 주는 HTML 보고서가 생성됩니다.

벤치마킹에 더 유용할 수 있는 다른 시나리오도 있습니다.

대부분의 작업을 실행하는 클래스의 메서드 본문에서 코드를 변경합니다.
프로젝트 전체에서 사용되는 모듈의 API를 변경합니다. 자체 코드 변경보다 자주 발생하지는 않지만 영향력은 더 크고 측정하는 데 유용합니다.
UI 작업의 반복을 시뮬레이션하기 위해 레이아웃을 수정합니다.
변환 작업 처리를 시뮬레이션하기 위해 문자열을 수정합니다.
빌드 자체의 변경을 시뮬레이션하기 위해 빌드를 클린합니다(예: Android Gradle 플러그인 업데이트, Gradle 업데이트 또는 buildSrc에서 자체 빌드 코드 수정)

이러한 사용 사례를 벤치마킹하려면 gradle-profiler 실행을 유도하는 데 사용되고 소스를 적절하게 변경하는 시나리오를 만들면 됩니다. 아래에서 일반적인 시나리오를 살펴볼 수 있습니다.

다양한 메모리/CPU 설정 프로파일링

다양한 메모리 및 CPU 설정을 벤치마킹하려면 서로 다른 org.gradle.jvmargs 값을 사용하는 여러 시나리오를 만들면 됩니다. 예를 들어 다음과 같은 시나리오를 만들 수 있습니다.

# <root-project>/scenarios.txt
clean_build_2gb_4workers {
    tasks = [":app:assembleDebug"]
    gradle-args = ["--max-workers=4"]
    jvm-args = ["-Xmx2048m"]
    cleanup-tasks = ["clean"]
}
clean_build_parallelGC {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-XX:+UseParallelGC"]
    cleanup-tasks = ["clean"]
}

clean_build_G1GC_4gb {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-Xmx4096m", "-XX:+UseG1GC"]
    cleanup-tasks = ["clean"]
}

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt를 실행하면 세 가지 시나리오가 실행되며 이러한 각 설정에서 :app:assembleDebug에 걸리는 시간을 비교할 수 있습니다.

다양한 Gradle 플러그인 버전 프로파일링

Gradle 플러그인 버전 변경이 빌드 시간에 어떤 영향을 미치는지 확인하려면 이를 벤치마킹하는 시나리오를 만드세요. 이를 위해서는 플러그인 버전을 시나리오에서 삽입할 수 있도록 준비해야 합니다. 다음과 같이 루트 build.gradle을 변경합니다.

# <root-project>/build.gradle
buildscript {
    def agpVersion = providers.systemProperty("agpVersion").forUseAtConfigurationTime().orNull ?: '4.1.0'

    ext.kotlin = providers.systemProperty('kotlinVersion').forUseAtConfigurationTime().orNull ?: '1.4.0'

    dependencies {
        classpath "com.android.tools.build:gradle:$agpVersion"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin"
    }
}

이제 시나리오 파일에서 Android Gradle 플러그인과 Kotlin Gradle 플러그인 버전을 지정하고 시나리오에서 소스 파일에 새 메서드를 추가하도록 할 수 있습니다.

# <root-project>/scenarios.txt
non_abi_change_agp4.1.0_kotlin1.4.10 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.1.0"
      "kotlinVersion" = "1.4.10"
}

non_abi_change_agp4.2.0_kotlin1.4.20 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.2.0-alpha16"
      "kotlinVersion" = "1.4.20"
}

증분 빌드 프로파일링

대부분의 빌드는 증분 방식이므로 프로파일링할 가장 중요한 시나리오 중 하나입니다. Gradle Profiler는 증분 빌드 프로파일링을 광범위하게 지원합니다. 메서드 본문을 변경하거나 새 메서드를 추가하거나 레이아웃 또는 문자열 리소스를 변경하여 소스 파일에 변경사항을 자동으로 적용할 수 있습니다. 예를 들어 다음과 같은 증분 시나리오를 만들어 보세요.

# <root-project>/scenarios.txt
non_abi_change {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

abi_change {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

layout_change {
    tasks = [":app:assembleDebug"]
    apply-android-layout-change-to = "app/src/main/res/your_layout_file.xml"
}
string_resource_change {
    tasks = [":app:assembleDebug"]
    apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt를 실행하면 벤치마킹 데이터가 포함된 HTML 보고서가 생성됩니다.

증분 시나리오를 힙 크기, 작업자 수 또는 Gradle 버전과 같은 다른 설정과 결합할 수 있습니다.

# <root-project>/scenarios.txt
non_abi_change_4g {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
}

non_abi_change_4g_8workers {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
    gradle-args = ["--max-workers=8"]
}

non_abi_change_3g_gradle67 {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx3072m"]
    version = ["6.7"]
}

클린 빌드 프로파일링

클린 빌드를 벤치마킹하려면 Gradle Profiler 실행을 유도하는 데 사용할 시나리오를 만들면 됩니다.

# <root-project>/scenarios.txt
clean_build {
    tasks = [":app:assembleDebug"]
    cleanup-tasks = ["clean"]
}

이 시나리오를 실행하려면 다음 명령어를 사용하세요.

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt

Gradle `--profile` 옵션 사용

Gradle 명령줄에서 빌드 프로필을 생성하고 보려면 다음 단계를 따르세요.

프로젝트 루트에서 명령줄 터미널을 엽니다.
다음 명령어를 입력하여 클린 빌드를 실행합니다. 빌드를 프로파일링할 때 Gradle은 작업에 관한 입력(예: 소스 코드)이 변하지 않을 때는 이 작업을 건너뛰므로, 개발자가 프로파일링되는 각 빌드 간에 클린 빌드를 실행해야 합니다. 따라서 입력 변화가 없는 두 번째 빌드는 작업이 재실행되지 않기 때문에 항상 더 빠르게 실행됩니다. 그래서 빌드 간에 clean 작업을 실행하면 전체 빌드 프로세스의 프로파일링이 보장됩니다.
```
// On Mac or Linux, run the Gradle wrapper using "./gradlew".
gradlew clean
```
제품 버전(예: 'dev' 버전) 중 하나의 디버그 빌드를 다음 플래그와 함께 실행합니다.
```
gradlew --profile --offline --rerun-tasks assembleFlavorDebug
```
- --profile: 프로파일링을 사용 설정합니다.
- --offline: Gradle이 온라인 종속 항목을 가져오는 것을 중지합니다. 이렇게 하면 종속 항목 업데이트를 시도하는 Gradle에 의해 발생하는 모든 지연이 프로파일링 데이터와 충돌하지 않습니다. Gradle이 이미 종속 항목을 다운로드하고 캐시했는지 확인하려면 개발자가 한 번이라도 프로젝트를 이미 빌드했어야 합니다.
- --rerun-tasks: Gradle에서 강제로 모든 작업을 재실행하고 모든 작업 최적화를 무시하도록 합니다.
그림 1. 프로필 보고서의 위치를 나타내는 프로젝트 뷰

빌드가 완료된 후 Project 창을 사용하여 project-root/build/reports/profile/ 디렉터리로 이동합니다(그림 1 참조).
profile-timestamp.html 파일을 마우스 오른쪽 버튼으로 클릭하고 Open in Browser > Default를 선택합니다. 보고서의 모양은 그림 2와 비슷합니다. 보고서의 각 탭을 검사하여 빌드에 관해 알아보세요. 예를 들어 Task Execution 탭은 Gradle이 각 빌드 작업을 실행하는 데 걸리는 시간을 나타냅니다.

그림 2. 브라우저에서 보고서 보기
선택사항: 프로젝트나 빌드 구성을 변경하기 전에 3단계의 명령어를 반복하되 --rerun-tasks 플래그는 생략합니다. Gradle에서는 시간 절약을 위해 입력이 변경되지 않은 작업(이러한 작업은 그림 3의 보고서에서 Task Execution 탭에 UP-TO-DATE로 표시)을 재실행하지 않으므로 실행되면 안 될 때 실행되는 작업을 확인할 수 있습니다. 예를 들어 :app:processDevUniversalDebugManifest가 UP-TO-DATE로 표시되지 않은 경우 모든 빌드마다 빌드 구성이 매니페스트를 동적으로 업데이트하도록 제안할 수도 있습니다. 그러나 일부 작업은 각 빌드 중에 실행되어야 합니다(예: :app:checkDevDebugManifest).

그림 3. 작업 실행 결과 보기

이제 빌드 프로필 보고서가 있으므로, 이 보고서의 각 탭에 있는 정보를 검사하여 최적화를 시작할 수 있습니다. 프로젝트와 워크스테이션 간에 이점 차이가 있을 수 있으므로 일부 빌드 설정에서는 실험이 필요합니다. 예를 들어 대량의 코드베이스가 있는 프로젝트는 코드 축소를 통해 미사용 코드를 삭제하고 앱 크기를 축소하는 이점이 있을 수 있습니다. 그러나 더 작은 프로젝트는 코드 축소를 모두 사용 중지할 때 더 이점이 있을 수 있습니다. 또한 Gradle 힙 크기를 늘리면(org.gradle.jvmargs 사용) 메모리 용량이 낮은 시스템에서 성능에 악영향을 미칠 수도 있습니다.

빌드 구성을 변경한 후 위의 단계를 반복하고 새 빌드 프로필을 생성하여 변경 결과를 관찰합니다. 예를 들어, 그림 4는 이 페이지에 설명된 기본적인 최적화를 동일한 샘플 앱에 적용한 후의 보고서를 보여줍니다.

그림 4. 빌드 속도를 최적화한 후의 새 보고서 보기