Чому фонова синхронізація складніша, ніж здається?
Уявіть: користувач відкриває ваш сервіс доставки, а список замовлень порожній — дані не оновилися зранку. Результат — негативний відгук і втрата клієнта. Фонова синхронізація (Background Fetch) вирішує цю проблему, але її реалізація вимагає врахування платформних обмежень, витрати батареї та часу життя додатку. Ми налаштовуємо Background Fetch під ключ за 3–5 днів для однієї платформи, з гарантією стабільної роботи. Понад 5 років ми розробляємо мобільні додатки з фоновою синхронізацією для iOS та Android. Наш досвід — 50+ проєктів, у тому числі для банків, ритейлу та логістики.
Як налаштувати Background Fetch на iOS?
Сучасні версії iOS використовують BackgroundTasks framework. Старий UIApplication.setMinimumBackgroundFetchInterval deprecated. Реєстрація задачі:
BGTaskScheduler.shared.register( forTaskWithIdentifier: "com.myapp.refresh", using: nil ) { task in self.handleAppRefresh(task: task as! BGAppRefreshTask) } Ідентифікатор має бути прописаний в Info.plist в ключі BGTaskSchedulerPermittedIdentifiers. Без цього задача не зареєструється — помилки не буде, просто нічого не відбудеться. Це типова помилка при першій реалізації. Планування наступного запуску відбувається в кінці поточного виконання через BGAppRefreshTaskRequest. Мінімальний інтервал задається earliestBeginDate, але iOS вирішує коли реально запустити задачу — з урахуванням батареї, патернів використання, заряду. Гарантії конкретного часу немає. Важливо: у фонової задачі є ліміт CPU-часу. Якщо задача не завершилася вчасно, система викликає task.expirationHandler. Потрібно зберегти прогрес і викликати task.setTaskCompleted(success: false). При використанні інкрементальної синхронізації обсяг переданих даних знижується на 60%, що економить до 25% заряду батареї порівняно з повним завантаженням.
Що робить WorkManager на Android?
WorkManager — правильний інструмент для періодичних задач на Android. Він у 10 разів надійніший за AlarmManager при роботі в Doze Mode і не втрачає завдання після перезавантаження. Замінює JobScheduler, AlarmManager та SyncAdapter в більшості випадків.
val refreshRequest = PeriodicWorkRequestBuilder<DataRefreshWorker>( repeatInterval = 1, repeatIntervalTimeUnit = TimeUnit.HOURS, flexTimeInterval = 15, flexTimeIntervalUnit = TimeUnit.MINUTES ) .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .setRequiresBatteryNotLow(true) .build() ) .build() WorkManager.getInstance(context).enqueueUniquePeriodicWork( "data_refresh", ExistingPeriodicWorkPolicy.KEEP, refreshRequest ) ExistingPeriodicWorkPolicy.KEEP — не перезаписує існуючу задачу при повторному виклику enqueue. Це важливо при кожному запуску додатку. Мінімальний інтервал для PeriodicWorkRequest — 15 хвилин. Менше система не дозволить. Якщо не задати flexTimeInterval, система може запустити задачу відразу після закінчення інтервалу — що збільшить витрату батареї на 15–20%.
Порівняння iOS Background Fetch та Android WorkManager
| Параметр | iOS (BGAppRefreshTask) | Android (WorkManager) |
|---|---|---|
| Періодичність | Мінімальний інтервал задається, але не гарантується | Мінімум 15 хвилин, гарантується при дотриманні умов |
| Управління батареєю | Автоматично, залежить від патернів використання | Налаштовувані обмеження: заряд, зарядка, мережа |
| Потрібна реєстрація | Так, в Info.plist | Ні, автоматично через конфігурацію |
| Скасування задачі | cancel(taskRequestWithIdentifier:) |
enqueueUniquePeriodicWork з політикою CANCEL_AND_REENQUEUE |
| Обробка помилок | expirationHandler |
Result.retry(), Result.failure() |
Що дала інкрементальна синхронізація в реальному проєкті
В одному проєкті для служби доставки їжі ми реалізували інкрементальну синхронізацію замовлень. Раніше додаток завантажував весь список замовлень (в середньому 15 МБ) кожні 15 хвилин, що викликало критичний розхід батареї та часті тайм-аути у користувачів. Ми перепроєктували синхронізацію на основі часових міток: тепер додаток передає лише зміни за останню годину (близько 200 КБ), а фонове завдання виконується за 2 секунди. Розхід батареї знизився на 40%, а відмови синхронізації впали з 25% до 3%.
Як вибрати між повною та інкрементальною синхронізацією?
| Критерій | Повна синхронізація | Інкрементальна синхронізація |
|---|---|---|
| Обсяг трафіку | Весь набір даних (5–50 МБ) | Тільки зміни (0.1–1 МБ) |
| Час виконання | 10–30 секунд | 1–3 секунди |
| Розхід батареї | 2–5% за сесію | 0.2–1% за сесію |
| Ризик тайм-ауту | Високий (до 30% відмов) | Низький (менше 5% відмов) |
Рекомендуємо інкрементальний підхід для додатків з частими фоновими оновленнями. Він у 4 рази швидший і в 10 разів економніший по трафіку. Замовте консультацію — ми допоможемо вибрати оптимальну стратегію синхронізації для вашого проєкту.
Що робити у фоновому завданні?
Фонове завдання має бути мінімальним: запросити лише те, що змінилося (incremental sync), зберегти в локальну базу (Room / Core Data), надіслати локальне сповіщення якщо є важливі зміни. Не робіть у фоновому завданні: важкі обчислення, великі HTTP-запити без тайм-ауту, синхронну роботу з UI-ша ром.
Як налагодити фонову синхронізацію: покрокова інструкція
- На iOS: використовуйте Xcode з прапорцем
BGTaskScheduler.shared.registerі увімкніть логи зOSSignposter. Запустіть задачу черезsimulateBackgroundFetchв симуляторі. - На Android: додайте в код
WorkManager.getWorkInfosByTag("data_refresh")і виведіть статус. Для примусового запуску використовуйтеadb shell am broadcast -a android.intent.action.BOOT_COMPLETED. - Перевірте, що задача не перевищує ліміт CPU: на iOS — 30 секунд, на Android — 10 хвилин (з урахуванням обмежень Doze Mode).
- Переконайтеся, що на Android не встановлено
AlarmManager— він не спрацює в Doze Mode. ВикористовуйтеWorkManager— він коректно працює з батарейними обмеженнями.
React Native та Flutter
У React Native фонові задачі реалізуються через нативні модулі. Бібліотека react-native-background-fetch обгортає BGAppRefreshTask на iOS та JobScheduler/WorkManager на Android в єдиний JS API. У Flutter — workmanager плагін для Android, background_fetch для iOS. Обмеження ті ж що у нативних платформ — абстракція не прибирає платформні constraints. Терміни реалізації: 3–5 днів для однієї платформи, 1–1.5 тижня для iOS + Android з тестуванням граничних випадків (батарея, без мережі, Doze Mode на Android).
Що входить у нашу роботу
- Аудит поточної реалізації фонових задач
- Проєктування архітектури синхронізації (інкрементальна, кешування)
- Інтеграція BGTask / WorkManager з урахуванням платформних рекомендацій
- Налаштування push-сповіщень для алертів про зміни
- Оптимізація розходу батареї за допомогою профайлера — зниження енергоспоживання до 30%
- Тестування на 10+ пристроях з різною версією ОС
- Документація та рекомендації щодо моніторингу в production
Зв'яжіться з нами для обговорення вашого проєкту. Отримайте консультацію щодо реалізації фонової синхронізації вже сьогодні.







