Android fundamentals

Trên máy tính, app của bạn chạy liên tục cho tới khi bạn tự tắt nó. Trên điện thoại thì khác: hệ điều hành mới là bên quyết định khi nào màn hình app của bạn được tạo ra, khi nào bị dọn đi — kể cả khi bạn không hề bấm nút thoát. Lý do là điện thoại có RAM hạn chế và phải chạy nhiều app cùng lúc, nên Android có quyền "dọn dẹp" app đang không dùng để lấy chỗ cho việc khác.

Vì vậy, học lifecycle (vòng đời) không phải để thuộc tên hàm cho vui, mà để trả lời đúng một câu hỏi thực tế: "nếu màn hình này bị hệ thống dọn đi bất ngờ, dữ liệu của tôi có bị mất không, và tôi có đang giữ thứ gì mà lẽ ra phải bỏ đi không?"

Cách dễ nhớ nhất là gắn mỗi callback với một khoảnh khắc thật, cụ thể — không cần ẩn dụ, vì đây đúng là những gì xảy ra khi bạn cầm điện thoại lên dùng app. Sơ đồ dưới đây lấy ví dụ app Product Catalog (app trong phần Mini Project của portal này): mở app xem danh sách sản phẩm, gõ tìm kiếm, bấm vào một sản phẩm để xem ảnh full-screen, rồi rời đi — mỗi ô là một callback, kèm mô tả đúng chuyện gì xảy ra tại đó. Mỗi callback cũng gắn với một "trạng thái" (state) cụ thể, và những trạng thái này (CREATED, STARTED, RESUMED, DESTROYED) chính là những giá trị bạn sẽ gặp lại khi dùng Lifecycle.State ở các phần sau (ví dụ repeatOnLifecycle(Lifecycle.State.STARTED)):

Khi bạn xoay điện thoại, đổi giao diện sáng/tối, hay đổi ngôn ngữ máy — những thứ này gọi chung là configuration change. Cách Android xử lý khá "triệt để": nó không cố gắng chỉnh sửa màn hình hiện tại, mà đập bỏ toàn bộ Activity rồi dựng lại một cái mới từ đầu, để áp đúng layout/ngôn ngữ mới. Giống như thay vì xoay lại vài món đồ trong phòng, người ta dọn sạch cả phòng và bày lại từ con số 0.

Hậu quả: nếu dữ liệu bạn đang có (ví dụ danh sách đã tải, ô nhập đang gõ) chỉ nằm trong biến của Activity, nó sẽ mất sạch mỗi lần xoay màn hình — vì Activity cũ đã bị đập bỏ. ViewModel được thiết kế để không bị đập bỏ cùng Activity — nó là "cái hộp" được giữ lại nguyên vẹn qua lần dựng lại đó. Đây chính là lý do ViewModel tồn tại: để bạn có một nơi đặt dữ liệu mà không lo mất khi xoay màn hình.

Trước hết cần phân biệt rõ hai thứ: Activity giống như CÁI CỬA SỔ của toàn app — nó mở lên khi bạn mở app, đóng lại khi bạn thoát app. Fragment là MỘT MIẾNG UI nằm BÊN TRONG cửa sổ đó — ví dụ miếng hiển thị danh sách sản phẩm, hoặc miếng hiển thị chi tiết một sản phẩm. Rất nhiều app chỉ dùng DUY NHẤT MỘT Activity trong suốt lúc chạy, và bên trong Activity đó, các Fragment được thay ra thay vào liên tục để hiện các màn hình khác nhau — mà không cần đóng/mở lại cửa sổ.

Đây là điểm khác cốt lõi: Activity lifecycle nói về việc CẢ CÁI CỬA SỔ xuất hiện hay biến mất. Fragment lifecycle nói về việc MỘT MIẾNG UI bên trong cửa sổ đó được thêm vào hay gỡ ra — trong lúc cửa sổ (Activity) vẫn đứng yên, không hề bị tạo lại hay đóng đi. Vì một Fragment có thể bị gỡ ra rồi lắp lại nhiều lần trong khi Activity chứa nó vẫn sống nguyên, nên nó cần một vòng đời chi tiết hơn để mô tả đủ các tình huống đó — đó là lý do Fragment có nhiều callback hơn Activity.

Đây là sơ đồ đầy đủ, chính xác theo tài liệu chính thức của Android — nhìn kỹ sẽ thấy có HAI cột trạng thái riêng: cột Fragment (bên trái) và cột View (bên phải). Cột View bắt đầu MUỘN HƠN (chỉ có từ sau onCreateView) và kết thúc SỚM HƠN (DESTROYED ngay ở onDestroyView, trước khi Fragment kết thúc ở onDestroy) — đây chính là bằng chứng trực quan nhất cho việc "Fragment có hai vòng đời tách biệt".

Hãy bám theo một tình huống thật: bạn đang ở màn hình danh sách sản phẩm (ProductListFragment). Bạn bấm vào một sản phẩm để xem chi tiết. App KHÔNG mở một cửa sổ (Activity) mới — nó chỉ thay miếng UI đang hiển thị bên trong CÙNG MỘT Activity, và "cất" ProductListFragment vào một hàng chờ (gọi là back stack) để có thể lấy lại ngay khi bạn bấm Back.

Bạn bấm vào 1 sản phẩm trong danh sách:
  -> ProductDetailFragment được tạo và hiện lên (onCreateView, onViewCreated...)
  -> ProductListFragment bị che đi, và PHẦN HIỂN THỊ của nó bị dọn: onDestroyView
     (nhưng đối tượng ProductListFragment thì KHÔNG bị huỷ — onDestroy KHÔNG
     được gọi, nó chỉ đang chờ trong back stack, chưa mất đi đâu cả)

Bạn bấm nút Back:
  -> ProductDetailFragment bị đóng hẳn: onDestroyView -> onDestroy -> onDetach
  -> ProductListFragment hiện lại — nhưng KHÔNG PHẢI một đối tượng mới được
     tạo ra, mà CHÍNH đối tượng cũ được dùng lại. Chỉ riêng phần hiển thị của
     nó được DỰNG LẠI TỪ ĐẦU: onCreateView chạy thêm một lần nữa.

Đây chính là ý nghĩa của "Fragment có hai vòng đời": đối tượng ProductListFragment (nơi chứa dữ liệu, biến, logic bạn viết) có thể tồn tại LÂU HƠN phần hiển thị (View) của nó. Có lúc phần hiển thị bị dọn đi rồi dựng lại thành một bản HOÀN TOÀN MỚI, nhưng đối tượng Fragment thì vẫn là MỘT, không đổi trong suốt quá trình đó.

Vì sao điều này thực sự gây rắc rối: giả sử trong ProductListFragment, bạn viết code lắng nghe (observe) dữ liệu mới nhất từ ViewModel ngay khi màn hình được tạo ra. Nếu bạn gắn việc lắng nghe đó theo vòng đời của CHÍNH FRAGMENT (this) thay vì theo vòng đời của PHẦN HIỂN THỊ (viewLifecycleOwner), chuyện sau sẽ xảy ra: lần đầu hiện màn hình, bạn tạo ra một "người lắng nghe". Bạn qua xem chi tiết sản phẩm rồi bấm Back quay lại — onCreateView chạy lại lần hai, và đoạn code lắng nghe đó CHẠY LẠI, tạo thêm một "người lắng nghe" thứ hai. Người lắng nghe đầu tiên thì chưa từng bị dừng, vì lý do khiến nó dừng (this bị huỷ) chưa hề xảy ra — Fragment vẫn còn sống nguyên như đã nói ở trên. Kết quả: có 2 người cùng lắng nghe 1 nguồn dữ liệu — mỗi khi có dữ liệu mới, code cập nhật UI chạy hai lần; nhẹ thì lãng phí, nặng thì một trong hai lần cố cập nhật lên một View đã không còn tồn tại và làm app crash.

// Sai: gắn theo vòng đời của chính Fragment — sống quá lâu, dễ lắng nghe trùng
lifecycleScope.launch {
    viewModel.uiState.collect { render(it) }
}

// Đúng: gắn theo vòng đời của PHẦN HIỂN THỊ hiện tại
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { render(it) }
    }
}

Context là thứ bạn cần để làm hầu hết mọi việc trong Android — hiển thị dialog, đọc resource, mở màn hình mới. Nhưng có hai loại Context, và nhầm loại là nguyên nhân memory leak phổ biến nhất.

• Activity Context: giống như "một căn phòng cụ thể" — chỉ tồn tại trong lúc màn hình đó còn mở. Dùng khi cần hiển thị UI, dialog, hoặc lấy theme của đúng màn hình đó.
• Application Context: giống như "cả toà nhà" — tồn tại suốt thời gian app còn chạy, không gắn với một màn hình cụ thể nào. Dùng cho thứ sống lâu như một object dùng chung toàn app, hoặc khởi tạo thư viện.

Khi app của bạn ở dưới nền một thời gian, Android có thể dọn hẳn (kill) toàn bộ tiến trình app để lấy lại RAM cho việc khác — mạnh tay hơn nhiều so với chuyện xoay màn hình. Điều khó chịu là: khi người dùng mở lại app, họ mong thấy đúng màn hình như lúc họ rời đi, dù thực chất app đang khởi động lại từ đầu.

Vì ViewModel cũng bị xoá sạch trong trường hợp này (nó chỉ sống qua xoay màn hình, không sống qua bị dọn hẳn), bạn cần một chỗ lưu "bền" hơn: onSaveInstanceState (cách làm gốc, có từ lâu), SavedStateHandle (bản bọc gọn hơn, dùng trong ViewModel), hoặc rememberSaveable (bản dành cho Compose). Ba cái này thực chất dùng chung một cơ chế phía dưới — chỉ khác cách bạn cầm nó trên tay.

Hãy tưởng tượng cụ thể hơn: ngay TRƯỚC KHI Android có thể huỷ Activity của bạn (mà không phải do bạn tự đóng), hệ thống đưa cho bạn một cái hộp nhỏ rỗng gọi là Bundle, và gọi hàm onSaveInstanceState(outState: Bundle) — đây là lúc bạn nhanh tay nhét vài thứ quan trọng vào hộp. Sau đó, nếu Activity thật sự bị tạo lại (do xoay màn hình, hoặc bị dọn rồi mở lại), cái hộp đó được trả về cho bạn ngay trong onCreate(savedInstanceState: Bundle?) — bạn mở hộp ra và khôi phục lại những gì đã lưu.

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("search_query", currentQuery)   // nhét vào hộp
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // mở hộp ra, nếu không có hộp (lần đầu mở app) thì dùng chuỗi rỗng
    currentQuery = savedInstanceState?.getString("search_query") ?: ""
}

Một điểm dễ hiểu lầm: hàm này KHÔNG được gọi khi người dùng TỰ Ý đóng màn hình — ví dụ bấm nút Back hoặc bạn tự gọi finish(). Lý do rất hợp lý: nếu người dùng cố tình rời khỏi màn hình đó, Android hiểu là bạn không cần quay lại trạng thái cũ nữa. Nó chỉ được gọi khi Activity có thể bị huỷ NGOÀI Ý MUỐN của người dùng — xoay màn hình, đổi ngôn ngữ, hoặc app bị đẩy xuống nền rồi có khả năng bị dọn.

Vậy SavedStateHandle khác gì? Về bản chất nó dùng đúng cái hộp này, nhưng Google đóng gói lại cho tiện hơn: bạn không cần tự override onSaveInstanceState/onCreate, mà chỉ cần đọc/ghi qua SavedStateHandle như một cái Map ngay trong ViewModel — mọi việc "nhét vào hộp" và "mở hộp ra đúng lúc" được làm tự động phía sau. Còn rememberSaveable trong Compose cũng là một lớp vỏ tương tự, dành riêng cho biến bạn khai báo trong composable.