[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Boot image profiles\n\nAndroid 11 or higher supports generating boot image profiles, which encapsulate\ninformation about the code of various system-level components such as system\nserver and boot classpath. Android Runtime (ART) uses this information to\nperform system-wide optimizations, some of which are critical to Android's\nperformance and impact the execution of all nonnative code (system or app\nlevel). In some cases, boot image profiles can impact execution performance and\nmemory consumption by double digit percentages.\n| **Note:** This page doesn't detail specific optimizations (such as profile guided optimizations, Zygote preloading, and `.art` images) or how profiles hook into the build system.\n\nGet boot profile information\n----------------------------\n\nBoot image profiles are derived from the profiles of apps executed during\ncritical user journeys (CUJs). In a specific device configuration, ART captures\n(as part of the JIT profiles) the boot classpath methods and classes used by\napps, then records that information in the app profile (for example,\n`/data/misc/profiles/cur/0/com.android.chrome/primary.prof`), where it's\nindexed by the boot classpath Dalvik EXecutable (DEX) file (see [ART profile\nformat](#art-profile-format)).\n| **Key Point:** Boot image profiles are built into the system image and can't be updated outside OTAs, so it's critical to select a good set of profiles before creating an image.\n\nReview the app profiles recorded during CUJs to determine which part of the boot\nclasspath is most used and most important to optimize (for an example, see [ART\nprofile format](#art-profile-format)). Including all methods or classes\nnegatively affects performance, so focus on the most commonly used code paths.\nFor example, if a method from the boot classpath is used by a single app, it\nshouldn't be part of the boot profiles. Each device should configure the\nmethod/class selection based on the CUJ selection and the amount of data\nproduced by testing.\n\nTo aggregate boot classpath information from all individual app profiles on the\ndevice, run the `adb shell cmd package snapshot-profile android` command. You\ncan use the aggregated information as the basis for processing and method/class\nselection without manually aggregating individual profiles (although you can do\nthat if desired).\n\n**Figure 1.** Process for getting boot image profiles\n\n### Boot image profile data\n\nBoot image profiles include the following files and data.\n\n- Profile for the boot classpath\n ([`frameworks/base/config/boot-image-profile.txt`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/boot/boot-image-profile.txt).\n Determines which methods from the boot classpath get optimized and which class\n is included in the boot `.art` image.\n\n- List of [preloaded\n classes](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/config/preloaded-classes).\n Determines which classes are preloaded in Zygote.\n\n- Profile for the system server components\n ([`frameworks/base/services/art-profile`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/art-profile;l=1?q=art-profile&sq=)).\n Determines which methods from the system server get optimized/compiled, which\n class is included in the boot `.art` image, and how the corresponding DEX\n files are laid out.\n\n| **Note:** The system server contains multiple JAR files and each JAR gets its own profile (as opposed to the boot classpath, where all the data is in the same file). This page describes the profile for `services.jar`.\n\n### ART profile format\n\nThe ART profile captures information from each of the loaded DEX files,\nincluding information about methods worth optimizing and classes used during\nstartup. When boot image profiling is enabled, ART also includes the boot\nclasspath and system server JAR files in the profile and annotates each DEX file\nwith the name of the package that uses it.\n\nFor example, dump the raw boot image profile with the following command: \n\n adb shell profman --dump-only --profile-file=/data/misc/profman/android.prof\n\nThis produces output similar to: \n\n === Dex files ===\n === profile ===\n ProfileInfo [012]\n\n core-oj.jar:com.google.android.ext.services [index=0] [checksum=e4e3979a]\n hot methods: 520[], 611[] ...\n startup methods: ...\n classes: ...\n ...\n core-oj.jar:com.android.systemui [index=94] [checksum=e4e3979a]\n hot methods: 520[], 521[]...\n startup methods: ...\n classes: ...\n\nIn the above example:\n\n- `core-oj.jar` is used by `com.google.android.ext.services` and\n `com.android.systemui`. Each entry lists the two packages used from\n `core-oj.jar`.\n\n- Both processes use the method with DEX index 520, but only the `systemui`\n process uses the method with DEX index 521. The same rationale applies to the\n other profile sections (for example, the startup classes).\n\nDuring data processing, filter methods/classes based on usage, giving priority\nto system-level processes (for example, the system server or `systemui`) or to\nmethods that might not be commonly used but are still important (for example,\nmethods used by the camera app).\n\nThe profile format internally annotates each method with multiple flags\n(startup, post-startup, hotness, abi), which is more than is displayed in the\ndump-only format. To make use of all the signals, modify the available scripts.\n\n### Recommendations\n\nUse the following guidelines for best results.\n\n- Deploy the configuration for generating boot image profiles to several test\n devices and aggregate the results before generating the final boot image\n profile. The `profman` tool supports aggregating and selecting multiple boot\n image profiles, but it works only with the same version of the boot image\n (same boot classpath).\n\n- Give selection priority to the methods/classes that are used by system\n processes. These methods/classes might use code that isn't often used by other\n apps but that's still critical to optimize.\n\n- The data shape from a single device run looks very different compared to test\n devices that execute real-world CUJs. If you don't have a large fleet of test\n devices, use the same device to run several CUJs to increase the confidence\n that the boot image profile optimizations will work well in production (this\n scenario is described below).\n\nConfigure devices\n-----------------\n\nTo enable boot profile configuration through system properties, use one of the\nfollowing methods.\n\n- **Option 1:** Manually set up props (works up to reboot):\n\n adb root\n adb shell stop\n adb shell setprop dalvik.vm.profilebootclasspath true\n adb shell setprop dalvik.vm.profilesystemserver true\n adb shell start\n\n- **Option 2:** Use a `local.prop` (permanent effect until the file is deleted).\n To do so:\n\n 1. Create a `local.prop` file with the content:\n\n dalvik.vm.profilebootclasspath=true\n dalvik.vm.profilesystemserver=true\n\n 2. Run the following commands:\n\n adb push local.prop /data/\n adb shell chmod 0750 /data/local.prop\n adb reboot\n\n- **Option 3:** Use device configuration to set the following server-side\n properties:\n\n adb shell device_config put runtime_native_boot profilebootclasspath true\n adb shell device_config put runtime_native_boot profilesystemserver true\n\n| **Note:** The `art/tools/boot-image-profile-configure-device.sh` script includes the above steps.\n\nGenerate boot image profiles\n----------------------------\n\nUse the following instructions to generate a basic boot image profile using\ntesting on a single device.\n\n1. Set up the device.\n\n 1. Configure the device as described in [Configuring\n devices](#configuring-devices).\n\n 2. (Optional) It takes time for the new profile format to clean and replace the\n other profiles. To speed up profile collection, reset all profiles on the\n device.\n\n adb shell stop\n adb shell find \"/data/misc/profiles -name *.prof -exec truncate -s 0 {} \\;\"\n adb shell start\n\n 3. Run the CUJs on the device.\n\n2. Capture the profile using the following command:\n\n adb shell cmd package snapshot-profile android\n\n3. Extract the profile using the following command:\n\n adb pull /data/misc/profman/android.prof\n\n4. Navigate to the boot classpath JAR files using the following commands:\n\n m dist\n ls $ANDROID_PRODUCT_OUT/boot.zip\n\n5. Generate the boot image profile using the following `profman` command.\n\n profman --generate-boot-image-profile --profile-file=android.prof --out-profile-path=... --out-preloaded-classes-path=...\n\n6. Using data, tweak the `profman` command using the available selection\n threshold flags.\n\n - `--method-threshold`\n - `--class-threshold`\n - `--clean-class-threshold`\n - `--preloaded-class-threshold`\n - `--upgrade-startup-to-hot`\n - `--special-package`\n\n To view the full list, refer to the `profman` help page or source code.\n\n| **Note:** The `art/tools/boot-image-profile-generate.sh` script includes these steps."]]
