自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
配置分片
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页介绍如何通过分片对套件模块 (AndroidTest.xml
) 进行调优,以及如何在实验室中连续执行期间获得最快速的性能。我们将尝试以一种通用的方式描述相应选项,并说明如何理性地使用每个选项。
在实验室中连续运行套件时,套件通常会在多个设备之间进行分片,以缩短总体完成时间。自动化测试框架通常会尝试平衡每个分片的执行时间,以最大限度地缩短总体完成时间(当最后一个分片完成时)。但由于某些测试的性质,我们的自检机制并不总是能够达到足够好的效果,因此还需要模块所有者对一些行为进行调优。
可分片还是不可分片?
可以使用 <option name="not-shardable" value="true" />
标记模块 (AndroidTest.xml
),以通知自动化测试框架不应将该模块分片。
在典型模块中,让自动化测试框架将模块分片(默认行为)是正确的做法。但在某些情况下,您可能需要覆盖此行为:
将模块分片会导致可能在所涉及的每个设备上运行一次准备步骤(安装 APK、推送文件等)。如果模块设置耗时很长且成本高昂,并且与测试的运行时相比不值得复制,那么您应将模块标记为不可分片。
将模块分片会导致所有测试用例可能在不同的设备上独立执行。这与第一点有关;如果测试数很少,那么最终可能某些分片中只有一个测试或根本没有测试,这样会使所有准备步骤成本很高。例如,为单个测试用例安装 APK 通常是不值得的。
插桩测试:最大分片数是多少?
在我们实际安装和运行 APK 之前,通过 AndroidJUnitTest 运行的插桩测试不会向自动化测试框架公开该插桩测试包含多少测试。这些操作成本高昂,并且无法在分片时对属于套件的所有模块执行。
自动化测试框架可能会将插桩测试过度分片,最终生成一些空分片。如果将包含五个测试的插桩测试分成六个分片,那么结果是五个分片中各自有一个测试,一个分片中根本没有测试。其中每个分片都要求安装 APK,这需要高昂的成本。
因此,当插桩测试 APK 中的测试数很少时,使用 <option name="not-shardable" value="true" />
标记模块可允许自动化测试框架将该模块分片。
AndroidJUnitTest
运行程序有一个特殊选项,用于指定允许分成的最大分片数:<option name="ajur-max-shard" value="5" />
。
您可以利用此选项来指定插桩测试可分片的最大次数,而不管在调用级别请求的分片数是多少。默认情况下,插桩测试将分成调用请求的分片数。
例如,如果您的插桩测试 APK 仅包含两个测试用例,但您仍希望将其分片,那么应将 ajur-max-shard
值为 2
,这样可确保您不会创建空分片。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-03-26。"],[],[],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."]]