안드로이드 노트 - 코드 구축 속도 최적화

전언
오랫동안 쓰지 않아서 이 편은 다시 시작하는 셈이다
최근 프로젝트의 컴파일 속도가 갈수록 느려지고 때로는 10분에 가까워져야 완전한 컴파일을 완성할 수 있기 때문에 공식 문서에 대한 최적화Gradle를 결정했다.최적화가 완료된 후 구축 속도가 대폭 상승하여 이 기록을 세웠다
시작 방법
공식 문서를 대조하고 실제 프로젝트와 결합하여 최적화하기 때문에 일부 세부 사항이나 프로젝트에서 사용하지 않은 점은 간략하게 가지고 있다
도구를 최신 상태로 유지
Android Studio 및 SDK 도구
Android Plugin for Gradle
개발을 위한 변형 만들기
운영 환경과 개발 환경을 분리하여 구성productFlavors불필요한 자원 컴파일 방지dev의 productFlavors에만 언어 자원 및 화면 밀도를 지정할 수 있습니다.

productFlavors {
    dev {
      resConfigs "en", "xxhdpi"
    }
    ...
}

디버그를 위한 Crashlytics 비활성화
일반적으로 debug에서 정지합니다

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

정적 구축 설정값과 디버깅 구축 결합 사용
항상 manifest 파일에 들어오는 속성에 정적/하드 인코딩 값을 사용하거나 디버그 구축 형식에 자원 파일을 사용합니다.manifest 파일이나 응용 자원의 값이 모든 구축에 따라 업데이트되어야 한다면 Instant Run 코드 교환을 실행할 수 없습니다. - 새로운 APK를 구축하고 설치해야 합니다.
예를 들어, 변경 사항을 실행할 때마다 동적 버전 코드, 버전 이름, 자원, 또는 변경할 수 있는 파일 manifest 을 사용하는 구축 논리는 완전한 APK 구축이 필요합니다. 실제 변경은 열교환만 필요하더라도 마찬가지입니다.만약 구축 설정에 이러한 동적 속성이 필요하다면, 게시 구축 변형에 격리시키고, 값을 디버깅 구축에 정적 상태로 유지합니다
간단하게 말하자면gradle 구축에 동적 구축 설정을 사용했다면 Instant Run 제대로 역할을 할 수 없고 새로운 APK를 직접 구축하는 것과 아무런 차이가 없다.
다음은 예이다

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

android {
    ...
    defaultConfig {
        versionCode 1
        versionName "1.0"
        ...
    }

    applicationVariants.all { variant ->
        if (variant.buildType.name == "release") {
            variant.mergedFlavor.versionCode = minutesSinceEpoch;
            variant.mergedFlavor.versionName = minutesSinceEpoch + "-" + variant.flavorName;
        }
    }
}

정적 종속 버전 사용build.gradle 파일에 의존항을 명시할 때, 마지막에 버전 번호를 더하기 번호와 함께 사용하는 것을 피해야 합니다. 예를 들어 com.android.tools.build:gradle:2.+ 동적 버전 번호를 사용하면 의외의 버전 업데이트와 해석하기 어려운 버전 차이를 초래할 수 있고 Gradle 업데이트 유무를 검사하여 구조 구축 속도를 늦출 수 있습니다.정적/하드 인코딩 버전 번호로 변경해야 합니다.
이것은 모두가 다 알고 있으니 더 이상 말하지 않겠다
오프라인 모드 사용
만약 네트워크 연결 속도가 비교적 느리다면, Gradle 네트워크 자원 분석 의존항을 사용하려고 시도할 때, 구축 시간이 길어질 수 있습니다.네트워크 자원 사용을 피하기 위해 로컬 작업에 캐시된 것만 사용하도록 지시할 수 있습니다.
이것도 흔히 볼 수 있는 구축 속도를 가속화하는 방식이다. 특히 국내에서 오프라인 모델을 사용하면 구축 속도가 크게 향상될 수 있다.그러나 오프라인 모드는 새로운 의존을 인용할 때마다 의존을 찾지 못하기 때문에 새로운 프로젝트는 사용하지 않을 수 있으면 사용하지 마세요.
필요 시 구성 사용Gradle 응용 프로그램을 어떻게 구축하는지 정확하게 이해하기 위해 구축 시스템은 모든 구축 전에 프로젝트에 모든 모듈과 이 모듈의 의존 항목을 설정합니다. (모듈을 구축하고 테스트하고 있어도 마찬가지입니다.)이것은 대형 다모듈 프로젝트의 구축 과정을 늦출 것이다
참고: 새 Android Studio의 경우 필요에 따라 구성할 수 없습니다.
병렬 컴파일 사용
필요에 따라 설정하는 과정에서 Gradle 이 옵션을 발견했습니다. 한 번 검색한 결과 병행화된 컴파일을 사용하여 컴파일 속도를 높일 수 있음을 발견했습니다. 선택하면 됩니다.
모듈화 개발에서 병행화 컴파일을 사용하여 컴파일 속도를 높이는 것이 더욱 현저하다
라이브러리 모듈 만들기
Android 라이브러리 모듈로 변환할 수 있는 코드를 응용 프로그램에서 찾습니다.이러한 방식으로 코드를 모듈화하면 구축 시스템이 수정된 모듈만 컴파일하고 미래 구축에 사용할 출력을 캐시할 수 있습니다.이런 방식도 필요에 따라 설정하고 병행 프로젝트를 실행하는 데 더욱 효과적일 수 있습니다. (만약 이 기능을 사용한다면)
프로젝트를 모듈화하고 더 이상 군말하지 말라는 것이다
사용자 정의를 위한 논리 구축 작업
구축 분석을 만든 후 구축 시간의 상당 부분이 '프로젝트 설정' 단계에 사용되었다는 것을 분석하려면build을 확인하십시오.gradle 스크립트에서 사용자 정의Gradle 작업에 추가할 코드를 찾습니다.구축 논리를 작업으로 이동하면 필요할 때만 실행되며, 후속 구축 캐시 결과를 만들 수 있으며, 이 구축 논리는 병행 실행할 자격이 있습니다. (병행 프로젝트 실행을 사용하면)자세한 내용은 공식Gradle 문서를 참조하십시오.
Debug에서 실행할 필요가 없는 구축을 Task로 옮기는 것입니다. 예를 들어 Debug에서 실행할 필요가 없는 구축
dexOptions 구성 및 라이브러리 사전 dexing 사용
이러한 설정을 사용하면 구축이 빨라질 수 있지만, 홈페이지에 따르면,
이 설정의 값을 늘려서 시험하고 구축 관찰 효과를 분석해야 합니다.프로세스에 너무 많은 자원을 분배하면 성능이 떨어질 수 있습니다
그러니까 이게 열릴지 안 열릴지 스스로 판단해야 돼.구체적인 구성에 대응하는 의미에 대해서는 홈페이지에 이미 분명하게 쓰여 바로 발표하였다

Compile independent modules in parallel는 추가 구축 속도를 높이기 위해 dex 라이브러리 의존항을 미리 설정했는지 여부를 성명합니다.이 기능은 깨끗한 구축 속도를 늦출 수 있기 때문에 지속적인 통합 서버를 위해 이 기능을 사용하지 않을 수도 있습니다.

preDexLibraries 실행 maxProcessCount 시 사용할 최대 스레드 수를 설정합니다.기본값은 4입니다.

dex-in-process DEX 컴파일러의 최대 무더기 크기를 설정합니다.단, 이 속성을 설정하지 않고 javaMaxHeapSize 무더기 크기 Gradle 를 늘려야 합니다.

Gradle의 무더기 크기 증가 및 dex-in-process 사용하기
프로젝트의 dex-in-process 파일에서 gradle.properties의 스택 크기를 2048MB로 설정합니다.

org.gradle.jvmargs = -Xmx2048m

이미지를 WebP로 변환
이것도 상투적인 말이다. 안드로이드 스튜디오에서 바로 전환할 수 있지만, 나는 프로젝트에서 이렇게 하지 않았다.
PNG 처리 비활성화
PNG 이미지를 WebP로 변환할 수 없거나 원하지 않을 경우, 구축할 때마다 자동 이미지 압축을 사용하지 않는 방식으로 구축 속도를 높일 수 있습니다.이 최적화를 비활성화하려면 다음 코드를 Gradle 파일에 추가합니다.

android {
  ...
  aaptOptions {
    cruncherEnabled false
  }
}

구축 유형이나 제품 맛이 이 속성을 정의하지 않기 때문에 발표 버전의 응용을 구축할 때 이 속성을 수동으로 설정해야 합니다 build.gradle이걸 켜면 컴파일 속도가 한 단계 더 빠를 것 같아요.
Instant Run 사용
앞에서 언급한 바와 같이 전제는 스크립트에서 정적 의존을 최대한 사용하는 것이다.현재 프로젝트에서 동적 의존을 너무 많이 썼기 때문에 이것은 당분간 쓸모가 없다
구축 캐시 설정
Android 플러그인 2.3.0 이상의 새 프로젝트를 사용하면 기본적으로 구축 캐시가 활성화됩니다. (구축 캐시를 명확하게 사용하지 않는 한)
콜아웃 프로세서 비활성화
콜아웃 프로세서(Annotation-Processing-Tool)를 사용할 때 증분 Java 컴파일링이 비활성화됩니다.가능하다면, 서로 다른 구축 사이에서 수정된 클래스만 컴파일할 수 있도록 주석 프로세서를 사용하지 마십시오.
그렇게 많은 제3자 라이브러리에서 주해로 쓴 것은 일반적인 상황에서 주해 처리를 정지할 수 없다
그러나 Butterknife를 사용하지 않고findViewById를 사용하면 컴파일 속도를 높일 수 있습니다. 왜냐하면 대응하는 주석 클래스를 생성하는 것을 피하기 때문입니다.하위 요소가 많지 않거나 자주 생성될 때findViewById
결말
사실은 한 편의 홈페이지 구축 속도가 최적화된 독후감이지만 제시에 따라 구축 속도가 뚜렷하게 향상되었다.다음 편에서는 구축 분석 도구를 어떻게 사용하여 구축 속도가 느린 원인을 분석하는지 이야기할 것이다
Optimize your build speed