Phân trang trong phát triển di động — định nghĩa, loại và nguyên lý hoạt động

Phân trang là gì?

Phân trang (từ tiếng Latin pagination — chia trang) là kỹ thuật chia một tập dữ liệu lớn thành các phần tuần tự (trang). Trong ứng dụng di động, phân trang được sử dụng khi tải danh sách tin nhắn, bảng tin, danh mục sản phẩm, lịch sử đơn hàng và bất kỳ bộ sưu tập nào có số lượng bản ghi tiềm năng không giới hạn.

Không có phân trang, ứng dụng buộc phải tải toàn bộ dữ liệu cùng một lúc, dẫn đến thời gian chờ lâu, tiêu tốn nhiều băng thông và hiệu suất không ổn định trên thiết bị yếu. Yêu cầu API có phân trang chỉ trả về một phần dữ liệu và thông tin meta để tải phần tiếp theo — do đó, ứng dụng kiểm soát được lượng thông tin nhận được.

Các chỉ số chính của phân trang: kích thước trang (page size) — số bản ghi trên một trang (thường 10–50), và số trang hoặc con trỏ — con trỏ đến vị trí hiện tại trong tập dữ liệu. Việc chọn kích thước trang phụ thuộc vào loại dữ liệu: đối với phần tử nhỏ gọn (tên) 20–30 là đủ, đối với thẻ có hình ảnh — 10–15.

Tại sao cần phân trang trong ứng dụng di động

Thiết bị di động có tài nguyên hạn chế: RAM, tốc độ xử lý và giới hạn băng thông. Phân trang giải quyết ba nhiệm vụ chính: giảm tiêu thụ bộ nhớ (chỉ lưu các phần tử hiển thị trong bộ nhớ), tăng tốc hiển thị lần đầu (phần đầu tiên tải nhanh hơn toàn bộ tập dữ liệu) và tiết kiệm băng thông (dữ liệu chỉ được tải khi người dùng cuộn danh sách).

Các loại phân trang chính

Có bốn loại phân trang chính, mỗi loại giải quyết các nhiệm vụ cụ thể. Việc chọn phương pháp phụ thuộc vào yêu cầu về tính nhất quán dữ liệu, kiến trúc API, loại lưu trữ và độ phức tạp triển khai chấp nhận được ở phía máy khách và máy chủ.

Khi nào sử dụng loại nào

Phân trang Offset phù hợp với tập dữ liệu tĩnh hoặc hiếm khi cập nhật, khi sự đơn giản trong triển khai là quan trọng. Cursor và Keyset dành cho dữ liệu động có nhiều thao tác chèn. Phân trang dựa trên thời gian dành cho bảng tin theo trình tự thời gian, nơi các bản ghi được sắp xếp theo thời gian tạo. Tiêu chuẩn GraphQL Relay sử dụng phân trang con trỏ là phương pháp duy nhất được khuyến nghị.

Phân trang Offset: ưu điểm và nhược điểm

Phân trang Offset là loại tải theo trang đơn giản nhất. Máy khách gửi tham số page và limit (hoặc offset và limit), máy chủ áp dụng SQL OFFSET và LIMIT. Ví dụ: page=2, limit=20 trả về các bản ghi từ 21 đến 40. Phương pháp này trực quan và dễ triển khai trên bất kỳ nền tảng nào.

from fastapi import FastAPI, Query

app = FastAPI()

@app.get("/items")
async def get_items(
    page: int = Query(default=1, ge=1),
    limit: int = Query(default=20, le=100)
):
    offset = (page - 1) * limit
    items = await fetch_items(offset, limit)
    total = await count_items()
    return {
        "items": items,
        "total": total,
        "page": page,
        "pages": (total + limit - 1) // limit
    }

Vấn đề không nhất quán dữ liệu

Nhược điểm chính của phân trang Offset là vấn đề bản ghi bị bỏ sót và trùng lặp. Nếu các bản ghi mới được thêm vào bảng giữa hai yêu cầu, OFFSET bị dịch chuyển: người dùng có thể thấy cùng một bản ghi hai lần hoặc bỏ lỡ một bản ghi mới. Điều này rất quan trọng đối với bảng tin và trò chuyện, nơi tính nhất quán là quan trọng.

Một vấn đề khác là suy giảm hiệu suất trên các giá trị OFFSET lớn. Cơ sở dữ liệu phải quét và bỏ qua các bản ghi offset đầu tiên trước khi trả về kết quả. Với offset=100000 ngay cả với LIMIT 20, máy chủ sẽ mất thời gian đáng kể để quét. PostgreSQL và MySQL cho thấy tốc độ giảm tuyến tính khi OFFSET tăng.

Khi nào Offset vẫn tốt

Phân trang Offset vẫn là lựa chọn tốt nhất cho: bảng quản trị (dữ liệu hiếm khi thay đổi, cần điều hướng trang), báo cáo và nhật ký lịch sử (ảnh chụp dữ liệu cố định), danh mục có bộ lọc (có thể chuyển đến bất kỳ trang nào). Offset cũng dễ triển khai nhất ở phía máy khách — RecyclerView với Paging 3 hỗ trợ sẵn.

Phân trang Keyset và dựa trên thời gian

Phân trang Keyset sử dụng khóa duy nhất (thường là khóa chính) để lọc bản ghi. Thay vì OFFSET, truy vấn sử dụng WHERE id > last_seen_id. Điều này đảm bảo hiệu suất ổn định bất kể số lượng bản ghi và không có trùng lặp khi chèn, vì bản ghi mới luôn có id lớn hơn.

-- Phân trang Offset (có vấn đề)
SELECT * FROM posts
ORDER BY id
LIMIT 20 OFFSET 100;

-- Phân trang Keyset (ổn định)
SELECT * FROM posts
WHERE id > 100
ORDER BY id
LIMIT 20;

Phân trang dựa trên thời gian

Phân trang dựa trên thời gian (hoặc con trỏ theo thời gian) sử dụng dấu thời gian created_at để điều hướng. Máy khách gửi dấu thời gian của bản ghi cuối cùng đã tải và máy chủ trả về các bản ghi được tạo trước hoặc sau dấu thời gian đó. Phương pháp này phổ biến trong mạng xã hội và bảng tin nơi thứ tự bản ghi được xác định bởi thời gian đăng.

Một đặc điểm của phân trang dựa trên thời gian là có thể xảy ra trùng lặp nếu hai bản ghi được tạo trong cùng một mili giây. Để loại bỏ vấn đề này, hãy kết hợp khóa dựa trên thời gian với id duy nhất: WHERE (created_at, id) < (last_time, last_id). Con trỏ kết hợp như vậy đảm bảo tính duy nhất của mỗi bản ghi và thứ tự chính xác.

So sánh Keyset và dựa trên thời gian

Phân trang Keyset yêu cầu một cột có giá trị duy nhất và tăng đơn điệu (id tự tăng, UUID v7). Phân trang dựa trên thời gian phù hợp với bất kỳ bảng nào có created_at nhưng cần xử lý trùng lặp bổ sung. Sự khác biệt chính: Keyset hoạt động ổn định trong mọi thao tác chèn, trong khi dựa trên thời gian nhạy cảm với các dấu thời gian giống nhau.

Cách chọn loại phân trang cho dự án của bạn

Việc chọn loại phân trang phụ thuộc vào bản chất của dữ liệu và yêu cầu về trải nghiệm người dùng. Dưới đây là các khuyến nghị cho các tình huống điển hình trong phát triển di động. Không có giải pháp phổ quát — mỗi phương pháp có một lĩnh vực mà nó là tối ưu.

• Trò chuyện / Nhắn tin — Phân trang Cursor (theo id tin nhắn). Tin nhắn mới xuất hiện ở trên cùng, con trỏ không bị lệch.
• Bảng tin — Phân trang dựa trên thời gian (theo created_at). Bản ghi được sắp xếp theo thời gian, trình tự thời gian quan trọng.
• Danh mục sản phẩm — Phân trang Offset. Người dùng có thể chuyển đến trang cụ thể, dữ liệu hiếm khi thay đổi.
• Lịch sử đơn hàng — Phân trang Cursor. Tính ổn định quan trọng vì đơn hàng mới được thêm vào giữa các lần tải.
• Bình luận — Phân trang Keyset. Mỗi bình luận có id duy nhất, khối lượng lớn không trùng lặp.

Triển khai trên Android với Paging 3

Thư viện Android Paging 3 hỗ trợ tất cả các loại phân trang thông qua PagingSource. Đối với Offset — PagingSource với khóa Int (page), đối với Cursor — với khóa String hoặc Long (cursor). PagingSource tự động quản lý việc tải, lưu cache và thử lại khi có lỗi.

class PostPagingSource(
    private val api: PostApi
) : PagingSource<Long, Post>() {

    override suspend fun load(
        params: LoadParams<Long>
    ): LoadResult<Long, Post> {
        val cursor = params.key ?: Long.MAX_VALUE
        return try {
            val response = api.getPosts(cursor, params.loadSize)
            LoadResult.Page(
                data = response.items,
                prevKey = null,
                nextKey = response.items.lastOrNull()?.id
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }

    override fun getRefreshKey(state: PagingState<Long, Post>): Long? {
        return state.anchorPosition?.let {
            state.closestItemToPosition(it)?.id
        }
    }
}

Khuyến nghị về kích thước trang

Kích thước trang ảnh hưởng đến tốc độ tải và cảm nhận về hiệu suất. Đối với ứng dụng di động, phạm vi tối ưu là 10–25 phần tử trên mỗi trang. Ít hơn 10 dẫn đến quá nhiều yêu cầu API và cuộn giật cục. Nhiều hơn 25 dẫn đến tải phần đầu tiên chậm trên mạng chậm.

Đối với hình ảnh và video, giảm kích thước trang xuống 5–10, vì mỗi phần tử cần thêm thời gian để tải phương tiện. Đối với danh sách văn bản (bình luận, nhật ký), kích thước có thể tăng lên 30–50 bản ghi. Nên làm cho kích thước trang có thể cấu hình được qua API để máy khách có thể thích ứng với các điều kiện mạng khác nhau.