onPause: nó là gì, lưu trạng thái Activity trong Android

onPause trong Android là gì

onPause là phương thức thứ tư của vòng đời Activity, được gọi khi màn hình mất tiêu điểm đầu vào nhưng vẫn hiển thị một phần cho người dùng. Đây là trạng thái chuyển tiếp giữa ứng dụng đang chạy tích cực và bị ẩn. Hệ thống gọi onPause trong các kịch bản sau: mở một Activity khác (màn hình mới che một phần màn hình hiện tại), xuất hiện cửa sổ hộp thoại (Dialog, PopupWindow, Snackbar không kích hoạt onPause, nhưng DialogFragment thì có), nhấn nút ứng dụng gần đây, cuộc gọi đến, nhấn nút nguồn để khóa màn hình.

Nhiệm vụ chính của onPause là chuẩn bị ứng dụng cho khả năng bị ẩn hoặc bị hủy. Đây là điểm cuối cùng trong vòng đời mà nhà phát triển có thể chắc chắn rằng mã của họ sẽ được thực thi trước khi hệ thống tiếp tục chuyển đổi sang thành phần khác. Sau onPause, hệ thống gọi onStop (nếu Activity bị ẩn hoàn toàn), sau đó tiến trình có thể bị kết thúc bất cứ lúc nào mà không cần thông báo thêm.

Theo tài liệu của Android Developers (2025), onPause phải nhẹ và nhanh nhất có thể. Trong khi onPause chưa trả lại quyền điều khiển, hệ thống không thể khởi động Activity tiếp theo — điều này có nghĩa là người dùng thấy độ trễ trong quá trình chuyển đổi màn hình. Google khuyến nghị hoàn thành onPause trong ít hơn 100 mili giây và tất cả các thao tác dài (lưu vào cơ sở dữ liệu, ghi vào đĩa) phải được thực hiện bất đồng bộ thông qua coroutines hoặc apply().

onPause trong Activity

Trong một Activity, phương thức onPause được gọi mỗi khi màn hình không còn hoạt động nhưng có thể tiếp tục hiển thị một phần. Một ví dụ điển hình: người dùng mở ứng dụng Bản đồ, nhấn Chia sẻ vị trí và một hộp thoại chọn ứng dụng hệ thống xuất hiện trên Bản đồ. Activity Bản đồ nhận onPause nhưng vẫn hiển thị bên dưới hộp thoại. Khi hộp thoại đóng lại, Bản đồ nhận onResume mà không cần gọi onStart (màn hình không bị ẩn hoàn toàn).

class NoteEditorActivity : AppCompatActivity() {
    private var binding: ActivityNoteEditorBinding? = null
    private val prefs by lazy {
        getSharedPreferences("note_drafts", Context.MODE_PRIVATE)
    }

    override fun onPause() {
        super.onPause()

        // Lưu bản nháp ghi chú — bất đồng bộ
        prefs.edit()
            .putString("draft_title", binding?.titleInput?.text.toString())
            .putString("draft_body", binding?.bodyInput?.text.toString())
            .putLong("draft_timestamp", System.currentTimeMillis())
            .apply()

        // Tạm dừng video
        binding?.videoPlayer?.pause()

        // Giải phóng tài nguyên độc quyền
        releaseCamera()
        releaseAudioFocus()
    }

    override fun onResume() {
        super.onResume()
        // Khôi phục bản nháp
        binding?.titleInput?.setText(prefs.getString("draft_title", ""))
        binding?.bodyInput?.setText(prefs.getString("draft_body", ""))
        acquireCamera()
        acquireAudioFocus()
    }
}

Ví dụ NoteEditorActivity minh họa cách xử lý onPause đúng cách: lưu bản nháp vào SharedPreferences qua apply(), tạm dừng tệp video, giải phóng camera và tiêu điểm âm thanh. Mỗi lần gọi đều nhẹ và nhanh, không chặn luồng UI đủ lâu để gây ra ANR. Hãy chú ý đến thứ tự: super.onPause() được gọi ở dòng đầu tiên — điều này đảm bảo logic hệ thống thực thi ngay cả khi xảy ra ngoại lệ trong mã người dùng.

Lưu trạng thái trong onPause

onPause là điểm cuối cùng mà nhà phát triển có thể lưu dữ liệu người dùng một cách đáng tin cậy trước khi ứng dụng bị ẩn hoặc bị hệ thống kết thúc. Sau onStop, hệ thống có thể kết thúc tiến trình nếu thiếu bộ nhớ mà không gọi onDestroy. Phương thức onSaveInstanceState() được gọi sau onPause, nhưng Bundle của nó không dành cho lưu trữ dài hạn — nó chỉ tồn tại đến onCreate tiếp theo.

SharedPreferences với apply()

SharedPreferences với apply() bất đồng bộ là cách tối ưu để lưu một lượng nhỏ dữ liệu trong onPause. Không giống như commit(), ghi dữ liệu đồng bộ vào đĩa và trả về boolean, apply() lưu dữ liệu ngay vào bộ nhớ và lên lịch ghi bất đồng bộ vào đĩa. Thao tác này mất ít hơn 1 mili giây trên luồng UI so với 10–100 mili giây của commit().

override fun onPause() {
    super.onPause()

    // ❌ Tệ: ghi đồng bộ chặn luồng
    // prefs.edit().putInt("score", score).commit()

    // ✅ Tốt: ghi bất đồng bộ
    prefs.edit().putInt("score", score).apply()

    // Đối với đối tượng phức tạp — lưu cache trong ViewModel
    viewModel.saveState()
}

Room và Coroutines

Đối với dữ liệu có cấu trúc (SQLite qua Room) trong onPause, hãy sử dụng coroutines với lifecycleScope. ViewModelScope tự động hủy coroutine khi ViewModel bị hủy, ngăn ghi vào cơ sở dữ liệu đã đóng. Ghi qua Room với coroutines mất 5–15 mili giây và không chặn luồng UI.

// Trong ViewModel:
fun saveDraft(title: String, body: String) {
    viewModelScope.launch(Dispatchers.IO) {
        noteDao.insert(NoteDraft(title = title, body = body))
    }
}

// Trong Activity.onPause:
viewModel.saveDraft(
    binding?.titleInput?.text.toString(),
    binding?.bodyInput?.text.toString()
)

onPause trong Fragment

onPause trong Fragment được gọi khi Fragment không còn hoạt động nhưng có thể vẫn hiển thị. Điều này xảy ra khi: một Fragment được thay thế bằng Fragment khác qua FragmentTransaction; Fragment không còn là trang hiện tại trong ViewPager; Activity chứa Fragment nhận onPause. Sự tương tác giữa onPause của Activity và onPause của Fragment có thứ bậc chặt chẽ: Activity nhận onPause trước, sau đó đến tất cả các Fragment của nó.

class MapFragment : Fragment() {
    private var mapController: MapController? = null

    override fun onPause() {
        super.onPause()
        mapController?.stopFollowMode()
        binding?.mapContainer?.alpha = 0.7f
    }

    override fun onResume() {
        super.onResume()
        binding?.mapContainer?.alpha = 1.0f
        if (isVisible) {
            mapController?.startFollowMode()
        }
    }
}

Chi tiết cụ thể khi làm việc với bản đồ trong onPause: Google Maps và Yandex Maps tiêu thụ tài nguyên GPU đáng kể ở chế độ theo dõi chủ động. Khi mất tiêu điểm, nên tắt hoạt ảnh bản đồ và giảm tần suất cập nhật điểm đánh dấu, và khi lấy lại tiêu điểm, khôi phục đầy đủ chức năng. Điều này cải thiện hiệu suất và giảm mức tiêu thụ điện khi chuyển đổi giữa các màn hình.

onPause vs onStop: Sự khác biệt và kịch bản

Một trong những nhầm lẫn phổ biến nhất ở các nhà phát triển Android mới bắt đầu là không hiểu sự khác biệt giữa onPause và onStop. Hãy xem xét từng kịch bản và xác định phương thức chính xác.

Quy tắc chính: onPause được gọi khi mất tiêu điểm, onStop chỉ được gọi khi mất hoàn toàn khả năng hiển thị. Nếu Activity vẫn hiển thị (dù chỉ một phần), onStop không được gọi. Điều này cực kỳ quan trọng đối với chế độ Màn hình chia đôi, PiP và Activity trong suốt — ở đây onPause/onResume hoạt động, nhưng onStart/onStop thì không.

Thời gian và hiệu suất của onPause

onPause là phương thức vòng đời quan trọng nhất về mặt thời gian vì nó chặn việc hiển thị Activity tiếp theo. Hệ thống chờ onPause của Activity hiện tại hoàn thành trước khi hiển thị Activity mới. Nếu onPause mất hơn 100 mili giây, người dùng nhận thấy độ trễ chuyển đổi; nếu mất hơn 5 giây, hệ thống hiển thị ANR.

Khuyến nghị về hiệu suất

Hướng dẫn Hiệu suất Android của Google (2025) đưa ra các khuyến nghị sau cho onPause: không thực hiện yêu cầu mạng — chúng nên bị hủy hoặc chuyển sang WorkManager; không ghi tệp lớn vào đĩa — sử dụng BufferedWriter trên luồng nền; không thực hiện truy vấn SQL phức tạp — các thao tác Room phải bất đồng bộ qua coroutines; tránh tạo đối tượng mới — thu gom rác trong onPause làm trầm trọng thêm độ trễ; sử dụng apply() thay vì commit() cho SharedPreferences.

override fun onPause() {
    super.onPause()

    // ❌ Tệ: yêu cầu HTTP chặn UI
    // val response = api.syncSave(data).execute()

    // ❌ Tệ: ghi đồng bộ vào tệp
    // FileOutputStream(file).write(data)

    // ✅ Tốt: lưu bất đồng bộ
    lifecycleScope.launch {
        withContext(Dispatchers.IO) {
            api.saveData(data)
            fileDao.write(data)
        }
    }

    // ✅ Tốt: ghi nhẹ vào SharedPreferences
    prefs.edit().putString("key", value).apply()
}

Hồ sơ onPause thông qua Android Studio Profiler (dấu vết CPU) hiển thị thời gian thực thi chính xác. Nếu onPause mất hơn 100 ms, Profiler đánh dấu phương thức bằng màu vàng và hơn 500 ms bằng màu đỏ. Trong các dự án thương mại tại IT Sectr, chúng tôi sử dụng các bài kiểm tra Macrobenchmark tự động kiểm tra thời gian chuyển đổi giữa các Activity và báo hiệu sự suy giảm hiệu suất trong đường ống CI.

Lỗi thường gặp trong onPause

Ngay cả các nhà phát triển giàu kinh nghiệm cũng mắc lỗi trong onPause. Hãy xem xét năm vấn đề điển hình và giải pháp của chúng.

Ghi đồng bộ vào cơ sở dữ liệu

Gọi Room DAO với truy vấn đồng bộ (.executeAsObservable() không có coroutines) trong onPause chặn luồng UI trong 10–50 ms. Nếu GC hoặc tranh chấp ghi xảy ra cùng lúc, độ trễ có thể lên tới 200–500 ms. Giải pháp: sử dụng coroutines với Dispatchers.IO hoặc apply() cho SharedPreferences.

Đăng ký trình lắng nghe mới

onPause không phải là nơi để đăng ký trình lắng nghe. Nếu bạn đăng ký BroadcastReceiver trong onPause, nó sẽ vẫn hoạt động khi Activity không còn hiển thị. Việc đăng ký chỉ nên thực hiện trong onStart/onResume và trong onPause/onStop — chỉ hủy đăng ký. Ngoại lệ là các API dựa trên Intent yêu cầu đăng ký trước khi gọi.

Bỏ qua ngoại lệ

Nếu xảy ra ngoại lệ chưa được xử lý trong onPause, hệ thống không gọi onStop và onDestroy. Activity bị kẹt ở trạng thái không xác định và onResume khi quay lại có thể không khôi phục đúng cách các tài nguyên đã giải phóng. Giải pháp: bọc các thao tác quan trọng trong try/catch với ghi nhật ký qua Log.e().

Lưu dữ liệu dư thừa

Không cần lưu trong onPause dữ liệu có thể dễ dàng khôi phục. Ví dụ: kết quả yêu cầu API được lưu vào bộ nhớ đệm trong Room hoặc DataStore tại thời điểm lấy, không phải trong onPause. Chỉ lưu những gì người dùng nhập thủ công và không thể khôi phục tự động — văn bản trong trường, mục đã chọn, vị trí cuộn.

Quên super.onPause()

super.onPause() nên được gọi, nhưng không giống như onCreate, việc bỏ qua nó không gây ra sự cố ngay lập tức. Hệ thống tha thứ cho việc thiếu super trong onPause, nhưng máy trạng thái nội bộ chuyển sang trạng thái không chính xác. Lần gọi onResume tiếp theo có thể không khôi phục được tiêu điểm đầu vào, khiến Activity bị đóng băng. Luôn gọi super.onPause() càng sớm càng tốt.