แก้ไขข้อบกพร่องของโปรไฟล์พื้นฐาน

เอกสารนี้มีแนวทางปฏิบัติแนะนำและขั้นตอนการแก้ปัญหาที่จะช่วยวิเคราะห์ ปัญหาและตรวจสอบว่าโปรไฟล์พื้นฐานทำงานได้อย่างถูกต้องเพื่อให้ได้รับประโยชน์สูงสุด

ปัญหาเกี่ยวกับการสร้าง

หากคุณคัดลอกตัวอย่าง Baseline Profile ในแอปตัวอย่าง Now in Android คุณอาจพบว่าการทดสอบล้มเหลวระหว่างงาน Baseline Profile โดยระบุว่าไม่สามารถเรียกใช้การทดสอบในโปรแกรมจำลองได้

./gradlew assembleDemoRelease
Starting a Gradle Daemon (subsequent builds will be faster)
Calculating task graph as no configuration cache is available for tasks: assembleDemoRelease
Type-safe project accessors is an incubating feature.

> Task :benchmarks:pixel6Api33DemoNonMinifiedReleaseAndroidTest
Starting 14 tests on pixel6Api33

com.google.samples.apps.nowinandroid.foryou.ScrollForYouFeedBenchmark > scrollFeedCompilationNone[pixel6Api33] FAILED
        java.lang.AssertionError: ERRORS (not suppressed): EMULATOR
        WARNINGS (suppressed):
        ...

ความล้มเหลวเกิดขึ้นเนื่องจาก Now in Android ใช้อุปกรณ์ที่ Gradle จัดการสำหรับการสร้าง Baseline Profile การทดสอบล้มเหลวเป็นเรื่องปกติ เนื่องจากโดยทั่วไปแล้วคุณไม่ควรเรียกใช้การเปรียบเทียบประสิทธิภาพในโปรแกรมจำลอง อย่างไรก็ตาม เนื่องจากคุณไม่ได้ รวบรวมเมตริกประสิทธิภาพเมื่อสร้างโปรไฟล์พื้นฐาน คุณจึงเรียกใช้ การรวบรวมโปรไฟล์พื้นฐานในโปรแกรมจำลองเพื่อความสะดวกได้ หากต้องการใช้ Baseline Profiles กับโปรแกรมจำลอง ให้ทำการบิลด์และติดตั้งจาก บรรทัดคำสั่ง แล้วตั้งค่าอาร์กิวเมนต์เพื่อเปิดใช้กฎ Baseline Profiles ดังนี้

installDemoRelease -Pandroid.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile

หรือคุณจะสร้างการกำหนดค่าการเรียกใช้ที่กำหนดเองใน Android Studio เพื่อ เปิดใช้ Baseline Profile ในโปรแกรมจำลองได้โดยเลือก เรียกใช้ > แก้ไขการกำหนดค่า

เพิ่มการกำหนดค่าการเรียกใช้ที่กำหนดเองเพื่อสร้างโปรไฟล์พื้นฐานใน Now in Android
รูปที่ 1 เพิ่มการกำหนดค่าการเรียกใช้ที่กำหนดเองเพื่อสร้างโปรไฟล์ Baseline ใน Now in Android

ยืนยันการติดตั้งและการใช้โปรไฟล์

หากต้องการตรวจสอบว่า APK หรือ Android App Bundle (AAB) ที่คุณกำลังตรวจสอบมาจาก ตัวแปรบิลด์ที่มี Baseline Profile ให้ทำดังนี้

  1. ใน Android Studio ให้เลือกบิวด์ > วิเคราะห์ APK
  2. เปิด AAB หรือ APK

  3. ยืนยันว่ามีไฟล์ baseline.prof ดังนี้

    • หากตรวจสอบ AAB โปรไฟล์จะอยู่ที่ /BUNDLE-METADATA/com.android.tools.build.profiles/baseline.prof

    • หากตรวจสอบ APK โปรไฟล์จะอยู่ที่ /assets/dexopt/baseline.prof

      การมีอยู่ของไฟล์นี้เป็นสัญญาณแรกของการกำหนดค่าบิลด์ที่ถูกต้อง หากไม่มี แสดงว่า Android Runtime จะไม่ได้รับ วิธีการคอมไพล์ล่วงหน้าใดๆ ในเวลาที่ติดตั้ง

      ตรวจสอบ Baseline Profile โดยใช้ตัววิเคราะห์ APK ใน Android Studio
      รูปที่ 2 ตรวจสอบ Baseline Profile โดยใช้ตัววิเคราะห์ APK ใน Android Studio

ต้องคอมไพล์ Baseline Profile ในอุปกรณ์ที่เรียกใช้แอป เมื่อคุณ ติดตั้งบิลด์ที่แก้ไขข้อบกพร่องไม่ได้โดยใช้ Android Studio หรือเครื่องมือบรรทัดคำสั่ง Gradle Wrapper การคอมไพล์ในอุปกรณ์จะเกิดขึ้นโดยอัตโนมัติ หากคุณติดตั้ง แอปจาก Google Play Store ระบบจะคอมไพล์ Baseline Profile ระหว่าง การอัปเดตอุปกรณ์ในเบื้องหลังแทนที่จะเป็นตอนติดตั้ง เมื่อติดตั้งแอป โดยใช้เครื่องมืออื่นๆ ไลบรารี Jetpack ProfileInstaller จะมีหน้าที่ ในการจัดคิวโปรไฟล์สำหรับการคอมไพล์ในระหว่างกระบวนการเพิ่มประสิทธิภาพ DEX ในเบื้องหลังครั้งถัดไป

ในกรณีดังกล่าว หากต้องการให้มั่นใจว่ามีการใช้ Baseline Profile คุณอาจต้องบังคับให้คอมไพล์ Baseline Profile ProfileVerifier ช่วยให้คุณค้นหาสถานะการติดตั้งโปรไฟล์และการคอมไพล์ได้ ดังตัวอย่างต่อไปนี้

Kotlin

private const val TAG = "MainActivity"

class MainActivity : ComponentActivity() {
  ...
  override fun onResume() {
    super.onResume()
    lifecycleScope.launch {
      logCompilationStatus()
    }
  }

  private suspend fun logCompilationStatus() {
     withContext(Dispatchers.IO) {
        val status = ProfileVerifier.getCompilationStatusAsync().await()
        when (status.profileInstallResultCode) {
            RESULT_CODE_NO_PROFILE ->
                Log.d(TAG, "ProfileInstaller: Baseline Profile not found")
            RESULT_CODE_COMPILED_WITH_PROFILE ->
                Log.d(TAG, "ProfileInstaller: Compiled with profile")
            RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION ->
                Log.d(TAG, "ProfileInstaller: Enqueued for compilation")
            RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING ->
                Log.d(TAG, "ProfileInstaller: App was installed through Play store")
            RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST ->
                Log.d(TAG, "ProfileInstaller: PackageName not found")
            RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ ->
                Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read")
            RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE ->
                Log.d(TAG, "ProfileInstaller: Can't write cache file")
            RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION ->
                Log.d(TAG, "ProfileInstaller: Enqueued for compilation")
            else ->
                Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued")
        }
    }
}

Java

public class MainActivity extends ComponentActivity {

    private static final String TAG = "MainActivity";

    @Override
    protected void onResume() {
        super.onResume();

        logCompilationStatus();
    }

    private void logCompilationStatus() {
         ListeningExecutorService service = MoreExecutors.listeningDecorator(
                Executors.newSingleThreadExecutor());
        ListenableFuture<ProfileVerifier.CompilationStatus> future =
                ProfileVerifier.getCompilationStatusAsync();
        Futures.addCallback(future, new FutureCallback<>() {
            @Override
            public void onSuccess(CompilationStatus result) {
                int resultCode = result.getProfileInstallResultCode();
                if (resultCode == RESULT_CODE_NO_PROFILE) {
                    Log.d(TAG, "ProfileInstaller: Baseline Profile not found");
                } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE) {
                    Log.d(TAG, "ProfileInstaller: Compiled with profile");
                } else if (resultCode == RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION) {
                    Log.d(TAG, "ProfileInstaller: Enqueued for compilation");
                } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING) {
                    Log.d(TAG, "ProfileInstaller: App was installed through Play store");
                } else if (resultCode == RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST) {
                    Log.d(TAG, "ProfileInstaller: PackageName not found");
                } else if (resultCode == RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ) {
                    Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read");
                } else if (resultCode
                        == RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE) {
                    Log.d(TAG, "ProfileInstaller: Can't write cache file");
                } else if (resultCode == RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION) {
                    Log.d(TAG, "ProfileInstaller: Enqueued for compilation");
                } else {
                    Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued");
                }
            }

            @Override
            public void onFailure(Throwable t) {
                Log.d(TAG,
                        "ProfileInstaller: Error getting installation status: " + t.getMessage());
            }
        }, service);
    }
}

รหัสผลลัพธ์ต่อไปนี้จะให้คำแนะนำเกี่ยวกับสาเหตุของปัญหาบางอย่าง

RESULT_CODE_COMPILED_WITH_PROFILE
ระบบจะติดตั้ง คอมไพล์ และใช้โปรไฟล์ทุกครั้งที่เรียกใช้แอป นี่คือผลลัพธ์ที่คุณต้องการเห็น
RESULT_CODE_ERROR_NO_PROFILE_EMBEDDED
ไม่พบโปรไฟล์ใน APK ที่กำลังเรียกใช้ ตรวจสอบว่าคุณใช้ตัวแปรบิลด์ ที่มี Baseline Profile หากเห็นข้อผิดพลาดนี้ และ APK มีโปรไฟล์
RESULT_CODE_NO_PROFILE
ไม่มีการติดตั้งโปรไฟล์สำหรับแอปนี้เมื่อติดตั้งแอปผ่าน App Store หรือ Package Manager สาเหตุหลักที่ทำให้เกิดรหัสข้อผิดพลาดนี้คือโปรไฟล์ โปรแกรมติดตั้งไม่ได้ทำงานเนื่องจากProfileInstallerInitializerถูกปิดใช้ โปรดทราบว่าเมื่อมีการรายงานข้อผิดพลาดนี้ ระบบจะยังพบโปรไฟล์ที่ฝังอยู่ใน APK ของแอปพลิเคชัน เมื่อไม่พบโปรไฟล์ที่ฝังไว้ รหัสข้อผิดพลาดที่แสดงคือ RESULT_CODE_ERROR_NO_PROFILE_EMBEDDED
RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION
พบโปรไฟล์ใน APK หรือ AAB และจัดคิวเพื่อคอมไพล์ เมื่อ ProfileInstaller ติดตั้งโปรไฟล์ ระบบจะจัดคิวโปรไฟล์ดังกล่าวเพื่อคอมไพล์ในครั้งถัดไปที่ระบบเรียกใช้การเพิ่มประสิทธิภาพ DEX ในเบื้องหลัง โปรไฟล์จะยังไม่ ใช้งานจนกว่าการคอมไพล์จะเสร็จสมบูรณ์ อย่าพยายามเปรียบเทียบประสิทธิภาพโปรไฟล์พื้นฐานจนกว่าการคอมไพล์จะเสร็จสมบูรณ์ คุณอาจต้องบังคับการคอมไพล์ โปรไฟล์พื้นฐาน ข้อผิดพลาดนี้จะไม่เกิดขึ้นเมื่อติดตั้งแอปจาก Play Store หรือตัวจัดการแพ็กเกจในอุปกรณ์ที่ใช้ Android 9 (API 28) ขึ้นไป เนื่องจากระบบจะทำการคอมไพล์ระหว่างการติดตั้ง
RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING
มีการติดตั้งโปรไฟล์ที่ไม่ตรงกันและคอมไพล์แอปด้วยโปรไฟล์ดังกล่าว ซึ่งเป็นผลลัพธ์ของการติดตั้งผ่าน Google Play Store หรือ Package Manager โปรดทราบว่าผลลัพธ์นี้แตกต่างจาก RESULT_CODE_COMPILED_WITH_PROFILE เนื่องจาก โปรไฟล์ที่ไม่ตรงกันจะรวบรวมเฉพาะเมธอดที่ยังคงแชร์ ระหว่างโปรไฟล์กับแอปเท่านั้น โปรไฟล์จึงมีขนาดเล็กกว่า ที่คาดไว้ และจะรวบรวมเมธอดน้อยกว่าที่รวมอยู่ในโปรไฟล์พื้นฐาน
RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE
ProfileVerifier เขียนไฟล์แคชผลการยืนยันไม่ได้ ปัญหานี้อาจเกิดขึ้นเนื่องจากสิทธิ์ของโฟลเดอร์แอปมีปัญหาหรืออุปกรณ์มีพื้นที่ว่างในดิสก์ไม่เพียงพอ
RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION
ProfileVerifieris running on an unsupported API version of Android. ProfileVerifier รองรับเฉพาะ Android 9 (API ระดับ 28) ขึ้นไป
RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST
ระบบจะส่ง PackageManager.NameNotFoundException เมื่อค้นหา PackageManager สำหรับแพ็กเกจแอป กรณีนี้เกิดขึ้นได้น้อยมาก ลอง ถอนการติดตั้งแอปแล้วติดตั้งทุกอย่างอีกครั้ง
RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ
มีไฟล์แคชผลการยืนยันก่อนหน้านี้ แต่อ่านไม่ได้ กรณีนี้ ไม่ค่อยเกิดขึ้น ลองถอนการติดตั้งแอปแล้วติดตั้งทุกอย่างอีกครั้ง

ใช้ ProfileVerifier ในเวอร์ชันที่ใช้งานจริง

ในเวอร์ชันที่ใช้งานจริง คุณสามารถใช้ ProfileVerifier ร่วมกับ ไลบรารีการรายงานข้อมูลวิเคราะห์ เช่น Google Analytics สำหรับ Firebase เพื่อ สร้างเหตุการณ์วิเคราะห์ที่ระบุสถานะโปรไฟล์ เช่น การแจ้งเตือนนี้จะช่วยให้คุณทราบอย่างรวดเร็วหากมีการเปิดตัวแอปเวอร์ชันใหม่ที่ไม่มี Baseline Profiles

บังคับให้คอมไพล์โปรไฟล์พื้นฐาน

หากสถานะการคอมไพล์ของโปรไฟล์พื้นฐานเป็น RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION คุณสามารถบังคับให้คอมไพล์ทันที ได้โดยใช้ adb

adb shell cmd package compile -r bg-dexopt PACKAGE_NAME

ตรวจสอบสถานะการคอมไพล์โปรไฟล์พื้นฐานโดยไม่ต้องใช้ ProfileVerifier

หากไม่ได้ใช้ ProfileVerifier คุณสามารถตรวจสอบสถานะการคอมไพล์ได้โดยใช้ adb แม้ว่าจะไม่ได้ข้อมูลเชิงลึกเท่ากับ ProfileVerifier ก็ตาม

adb shell dumpsys package dexopt | grep -A 2 PACKAGE_NAME

การใช้ adb จะทำให้ได้ผลลัพธ์คล้ายกับตัวอย่างต่อไปนี้

  [com.google.samples.apps.nowinandroid.demo]
    path: /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/base.apk
      arm64: [status=speed-profile] [reason=bg-dexopt] [primary-abi]
        [location is /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/oat/arm64/base.odex]

ค่าสถานะจะระบุสถานะการคอมไพล์โปรไฟล์และเป็นค่าใดค่าหนึ่งต่อไปนี้

สถานะการคอมไพล์ ความหมาย
speed‑profile มีโปรไฟล์ที่คอมไพล์แล้วและกำลังใช้งานอยู่
verify ไม่มีโปรไฟล์ที่คอมไพล์แล้ว

สถานะ verify ไม่ได้หมายความว่า APK หรือ AAB ไม่มีโปรไฟล์ เนื่องจากอาจอยู่ในคิวสำหรับการคอมไพล์โดยงานการเพิ่มประสิทธิภาพ DEX ในเบื้องหลังครั้งถัดไป

ค่าเหตุผลระบุสิ่งที่ทริกเกอร์การรวบรวมโปรไฟล์และเป็นค่าใดค่าหนึ่งต่อไปนี้

เหตุผล ความหมาย
install‑dm ระบบจะรวบรวม Baseline Profile ด้วยตนเองหรือโดย Google Play เมื่อติดตั้งแอป
bg‑dexopt ระบบได้รวบรวมโปรไฟล์ขณะที่อุปกรณ์ไม่ได้ใช้งาน ซึ่งอาจเป็น Baseline Profile หรือโปรไฟล์ที่รวบรวมระหว่างการใช้งานแอป
cmdline การคอมไพล์ทริกเกอร์โดยใช้ adb ซึ่งอาจเป็น Baseline Profile หรือโปรไฟล์ที่รวบรวมระหว่างการใช้งานแอป

ยืนยันใบสมัครโปรไฟล์สตาร์ทอัพกับ DEX และ r8.json

R8 ใช้กฎโปรไฟล์การเริ่มต้นในเวลาสร้างบิลด์เพื่อเพิ่มประสิทธิภาพเลย์เอาต์ของ คลาสในไฟล์ DEX การเพิ่มประสิทธิภาพในเวลาบิลด์นี้แตกต่างจากวิธีใช้ Baseline Profiles (baseline.prof) เนื่องจากมีการแพ็กเกจไว้ภายใน APK หรือ AAB เพื่อให้ ART ทำการคอมไพล์ในอุปกรณ์ได้ เนื่องจากระบบจะใช้กฎของ Startup Profile ในระหว่างกระบวนการบิลด์เอง จึงไม่มีไฟล์ startup.prof แยกต่างหากภายใน APK หรือ AAB ให้ตรวจสอบ ผลของ Startup Profiles จะปรากฏในเลย์เอาต์ไฟล์ DEX แทน

ตรวจสอบการจัดเรียง DEX ด้วย r8.json (แนะนำสำหรับ AGP 8.8 ขึ้นไป)

สำหรับโปรเจ็กต์ที่ใช้ปลั๊กอิน Android Gradle (AGP) 8.8 ขึ้นไป คุณสามารถยืนยัน ว่ามีการใช้โปรไฟล์การเริ่มต้นหรือไม่โดยตรวจสอบไฟล์ r8.json ที่สร้างขึ้น ไฟล์นี้จะรวมอยู่ใน AAB

  1. เปิดที่เก็บ AAB แล้วค้นหาไฟล์ r8.json
  2. ค้นหาอาร์เรย์ dexFiles ในไฟล์ ซึ่งแสดงรายการไฟล์ DEX ที่สร้างขึ้น

  3. มองหาออบเจ็กต์ dexFiles ที่มีคู่คีย์-ค่า "startup": true ซึ่งระบุอย่างชัดเจนว่ามีการใช้กฎของโปรไฟล์การเริ่มต้น เพื่อเพิ่มประสิทธิภาพเลย์เอาต์ของไฟล์ DEX นั้นๆ

    "dexFiles": [
 {
   "checksum": "...",
   "startup": true // This flag confirms profile application to this DEX file
 },
 // ... other DEX files
]

ตรวจสอบการจัดเรียง DEX สำหรับ AGP ทุกเวอร์ชัน

หากใช้ AGP เวอร์ชันต่ำกว่า 8.8 การตรวจสอบไฟล์ DEX เป็นวิธีหลักในการยืนยันว่าโปรไฟล์การเริ่มต้นทำงานได้รับการใช้ถูกต้องแล้ว นอกจากนี้ คุณยังใช้วิธีนี้ได้หากใช้ AGP 8.8 ขึ้นไปและต้องการตรวจสอบเลย์เอาต์ DEX ด้วยตนเอง เช่น หากคุณไม่เห็นการปรับปรุงประสิทธิภาพตามที่คาดไว้ หากต้องการตรวจสอบข้อตกลง DEX ให้ทำดังนี้

  1. เปิด AAB หรือ APK โดยใช้บิวด์ > วิเคราะห์ APK ใน Android Studio
  2. ไปที่ไฟล์ DEX แรก เช่น classes.dex
  3. ตรวจสอบเนื้อหาของไฟล์ DEX นี้ คุณควรตรวจสอบได้ว่าคลาสและเมธอดที่สำคัญซึ่งกำหนดไว้ในไฟล์ Startup Profile (startup-prof.txt) อยู่ในไฟล์ DEX หลักนี้ การสมัครที่ประสบความสำเร็จหมายความว่าระบบจะจัดลำดับความสำคัญของ คอมโพเนนต์ที่สำคัญต่อการเริ่มต้นระบบเหล่านี้เพื่อให้โหลดได้เร็วขึ้น

ปัญหาด้านประสิทธิภาพ

ส่วนนี้จะแสดงแนวทางปฏิบัติแนะนำบางส่วนในการกำหนดและเปรียบเทียบ โปรไฟล์พื้นฐานอย่างถูกต้องเพื่อให้ได้รับประโยชน์สูงสุด

เปรียบเทียบเมตริกการเริ่มต้นอย่างถูกต้อง

โปรไฟล์พื้นฐานจะมีประสิทธิภาพมากขึ้นหากเมตริกการเริ่มต้นใช้งานของคุณได้รับการกำหนดไว้อย่างชัดเจน เมตริกหลัก 2 รายการคือเวลาที่ใช้ในการแสดงผลครั้งแรก (TTID) และ เวลาที่ใช้ในการแสดงผลครบถ้วน (TTFD)

TTID คือเวลาที่แอปวาดเฟรมแรก คุณควรทำให้ระยะเวลานี้สั้นที่สุด เนื่องจากการแสดงสิ่งใดก็ตามจะแสดงให้ผู้ใช้เห็นว่าแอปกำลังทำงานอยู่ คุณยังแสดงตัวบ่งชี้ความคืบหน้าที่ไม่แน่นอนเพื่อแสดงว่าแอป ตอบสนองได้ด้วย

TTFD คือเวลาที่โต้ตอบกับแอปได้จริง คุณควรทำให้ระยะเวลานี้สั้นที่สุดเพื่อไม่ให้ผู้ใช้รู้สึกหงุดหงิด หากส่งสัญญาณ TTFD อย่างถูกต้อง คุณจะบอกระบบว่าโค้ดที่ทำงานระหว่างทางไป TTFD เป็นส่วนหนึ่งของการเริ่มต้นแอป ระบบจึงมีแนวโน้มที่จะวางโค้ดนี้ไว้ในโปรไฟล์

พยายามให้ทั้ง TTID และ TTFD ต่ำที่สุดเพื่อให้แอปตอบสนองได้ดี

ระบบสามารถตรวจหา TTID แสดงใน Logcat และรายงานเป็นส่วนหนึ่ง ของการเปรียบเทียบประสิทธิภาพการเริ่มต้น อย่างไรก็ตาม ระบบไม่สามารถกำหนด TTFD ได้ และเป็นความรับผิดชอบของแอปที่จะต้องรายงานเมื่อแอปเข้าสู่สถานะแบบอินเทอร์แอกทีฟที่วาดเสร็จสมบูรณ์แล้ว โดยทำได้ด้วยการเรียกใช้ reportFullyDrawn() หรือ ReportDrawn หากใช้ Jetpack Compose หากมีงานเบื้องหลังหลายรายการที่ต้องทำให้เสร็จก่อนจึงจะถือว่าแอปวาดภาพเสร็จสมบูรณ์ คุณสามารถใช้ FullyDrawnReporter ได้ตามที่อธิบายไว้ในปรับปรุง ความแม่นยำของเวลาเริ่มต้น

โปรไฟล์ไลบรารีและโปรไฟล์ที่กำหนดเอง

เมื่อเปรียบเทียบผลกระทบของโปรไฟล์ อาจเป็นเรื่องยากที่จะแยกประโยชน์ของโปรไฟล์แอปออกจากโปรไฟล์ที่ไลบรารีมีส่วนร่วม เช่น ไลบรารี Jetpack เมื่อคุณสร้าง APK ปลั๊กอิน Android Gradle จะเพิ่มโปรไฟล์ใดๆ ในทรัพยากร Dependency ของไลบรารี รวมถึงโปรไฟล์ที่กำหนดเอง ซึ่งเหมาะ สำหรับการเพิ่มประสิทธิภาพโดยรวม และขอแนะนำให้ใช้สำหรับการสร้างรุ่นที่เผยแพร่ แต่จะทำให้วัดได้ยากว่าประสิทธิภาพที่เพิ่มขึ้นมาจากโปรไฟล์ที่กำหนดเองมากน้อยเพียงใด

วิธีที่รวดเร็วในการดูการเพิ่มประสิทธิภาพเพิ่มเติมที่โปรไฟล์ที่กำหนดเองมอบให้ด้วยตนเองคือการนำโปรไฟล์ออกแล้วเรียกใช้การเปรียบเทียบ จากนั้นให้เปลี่ยนแบตเตอรี่ใหม่แล้วเรียกใช้ การทดสอบเปรียบเทียบอีกครั้ง การเปรียบเทียบทั้ง 2 อย่างจะแสดงการเพิ่มประสิทธิภาพที่ได้รับจาก โปรไฟล์ไลบรารีเพียงอย่างเดียว และโปรไฟล์ไลบรารีรวมกับโปรไฟล์ที่กำหนดเอง

วิธีเปรียบเทียบโปรไฟล์ที่ทำได้โดยอัตโนมัติคือการสร้างตัวแปรบิลด์ใหม่ที่มีเฉพาะโปรไฟล์ไลบรารีและไม่มีโปรไฟล์ที่กำหนดเอง เปรียบเทียบ เกณฑ์มาตรฐานจากตัวแปรนี้กับตัวแปรที่เผยแพร่ซึ่งมีทั้ง โปรไฟล์ไลบรารีและโปรไฟล์ที่กำหนดเอง ตัวอย่างต่อไปนี้แสดงวิธี ตั้งค่าตัวแปรที่มีเฉพาะโปรไฟล์ห้องสมุด เพิ่มตัวแปรใหม่ ชื่อ releaseWithoutCustomProfile ลงในโมดูลผู้ใช้โปรไฟล์ ซึ่งโดยปกติแล้วจะเป็นโมดูลแอปของคุณ ดังนี้

Kotlin

android {
  ...
  buildTypes {
    ...
    // Release build with only library profiles.
    create("releaseWithoutCustomProfile") {
      initWith(release)
    }
    ...
  }
  ...
}
...
dependencies {
  ...
  // Remove the baselineProfile dependency.
  // baselineProfile(project(":baselineprofile"))
}

baselineProfile {
  variants {
    create("release") {
      from(project(":baselineprofile"))
    }
  }
}

Groovy

android {
  ...
  buildTypes {
    ...
    // Release build with only library profiles.
    releaseWithoutCustomProfile {
      initWith(release)
    }
    ...
  }
  ...
}
...
dependencies {
  ...
  // Remove the baselineProfile dependency.
  // baselineProfile ':baselineprofile"'
}

baselineProfile {
  variants {
    release {
      from(project(":baselineprofile"))
    }
  }
}

ตัวอย่างโค้ดก่อนหน้านี้จะนำการขึ้นต่อกันของ baselineProfile ออกจากตัวแปรทั้งหมด และใช้เฉพาะกับตัวแปร release เท่านั้น การที่ระบบยังคงเพิ่มโปรไฟล์ไลบรารีเมื่อนำการอ้างอิงโมดูลโปรดิวเซอร์โปรไฟล์ออกอาจดูขัดแย้งกับสามัญสำนึก อย่างไรก็ตาม โมดูลนี้มีหน้าที่สร้างโปรไฟล์ที่กำหนดเองเท่านั้น ปลั๊กอิน Android Gradle ยังคงทำงานสำหรับทุกตัวแปร และมีหน้าที่รับผิดชอบในการรวมโปรไฟล์ไลบรารี

นอกจากนี้ คุณยังต้องเพิ่มตัวแปรใหม่ลงในโมดูลเครื่องมือสร้างโปรไฟล์ด้วย ใน ตัวอย่างนี้ โมดูลโปรดิวเซอร์มีชื่อว่า :baselineprofile

Kotlin

android {
  ...
    buildTypes {
      ...
      // Release build with only library profiles.
      create("releaseWithoutCustomProfile") {}
      ...
    }
  ...
}

Groovy

android {
  ...
    buildTypes {
      ...
      // Release build with only library profiles.
      releaseWithoutCustomProfile {}
      ...
    }
  ...
}

เมื่อเรียกใช้การเปรียบเทียบจาก Android Studio ให้เลือกตัวแปร releaseWithoutCustomProfile เพื่อวัดประสิทธิภาพด้วยโปรไฟล์ไลบรารีเท่านั้น หรือเลือกตัวแปร release เพื่อวัดประสิทธิภาพด้วยโปรไฟล์ไลบรารีและโปรไฟล์ที่กำหนดเอง

หลีกเลี่ยงการเริ่มต้นแอปที่ต้องใช้ I/O

หากแอปทำการเรียก I/O หรือการเรียกเครือข่ายจำนวนมากในระหว่างการเริ่มต้น อาจส่งผลเสียต่อทั้งเวลาเริ่มต้นของแอปและความแม่นยำของการเปรียบเทียบประสิทธิภาพการเริ่มต้น การเรียกที่ใช้ทรัพยากรมากเหล่านี้อาจใช้เวลาไม่แน่นอน ซึ่งอาจแตกต่างกันไปเมื่อเวลาผ่านไปและแม้แต่ระหว่างการทำซ้ำของการทดสอบประสิทธิภาพเดียวกัน โดยทั่วไปแล้ว การเรียก I/O จะดีกว่าการเรียกเครือข่าย เนื่องจากอย่างหลังอาจได้รับผลกระทบจากปัจจัยภายนอกอุปกรณ์และในตัวอุปกรณ์เอง หลีกเลี่ยง การเรียกเครือข่ายระหว่างการเริ่มต้น หากหลีกเลี่ยงการใช้คำใดคำหนึ่งไม่ได้ ให้ใช้ I/O

เราขอแนะนำให้คุณสร้างสถาปัตยกรรมแอปให้รองรับการเริ่มต้นแอปโดยไม่ต้องมีการเรียกเครือข่ายหรือ I/O แม้ว่าจะใช้เฉพาะเมื่อเปรียบเทียบประสิทธิภาพการเริ่มต้นก็ตาม ซึ่งจะช่วยให้มั่นใจได้ว่า ความแปรปรวนระหว่างการทำซ้ำต่างๆ ของการเปรียบเทียบจะต่ำที่สุด

หากแอปใช้ Hilt คุณจะระบุการใช้งานที่จำลองซึ่งมีขอบเขต I/O ได้เมื่อทำการเปรียบเทียบประสิทธิภาพใน Microbenchmark และ Hilt

ครอบคลุมเส้นทางของผู้ใช้ที่สำคัญทั้งหมด

คุณต้องครอบคลุมเส้นทางของผู้ใช้ที่สำคัญทั้งหมดอย่างถูกต้องในการสร้างโปรไฟล์พื้นฐาน เส้นทางของผู้ใช้ที่ไม่ได้ครอบคลุมจะไม่ได้รับการปรับปรุงโดยโปรไฟล์พื้นฐาน โปรไฟล์พื้นฐานที่มีประสิทธิภาพมากที่สุดประกอบด้วยเส้นทางการเริ่มต้นใช้งานทั่วไปทั้งหมด รวมถึงเส้นทางของผู้ใช้ในแอปที่ไวต่อประสิทธิภาพ เช่น รายการที่เลื่อนได้

การเปลี่ยนแปลงโปรไฟล์เวลาคอมไพล์ของการทดสอบ A/B

เนื่องจากโปรไฟล์ Startup และ Baseline เป็นการเพิ่มประสิทธิภาพในเวลาคอมไพล์ โดยทั่วไปแล้วระบบจึงไม่รองรับการ ทดสอบ A/B โดยตรงกับ APK ที่แตกต่างกันโดยใช้ Google Play Store สำหรับการเผยแพร่เวอร์ชันที่ใช้งานจริง หากต้องการประเมินผลกระทบในสภาพแวดล้อมที่คล้ายกับการใช้งานจริง ให้พิจารณาวิธีการต่อไปนี้

  • การเผยแพร่นอกรอบ: อัปโหลดการเผยแพร่นอกรอบไปยังผู้ใช้เพียงไม่กี่เปอร์เซ็นต์ ซึ่งรวมเฉพาะการเปลี่ยนแปลงโปรไฟล์ ซึ่งช่วยให้คุณรวบรวม เมตริกในโลกแห่งความเป็นจริงเกี่ยวกับความแตกต่างของประสิทธิภาพได้

  • การเปรียบเทียบในพื้นที่: เปรียบเทียบแอปในพื้นที่โดยมีและไม่มี การใช้โปรไฟล์ อย่างไรก็ตาม โปรดทราบว่าการเปรียบเทียบในเครื่องจะแสดงสถานการณ์กรณีที่ดีที่สุดสำหรับโปรไฟล์ เนื่องจากไม่ได้รวมผลกระทบของโปรไฟล์ในระบบคลาวด์จาก ART ที่มีอยู่ในอุปกรณ์ที่ใช้งานจริง