Hot Start trong ứng dụng di động: nó là gì, các yếu tố và cách tăng tốc

Hot Start trong ứng dụng di động là gì

Hot Start là một kịch bản khởi động nơi tiến trình của ứng dụng đã tồn tại trong RAM của thiết bị. Người dùng thu nhỏ ứng dụng, sau đó quay lại — và hệ thống không tạo tiến trình mới mà tiếp tục tiến trình hiện có. Trong kịch bản này, không cần tải hệ điều hành, khởi tạo lớp Application hay tạo tiến trình, giúp giảm đáng kể thời gian cho đến khi UI xuất hiện trên màn hình. Theo Tài liệu Android (2025), Hot Start chỉ mất 200–500 ms, trong khi Cold Start có thể lên tới 5 giây hoặc hơn. Sự khác biệt về tốc độ đặc biệt rõ rệt trên các thiết bị có bộ nhớ hạn chế, nơi hệ thống thường xuyên dỡ các ứng dụng nền hơn.

Đặc điểm chính của Hot Start là tập hợp tối thiểu các phương thức vòng đời được gọi. Trong Android, đó là Activity.onCreate và Activity.onStart; trong iOS, đó là applicationDidBecomeActive. Không giống như Cold Start, nơi Application.onCreate, ContentProvider.onCreate, Activity.onCreate và nhiều lần khởi tạo thư viện được gọi tuần tự, Hot Start bỏ qua tất cả các giai đoạn này. Nhà phát triển phải hiểu mã nào chạy cụ thể trong quá trình khởi động nóng — thường thì các lần khởi tạo SDK nặng, phân tích và vùng chứa DI được lặp lại cả trong Cold và Hot Start, mặc dù chúng không còn cần thiết trong quá trình khởi động nóng.

Cold Start, Warm Start và Hot Start: so sánh

Ba kịch bản khởi động ứng dụng khác nhau về độ sâu khởi tạo. Cold Start xảy ra khi ứng dụng được khởi động lần đầu tiên sau khi cài đặt, khởi động lại thiết bị hoặc bị xóa khỏi bộ nhớ. Hệ thống tạo một tiến trình Linux mới, tải các lớp Application, tạo các phiên bản ContentProvider, thực hiện khởi tạo thư viện và chỉ sau đó mới hiển thị Activity. Toàn bộ quá trình mất 2–10 giây tùy thuộc vào độ phức tạp của ứng dụng và đặc điểm của thiết bị.

Warm Start là một kịch bản trung gian. Tiến trình ứng dụng còn sống trong bộ nhớ, nhưng Activity đã bị hủy và phải được tạo lại. Điều này xảy ra, ví dụ, khi xoay màn hình hoặc khi quay lại từ ứng dụng khác nơi Activity bị xóa do thiếu bộ nhớ nhưng tiến trình vẫn còn. Warm Start bao gồm việc gọi Activity.onCreate và Activity.onStart, nhưng không bao gồm Application.onCreate hoặc khởi tạo ContentProvider. Thời gian Warm Start là 500 ms đến 2 giây. Hot Start là nhanh nhất trong ba: Activity đã tồn tại trong ngăn xếp quay lại, tiến trình còn sống và hệ thống chỉ cần gọi Activity.onRestart, onStart và onResume. Thời gian Hot Start là 200–500 ms. Sự khác biệt so với Warm Start là Activity không được tạo mới — nó được khôi phục từ phiên bản hiện có.

Vòng đời Android trong Hot Start

Trong Android, Hot Start được kích hoạt khi người dùng quay lại ứng dụng qua màn hình Gần đây hoặc bằng cách chạm vào biểu tượng ứng dụng khi đang ở trạng thái thu nhỏ. Hệ thống kiểm tra xem tiến trình còn sống không, và nếu còn, gọi tuần tự Activity.onRestart, onStart và onResume. Phương thức onCreate không được gọi trong Hot Start vì phiên bản Activity đã tồn tại trong bộ nhớ. Đây là sự khác biệt quan trọng với Warm Start, nơi onCreate vẫn được gọi do Activity bị hủy. Theo Google I/O 2019, thời gian Hot Start điển hình trong Android là 200–400 ms, và bất kỳ sự chậm lại nào ở giai đoạn này đều trực tiếp làm tăng thời gian khởi động cảm nhận.

Các nhà phát triển thường bỏ qua rằng mã khởi tạo UI, đăng ký LiveData hoặc thiết lập RecyclerView được thực hiện không chỉ trong onCreate mà còn trong onStart hoặc onResume. Trong Hot Start, các khối mã này thực thi lại, mặc dù UI đã được cấu hình. Khuyến nghị nên tách riêng khởi tạo một lần (trong onCreate với kiểm tra savedInstanceState) và logic có thể tiếp tục (onStart/onResume). Ví dụ, các thao tác nặng — thiết lập bộ điều hợp, tải danh sách — nên được chuyển đến một khối không thực thi trong onRestart, hoặc kiểm tra savedInstanceState.

Ví dụ theo dõi loại khởi động

Mã Kotlin sau đây minh họa cách đơn giản để phát hiện kịch bản khởi động và đo thời gian. Biến launchTimeStamp ghi lại thời điểm bắt đầu khởi động và isColdStart cho phép tách logic cho khởi động lạnh và nóng.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // khởi tạo một lần
        } else {
            isColdStart = false
            // Hot Start — Activity được khôi phục
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

Vòng đời iOS khi khởi động nóng

Trong iOS, Hot Start tương ứng với việc quay lại ứng dụng từ nền qua sceneDidBecomeActive (UIKit) hoặc onAppear (SwiftUI). Hệ điều hành không tạo lại tiến trình nếu ứng dụng ở trạng thái Tạm dừng hoặc Nền. Trong quá trình khởi động nóng, applicationDidBecomeActive được gọi trong AppDelegate, nhưng applicationDidFinishLaunching không được gọi — điều này tương tự như Android nơi Application.onCreate bị bỏ qua. iOS dỡ ứng dụng khỏi bộ nhớ mạnh mẽ hơn: nếu thiết bị thiếu RAM, hệ thống có thể dỡ một ứng dụng nền và lần khởi động tiếp theo sẽ là Cold Start. Theo tài liệu Apple Developer, thời gian Hot Start trung bình trong iOS là 300–600 ms.

Sự khác biệt chính trong iOS là thiếu sự tương tự trực tiếp của Warm Start theo nghĩa Android. Trong iOS, khi ứng dụng được thu nhỏ, sceneDidEnterBackground được gọi và khi quay lại, sceneWillEnterForeground và sceneDidBecomeActive được gọi. Nếu hệ thống dỡ cảnh nhưng giữ tiến trình sống, lần khởi động tiếp theo sẽ là Cold từ góc nhìn cảnh nhưng Hot từ góc nhìn tiến trình. Nhà phát triển phải cân nhắc điều này khi đặt mã khởi tạo: đăng ký NotificationCenter, cập nhật UI và đặt lại trạng thái nên ở trong sceneDidBecomeActive, không chỉ trong viewDidLoad.

Ví dụ xử lý Hot Start trong iOS

Mã Swift này cho thấy cách theo dõi số lần khởi động nóng và tách logic. Bộ đếm foregroundCount tăng lên mỗi khi quay lại từ nền.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — khởi tạo hoàn chỉnh
            setupSDKs()
        } else {
            // Hot Start — chỉ cập nhật UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // cập nhật dữ liệu trên màn hình
    }
}

Các yếu tố ảnh hưởng đến tốc độ Hot Start

Một số loại yếu tố ảnh hưởng đến tốc độ Hot Start. Đầu tiên là khối lượng công việc trong các phương thức vòng đời onStart và onResume. Nếu nhà phát triển đặt tải dữ liệu mạng, phân tích JSON, khởi tạo bộ điều hợp hoặc tính toán nặng trong các phương thức này, mỗi khối như vậy sẽ thêm hàng chục hoặc hàng trăm mili giây vào thời gian khởi động. Theo Android Vitals, các ứng dụng có thời gian Hot Start vượt quá 800 ms sẽ mất tới 20% người dùng khi quay lại.

Loại thứ hai là các fragment và View được khôi phục từ savedInstanceState. Nếu các fragment chứa ViewPager2 nặng, WebView hoặc hệ thống phân cấp phức tạp lồng nhau sâu, việc khôi phục chúng tiêu tốn tài nguyên CPU. Theo Google I/O 2023, mỗi ViewGroup lồng nhau thêm trung bình 2–5 ms vào thời gian hiển thị trong Hot Start. Loại thứ ba là SDK bên thứ ba: thư viện phân tích, công cụ báo cáo sự cố, khung thử nghiệm A/B và trình tải DEX có thể thực hiện khởi tạo mỗi khi quay lại từ nền. Khuyến nghị kiểm tra SDK nào chạy mã cụ thể trong onStart/onResume và hoãn các tác vụ không quan trọng sang luồng nền.

Phương pháp tối ưu hóa khởi động nóng

Tối ưu hóa Hot Start tập trung vào việc giảm thiểu công việc trong các phương thức vòng đời tiếp tục. Phương pháp đầu tiên là khởi tạo lười biếng: bất kỳ mã nào không cần thiết cho khung hình UI đầu tiên nên chạy sau onResume với độ trễ qua Handler.postDelayed hoặc Coroutine.launch(Dispatchers.IO). Phương pháp thứ hai là lưu trạng thái View: khi ứng dụng được thu nhỏ, hãy lưu dữ liệu vào bộ đệm trong bộ nhớ để trong Hot Start bạn không phải tải lại từ cơ sở dữ liệu hoặc mạng. Phương pháp thứ ba là sử dụng SavedStateHandle trong Android và StateRestorationPolicy trong iOS để giảm thiểu lượng dữ liệu được khôi phục.

Tải lười biếng sau Hot Start

Trong ví dụ này, Handler.postDelayed trì hoãn khởi tạo phân tích 500 ms sau khi khung hình đầu tiên được hiển thị. Điều này không ảnh hưởng đến thời gian khởi động cảm nhận vì người dùng đã thấy giao diện.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // khởi tạo sau khung hình đầu tiên
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Sử dụng thư viện App Startup

AndroidX App Startup cho phép bạn kiểm soát thứ tự khởi tạo các thành phần khi khởi động. Tất cả ContentProvider được khởi tạo tự động trong Cold Start, nhưng bạn có thể tắt khởi tạo tự động cho các thành phần không cần thiết trong Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Công cụ giám sát thời gian khởi động

Để đo thời gian Hot Start, có cả công cụ tích hợp sẵn của nền tảng và giải pháp của bên thứ ba. Trong Android, công cụ chính là Android Vitals trong Google Play Console — nó tự động thu thập số liệu thời gian khởi động cho tất cả các kịch bản (Cold, Warm, Hot) được phân chia theo mẫu thiết bị và phiên bản hệ điều hành. Ngoài ra, bạn có thể sử dụng Macrobenchmark từ AndroidX — một thư viện để kiểm tra hiệu suất khởi động tự động. Trong iOS, tương đương là MetricKit, thu thập dữ liệu về thời gian khởi động, tốc độ khung hình và sử dụng bộ nhớ.

Để phân tích chi tiết khởi động nóng, Firebase Performance Monitoring (theo dõi dấu vết tùy chỉnh) và New Relic với bảng điều khiển thời gian khởi động phù hợp. Về phía nhà phát triển để đo thủ công, reportFullyDrawn trong Android được sử dụng — một API thông báo cho hệ thống thời điểm chính xác khi UI được hiển thị và sẵn sàng cho tương tác. Trong iOS, tương đương là endActivity trong MetricKit. Bằng cách kết hợp các công cụ này, bạn có thể xác định SDK hoặc khối mã nào làm chậm Hot Start trên các thiết bị cụ thể.

Ví dụ Macrobenchmark cho Hot Start

Mã Kotlin sử dụng thư viện Macrobenchmark để đo Cold và Hot Start. Bài kiểm tra khởi động Activity và đo thời gian cho đến trạng thái hoàn chỉnh.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}