Warm Start: แก่นแท้ การเริ่มต้นแบบอุ่นและการปรับแต่งใน Android

Warm Start คืออะไร

Warm Start คือสถานะระหว่าง Cold Start และ Hot Start: กระบวนการของแอปมีอยู่ในหน่วยความจำ (บางครั้งอยู่ในแคชพื้นหลังของ Linux) แต่ Activity ไม่ได้ทำงานและจะถูกสร้างขึ้นใหม่ เมื่อ Android หน่วยความจำRAM ไม่เพียงพอ มันอาจนำ Activity ออกจากสแต็ก โดยปล่อยให้กระบวนการยังคงทำงานอยู่ เมื่อผู้ใช้กลับมาที่แอป Warm Start จะเกิดขึ้น: อินสแตนซ์ Activity ใหม่ถูกสร้างขึ้น เมธอดวงจรชีวิต onCreate → onStart → onResume ถูกดำเนินการ แต่ Application.onCreate และการโหลดคลาสถูกข้ามไป

สาเหตุของ Warm Start

Android ตัดสินใจนำ Activity ออกตามลำดับความสำคัญของกระบวนการ (อันดับความสำคัญ) Activity ในพื้นหลัง (ระดับ PROCESS_STATE_IMPORTANT_FOREGROUND หรือ PROCESS_STATE_TOP_SLEEPING) อาจถูกทำลาย 5–30 นาทีหลังจากย่อเล็กสุดแอป ขึ้นอยู่กับ RAM ที่มีอยู่ บนอุปกรณ์ที่มี RAM 3 GB Activity อาจถูกนำออกภายใน 10 นาที; บนอุปกรณ์ที่มี RAM 8 GB หลังจากหลายชั่วโมง สิ่งสำคัญ: ระหว่าง Warm Start onSaveInstanceState ถูกเรียกก่อนที่ Activity จะถูกทำลาย และนักพัฒนาสามารถบันทึกสถานะ UI ได้

การรับรู้ของผู้ใช้

ผู้ใช้ไม่เห็นความแตกต่างระหว่าง Warm และ Cold Start — พวกเขาเพียงแค่แตะไอคอนแอปและรอ อย่างไรก็ตาม ระหว่าง Warm Start หน้าจอสีขาวอาจปรากฏขึ้นหากแอปไม่ได้ตั้งค่าธีมหน้าต่างเริ่มต้นแบบกำหนดเอง Google แนะนำให้ตั้งค่าธีมแบบกำหนดเองในไฟล์ Manifest (Theme.AppCompat.Light หรือ Theme.Material3.DayNight) สำหรับ Activity เริ่มต้น เพื่อหลีกเลี่ยงการกะพริบของหน้าจอสีขาว/ดำระหว่าง Warm Start บน Android 12+ SplashScreen API ก็ซ่อนเอฟเฟกต์นี้เช่นกัน

Warm Start เทียบกับ Cold Start เทียบกับ Hot Start

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

ในทางปฏิบัติ Warm Start คิดเป็น 30% ถึง 60% ของการเริ่มต้นแอปทั้งหมด ขึ้นอยู่กับนิสัยผู้ใช้และ RAM ของอุปกรณ์ ผู้ใช้ที่เปิดแอปหลายตัวไว้ (มัลติทาสก์) เจอ Warm Start บ่อยกว่า สำหรับโซเชียลเน็ตเวิร์กและแอปส่งข้อความ Warm Start เป็นสถานการณ์ที่พบบ่อยที่สุดเนื่องจากแอปอยู่ในพื้นหลังเสมอ สำหรับแอปธนาคาร ในทางกลับกัน Cold Start ครอบงำ (การล้างกระบวนการบังคับด้วยเหตุผลด้านความปลอดภัย)

ขั้นตอนของการเริ่มต้นแบบอุ่น

Warm Start ประกอบด้วยสามขั้นตอน แต่ละขั้นตอนสามารถวัดและปรับแต่งได้ ซึ่งแตกต่างจาก Cold Start ไม่มีขั้นตอน fork หรือการโหลดคลาส แต่มีขั้นตอนการเรียกคืนสถานะที่อาจมีราคาแพง

ขั้นตอนที่ 1: หน้าต่างเริ่มต้น (พื้นหลังหน้าต่าง)

ระบบตรวจสอบว่าแอปมีธีมสำหรับหน้าต่างเริ่มต้นหรือไม่ ถ้าไม่ได้ตั้งค่าธีม หน้าจอสีขาว (หรือสีดำ ขึ้นอยู่กับระบบ) จะแสดงขึ้น ถ้าตั้งค่าธีมแล้ว พื้นหลังของธีมจะแสดงขึ้น ขั้นตอนนี้ใช้เวลา 10–30 มิลลิวินาที แต่สังเกตเห็นได้ด้วยตาหากธีมไม่ตรงกับ UI จริงของแอป ใช้ Theme.Material3.DayNight กับ windowBackground แบบกำหนดเองซึ่งสีตรงกับพื้นหลังของหน้าจอแรก — สิ่งนี้สร้างเอฟเฟกต์การโหลดทันที

ขั้นตอนที่ 2: การสร้าง Activity (การเรียกคืน)

ระบบเรียก onCreate โดยส่ง Bundle savedInstanceState ที่ถูกบันทึกใน onSaveInstanceState ก่อนที่ Activity จะถูกทำลาย ถ้าแอปบันทึกสถานะอย่างถูกต้อง (ข้อความในฟิลด์ ตำแหน่งเลื่อน ข้อมูล ViewModel) การเรียกคืนจะเกิดขึ้นอย่างรวดเร็ว ถ้าไม่ Activity จะเริ่มจากศูนย์และผู้ใช้จะเห็นตัวโหลดในขณะที่ข้อมูลกำลังโหลด จุดสำคัญ: ออบเจ็กต์ ViewModel จะอยู่รอดใน Warm Start เฉพาะเมื่อกระบวนการไม่ถูกทำลาย — ระหว่าง Warm Start ViewModel จะยังคงอยู่ในหน่วยความจำ

ขั้นตอนที่ 3: เฟรมแรก (TTFD)

หลังจาก onCreate onStart → onResume จะถูกดำเนินการ และระบบจะเริ่มการวาดครั้งแรก TTFD (Time To First Draw) สำหรับ Warm Start ควรต่ำกว่า 300 มิลลิวินาทีบนอุปกรณ์ระดับกลาง ถ้าหน้าจอแรกมี RecyclerView ที่ซับซ้อนพร้อม Views ที่หนัก หรือโหลดรูปภาพจากเครือข่าย TTFD อาจเกินเกณฑ์ ใช้ Placeholder และ Shimmer เพื่อการโหลดเนื้อหาที่ราบรื่นหลังจากเฟรมแรก

วิธีวัด Warm Start

การวัด Warm Start ซับซ้อนกว่า Cold Start เพราะคุณต้องจำลองสถานะที่กระบวนการยังทำงานอยู่แต่ Activity ถูกทำลาย คำสั่ง ADB มาตรฐานพร้อมแฟล็ก -S ใช้ไม่ได้ — มันจะฆ่ากระบวนการ ใช้วิธีการที่แตกต่างสำหรับ Warm Start

ADB shell am start โดยไม่มี -S

ก่อนอื่น เริ่มแอปผ่าน adb shell monkey หรือแตะที่ไอคอน จากนั้นย่อเล็กสุด (adb shell input keyevent 3 keyevent HOME) รอ 5–10 วินาทีเพื่อให้ระบบสามารถนำ Activity ออก จากนั้นรัน adb shell am start -W (โดยไม่มี -S) คำสั่งจะส่งคืนเวลาเริ่มต้นที่สั้นกว่า Cold Start เพื่อความสามารถในการทำซ้ำ ให้ใช้สคริปต์: เริ่ม → รอ → โฮม → รอ → เริ่ม

# การจำลอง Warm Start ผ่าน ADB
$ adb shell am start -W \
    com.example.app/.MainActivity

# ผลลัพธ์ (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Macrobenchmark สำหรับ Warm Start

ไลบรารี androidx.benchmark.macro รองรับการวัด Warm Start ในการทดสอบ ให้ตั้งค่า startupMode = StartupMode.WARM — ไลบรารีจะเริ่มแอป ย่อเล็กสุด รอ (หน่วงเวลาที่กำหนดค่าได้) จากนั้นวัดการเริ่มใหม่ Macrobenchmark ทำซ้ำ 10–20 ครั้งและคำนวณเปอร์เซ็นไทล์ ใน CI/CD คุณสามารถตั้งค่าเกณฑ์: ถ้า P50 Warm Start เกิน 600 มิลลิวินาที การทดสอบจะล้มเหลว ซึ่งช่วยให้ติดตามการถดถอยได้ทุกคอมมิต

Firebase Performance Monitoring

Firebase แยกความแตกต่างระหว่าง Cold และ Warm Start โดยอัตโนมัติตามเวลาตั้งแต่ปิดแอปครั้งล่าสุด ถ้าแอปถูกเปิดภายใน 30 นาทีที่ผ่านมา Firebase จะจัดประเภทการเริ่มต้นเป็น Warm ในคอนโซล Firebase คุณจะเห็นกราฟแยกสำหรับแต่ละประเภทการเริ่มต้น ซึ่งช่วยให้คุณประเมินประสิทธิภาพของการปรับแต่งได้ ตัวอย่างเช่น หลังจากใช้การรักษาสถานะใน ViewModel คุณอาจเห็นการลดลง 30% ในเวลา Warm Start

วิธีปรับแต่ง Warm Start

การปรับแต่ง Warm Start มุ่งเน้นไปที่สองด้าน: การเร่ง Activity.onCreate และการเรียกคืนสถานะที่ถูกต้อง เนื่องจาก Application.onCreate และการโหลดคลาสเสร็จสมบูรณ์แล้ว คอขวดหลักคือโค้ด UI ของหน้าจอแรก

การเรียกคืนสถานะแบบอะซิงโครนัส

ถ้าสถานะที่บันทึกไว้ (savedInstanceState) มีข้อมูลที่ต้องการดีซีเรียลไลเซชัน (Bitmap, String, JSON) ให้ทำในเธรดพื้นหลัง แทนที่จะอ่านโดยตรงจาก Bundle ใน onCreate ให้เริ่ม coroutine และแสดงหน้าจอ shimmer ในทางปฏิบัติ การดีซีเรียลไลซ์ Bundle บนอุปกรณ์ระดับกลางใช้เวลา 20–100 มิลลิวินาที — ดูเหมือนน้อย แต่สำหรับ Warm Start นี่คือ 10–50% ของเวลาทั้งหมด ใช้ Saved State Module ของ Jetpack ซึ่งบันทึกและเรียกคืนสถานะ ViewModel ใน Bundle หรือฐานข้อมูลโดยอัตโนมัติ

การปรับแต่ง setContentView

การขยายเลย์เอาต์ XML เป็นหนึ่งในขั้นตอนที่แพงที่สุดของ Warm Start ถ้าหน้าจอแรกใช้ CoordinatorLayout ที่ซับซ้อนกับ AppBar, CollapsingToolbar, NestedScrollView บวกกับ RecyclerView สามตัว เวลาการขยายอาจถึง 300 มิลลิวินาที วิธีแก้ไข: ใช้ ConstraintLayout สำหรับลำดับชั้นแบบราบ ใช้ ViewStub สำหรับส่วนที่มองไม่เห็นเมื่อเริ่มต้น (bottom sheet, dialog) เปิดใช้งานการขยายแบบอะซิงโครนัสสำหรับ fragment ที่หนักผ่าน AsyncLayoutInflater ใน Jetpack Compose ไม่จำเป็นต้องขยาย แต่การคอมไพล์ทรี Compose ระหว่าง Warm Start อาจใช้เวลาใกล้เคียงกัน

การแคชข้อมูล

ระหว่าง Warm Start ข้อมูลที่แอปโหลดในเซสชันก่อนหน้าอาจอยู่ในแคชแล้ว: ฐานข้อมูล Room, SharedPreferences, แคชในหน่วยความจำใน ViewModel ถ้าหน้าจอแรกของคุณแสดงรายการจากเซิร์ฟเวอร์ ให้ตรวจสอบแคชเมื่อเริ่มต้นและอัปเดตข้อมูลในพื้นหลัง ใช้กลยุทธ์ cache-then-network: แสดงข้อมูลที่แคชไว้ก่อน (ทันที) จากนั้นอัปเดตจากเซิร์ฟเวอร์ (แบบอะซิงโครนัส) ซึ่งช่วยลดเวลา Warm Start ที่รับรู้ได้เหลือ 100–200 มิลลิวินาที

// ViewModel พร้อมการแคชสำหรับ Warm Start
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // แคชก่อน แล้วจึงเครือข่าย
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: ข้อมูลอยู่ใน DB แล้ว
            cache.emit(api.fetchItems()) // อัปเดตในพื้นหลัง
        }
    }
}

การรักษาสถานะระหว่าง Warm Start

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

onSaveInstanceState

ระบบเรียก onSaveInstanceState เมื่อ Activity กำลังถูกทำลาย แต่ก่อนที่กระบวนการจะถูกฆ่า เฉพาะชนิดข้อมูลง่าย ๆ (String, Int, Parcelable, Serializable) เท่านั้นที่ถูกบันทึกใน Bundle สำหรับข้อมูลที่ซับซ้อน ให้ใช้ SavedStateHandle ใน ViewModel — มันบันทึกและเรียกคืนฟิลด์โดยอัตโนมัติระหว่าง Warm Start แตกต่างจาก onSaveInstanceState SavedStateHandle ทำงานแม้ว่ากระบวนการจะรอดจาก Warm Start (ViewModel ไม่ถูกทำลาย) ตัวอย่าง: สำหรับข้อความใน EditText ให้ใช้ SavedStateHandle.getLiveData(“text”) — ข้อความจะถูกบันทึกและเรียกคืนโดยอัตโนมัติ

ViewModel และ Warm Start

ถ้ากระบวนการไม่ถูกฆ่าระหว่าง Warm Start ViewModel จะยังคงอยู่ในหน่วยความจำและ onCleared จะไม่ถูกเรียก ซึ่งหมายความว่าข้อมูลทั้งหมดที่โหลดในเซสชันก่อนหน้าพร้อมใช้งานทันที อย่างไรก็ตาม ถ้ากระบวนการถูกฆ่า (อุปกรณ์อยู่ในโหมดหลับลึกนานกว่า 30 นาที) ViewModel จะถูกทำลายและสร้างขึ้นใหม่ด้วย SavedStateHandle สำหรับพฤติกรรม ViewModel ที่ถูกต้องระหว่าง Warm Start ให้ใช้ SavedStateHandle กับฟิลด์ที่ต้องเรียกคืนในทุกสถานการณ์ ข้อแตกต่าง: ViewModel กับ @HiltViewModel รองรับ SavedStateHandle โดยอัตโนมัติ

การบันทึกตำแหน่งเลื่อน RecyclerView

หนึ่งในปัญหาที่พบบ่อยที่สุดของ Warm Start — การสูญเสียตำแหน่งเลื่อน ผู้ใช้เลื่อนไปที่รายการที่ 50 ย่อเล็กสุดแอป กลับมา — และเห็นจุดเริ่มต้นของรายการ วิธีแก้ไข: บันทึก layoutManager.onSaveInstanceState (บันทึกตำแหน่งและออฟเซ็ตของรายการที่มองเห็นแรก) และเรียกคืนใน onRestoreInstanceState คุณยังสามารถบันทึกตำแหน่งที่มองเห็นล่าสุดใน SharedPreferences ด้วยคีย์วันที่/เวลาเพื่อเรียกคืนตำแหน่งอย่างรวดเร็วระหว่าง Warm Start

// บันทึกตำแหน่งเลื่อน RecyclerView
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

ตัวอย่างโค้ดสำหรับ Warm Start

สองตัวอย่างเชิงปฏิบัติของการปรับแต่ง Warm Start: การใช้ SavedStateHandle ใน ViewModel และการเรียกคืนข้อมูลที่ซับซ้อนแบบอะซิงโครนัสหลังจากเริ่มต้น

ViewModel กับ SavedStateHandle

SavedStateHandle บันทึกฟิลด์ใน Bundle โดยอัตโนมัติและเรียกคืนระหว่าง Warm Start ฟิลด์โปรไฟล์ผู้ใช้ (String, JSON) จะถูกเรียกคืนโดยไม่ต้องร้องขอเซิร์ฟเวอร์โดยไม่จำเป็น ถ้ากระบวนการถูกฆ่า SavedStateHandle จะโหลดสถานะที่บันทึกไว้ล่าสุดจาก Bundle

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile ไม่ใช่ null, UI ไม่มีตัวโหลด
// หลังจากโหลด: profile อัปเดตใน SavedStateHandle

AsyncLayoutInflater สำหรับหน้าจอที่หนัก

ถ้าหน้าจอแรกมีเลย์เอาต์ที่ซับซ้อน (แผนที่ การไล่สี หลายรายการ) ให้ใช้ AsyncLayoutInflater เพื่อขยายองค์ประกอบที่หนักในพื้นหลัง ในขณะที่เลย์เอาต์กำลังถูกขยาย ให้แสดงตัวยึดตำแหน่งด้วยเอฟเฟกต์ shimmer สิ่งนี้สำคัญเป็นพิเศษสำหรับ Warm Start ที่ทุกมิลลิวินาทีมีค่า AsyncLayoutInflater ทำงานบนเธรดพื้นหลังและส่ง View ที่พร้อมไปยัง callback บนเธรดหลัก

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // เลย์เอาต์ Placeholder สำหรับการเรนเดอร์ทันที
        setContentView(R.layout.placeholder_shimmer)

        // การโหลดเลย์เอาต์หนักแบบอะซิงโครนัส
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}