State Restoration trong ứng dụng di động: khái niệm, cơ chế và nguyên lý hoạt động

State Restoration là gì?

State Restoration (khôi phục trạng thái) là cơ chế hệ thống cho phép lưu trạng thái hiện tại của giao diện người dùng ứng dụng và khôi phục sau khi kết thúc hoặc khởi động lại. Khi người dùng thu nhỏ ứng dụng hoặc hệ thống đóng ứng dụng để giải phóng tài nguyên, State Restoration sẽ ghi lại các tham số UI chính và lưu chúng vào bộ nhớ được mã hóa.

Nếu không có State Restoration, người dùng sẽ mất tất cả dữ liệu chưa lưu khi chuyển đổi giữa các ứng dụng. Ví dụ: biểu mẫu phản hồi đã điền, truy vấn tìm kiếm dài hoặc danh sách tin tức đã xem một phần — tất cả đều biến mất khi khởi động lại. State Restoration giải quyết vấn đề này bằng cách tự động ghi lại trạng thái của ViewController hoặc Activity tại thời điểm thu nhỏ.

Cơ chế hoạt động ở cấp độ hệ thống và được hỗ trợ bởi cả hai nền tảng di động chính. iOS cung cấp State Restoration qua NSUserActivity và giao thức UIStateRestoring, trong khi Android cung cấp qua SavedStateHandle trong các thành phần kiến trúc Jetpack và ViewModel. Cách triển khai khác nhau nhưng khái niệm là giống hệt nhau.

State Restoration hoạt động như thế nào?

Quy trình State Restoration được chia thành hai giai đoạn: lưu và khôi phục. Trong giai đoạn lưu, hệ thống gọi các phương thức vòng đời tương ứng, trong đó ứng dụng phải tuần tự hóa trạng thái UI hiện tại thành một biểu diễn nhỏ gọn. Trong giai đoạn khôi phục, hệ thống trả lại dữ liệu đã lưu và ứng dụng giải tuần tự hóa để khôi phục UI.

Cơ chế lưu trạng thái

Việc lưu được hệ thống khởi tạo khi ứng dụng chuyển sang nền hoặc nhận được tín hiệu sắp kết thúc. Trên iOS, phương thức encodeRestorableState của UIViewController được gọi; trên Android, onSaveInstanceState của Activity hoặc lưu qua SavedStateHandle được kích hoạt. Dữ liệu được tuần tự hóa thành định dạng hỗ trợ các kiểu nguyên thủy: chuỗi, số, mảng byte và đối tượng Parcelable.

Lượng dữ liệu được lưu phải ở mức tối thiểu — hệ thống áp đặt giới hạn về kích thước của gói trạng thái đã lưu. Trên Android, giới hạn là khoảng 50 KB cho mỗi tiến trình. Vượt quá giới hạn sẽ gây ra ngoại lệ TransactionTooLargeException. Do đó, các kiến trúc sư khuyến nghị chỉ lưu mã định danh và khóa, và tải dữ liệu đầy đủ từ bộ nhớ liên tục khi khôi phục.

Khôi phục UI từ trạng thái đã lưu

Trong quá trình khôi phục, hệ thống truyền gói dữ liệu đã lưu cho ứng dụng tại thời điểm khởi động. Trên iOS, phương thức decodeRestorableState được gọi; trên Android, onRestoreInstanceState hoặc đọc từ SavedStateHandle được sử dụng. Ứng dụng trích xuất mã định danh và khóa từ gói và khôi phục UI: vị trí cuộn, các mục đã chọn, dữ liệu đã nhập.

Điều quan trọng cần lưu ý là việc khôi phục có thể xảy ra trong một tiến trình mới. Nếu ứng dụng đã được giải phóng hoàn toàn khỏi bộ nhớ, tiến trình được tạo lại và tất cả các đối tượng trong bộ nhớ đều không tồn tại. Do đó, trạng thái phải có thể tuần tự hóa và độc lập với ngữ cảnh thời gian chạy của phiên trước. Điều này đặc biệt quan trọng đối với các biểu mẫu lớn có nhiều trường nhập liệu và giao diện nhiều trang dài.

class MainActivity : AppCompatActivity() {
    private var searchQuery: String = ""

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("search_query", searchQuery)
    }

    override fun onRestoreInstanceState(savedState: Bundle) {
        super.onRestoreInstanceState(savedState)
        searchQuery = savedState.getString("search_query", "")!!
        restoreSearchUI(searchQuery)
    }
}

State Restoration trên iOS và Android

Việc triển khai State Restoration khác nhau đáng kể giữa các nền tảng. iOS sử dụng cách tiếp cận khai báo qua storyboard và giao thức UIKit, trong khi Android sử dụng cách tiếp cận mệnh lệnh qua các phương thức vòng đời của Activity và các thành phần kiến trúc Jetpack. Việc lựa chọn cách tiếp cận phụ thuộc vào nền tảng mục tiêu và kiến trúc ứng dụng.

State Restoration trên iOS (UIKit)

Trên iOS, State Restoration được xây dựng trên ba thành phần: UIApplication quản lý quy trình tổng thể, UIViewController triển khai giao thức UIStateRestoring và NSUserActivity lưu trữ dữ liệu để khôi phục điều hướng. Để kích hoạt, bạn cần đặt restorationIdentifier trên UIViewController và triển khai encodeRestorableState cũng như decodeRestorableState.

iOS tự động lưu trạng thái của bộ điều khiển điều hướng (UINavigationController) và tất cả ViewController lồng nhau nếu chúng có restorationIdentifier được đặt. Hệ thống quản lý ngăn xếp điều hướng và khôi phục về trạng thái ban đầu. Tuy nhiên, dữ liệu bên trong bộ điều khiển (văn bản đã nhập, vị trí cuộn) phải được nhà phát triển lưu một cách rõ ràng.

State Restoration trên Android (SavedStateHandle)

Trên Android, cách tiếp cận hiện đại cho State Restoration được xây dựng trên SavedStateHandle — một thành phần từ thư viện AndroidX Lifecycle. SavedStateHandle có thể truy cập được bên trong ViewModel và tự động lưu và khôi phục dữ liệu khi thay đổi cấu hình (xoay màn hình) và khởi động lại tiến trình. Dữ liệu được lưu trữ trong Bundle và tự động được tuần tự hóa.

SavedStateHandle hoạt động như một kho lưu trữ khóa-giá trị với hỗ trợ LiveData. Khi thay đổi cấu hình, dữ liệu được tự động lưu và khôi phục. Để hỗ trợ khởi động lại tiến trình, ViewModel phải được tạo qua SavedStateViewModelFactory — điều này cho phép ViewModel tồn tại sau khi ứng dụng kết thúc hoàn toàn.

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

    companion object {
        private val KEY_QUERY = string("search_query")
    }

    fun getSearchQuery(): String? = savedStateHandle[KEY_QUERY]

    fun saveSearchQuery(query: String) {
        savedStateHandle[KEY_QUERY] = query
    }
}

Triển khai State Restoration trong mã

Việc triển khai thực tế State Restoration đòi hỏi phải xem xét một số khía cạnh: chọn bộ nhớ phù hợp, xác định lượng dữ liệu cần lưu và kiểm tra các kịch bản kết thúc khác nhau. Hãy xem qua triển khai từng bước cho ứng dụng Flutter sử dụng gói state_restoration.

class RestorableSearchField extends RestorableProperty<String> {
  String _value = '';

  @override
  String get value => _value;

  @override
  void set value(String newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String? toPrimitives() => _value;

  @override
  void fromPrimitives(String? data) {
    _value = data ?? '';
  }
}

Khi triển khai, điều quan trọng là phải nhớ ranh giới lưu. Không phải mọi trường UI đều cần khôi phục. Vị trí cuộn trong danh sách dài — có. Trạng thái hoạt ảnh tạm thời — không. Nhà phát triển phải có ý thức lựa chọn dữ liệu nào quan trọng đối với trải nghiệm người dùng và dữ liệu nào có thể được đặt lại một cách an toàn mà không làm mất sự tiện lợi.

Kiểm tra State Restoration là một nhiệm vụ riêng biệt đòi hỏi mô phỏng việc kết thúc tiến trình. Trên Android, điều này có thể được thực hiện qua lệnh adb shell am kill; trên iOS, qua mô phỏng kết thúc trong Xcode. Các framework kiểm thử UI như Espresso và XCTest cung cấp các phương thức đặc biệt để xác minh khôi phục trạng thái.

Thực hành tốt nhất cho State Restoration

Quy tắc đầu tiên — lưu mã định danh, không phải dữ liệu. Thay vì lưu toàn bộ đối tượng với hàng trăm trường, hãy lưu mã định danh duy nhất của nó và khi khôi phục, hãy tải dữ liệu thực tế từ cơ sở dữ liệu hoặc API. Điều này tiết kiệm không gian trong Bundle và đảm bảo dữ liệu luôn mới tại thời điểm khôi phục.

Quy tắc thứ hai — kiểm tra tất cả các kịch bản. Kiểm tra khôi phục sau khi xoay màn hình, sau khi thu nhỏ và quay lại một giờ sau, sau khi hệ thống kết thúc ứng dụng do thiếu bộ nhớ. Mỗi kịch bản có thể hoạt động khác nhau tùy thuộc vào trạng thái của hệ điều hành và tài nguyên khả dụng.

Quy tắc thứ ba — sử dụng cơ chế hệ thống, không phải cơ chế tùy chỉnh. iOS và Android cung cấp các API tích hợp cho State Restoration được tối ưu hóa cho nền tảng cụ thể của chúng. Việc triển khai tùy chỉnh qua SharedPreferences hoặc UserDefaults có thể dẫn đến các vấn đề đồng bộ hóa và hành vi không mong muốn trong quá trình khôi phục.

Quy tắc thứ tư — xử lý trường hợp không có trạng thái. Khi khởi chạy lần đầu hoặc sau khi xóa dữ liệu, trạng thái có thể không tồn tại. UI phải hoạt động chính xác ở trạng thái ban đầu mà không gây ra ngoại lệ. Kiểm tra tất cả dữ liệu đã lưu để tìm null trước khi sử dụng và cung cấp các giá trị mặc định.

Quy tắc thứ năm — ghi lại các khóa đã lưu. Khi một dự án có hàng chục màn hình và mỗi màn hình lưu nhiều trường, nếu không có quản lý khóa tập trung sẽ xảy ra hỗn loạn. Tạo một lớp hoặc tệp duy nhất với các hằng số khóa cho State Restoration trong mỗi mô-đun. Điều này đơn giản hóa việc bảo trì và ngăn chặn việc ghi đè dữ liệu vô tình trong quá trình tái cấu trúc.