bazel 모바일 설치

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
문제 신고 출처 보기

Android용 빠른 반복 개발

이 페이지에서는 bazel mobile-install가 Android의 반복 개발 속도를 훨씬 빠르게 만드는 방법을 설명합니다. 이 방법은 기존 앱 설치 방법의 문제와 비교하여 이 접근 방식의 이점을 설명합니다.

요약

Android 앱에 작은 변경사항을 매우 빠르게 설치하려면 다음 단계를 따르세요.

  1. 설치하려는 앱의 android_binary 규칙을 찾습니다.
  2. proguard_specs 속성을 삭제하여 Proguard를 사용 중지합니다.
  3. multidex 속성을 native로 설정합니다.
  4. dex_shards 속성을 10로 설정합니다.
  5. USB를 통해 ART가 아닌 ART를 실행하는 기기를 연결하고 기기에서 USB 디버깅을 사용 설정합니다.
  6. bazel mobile-install :your_target을 실행합니다. 앱 시작 시간이 평소보다 약간 느립니다.
  7. 코드 또는 Android 리소스를 수정합니다.
  8. bazel mobile-install --incremental :your_target을 실행합니다.
  9. 많은 시간을 기다리지 않아도 됩니다.

Bazel에 대한 몇 가지 명령줄 옵션은 유용할 수 있습니다.

  • --adb는 Bazel에게 사용할 adb 바이너리를 알려줍니다.
  • --adb_argadb의 명령줄에 인수를 더 추가하는 데 사용할 수 있습니다. 한 가지 유용한 용도는 bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target에 여러 기기가 연결되어 있는 경우 설치할 기기를 선택하는 것입니다.
  • --start_app 앱이 자동으로 시작됩니다.

확실하지 않은 경우 를 확인하거나 Google에 문의하세요.

소개

개발자 도구 모음의 가장 중요한 속성 중 하나는 속도입니다. 즉, 변경사항이 예상대로 실행되는지에 대한 피드백을 얻기 위해서는 코드를 변경하고 1초 이내에 실행되는 것을 확인하고 몇 분 또는 몇 시간 기다려야 하는 경우가 많습니다.

안타깝게도 .apk를 빌드하기 위한 기존의 Android 도구 모음에는 Android 앱을 빌드하기 위해 많은 모놀리식, 순차 단계가 수반됩니다. Google에서는 한 줄의 변경사항을 빌드하기까지 5분을 기다리는 것이 Google 지도와 같은 대규모 프로젝트에서 일반적이지 않았습니다.

bazel mobile-install는 앱 코드를 변경하지 않고 Android 내부의 변경사항 프루닝, 작업 샤딩, 기발한 조작을 조합하여 Android의 반복 개발을 훨씬 더 빠르게 합니다.

기존 앱 설치 관련 문제

Android 앱을 빌드하면 다음과 같은 문제가 있습니다.

  • 덱싱. 기본적으로 'dx'는 빌드에서 정확히 한 번 호출되며 이전 빌드의 작업 재사용 방법을 모릅니다. 즉, 하나의 메서드만 변경되었더라도 모든 메서드가 다시 덱싱됩니다.

  • 기기에 데이터 업로드. adb는 USB 2.0 연결의 전체 대역폭을 사용하지 않으며, 대용량 앱은 업로드하는 데 시간이 오래 걸릴 수 있습니다. 리소스 또는 단일 메서드와 같은 작은 부분만 변경되더라도 전체 앱이 업로드되므로 큰 병목 현상이 발생할 수 있습니다.

  • 네이티브 코드 컴파일 Android L에서는 Dalvik과 같이 앱을 제때 컴파일하지 않고 미리 앱을 컴파일하는 새로운 Android 런타임인 ART를 도입했습니다. 따라서 앱 설치 시간이 길어지면서 앱 속도가 훨씬 빨라집니다. 이는 일반적으로 앱을 한 번 설치하여 여러 번 사용하기 때문에 사용자에게 바람직한 장단점이지만, 앱이 여러 번 설치되고 각 버전은 최대 몇 번 실행되므로 개발 속도가 느려집니다.

bazel mobile-install의 접근 방식

bazel mobile-install 개선사항은 다음과 같습니다.

  • 샤딩된 덱싱 앱의 자바 코드를 빌드한 후 Bazel은 클래스 파일을 거의 같은 크기의 부분으로 샤딩하여 별도로 dx를 호출합니다. dx는 마지막 빌드 이후 변경되지 않은 샤드에서 호출되지 않습니다.

  • 증분 파일 전송 Android 리소스, .dex 파일, 네이티브 라이브러리는 기본 .apk에서 삭제되고 별도의 모바일 설치 디렉터리에 저장됩니다. 이렇게 하면 전체 앱을 재설치하지 않고도 코드와 Android 리소스를 독립적으로 업데이트할 수 있습니다. 따라서 파일을 전송하는 데 걸리는 시간이 단축되고 변경된 .dex 파일만 기기에서 다시 컴파일됩니다.

  • .apk 외부에서 앱의 일부를 로드하는 경우 아주 작은 스텁 애플리케이션이 .apk에 배치되어 Android 리소스, 자바 코드, 기기 내 모바일 설치 디렉터리에서 네이티브 코드를 로드한 다음 제어를 실제 앱에 전송합니다. 이는 앱에 투명하게 적용되지만, 아래에 설명된 몇 가지 특수한 경우는 예외입니다.

샤딩된 덱싱

샤딩된 덱싱은 상당히 간단합니다. .jar 파일이 빌드된 후 도구가 거의 동일한 크기의 별도의 .jar 파일로 샤딩한 후 이전 빌드 이후 변경된 .jar 파일을 dx를 호출합니다. dex를 어느 샤드로 할지 결정하는 로직은 Android에만 국한되지 않습니다. Bazel의 일반 변경 프루닝 알고리즘을 사용합니다.

샤딩 알고리즘의 첫 번째 버전은 단순히 .class 파일을 알파벳순으로 정렬한 다음 목록을 동일한 크기의 부분으로 자르었지만 이 방법은 최적이 아닌 것으로 입증되었습니다. 클래스가 추가되거나 중첩된 경우 (중첩되거나 익명인 클래스도 포함) 모든 클래스가 한 번에 알파벳순으로 이동하여 해당 샤드를 다시 덱싱하게 됩니다. 따라서 개별 클래스가 아닌 자바 패키지를 샤딩하기로 했습니다. 물론 새 패키지를 추가하거나 삭제하면 여전히 샤드가 많아지지만 단일 클래스를 추가하거나 삭제하는 것보다 훨씬 덜 발생합니다.

샤드 수는 BUILD 파일에서 제어합니다 (android_binary.dex_shards 속성 사용). 이상적인 환경에서는 Bazel이 가장 적합한 샤드 수를 자동으로 결정하지만, Bazel은 실행 전에 일련의 작업 (예: 빌드 중에 실행할 명령어)을 알고 있어야 합니다. 따라서 최종적으로 자바 클래스가 몇 개인지 모르기 때문에 최적의 샤드 수를 결정할 수 없습니다. 일반적으로 더 많은 샤드일수록 더 빠르게 실행됩니다. 가장 좋은 점은 일반적으로 샤드 10~50개입니다.

증분 파일 전송

앱을 빌드한 후 다음 단계는 가급적 적은 노력으로 앱을 설치하는 것입니다. 설치는 다음 단계로 구성됩니다.

  1. .apk 설치 (일반적으로 adb install 사용)
  2. 모바일 설치 디렉터리에 .dex 파일, Android 리소스, 네이티브 라이브러리 업로드

첫 번째 단계에서는 성과 증분이 많지 않습니다. 앱이 설치되었는지 여부가 아니라 현재 상황에 따라 필요한 경우 Bazel이 --incremental 명령줄 옵션을 통해 이 단계를 수행해야 하는지 여부를 사용자에게 나타냅니다.

두 번째 단계에서는 빌드의 앱 파일을 기기에 있는 앱 파일과 체크섬을 나열하는 기기 매니페스트 파일과 비교합니다. 모든 새 파일이 기기에 업로드되고 변경된 모든 파일이 업데이트되며 삭제된 모든 파일이 기기에서 삭제됩니다. 매니페스트가 없으면 모든 파일을 업로드해야 한다고 가정합니다.

기기의 파일을 변경하여 증분 설치 알고리즘을 속일 수 있지만 매니페스트에서 체크섬은 변경할 수 없습니다. 이는 기기에 있는 파일의 체크섬을 계산하여 보호될 수 있었지만 설치 시간을 늘리는 것이 가치가 없다고 판단되었습니다.

Stub 애플리케이션

스텁 애플리케이션은 기기 내 mobile-install 디렉터리에서 dexs, 네이티브 코드 및 Android 리소스를 로드하는 매직을 실행합니다.

실제 로드는 BaseDexClassLoader의 서브클래스를 통해 구현되며 상당히 잘 문서화된 기술입니다. 이 작업은 앱의 클래스가 로드되기 전에 이루어지므로 APK에 있는 모든 애플리케이션 클래스가 기기 내 mobile-install 디렉터리에 배치되어 adb install 없이 업데이트될 수 있게 됩니다.

이는 앱의 클래스가 로드되기 전에 이루어져야 하므로, 애플리케이션 클래스를 .apk에 추가할 필요가 없습니다. 즉, 이러한 클래스를 변경하면 완전히 다시 설치해야 합니다.

AndroidManifest.xml에 지정된 Application 클래스를 스텁 애플리케이션으로 대체하여 실행합니다. 이 메서드는 앱이 시작될 시점을 제어하고, Android 프레임워크 내부에서 자바 리플렉션을 사용하여 가장 초기의 클래스 (생성자)에서 클래스 로더와 리소스 관리자를 적절하게 조정합니다.

스텁 애플리케이션은 모바일 설치로 설치한 네이티브 라이브러리를 다른 위치에 복사합니다. 동적 링커는 파일에 X 비트를 설정해야 하는데 루트가 아닌 adb에서 액세스할 수 있는 어떤 위치에서는 할 수 없기 때문에 이렇게 해야 합니다.

이러한 작업이 모두 완료되면 스텁 애플리케이션이 실제 Application 클래스를 인스턴스화하고 앱 자체의 모든 참조를 Android 프레임워크 내의 실제 애플리케이션으로 변경합니다.

결과

실적

일반적으로 bazel mobile-install은 소규모 변경 후 대형 앱을 빌드하고 설치할 때 속도가 4~10배 더 빠릅니다.

일부 Google 제품의 계산 값은 다음과 같습니다.

물론 이는 변경의 특성에 따라 다릅니다. 기본 라이브러리를 변경한 후 다시 컴파일하는 데 더 많은 시간이 걸립니다.

제한사항

스텁 애플리케이션이 재생할 수 있는 트릭은 모든 경우에 작동하지 않습니다. 다음 사례는 예상대로 작동하지 않는 위치를 강조합니다.

  • ContextContentProvider#onCreate()Application 클래스로 변환되는 경우 이 메서드는 애플리케이션 시작 중에 호출되어 Application 클래스의 인스턴스를 대체하기 때문에 ContentProvider는 실제 애플리케이션 대신 스텁 애플리케이션을 계속 참조합니다. 이와 같이 Context를 다운캐스트하지 않아도 되므로 버그는 아니지만 Google의 일부 앱에서 발생하는 것 같습니다.

  • bazel mobile-install에서 설치한 리소스는 앱 내에서만 사용할 수 있습니다. PackageManager#getApplicationResources()을 통해 다른 앱에서 리소스에 액세스하는 경우 이러한 리소스는 마지막 비증분 설치의 리소스입니다.

  • ART를 실행하지 않는 기기 스텁 애플리케이션은 Froyo 이상에서 잘 작동하지만 Dalvik에서는 특정 사례(예: 자바 주석이 특정한 방식으로 사용되는 경우)에서 코드가 여러 .dex 파일에 배포되는 경우 앱이 잘못되었다고 생각하게 하는 버그가 있습니다. 앱에서 이러한 버그를 간과하지 않는 한 Dalvik에서도 작동해야 합니다 (단, 이전 Android 버전 지원은 중점을 두지 않음).