Android 11 이상에서는 시스템 서버 및 부팅 클래스 경로와 같은 다양한 시스템 수준 구성요소의 코드 정보를 캡슐화하는 부팅 이미지 프로필 생성을 지원합니다. Android 런타임(ART)은 이 정보를 사용하여 시스템 전체 최적화를 실행하며 이 중 일부는 Android 성능에 중요하고 네이티브가 아닌 모든 코드(시스템 또는 앱 수준)를 실행하는 데 영향을 미칩니다. 경우에 따라 부팅 이미지 프로필은 두 자릿수 비율로 실행 성능 및 메모리 소비에 영향을 미칠 수 있습니다.
부팅 프로필 정보 가져오기
부팅 이미지 프로필은 중요한 사용자 여정(CUJ) 중에 실행되는 앱의 프로필에서 파생됩니다. 특정 기기 구성에서는 ART가 앱에서 사용하는 부팅 클래스 경로 메서드와 클래스를 JIT 프로필의 일부로 캡처하고 앱 프로필(예: /data/misc/profiles/cur/0/com.android.chrome/primary.prof)에 이 정보를 기록하는데, 여기서 부팅 클래스 경로 Dalvik EXecutable(DEX) 파일로 색인이 생성됩니다(ART 프로필 형식 참고).
CUJ 중에 기록된 앱 프로필을 검토하여 부팅 클래스 경로의 어떤 부분이 가장 많이 사용되고 최적화에 가장 중요한지 확인합니다(예는 ART 프로필 형식 참고). 메서드나 클래스를 모두 포함하면 성능에 부정적인 영향을 미치므로 가장 흔히 사용되는 코드 경로에 집중합니다.
예를 들어 부팅 클래스 경로의 어떤 메서드가 하나의 앱에서 사용된다면, 이 메서드는 부팅 프로필에 포함되면 안 됩니다. 각 기기는 CUJ 선택과 테스트에서 생성된 데이터양에 기반하여 메서드/클래스 선택을 구성해야 합니다.
기기의 모든 개별 앱 프로필에서 부팅 클래스 경로 정보를 집계하려면 adb shell cmd package snapshot-profile android 명령어를 실행합니다. 수동으로 개별 프로필을 집계하지 않고도(원하면 집계할 수도 있음) 집계된 정보를 처리 및 메서드/클래스 선택의 기초로 사용할 수 있습니다.
ART 프로필은 최적화할 가치가 있는 메서드와 시작 시 사용되는 클래스에 관한 정보를 비롯하여 로드된 각 DEX 파일의 정보를 캡처합니다. 부팅 이미지 프로파일링이 사용 설정되면 ART에서는 프로필에 부팅 클래스 경로와 시스템 서버 JAR 파일도 포함하고 각 DEX 파일에 파일을 사용하는 패키지 이름으로 주석을 답니다.
core-oj.jar은 com.google.android.ext.services 및 com.android.systemui에서 사용됩니다. 각 항목에는 core-oj.jar에서 사용되는 패키지 두 개가 나열됩니다.
두 프로세스는 모두 DEX 색인 520이 있는 메서드를 사용하지만 systemui 프로세스만 DEX 색인 521이 있는 메서드를 사용합니다. 같은 근거가 다른 프로필 섹션(예: 시작 클래스)에도 적용됩니다.
데이터를 처리하는 동안 사용량을 바탕으로 메서드/클래스를 필터링하여 시스템 수준 프로세스(예: 시스템 서버 또는 systemui)나 흔히 사용되지 않을 수 있지만 여전히 중요한 메서드(예: 카메라 앱에서 사용되는 메서드)에 우선순위를 부여합니다.
프로필 형식은 내부적으로 각 메서드에 덤프 전용 형식에 표시되는 것보다 많은 여러 플래그(시작, 시작 후, 인기도, abi)로 주석을 답니다. 신호를 모두 사용하려면 사용 가능한 스크립트를 수정하세요.
권장사항
최상의 결과를 얻으려면 다음 가이드라인을 따르세요.
부팅 이미지 프로필을 생성하는 구성을 여러 테스트 기기에 배포하고 최종 부팅 이미지 프로필을 생성하기 전에 결과를 집계합니다. profman 도구는 여러 부팅 이미지 프로필 집계 및 선택을 지원하지만 동일한 부팅 이미지 버전(동일한 부팅 클래스 경로)에서만 작동합니다.
시스템 프로세스에서 사용하는 메서드/클래스에 선택 우선순위를 부여합니다. 이러한 메서드/클래스는 다른 앱에서 자주 사용되지 않지만 여전히 최적화에 중요한 코드를 사용할 수 있습니다.
단일 기기 실행의 데이터 모양은 실제 CUJ를 실행하는 테스트 기기와 비교할 때 매우 다릅니다. 테스트 기기가 많지 않은 경우 부팅 이미지 프로필 최적화가 프로덕션에서 제대로 작동할 것이라고 확신할 수 있도록 동일한 기기를 사용하여 여러 CUJ를 실행하세요. 이 시나리오는 아래에 설명되어 있습니다.
기기 구성
시스템 속성을 통해 부팅 프로필 구성을 사용 설정하려면 다음 메서드 중 하나를 사용하세요.
데이터를 사용하여 사용 가능한 선택 기준점 플래그를 사용하는 profman 명령어를 조정합니다.
--method-threshold
--class-threshold
--clean-class-threshold
--preloaded-class-threshold
--upgrade-startup-to-hot
--special-package
전체 목록을 보려면 profman 도움말 페이지나 소스 코드를 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-08-07(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"]],["최종 업데이트: 2024-08-07(UTC)"],[],[],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."]]
