Android Academy · บทเรียน

โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน

เริ่มต้นแบบเย็นได้เร็วขึ้น

บทเรียน 4 จาก 413 ขั้นตอน

โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน เป็นบทเรียน Android Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Android Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Android Academy มีบทเรียนทั้งหมด 4 บทเรียน

ความประทับใจแรก: การเริ่มต้นแอป

เวลาเริ่มต้นแอปคือสิ่งแรกที่ผู้ใช้ทุกคนสัมผัส Google Play ยังแสดงการเริ่มต้นที่ช้าว่าเป็นปัญหาด้านคุณภาพอีกด้วย การเริ่มต้นแบบเย็นที่รวดเร็วทำให้แอปดูมีคุณภาพสูง ส่วนการเริ่มต้นที่ช้าทำให้ผู้ใช้เลิกใช้งาน

ในบทเรียนนี้ คุณจะได้เรียนรู้ประเภทการเริ่มต้นทั้งสามแบบ สาเหตุที่ทำให้การเริ่มต้นช้า และเครื่องมือสมัยใหม่อย่าง App Startup และ Baseline Profiles ที่ช่วยให้การเริ่มต้นแบบเย็นเร็วขึ้นอย่างมาก

การเริ่มต้นแบบเย็น อุ่น และร้อน

Android กำหนดสถานการณ์การเริ่มต้นไว้สามแบบ เรียงจากช้าที่สุดไปเร็วที่สุด:

  • การเริ่มต้นแบบเย็น: กระบวนการทำงานยังไม่มีอยู่ Android จะสร้างกระบวนการ เรียกใช้ Application แล้วจึงเปิดหน้าจอแรกของคุณ เป็นแบบที่ช้าที่สุดและควรให้ความสำคัญในการเพิ่มประสิทธิภาพมากที่สุด
  • การเริ่มต้นแบบอุ่น: กระบวนการยังทำงานอยู่ แต่ต้องสร้าง Activity ขึ้นใหม่
  • การเริ่มต้นแบบร้อน: Activity ยังคงอยู่ในหน่วยความจำ เพียงนำกลับมาแสดงด้านหน้าเท่านั้น จึงเกือบจะทันที

ความพยายามในการเพิ่มประสิทธิภาพจะมุ่งเน้นที่การเริ่มต้นแบบเย็น เพราะเป็นสิ่งที่ผู้ใช้ใหม่และผู้ใช้ที่กลับมาใช้งานพบมากที่สุด

การวัดเวลาเริ่มต้นแอป

คุณไม่สามารถปรับปรุงสิ่งที่ไม่ได้วัดได้ วิธีง่าย ๆ มีสองวิธี:

  • Logcat: ระบบจะบันทึกบรรทัด Displayed พร้อมเวลาจนถึงเฟรมแรก
  • การวัดประสิทธิภาพระดับมาโคร: StartupTimingMetric ให้ค่าการเริ่มต้นแบบเย็นที่เสถียรและทำซ้ำได้

เรียกใช้คำสั่ง adb ด้านล่าง แล้วดูบรรทัด Displayed

# Cold-start the app and log time to first frame
adb shell am start -W -S com.example.app/.MainActivity

# Output includes:
#   TotalTime: 412   <- ms to first frame
# Or filter logcat:
adb logcat | grep "Displayed com.example.app"

ทำให้ Application.onCreate เบา

ทุกอย่างใน Application.onCreate() ทำงานบนเธรดหลักก่อนเฟรมแรกของคุณ การเริ่มต้นที่หนักหน่วงในส่วนนี้จะทำให้การเริ่มต้นแอปล่าช้าโดยตรง

เวอร์ชันที่ไม่ดีด้านล่างเริ่มต้นไลบรารีหลายตัวทันที ให้เลื่อนการเริ่มต้นหรือย้ายไปทำงานเบื้องหลังสำหรับสิ่งที่ยังไม่จำเป็นต่อหน้าจอแรก

// SLOW: blocks the first frame with eager init
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        Analytics.init(this)        // network, disk
        ImageLoader.preload(this)   // heavy
        Database.warmUp(this)       // disk I/O
    }
}
// Each of these adds milliseconds before the user sees anything.

ไลบรารี App Startup ของ Jetpack

ไลบรารี App Startup แทนที่ผู้ให้บริการเนื้อหาของไลบรารีหลายตัว (ซึ่งแต่ละตัวใช้เวลาในการเริ่มต้น) ด้วยผู้ให้บริการร่วมเพียงตัวเดียว และช่วยให้คุณระบุลำดับการเริ่มต้นและการพึ่งพาได้อย่างเป็นระเบียบ

คุณสร้าง Initializer สำหรับแต่ละองค์ประกอบ จากนั้น App Startup จะเรียกใช้แต่ละตัวเพียงครั้งเดียวตามลำดับการพึ่งพา

class AnalyticsInitializer : Initializer<Analytics> {
    override fun create(context: Context): Analytics {
        return Analytics.init(context.applicationContext)
    }
    // Runs after Logger is ready
    override fun dependencies() = listOf(LoggerInitializer::class.java)
}
// Registered via a single merged provider in the manifest,
// avoiding one ContentProvider per library.

การเริ่มต้นแบบขี้เกียจและเบื้องหลัง

สิ่งที่ดีกว่าการจัดลำดับงานที่เริ่มต้นทันที คือการทำงานเหล่านั้นให้<​​strong>น้อยลงในช่วงเริ่มต้น มีสองวิธี:

  • แบบขี้เกียจ: สร้างออบเจ็กต์ขนาดใหญ่เมื่อมีการใช้งานครั้งแรกด้วย by lazy ของ Kotlin
  • เบื้องหลัง: ย้ายการเริ่มต้นที่ไม่เกี่ยวกับส่วนติดต่อผู้ใช้ออกจากเธรดหลัก

ดังนั้นเฟรมแรกจะไม่ถูกบล็อกด้วยงานที่ผู้ใช้ยังไม่จำเป็นต้องใช้

class MyApp : Application() {
    // Built only when first accessed, not during onCreate
    val imageLoader by lazy { ImageLoader.build(this) }

    override fun onCreate() {
        super.onCreate()
        // Push non-critical setup off the main thread
        CoroutineScope(Dispatchers.Default).launch {
            Analytics.init(applicationContext)
        }
    }
}

AOT เทียบกับ JIT: เหตุใดการเรียกใช้ครั้งแรกจึงช้า

ตามค่าเริ่มต้น Android จะเรียกใช้ไบต์โค้ดของแอปด้วยการผสมระหว่างการแปลคำสั่งและการคอมไพล์แบบ Just-In-Time (JIT) เมื่อโค้ดที่ใช้งานบ่อยทำงานเป็นครั้งแรก โค้ดนั้นจะถูกแปลคำสั่ง (จึงช้า) และรันไทม์จะคอมไพล์เป็นโค้ดเนทีฟในภายหลังเท่านั้น

นี่คือเหตุผลที่การเริ่มต้นแบบเย็นและการเลื่อนครั้งแรกให้ความรู้สึกช้ากว่า Baseline Profiles แก้ปัญหานี้โดยบอกให้อุปกรณ์คอมไพล์โค้ดสำคัญแบบ Ahead-Of-Time (AOT) ตั้งแต่ติดตั้ง

Baseline Profile คืออะไร

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

Google รายงานว่าการเริ่มต้นมักเร็วขึ้นประมาณ 20–40% โดยไม่ต้องเปลี่ยนโค้ดฟีเจอร์ของคุณ เพียงเพิ่มโพรไฟล์เท่านั้น

// build.gradle.kts
plugins { id("androidx.baselineprofile") }

dependencies {
    baselineProfile(project(":baselineprofile"))
}
// The generated profile ships as
//   assets/dexopt/baseline.prof
// and is applied automatically at install.

การสร้าง Baseline Profile

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

ต่อไปนี้คือตัวสร้างทั่วไปที่บันทึกการเริ่มต้นและการเลื่อนหน้าจอ

@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
    @get:Rule val rule = BaselineProfileRule()

    @Test
    fun generate() = rule.collect(packageName = "com.example.app") {
        pressHome()
        startActivityAndWait()
        // exercise the critical journey
        device.findObject(By.res("feed")).fling(Direction.DOWN)
    }
}
// Run the generateBaselineProfile Gradle task to produce the file.

ตรวจสอบผลลัพธ์

ยืนยันการปรับปรุงด้วยการวัดประสิทธิภาพเสมอ โดยเปรียบเทียบการเริ่มต้นเมื่อใช้และไม่ใช้โพรไฟล์ (CompilationMode.None เทียบกับ Partial ที่ใช้โพรไฟล์)

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

@Test
fun startupWithProfile() = rule.measureRepeated(
    packageName = "com.example.app",
    metrics = listOf(StartupTimingMetric()),
    iterations = 10,
    startupMode = StartupMode.COLD,
    compilationMode = CompilationMode.Partial() // uses the baseline profile
) {
    pressHome()
    startActivityAndWait()
}

แผนเพิ่มประสิทธิภาพการเริ่มต้นแอป

รวมทุกอย่างเป็นแผนที่ทำซ้ำได้:

  • วัดการเริ่มต้นแบบเย็นด้วยการวัดประสิทธิภาพระดับมาโครและ adb am start -W
  • ลดงานใน Application.onCreate: เลื่อนการเริ่มต้นด้วย by lazy และย้ายงานออกจากเธรดหลัก
  • ใช้ App Startup เพื่อรวมผู้ให้บริการเนื้อหาและจัดลำดับการเริ่มต้น
  • ส่ง Baseline Profile ไปพร้อมแอปเพื่อคอมไพล์เส้นทางสำคัญแบบ AOT
  • ตรวจสอบด้วยการวัดประสิทธิภาพและดูแลให้โพรไฟล์เป็นปัจจุบัน

ผลลัพธ์คือเฟรมแรกที่ตอบสนองได้ฉับไวจนผู้ใช้สังเกตเห็น

ตรวจสอบอย่างรวดเร็ว

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

สรุป: รวดเร็วตั้งแต่เฟรมแรก

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

  • เพิ่มประสิทธิภาพการเริ่มต้นแบบเย็น โดยวัดด้วยการวัดประสิทธิภาพระดับมาโครและ adb am start -W
  • ทำให้ Application.onCreate เบา: เริ่มต้นแบบขี้เกียจและทำงานที่ไม่เกี่ยวกับส่วนติดต่อผู้ใช้แบบเบื้องหลัง
  • ใช้ไลบรารี App Startup เพื่อรวมผู้ให้บริการและจัดลำดับตัวเริ่มต้น
  • ส่ง Baseline Profile ไปพร้อมแอป เพื่อให้โค้ดที่ใช้บ่อยถูกคอมไพล์แบบ AOT ตั้งแต่ติดตั้ง และทำงานด้วยความเร็วระดับเนทีฟตั้งแต่ครั้งแรก
  • ตรวจสอบผลลัพธ์ด้วยการวัดประสิทธิภาพเสมอ และดูแลให้โพรไฟล์เป็นปัจจุบัน

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

เริ่มต้นได้ฟรี

เรียนรู้ Kotlin ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
36
บทเรียน
152

คำถามที่พบบ่อย

บทเรียน “โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Android Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Android Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน”

เริ่มต้นแบบเย็นได้เร็วขึ้น คุณปฏิบัติ Android Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Android Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Android Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Android Academy นี้ได้ไหม

ได้ บทเรียน Android Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การวัดประสิทธิภาพ
  2. การควบคุมการจัดองค์ประกอบใหม่
  3. หน่วยความจำรั่วและวิธีแก้ไข
  4. โปรไฟล์การเริ่มต้นและโปรไฟล์พื้นฐาน
← กลับไปที่ Android Academy