Представьте: курьерская служба использует мобильное приложение для приёма заказов. Сотни заказов теряются при заезде в туннель — синхронизация не успевает. После восстановления сети данные расходятся, клиенты не получают посылки. Такие ситуации — наша специализация. Мы разрабатываем архитектуру офлайн-синхронизации мобильных приложений, которая гарантирует целостность данных даже при нестабильном соединении. Команда имеет более 5 лет опыта и выполнила свыше 30 проектов с синхронизацией для fintech, e-commerce и logistics.
Без правильной синхронизации офлайн-изменения теряются, возникают конфликты, пользовательский опыт страдает. Наш подход — двухсторонняя дельта-синхронизация с очередью операций и обработкой конфликтов. Пример из практики: для e-commerce с 500 000 товаров и 10 000 заказов в день мы внедрили дельта-синхронизацию. Конфликты возникали у 2% заказов — решили через LWW. Среднее время синхронизации сократилось с 30 до 2 секунд, трафик на 90%. Delta sync лучше full sync в 10 раз по скорости и в 50 раз по трафику.
Как реализовать двухстороннюю дельта-синхронизацию?
Дельта-синхронизация — эффективный способ минимизировать трафик. В отличие от полной синхронизации (full sync), клиент загружает только изменения с момента последней синхронизации. Это снижает нагрузку на сервер на 90% и ускоряет синхронизацию в 5–10 раз.
| Метод | Трафик | Время | Нагрузка на сервер | Подходит для |
|---|---|---|---|---|
| Full sync | Высокий | Медленно | Высокая | Мало данных (<100 записей) |
| Delta sync | Низкий | Быстро | Низкая | Частые изменения, много записей |
| Incremental sync | Средний | Средне | Средняя | Данные с монотонным ID |
Мы используем delta sync как основной механизм. Клиент присылает lastSyncTimestamp, сервер возвращает только изменённые и удалённые записи.
Код SyncManager
data class SyncRequest( val lastSyncTimestamp: Long, val clientId: String ) data class SyncResponse( val serverTimestamp: Long, // время ответа сервера val updated: List<ProductDto>, // изменённые или новые val deletedIds: List<String> // удалённые на сервере ) На клиенте сохраняем lastSuccessfulSyncTimestamp в MMKV или SharedPreferences. При следующей синхронизации используем его как фильтр.
Почему важна серверная временная метка?
Время должно быть серверным. Если клиент использует своё время, расхождение часов даёт пропуски или дубли. Сервер отдаёт свой timestamp в ответе — клиент сохраняет именно его. Так избегаем проблем с часовыми поясами и неточными настройками времени на устройстве.
Архитектура SyncManager
SyncManager — центральный компонент. Он координирует отправку накопленных операций и получение дельты. Код ниже — основа для iOS и Android, с адаптацией под платформу.
Код SyncManager (kotlin)
class SyncManager( private val api: SyncApi, private val dao: ProductDao, private val pendingOpsDao: PendingOperationDao, private val prefs: SyncPreferences ) { suspend fun sync(): SyncResult { // 1. Отправляем накопленные offline-операции val pending = pendingOpsDao.getAll() if (pending.isNotEmpty()) { try { val uploadResult = api.uploadOperations(pending.map { it.toRequest() }) pendingOpsDao.deleteByIds(uploadResult.processedIds) } catch (e: NetworkException) { return SyncResult.NetworkError } } // 2. Скачиваем изменения с сервера return try { val response = api.sync( SyncRequest( lastSyncTimestamp = prefs.lastSyncTimestamp, clientId = prefs.clientId ) ) dao.applyDelta( updated = response.updated.map { it.toEntity() }, deletedIds = response.deletedIds ) prefs.lastSyncTimestamp = response.serverTimestamp SyncResult.Success( updatedCount = response.updated.size, deletedCount = response.deletedIds.size ) } catch (e: Exception) { SyncResult.Error(e) } } } applyDelta в транзакции — атомарно. Или применяем всё, или ничего:
@Transaction suspend fun applyDelta(updated: List<ProductEntity>, deletedIds: List<String>) { upsertAll(updated) softDeleteByIds(deletedIds, System.currentTimeMillis()) } Soft delete обязателен: не удаляем физически, ставим флаг is_deleted = true и сохраняем timestamp. Иначе при следующем delta sync мы снова «забудем» про это удаление.
Триггеры синхронизации
Синхронизацию запускаем в нескольких сценариях:
class SyncScheduler( private val workManager: WorkManager, private val syncManager: SyncManager, private val networkMonitor: NetworkMonitor ) { init { val periodicSync = PeriodicWorkRequestBuilder<SyncWorker>(15, TimeUnit.MINUTES) .setConstraints(Constraints(requiredNetworkType = NetworkType.CONNECTED)) .build() workManager.enqueueUniquePeriodicWork( "periodic-sync", ExistingPeriodicWorkPolicy.KEEP, periodicSync ) } fun observeNetworkAndSync() { networkMonitor.isOnline .filter { it } .distinctUntilChanged() .onEach { triggerImmediateSync() } .launchIn(applicationScope) } fun onAppForeground() { val lastSync = prefs.lastSyncTimestamp val tooOld = System.currentTimeMillis() - lastSync > 5 * 60 * 1000L if (tooOld) triggerImmediateSync() } } На iOS аналог WorkManager — BGAppRefreshTask и BGProcessingTask (см. документацию Apple). Согласно Apple Background Execution Guide, фоновые задачи iOS ограничены 30 секундами. Наше решение учитывает эти ограничения и использует оптимальные триггеры.
Синхронизация изображений и файлов
Бинарные данные — отдельно от метаданных. Синхронизируем список файлов (имена, URL, хэши), скачиваем файлы по отдельным запросам с приоритизацией:
class MediaSyncManager { suspend fun syncMedia(mediaList: List<MediaMeta>) { val toDownload = mediaList.filter { meta -> !fileCache.exists(meta.localPath) || fileCache.getHash(meta.localPath) != meta.serverHash } toDownload.chunked(4).forEach { batch -> batch.map { meta -> async { downloadFile(meta) } }.awaitAll() } } } Чанки по 4 — не перегружаем соединение, при потере связи теряем максимум 4 файла из текущего батча.
Сравнение стратегий разрешения конфликтов
| Стратегия | Принцип | Производительность | Сложность |
|---|---|---|---|
| LWW (Last Writer Wins) | Побеждает последнее изменение по серверному времени | Очень быстро | Низкая |
| CRDT | Автоматическое слияние без конфликтов | Средне | Высокая |
| Custom merge | Ручное разрешение через UI | Медленно | Высокая |
Для большинства сценариев достаточно LWW. CRDT оправдан для коллаборативных редакторов или финансовых данных, где нельзя потерять ни одно изменение (см. Wikipedia: Conflict-free replicated data type).
Состояние синхронизации в UI
Пользователь должен видеть актуальность данных. Минимум: timestamp последней синхронизации. Лучше: иконка статуса (synced / syncing / sync error) рядом с данными, которые могут быть устаревшими.
При sync error — не блокировать UI. Показывать предупреждение, разрешать работу с локальными данными, предлагать повторить.
Что входит в работу
- Аудит текущей архитектуры данных и подготовка спецификации
- Проектирование схемы синхронизации (сущности, идентификаторы, конфликты)
- Реализация SyncManager, очереди операций и API-интеграции
- Настройка фоновых задач (WorkManager / BGAppRefreshTask)
- Разработка обработчиков конфликтов (LWW или CRDT)
- Покрытие кода unit-тестами и сценариев интеграционного тестирования
- Предоставление документации API и руководства по развертыванию
- Поддержка в течение 30 дней после запуска
Процесс работы
- Анализ — изучаем модель данных, нагрузку, требования к консистентности
- Проектирование — выбираем стратегию конфликтов, определяем поля для синхронизации
- Реализация — пишем код, интегрируем с вашим бэкендом (REST, GraphQL, Firebase)
- Тестирование — эмуляция офлайн-сценариев, нагрузочное тестирование, проверка edge cases
- Деплой — настройка CI/CD, мониторинг, логирование ошибок синхронизации
Сроки и стоимость
Полная реализация двухсторонней дельта-синхронизации с очередью операций и обработкой конфликтов: от 4 до 8 недель в зависимости от объёма данных и количества типов сущностей. Стоимость рассчитывается индивидуально после анализа проекта. Внедрение дельта-синхронизации сокращает расходы на серверную инфраструктуру до 80% и ускоряет выход на рынок на 2 месяца.
Получите бесплатную консультацию и оценку вашего проекта. Закажите разработку под ключ и обеспечьте вашим пользователям бесшовную работу даже без интернета.
Наша команда сертифицированных iOS и Android разработчиков гарантирует соблюдение гайдлайнов App Store и Google Play. Опыт в проектах от 50 000 до 10 млн пользователей.