2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
샤딩 구성
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 페이지에서는 샤딩을 통해 도구 모음 모듈(AndroidTest.xmlAndroidTest.xml)의 어떤 부분을 조정할 수 있는지, 실습 과정의 계속적인 실행 도중 어떻게 해야 가장 빠른 성능을 얻을 수 있는지에 대해 설명합니다. 옵션을 일반적인 방식으로 설명하고 각 옵션에 대한 합리적인 설명을 제공할 수 있도록 노력해 보겠습니다.
실습에서 계속적으로 시행되는 도구 모음은 보통 전반적인 완료 시간을 줄이기 위해 여러 기기에 걸쳐 샤딩됩니다. 일반적으로 하네스는 각 샤드의 실행 시간을 조정하여 전체 완료 시간(마지막 샤드가 완료되는 시점)을 최소화하려고 하지만 일부 테스트의 특성으로 인해 충분한 검사가 이루어지지 않고 모듈 소유자가 일부 동작을 조정해야 하는 경우도 있습니다.
샤딩 가능 여부
모듈 (AndroidTest.xml)에 <option name="not-shardable" value="true" /> 태그를 지정하여 샤딩하면 안 된다는 내용을 하네스에 알릴 수 있습니다.
일반적인 모듈에서는 하네스가 모듈을 샤딩하는 것이 좋습니다(기본 동작). 하지만 경우에 따라서는 이러한 동작을 재정의해야 할 수도 있습니다.
모듈을 샤딩하면 준비되는 기기 (APK 설치, 파일 푸시 등)가 관련 기기당 한 번씩 실행될 수 있습니다. 모듈 설정 시간이 길고 비용이 높고 테스트 런타임 대비 복제할 만한 가치가 없는 경우에는 모듈에 샤딩이 불가하다는 태그를 지정해야 합니다.
모듈을 샤딩하면 모든 테스트 사례가 다른 기기에서 개별적으로 실행될 수 있습니다. 이는 첫 번째 요점과 관련이 있습니다. 테스트 수가 적으면 일부 샤드에서 한 개의 테스트만 실행되거나 아예 테스트가 실행되지 않을 수도 있습니다. 이 경우에는 모든 준비 단계에 높은 비용이 발생하게 됩니다. 예를 들어 단일 테스트 사례에는 APK를 설치할 만한 가치가 없는 것이 일반적입니다.
계측 테스트: 최대 샤드 수?
AndroidJUnitTest를 통해 실행되는 계측 테스트는 실제로 APK를 설치하고 실행할 때까지 몇 개의 테스트가 계측의 일부인지 하네스에 노출시키지 않습니다. 이러한 작업에는 높은 비용이 발생하며, 도구 모음의 모든 모듈 부분에 대해 샤딩 시간에 실행할 수 없습니다.
하네스는 계측 테스트에 대한 과도한 샤딩을 수행할 수 있으며 이 경우 샤드가 빌 수 있습니다. 6개의 샤드에서 5개의 테스트로 계측 테스트를 샤딩하면 테스트가 1개인 5개의 샤드와 테스트가 없는 1개의 샤드로 결과로 주어집니다. 이러한 각 샤드에는 값비싼 APK 설치가 요구됩니다.
따라서 계측 테스트 APK의 테스트 수가 적은 경우에는 모듈에 <option name="not-shardable" value="true" />로 태그를 지정하면 하네스가 해당 모듈을 샤딩할 만한 가치가 없음을 인식하도록 만들 수 있습니다.
AndroidJUnitTest 실행기에는 <option name="ajur-max-shard" value="5" />로 샤딩 가능한 최대 샤드 수를 지정할 수 있는 특수 옵션이 있습니다.
이 옵션을 사용하면 호출 수준에서 요청된 샤드 수와 상관없이 계측을 샤딩할 수 있는 최대 횟수를 지정할 수 있습니다. 기본적으로 계측은 호출에 요청된 샤드 수로 샤딩됩니다.
예를 들어 계측 테스트 APK에 2개의 테스트 사례만 포함되었지만 계속해서 이를 샤딩하고 싶다면 ajur-max-shard 값을 2로 설정하여 빈 샤드가 생성되지 않도록 할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Configure sharding\n\nThis page describes what is possible to tune for a suite module\n(`AndroidTest.xml`) via sharding and get the best speed performance during\ncontinuous execution in the lab. We will attempt to describe the options in a\ngeneric manner with the rationale for using each.\n\nWhen running continuously a suite in the lab, the suite is usually sharded\nacross several devices to reduce the overall completion time. The harness\ntypically attempts to balance the execution time of each shard to minimize the\noverall completion time (when the last shard finishes); but due to the nature of\nsome tests, we do not always have enough introspection and need the module owner\nto tune some behavior.\n\nShardable or not shardable?\n---------------------------\n\nIt is possible to tag a module (`AndroidTest.xml`) with\n`\u003coption name=\"not-shardable\" value=\"true\" /\u003e` to notify the harness that it\nshould not be sharded.\n\nIn a typical module, letting the harness shard your module\n(the default behavior) is the right thing to do. But in some cases, you might\nwant to override that behavior:\n\n- When the setup of your module is expensive:\n\nSharding a module results in the preparation (install APK, push file, etc.)\npossibly run once per device involved. If your module setup is long and\nexpensive and not worth being replicated compared to the test's runtime, you\nshould tag your module as not-shardable.\n\n- When the number of tests in your module is low:\n\nSharding a module results in all the test cases possibly executing independently\non different devices. This relates to the first point; if your number of tests\nis low, you might end up with a single test or no test in some shards, which\nwould make any preparation step quite expensive. Installing an APK for a single\ntest case is usually not worth it, for example.\n\nInstrumentation tests: Max number of shards?\n--------------------------------------------\n\nAn instrumentation test running through [AndroidJUnitTest](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/test_framework/com/android/tradefed/testtype/AndroidJUnitTest.java)\ndoes not expose to the harness how many tests are part of the instrumentation\nuntil we actually install and run the APK. These operations are costly and\ncannot be executed at sharding time for all the modules part of the suite.\n\nThe harness might over-shard the instrumentation test and end up with some\nempty shards; sharding an instrumentation test with five tests in six shards\nresults in five shards with one test and one shard with no tests. Each of these\nshards would require a costly APK installation.\n\nSo when the number of tests in the instrumentation test APK is low, tagging the\nmodule with `\u003coption name=\"not-shardable\" value=\"true\" /\u003e` would allow the\nharness to know sharding that module is not worth it.\n\nThe `AndroidJUnitTest` runner has a special option allowing it to specify the\nmax number of shards it is allowed to shard into:\n`\u003coption name=\"ajur-max-shard\" value=\"5\" /\u003e`.\n\nThis allows you to specify a maximum number of times the instrumentation can be\nsharded regardless of the number of shards requested at the invocation level. By\ndefault, the instrumentation will be sharded into the number of shards requested\nfor the invocation.\n\nFor example, if your instrumentation test APK contains only two test cases but\nyou still want to shard it, having a `ajur-max-shard` value of `2` would ensure\nyou are not creating empty shards."]]
