Offset Pagination в мобильной разработке: что это и как реализовать

Что такое Offset Pagination?

Offset Pagination — это метод постраничного разделения данных, при котором клиентский запрос содержит два параметра: offset (сколько записей пропустить) и limit (сколько записей вернуть). Сервер выполняет SQL-запрос с OFFSET и LIMIT, пропускает указанное количество строк и возвращает результирующий набор фиксированного размера.

Метод появился в реляционных базах данных как простейший способ организации навигации по страницам и был перенесён в HTTP API вместе с развитием REST-архитектуры. Offset Pagination не требует хранения состояния на сервере — каждый запрос независим и содержит всю информацию для выборки.

По данным исследования API-дизайна от Postman (2025), offset-пагинация используется в 72% публичных REST API, что делает её доминирующим стандартом несмотря на известные ограничения производительности на больших объёмах данных.

Структура запроса и ответа

Типичный REST-запрос с Offset Pagination включает query-параметры offset и limit. Ответ содержит список записей нужной страницы и метаданные для построения интерфейса навигации.

Параметр limit ограничивает количество возвращаемых записей и защищает сервер и клиента от избыточной загрузки. Типовые значения limit — от 10 до 50 записей на страницу в зависимости от сложности данных.

data class PageRequest(
    val offset: Int,
    val limit: Int
)

data class PageResponse<T>(
    val items: List<T>,
    val total: Int,
    val hasMore: Boolean
)

fun RetrofitApi.fetchPage(request: PageRequest): Call<PageResponse<Item>>

Как работает Offset Pagination

Offset Pagination преобразуется в SQL-запрос с конструкциями OFFSET и FETCH NEXT (или LIMIT в MySQL/SQLite). Сервер базы данных сканирует таблицу, пропускает количество строк, равное offset, и возвращает следующие limit строк. Чем больше offset, тем дольше выполняется запрос.

Проблема производительности связана с тем, что база данных не может перейти сразу к позиции offset — она должна прочитать и отбросить все предыдущие строки. При offset = 100000 и limit = 20 СУБД прочитает 100020 строк и вернёт только 20.

SQL-запрос под капотом

SQL — язык, на котором сервер выполняет offset-пагинацию. В PostgreSQL и MySQL используется LIMIT, в SQL Server и Oracle — OFFSET...FETCH. Разные СУБД оптимизируют этот запрос по-своему, но фундаментальная проблема сканирования остаётся той же.

SELECT id, title, created_at
FROM articles
ORDER BY created_at DESC
OFFSET 100000 ROWS
FETCH NEXT 20 ROWS ONLY;

Проблема консистентности

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

Представим таблицу из 100 записей с limit = 20. На странице 1 пользователь видит записи 1-20. Администратор добавляет 5 новых записей. На странице 2 пользователь видит записи 26-45 вместо ожидаемых 21-40 — записи 21-25 пропущены, а записи 21-25 из предыдущего набора — дублированы на странице 1.

Offset vs Cursor-based: сравнение подходов

Cursor-based pagination — альтернатива Offset Pagination, использующая указатель на последнюю запись текущей страницы. Вместо числового смещения клиент передаёт идентификатор последней полученной записи, а сервер возвращает следующие N записей после неё.

Cursor-based подход решает проблему консистентности: положение курсора не меняется при вставках или удалениях, так как курсор ссылается на конкретную запись, а не на позицию. Однако он сложнее в реализации — требуется уникальное сортируемое поле (обычно ID или timestamp).

Выбор между подходами зависит от требований к интерфейсу пользователя. Если нужна навигация с номерами страниц и прямым переходом — Offset Pagination проще. Для бесконечного скролла или ленты новостей предпочтительнее курсоры.

Keyset pagination

Keyset pagination — разновидность cursor-based подхода, при которой фильтрация выполняется по уникальному ключу с помощью WHERE вместо OFFSET. SQL-запрос использует условие WHERE id > lastId, что позволяет базе данных использовать индекс без сканирования отброшенных строк.

По данным PostgreSQL Wiki, keyset pagination выполняется в 100-1000 раз быстрее offset-запроса при больших смещениях, так как индексное сканирование заменяет полный обход таблицы. Недостаток — невозможность прыжка на произвольную страницу без последовательного прохода.

Когда использовать Offset Pagination

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

Для мобильных приложений offset-пагинация подходит при загрузке исторических данных, где вставки новых записей редки или невозможны — например, история заказов пользователя, список завершённых задач, архив транзакций. В этих сценариях проблема консистентности не возникает.

Не рекомендуется использовать Offset Pagination для лент социальных сетей, списков комментариев, чатов и других динамических наборов с частыми вставками. В этих случаях пропуски и дубликаты записей ухудшают пользовательский опыт и требуют дополнительной логики дедупликации на клиенте.

Гибридный подход

Гибридная пагинация комбинирует offset и cursor: первый запрос использует offset для показа начальной страницы, а последующие — cursor для подгрузки бесконечного скролла. Этот подход реализуется в Instagram и Twitter, где первая страница загружается через cursor, но offset используется для расчёта позиции при возврате к предыдущему просмотру.

Реализация гибридного подхода требует хранения виртуальной позиции пользователя на клиенте и согласования двух механизмов пагинации на сервере. По данным блога Instagram Engineering, их команда использует cursor-based пагинацию с дополнительным полем startCursor, которое заменяет offset для начальной загрузки.

Offset Pagination в мобильных приложениях

Мобильные приложения используют Offset Pagination в паре с Retrofit/OkHttp на Android и URLSession/Combine на iOS. Типичный паттерн — загрузка следующей страницы при скролле к концу списка через RecyclerView.OnScrollListener или UICollectionView prefetching.

Реализация offset-пагинации на мобильном клиенте включает три компонента: менеджер пагинации (хранит текущий offset и hasMore), адаптер списка (отображает элементы и индикатор загрузки) и репозиторий (выполняет запросы и обрабатывает ошибки). Android Jetpack предлагает Paging 3 Library, которая поддерживает как offset, так и cursor-based пагинацию из коробки.

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

Paging 3 — библиотека Android Jetpack для постраничной загрузки данных. Она инкапсулирует логику пагинации, включая отслеживание offset, управление состоянием загрузки и автоматическую подгрузку при скролле. PagingSource определяет ключи для следующей и предыдущей страниц.

class OffsetPagingSource(
    private val api: ApiService,
    private val limit: Int = 20
) : PagingSource<Int, Item>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Item> {
        val offset = params.key ?: 0
        return try {
            val response = api.getItems(offset, limit)
            LoadResult.Page(
                data = response.items,
                prevKey = null,
                nextKey = if (response.hasMore) offset + limit else null
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }
}

PagingSource определяет ключи prevKey и nextKey для постраничной навигации. При offset-пагинации prevKey всегда null (нельзя перейти на предыдущую страницу без сохранения истории), а nextKey увеличивается на limit при каждой загрузке, пока сервер не вернёт hasMore = false. Это простая и предсказуемая модель для мобильных списков.

Типовые ошибки при Offset Pagination

Первая ошибка — полагаться на порядок записей без сортировки. Offset Pagination требует стабильной сортировки ORDER BY по уникальному полю. Без неё СУБД может возвращать записи в произвольном порядке, что приводит к случайным дубликатам и пропускам между страницами.

Вторая ошибка — использовать offset для расчёта номера страницы в UI. Формула page = offset / limit + 1 работает только при условии, что ни одна запись не была удалена или добавлена между загрузками. При динамических данных номер страницы становится неточным, и пользователь видит некорректную информацию.

Третья ошибка — игнорировать таймауты запросов с большим offset. При offset свыше 100000 запрос может выполняться десятки секунд, блокируя UI и потребляя ресурсы сервера. Рекомендуется устанавливать максимальное значение offset на уровне API (например, 10000) и использовать cursor-based пагинацию для больших объёмов.

Четвёртая ошибка — не добавлять total count в ответ. Без общего количества записей клиент не может отобразить число страниц и реализовать пагинацию с номерами. Однако вычисление COUNT(*) на больших таблицах тоже дорого — для наборов свыше 100000 записей используйте приблизительные оценки или ограничьте максимальное значение total.