Пагинация в мобильной разработке — что это, виды и принцип работы

Что такое пагинация?

Пагинация (от англ. pagination — постраничное деление) — это техника разбиения большого набора данных на последовательные порции (страницы). В мобильных приложениях пагинация используется при загрузке списков сообщений, ленты новостей, каталогов товаров, истории заказов и любых других коллекций с потенциально неограниченным числом записей.

Без пагинации приложение вынуждено загружать все данные сразу, что приводит к долгому ожиданию, большому расходу трафика и нестабильной работе на слабых устройствах. API-запрос с пагинацией возвращает только одну порцию данных и мета-информацию для загрузки следующей — таким образом, приложение контролирует объём получаемой информации.

Основные метрики пагинации: размер страницы (page size) — количество записей на одной странице (обычно 10-50), и номер страницы или курсор — указатель на текущую позицию в наборе. Выбор размера страницы зависит от типа данных: для компактных элементов (названия) достаточно 20-30, для карточек с изображениями — 10-15.

Зачем нужна пагинация в мобильных приложениях

Мобильные устройства имеют ограниченные ресурсы: объём оперативной памяти, скорость процессора и лимиты трафика. Пагинация решает три ключевые задачи: снижение потребления памяти (в памяти хранятся только видимые элементы), ускорение первого отображения (первая порция грузится быстрее всего набора) и экономия трафика (данные подгружаются только когда пользователь прокручивает список).

Основные виды пагинации

Существует четыре основных вида пагинации, каждый из которых решает специфические задачи. Выбор метода зависит от требований к согласованности данных, архитектуры API, типа хранилища и допустимой сложности реализации на клиенте и сервере.

Когда какой тип использовать

Offset-пагинация подходит для статических или редко обновляемых наборов данных, когда важна простая реализация. Cursor и Keyset — для динамических данных с частыми вставками. Time-based — для хронологических лент, где записи упорядочены по времени создания. GraphQL-стандарт Relay использует cursor-пагинацию как единственный рекомендуемый метод.

Offset-пагинация: преимущества и недостатки

Offset-пагинация — самый простой вид постраничной загрузки. Клиент передаёт параметры page и limit (или offset и limit), сервер применяет SQL OFFSET и LIMIT. Например, page=2, limit=20 вернёт записи с 21 по 40. Этот метод интуитивно понятен и легко реализуется на любом стеке.

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
    }

Проблема несогласованности данных

Главный недостаток Offset-пагинации — проблема пропущенных и дублирующихся записей. Если между двумя запросами в таблицу добавляются новые записи, OFFSET смещается: пользователь может увидеть одну запись дважды или пропустить новую. Это критично для лент новостей и чатов, где важна консистентность.

Другая проблема — падение производительности на больших OFFSET. База данных вынуждена сканировать и пропускать первые offset записей перед возвратом результата. При offset=100000 даже с LIMIT 20 сервер потратит заметное время на сканирование. PostgreSQL и MySQL демонстрируют линейное падение скорости с ростом OFFSET.

Когда Offset всё ещё хорош

Offset-пагинация остаётся лучшим выбором для: административных панелей (данные меняются редко, нужна навигация по страницам), отчётов и исторических логов (фиксированный срез данных), каталогов с фильтрацией (можно перейти на любую страницу). Также Offset проще всего реализовать на клиенте — RecyclerView с Paging 3 поддерживает его из коробки.

Keyset и Time-based пагинация

Keyset-пагинация использует уникальный ключ (обычно первичный ключ) для фильтрации записей. Вместо OFFSET запрос использует WHERE id > last_seen_id. Это обеспечивает стабильную производительность независимо от количества записей и отсутствие дубликатов при вставках, так как новые записи всегда имеют больший id.

-- Offset-пагинация (проблемная)
SELECT * FROM posts
ORDER BY id
LIMIT 20 OFFSET 100;

-- Keyset-пагинация (стабильная)
SELECT * FROM posts
WHERE id > 100
ORDER BY id
LIMIT 20;

Time-based пагинация

Time-based пагинация (или cursor по времени) использует временную метку created_at для навигации. Клиент передаёт timestamp последней загруженной записи, сервер возвращает записи, созданные до или после этой метки. Метод популярен в социальных сетях и лентах новостей, где порядок записей определяется временем публикации.

Особенность Time-based пагинации — возможны дубликаты, если две записи созданы в одну миллисекунду. Для устранения этой проблемы комбинируют time-based ключ с уникальным id: WHERE (created_at, id) < (last_time, last_id). Такой составной курсор гарантирует уникальность каждой записи и точный порядок.

Сравнение Keyset и Time-based

Keyset-пагинация требует столбца с уникальным и монотонно возрастающим значением (автоинкрементный id, UUID v7). Time-based подходит для любых таблиц с created_at, но требует дополнительной обработки дубликатов. Основное различие: Keyset стабильно работает при любых операциях вставки, а Time-based чувствителен к одинаковым временным меткам.

Как выбрать тип пагинации для проекта

Выбор типа пагинации зависит от характера данных и требований к пользовательскому опыту. Ниже приведены рекомендации для типовых сценариев в мобильной разработке. Универсального решения не существует — каждый метод имеет область применения, в которой он оптимален.

• Чат / мессенджер — Cursor-пагинация (по id сообщения). Новые сообщения добавляются сверху, курсор не сбивается.
• Лента новостей — Time-based пагинация (по created_at). Записи упорядочены по времени, важна хронология.
• Каталог товаров — Offset-пагинация. Пользователь может перейти на конкретную страницу, данные меняются редко.
• История заказов — Cursor-пагинация. Стабильность важна, так как новые заказы добавляются между загрузками.
• Комментарии — Keyset-пагинация. Каждый комментарий имеет уникальный id, большие объёмы без дубликатов.

Реализация на Android с Paging 3

Библиотека Android Paging 3 поддерживает все типы пагинации через PagingSource. Для Offset — PagingSource с ключом Int (page), для Cursor — с ключом String или Long (cursor). PagingSource автоматически управляет загрузкой, кэшированием и повторными попытками при ошибках.

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
        }
    }
}

Рекомендации по размеру страницы

Размер страницы влияет на скорость загрузки и восприятие производительности. Для мобильных приложений оптимальный диапазон — 10-25 элементов на страницу. Меньше 10 — слишком частые запросы к API и дёрганный скролл. Больше 25 — долгая загрузка первой порции на медленных сетях.

Для изображений и видео размер страницы уменьшают до 5-10, так как каждый элемент требует дополнительного времени на загрузку медиа. Для списков с текстовыми элементами (комментарии, логи) размер можно увеличить до 30-50 записей. Рекомендуется делать размер страницы настраиваемым через API, чтобы клиент мог адаптироваться под разные условия сети.