Как работает offline-режим в мобильных приложениях

1) Что такое offline-режим и зачем он нужен

Offline-режим — это способность приложения работать без сети (или при нестабильном интернете), а затем синхронизироваться, когда связь появляется. Он:

снижает отказы и повышает удержание;
ускоряет первый экран (данные уже локально);
позволяет выполнять критичные действия (черновики, просмотр контента, часть операций) «в поле».

2) Слои офлайн-архитектуры (в любом стеке)

1. Локальное хранилище данных

Мобильные нативные: SQLite/Room (Android), Core Data/SQLite (iOS), Realm, Key-Value (SharedPreferences/UserDefaults).

Веб/PWA: IndexedDB (поверх — Dexie/LocalForage), Cache Storage для статики.

2. Кэш статики (App Shell)

Иконки, шрифты, CSS/JS, базовые шаблоны экранов.

3. Очередь операций (Outbox)

Запросы «на запись» (создать/изменить/удалить) складываются в очередь и уходят на сервер при появлении сети.

4. Слой синхронизации

Политики мерджа, версии, дедупликация, ретраи, бэкофф.

5. Сигналы состояния сети

NetInfo/Reachability/API браузера для переключения UI между online/offline/limbo.

3) Как это выглядит на iOS/Android

Кэш и БД: структура данных зеркалит основные API-ответы (нормализуйте сущности).

Офлайн-черновики: формы и действия пишутся в локальную БД с флагами `pending/sent/failed`.

Синхронизация: фоновая задача периодически читает outbox и отправляет партии (batch), помечая статус.

Безопасность: секреты/токены — в Keychain (iOS) / Android Keystore. Данные с PII/платежами шифруются (например, AES-256 GCM) ключом из защищённого контейнера.

Ограничения ОС: фоновые задачи зависят от режимов энергосбережения; планируйте идемпотентность запросов и возобновление после убийства процесса.

4) Как это работает в PWA (веб)

Service Worker (SW) — прокси между сетью и приложением:

Precache (App Shell): интерфейс доступен моментально.
Runtime cache: данные/медиа по стратегиям ниже.
Background Sync / Periodic Sync (где доступно): отправка очереди, обновление кэша без участия пользователя.
IndexedDB для данных и Cache Storage для статики.
Ограничения: квоты хранения, жёсткий контроль фоновых задач (особенно iOS Safari).

5) Стратегии кэширования (что и когда применять)

Cache First — для неизменяемой статики (иконки, шрифты, версии JS).

Stale-While-Revalidate (SWR) — для списков/каталогов: мгновенно из кэша, фоном подтянуть свежие данные.

Network First — для личных данных, когда сеть есть; бэкап — из кэша при офлайне.

Cache Only / Network Only — редкие частные случаи (диагностика, приватные ресурсы).

Комбинируйте: статика — CF/SWR; динамика — SWR/NF; записи — через очередь.

6) Очередь изменений и идемпотентность

Outbox-модель: каждое действие (POST/PUT/PATCH/DELETE) сериализуется в запись очереди с временным ID, телом, версией и дедлайном.

Отправка пакетами (batch) с экспоненциальным backoff при ошибках сети/сервера.

Идемпотентные ключи в заголовках/эндпоинтах — повторная отправка не создаст дублей.

Транзакции БД: запись в очередь и обновление локального состояния должны быть атомарны.

7) Разрешение конфликтов (server vs client)

Подходы:

Last Write Wins (LWW) — просто, но риск потери правок.
Версионирование/ETag — сервер отклоняет устаревшие версии → клиент делает merge/пересохранение.
Операционные трансформации/CRDT — для совместного редактирования сложных сущностей.
Правила по полям — какие поля «истина» на сервере, какие — у клиента (например, локальные метки/флаги).

UX:

Показывайте бейдж «не синхронизировано», кнопку «обновить», и дифф при конфликте (чтобы выбрать версию).

8) Работа с медиа и тяжёлыми ресурсами

Дедупликация и хэши (content-addressable) — не грузите одинаковое.

Плейсхолдеры/миниатюры офлайн, полная версия — после сети.

Очередь загрузок с паузой при плохой сети/аккумуляторе.

Политика TTL для кэша медиа — не копите гигабайты.

9) UX-паттерны, чтобы офлайн был «человечным»

ТОП-правило: никогда не показывайте «пустоту». App Shell + skeleton + последняя валидная версия контента.

Чёткие статусы: Online / Offline / Синхронизация… / Требуется действие.

Undo/Retry: отмена последнего офлайн-действия; автоматический и ручной повтор.

Локальные черновики: видимые списки «Ожидает отправки».

Тихие ошибки: агрессивно не тревожьте — достаточно ненавязчивых индикаторов + журнал.

10) Безопасность и приватность в офлайне

Шифруйте чувствительные данные «на диске»; ключи — в Keystore/Keychain.

Минимизируйте сбор/хранение PII офлайн; задайте ретеншн и авто-очистку.

Никогда не кэшируйте секреты/полные PAN/CVV; токены платёжных провайдеров — только по правилам PCI.

Защитите SW/клиент от XSS (CSP, SRI), иначе атакующий сможет украсть офлайн-данные при следующем онлайне.

11) Ограничения платформ

iOS: строгие лимиты фоновых задач в браузере; Web Push/periodic sync — с нюансами; Keychain — надёжно для секретов.

Android: гибче фоновые сервисы (WorkManager), но OEM-оптимизации могут «убивать» задачи — размечайте как «важные».

PWA: квоты IndexedDB/Cache Storage, очистка системой без предупреждений при нехватке места.

12) Тестирование офлайна

Сетевые профили (Airplane, 2G/3G, packet loss, high RTT).

Kill/restore процесса во время синка.

Chaos-тесты: половина батча падает 429/503/timeout.

Конфликты: параллельные правки с двух устройств.

Квоты хранилища: заполнить диск, проверить поведение кэша.

13) Метрики и наблюдаемость

Time To First Offline View (TTFOV): скорость появления App Shell.

Offline coverage: доля экранов/операций, доступных без сети.

Outbox health: длина очереди, среднее время до синка, доля ошибок.

Коэффициент конфликтов и доля ручных мерджей.

Квота/использование хранилища, частота очисток ОС.

User impact: сессии, начатые без сети → конверсия после синка.

14) Быстрый план внедрения (90 дней)

1. Определить скоп офлайна: какие экраны читаются из кэша, какие операции можно отложить.

2. Выбрать БД и схему: нормализованные таблицы, индексы, версии.

3. Включить App Shell: PWA SW/кэш статик/иконки/шрифты.

4. Собрать Outbox: очередь, идемпотентность, бэкофф, батчи.

5. Стратегии кэша: SWR для списков, Network First для персональных данных.

6. UX статусов + журнал синка, retry/undo.

7. Безопасность: шифрование на диске, CSP/SRI, минимизация PII.

8. Тесты под плохую сеть, хаос-тесты и метрики.

15) Частые ошибки и как их избежать

«Офлайн» только для статики. → Нужны черновики и outbox, иначе ценность мала.

Нет идемпотентности. → Дубли операций при ретраях. Введите идемпотентные ключи.

Скрытые конфликты. → Пользователь теряет правки. Показывайте дифф/решалку.

Без TTL и очистки кэша. → Приложение распухает, ОС чистит принудительно.

Синк блокирует UI. → Синхронизация всегда в фоне, UI — отзывчивый.

Хранение секретов в открытом виде. → Используйте Keychain/Keystore и шифрование.

16) FAQ

Можно ли сделать «полный» офлайн для всего?

Часто нет: платежи, проверка лицензий и живые данные требуют сети. Делайте гибрид: чтение из кэша + отложенные записи.

Что быстрее: SWR или Network First?

SWR даёт мгновенный ответ из кэша и тихое обновление — лучший UX для списков. Network First нужен там, где важна свежесть (профиль, баланс).

Как хранить большие медиа?

Кешируйте миниатюры и недолгий TTL, оригиналы — по запросу, с очисткой LRU.

Нужно ли шифровать всё?

Шифруйте PII/секреты и чувствительные записи. Остальное — по политике риска и квотам.

Офлайн ухудшит SEO/PWA?

Нет, при правильном SW и SSR наоборот улучшит скорость и повторные визиты.

Офлайн-режим — это не «галочка», а системная архитектура: локальная БД + кэш статики + очередь изменений + надёжный синк и продуманный UX статусов. Добавьте безопасность (шифрование, Keychain/Keystore), идемпотентность и метрики, протестируйте плохую сеть — и ваше приложение останется полезным даже без интернета, а при его появлении бесшовно догонит сервер, не теряя данные и доверие пользователя.