Синхронізація Google Drive у мобільному застосунку: де рветься
Синхронізація Google Drive у мобільному застосунку ламається не на «складній логіці», а на побутових речах: користувач згорнув застосунок у ліфті, мережа зникла на середині вивантаження, файл перейменували на двох пристроях одночасно.
Drive API віддає це як набір розрізнених помилок і ревізій, і без явної обробки кожна така ситуація перетворюється на конфлікт версій файлів або тиху втрату змін.
Найдорожче обходиться обрив синхронізації на мобільній мережі. Завантаження великого файлу через resumable-сесію переривається, а застосунок або починає вивантаження заново, або залишає файл у проміжному стані — і користувач бачить «завантажено», хоча на диску половина даних. На слабкому каналі це повторюється на кожній спробі, з'їдаючи трафік і батарею.
Другий клас збоїв — дублікати файлів у хмарі. Повторний запит після таймауту створює другу копію, бо застосунок не звірив ідентифікатор уже надісланого файлу.
З часом папка обростає версіями «документ (1)», «документ (2)», і розібрати, яка з них актуальна, уже не може ні користувач, ні підтримка.
Третій — зависла черга відкладеної синхронізації. Завдання накопичуються локально, частина з них посилається на видалені файли, частина чекає мережу, яка не з'явиться.
Черга зростає, застосунок під час запуску витрачає секунди на її розбір, а частина операцій так і не доходить до сервера.
Ціна в усіх трьох збоїв одна: користувач перестає довіряти застосунку й заводить звичку «перевіряти, чи збереглося». Далі розбираємо, як це закривається на рівні архітектури синхронізації.
Що дає керована синхронізація Google Drive за ефектом
Режими синхронізації та їхній вимірюваний ефект
Повна синхронізація тягне весь набір файлів під час кожного запуску — під час першого входу це хвилини очікування та помітна витрата трафіку.
Інкрементальна синхронізація спирається на журнал змін: застосунок запитує лише те, що змінилося з минулого запуску, і перше завантаження скорочується в рази, а повторні — до секунд.
Офлайн-черга змін вирішує головний біль мобільних сценаріїв — зниклу мережу. Правки користувача складаються в локальну чергу й надсилаються після відновлення зв'язку, тому жодна правка не губиться під час перемикання між мережами та згортання застосунку.
Розв'язання конфліктів визначає, що станеться, коли один файл змінили на двох пристроях. Стратегія «остання правка перемагає» проста, але мовчки втрачає дані; версіонування з явним злиттям зберігає обидві сторони та знижує частку втрачених змін до нуля.
Час збіжності даних — ключова метрика: скільки минає від правки на одному пристрої до її появи на іншому. За інкрементальної синхронізації та коректної обробки журналу він вимірюється секундами, а не хвилинами.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повна синхронізація | Малі набори, рідкі правки | Тривале перше завантаження, зростання трафіку |
| Інкрементальна | Великі набори, часті правки | Потрібен журнал змін та його обробка |
| Офлайн-черга | Нестабільна мережа, мобільний сценарій | Потребує логіки повторного надсилання |
| Версіонування зі злиттям | Спільна робота над файлами | Складніше в реалізації |
На практиці режими комбінують: інкрементальна синхронізація як основа, офлайн-черга для стійкості, версіонування для конфліктів. Такий набір прибирає цілий клас відмов — «зникли правки», «дані розійшлися між пристроями», «застосунок завис на першому завантаженні».
Google Drive API дає для цього журнал змін і версіонування файлів — на них і будується передбачувана синхронізація.
Як ми впроваджуємо синхронізацію: етапи інженерної роботи
Синхронізація Google Drive ламається не на виклику API, а на невідповідності моделей даних: локальна база зберігає одне, хмара віддає інше, і при конфлікті версій застосунок затирає свіжі правки старими.
Тому роботу починаємо не з коду, а з розбору того, як дані живуть зараз — і лише потім проєктуємо обмін.
- Аудит схеми даних. Розбираємо локальне сховище, серверні сутності та структуру файлів у хмарі: які поля змінюються, хто власник запису, де можливі одночасні правки з двох пристроїв. На виході — карта розбіжностей і список місць, де синхронізація зобов'язана розв'язувати конфлікт, а не перезаписувати.
- Проєктування моделі синхронізації. Визначаємо одиницю обміну, напрямок (односторонній чи двосторонній), стратегію розв'язання конфліктів і правила видалення. Фіксуємо, що відбувається при офлайн-правці: зміни стають у чергу і йдуть у хмару при появі мережі.
- Налаштування доступу до хмари. Налаштовуємо авторизацію через OAuth, мінімально необхідні області доступу, оновлення токенів і поведінку при відкликанні прав користувачем. Окремо перевіряємо сценарій зміни акаунта на пристрої.
- Реалізація обміну. Пишемо шар синхронізації: дельта-завантаження замість повного, обробка часткових збоїв, повторні спроби з наростаючою паузою. Інкрементальний обмін замість перекачування всього дерева файлів.
- Навантажувальна перевірка. Прогоняємо сценарії з великою кількістю файлів, слабким каналом і обривом зв'язку на середині передачі. Дивимося, чи відновлюється стан без дублів і втрат.
- Передача документації. Віддаємо схему моделі синхронізації, опис стратегії конфліктів, інструкції щодо доступів і розбір типових збоїв — щоб підтримку можна було вести без нас.
Опишіть задачу — повернемося з оцінкою та планом під ваш сценарій.
Чим відрізняється двостороння синхронізація від односторонньої?
Одностороння синхронізація — це потік в один бік: застосунок або вивантажує дані на Google Drive, або забирає їх звідти, але не поєднує обидва напрямки.
Така модель передбачувана: у кожного запису один власник, джерело істини зафіксоване, а отже, конфлікт правок у принципі не виникає.
Саме тому односторонню схему беруть для резервних копій, вивантаження звітів, доставки оновлюваного контенту — там, де дані змінює лише одна сторона.
Синхронізація Google Drive у цьому режимі зводиться до відстеження змін і повторного надсилання або завантаження, без логіки злиття.
Двостороння синхронізація — інше завдання: обидві сторони можуть змінювати ті самі об'єкти, і рано чи пізно той самий запис зміниться у двох місцях. Тут з'являється розв'язання конфліктів правок — обов'язковий шар, а не деталь реалізації.
Працює він поверх стратегії злиття: або перемагає остання правка за часом, або пріоритет віддається одній стороні, або зміни зливаються за полями, або конфлікт виноситься користувачеві на вибір.
Від обраної стратегії залежить, що побачить людина після розходження: тихо перезаписані дані, об'єднаний запис або явний запит «яку версію залишити».
Різниця проявляється в підтримці. Одностороння схема ламається рідко: збій локалізується в одному напрямку, відкат простий, стан відновлюється повторним вивантаженням.
Двостороння вимагає зберігати мітки версій і час останньої зміни по кожному об'єкту, інакше система не відрізнить чужу правку від власної й почне затирати дані.
Додаються сценарії, яких немає в односторонній моделі: видалення з одного боку при живій копії з іншого, розходження при офлайн-роботі, повторна синхронізація після довгої відсутності зв'язку.
Вибір диктує не зручність, а характер даних. Якщо запис змінює один користувач або один пристрій — односторонньої моделі достатньо, і вона дешевша в супроводі.
Щойно правки йдуть з кількох пристроїв або з веб-інтерфейсу, потрібна двостороння синхронізація з явною стратегією злиття та продуманим розв'язанням конфліктів правок.
Проміжний варіант — гібрид: важкі дані в один бік, невеликі користувацькі налаштування в обидва, з пріоритетом сервера при розходженні.
Кейс: як синхронізація перестала втрачати правки користувачів
Замовник прийшов із класичною скаргою: користувачі редагують той самий документ із телефона й планшета, а частина змін зникає. Застосунок записував файл цілком за таймером, без урахування ревізій, тому в разі конфлікту перемагав останній запис — решту затирало мовчки.
За квартал накопичилося 340 звернень до підтримки з формулюванням «зникли правки», а частка втрачених змін сягала 6% від усіх операцій запису.
Що показав розбір
Ми зняли метрики на реальному трафіку й побачили три причини. Перша — запис без перевірки ревізії: клієнт не читав метадані файлу перед надсиланням і не знав, що версія на сервері вже пішла вперед.
Друга — черга синхронізації жила лише в пам'яті: під час згортання застосунку ненадіслані операції губилися. Третя — повторне надсилання після обриву мережі створювало дублікати, бо не було ключа ідемпотентності.
Що змінили
Перевели запис на модель із перевіркою ревізії: перед надсиланням клієнт запитує поточні метадані, порівнює з локальною базовою версією і в разі розбіжності розв'язує конфлікт за правилом «об'єднуємо поля, конфліктні версії зберігаємо поряд».
Чергу операцій перенесли в локальне сховище — вона переживає перезапуск і згортання. Для кожної операції додали унікальний ключ, тому повтор після обриву не плодить копії.
| Метрика | До | Після |
|---|---|---|
| Частка втрачених змін | 6% | 0,2% |
| Час збіжності даних | до 40 секунд | 2-4 секунди |
| Звернення до підтримки за квартал | 340 | 28 |
| Дублікати файлів | регулярно | поодинокі випадки |
Окремо налаштували фонову синхронізацію з обмеженням на витрату трафіку: важкі файли довантажуються лише через Wi-Fi, легкі — одразу. Це прибрало скарги на розряджання батареї, які з'явилися після першого варіанта рішення.
Google Drive API дає для цього готовий набір — ревізії, метадані та посторінкову видачу змін, — але коректність цілком на боці клієнта: сервер не розв'яже конфлікт за вас.
Сумніви щодо сумісності, міграції та відкату синхронізації
Синхронізація через Google Drive API майже завжди вбудовується в застосунок, де дані вже лежать локально або в іншій хмарі. Тому головне питання замовника — не «чи спрацює», а «що буде з тим, що вже накопичено, і як це відкотити, якщо щось піде не так». Нижче — як ми закриваємо ці ризики на рівні архітектури, а не обіцянок.
Що буде з уже завантаженими даними?
Міграція даних іде за схемою «читання — зіставлення — запис»: спочатку знімається повна копія поточного сховища, потім старі записи зіставляються з новою структурою за стабільними ідентифікаторами, і лише після звірки контрольних сум дані переносяться.
Початкове сховище залишається недоторканим до підтвердження цілісності, тому втратити дані на цьому етапі неможливо.
Як влаштований відкат синхронізації? Кожна операція запису йде через версіонування: перед зміною файлу створюється його попередня ревізія, а стан синхронізації фіксується окремою точкою відновлення.
Відкат повертає застосунок до узгодженого стану — не «на око», а до конкретної мітки, після якої розбіжностей між локальною копією та хмарою немає.
Які права доступу до хмари потрібні? Застосунок запитує мінімально необхідний набір — доступ лише до своєї папки застосунку, без читання всього диска користувача.
Це знімає питання модерації та знижує ризик при відкликанні згоди: користувач вимикає доступ, і застосунок продовжує працювати в локальному режимі.
Що якщо користувач відкличе доступ або змінить акаунт?
Синхронізація переходить у локальний режим без втрати даних: черга змін зберігається на пристрої та досилається при наступній авторизації. Зміна акаунта обробляється як нове сховище — стара папка не перезаписується, конфлікти вирішуються за часом зміни, а не «хто останній».
На руки замовник отримує:
- схему міграції даних з точками звірки та порядком перенесення;
- регламент відкату синхронізації з описом міток відновлення;
- матрицю прав доступу до хмари та обґрунтування мінімальних областей;
- конфігурації застосунку з параметрами синхронізації та конфліктів;
- інструкцію з передачі конфігурацій між середовищами (тестове, продуктивне);
- документацію з обробки конфліктів та офлайн-режиму;
- чеклист приймання синхронізації з перевіркою цілісності після відкату.
Опишіть вашу задачу — поточне сховище, обсяг даних і вимоги до доступів. Повернемося з оцінкою та планом міграції, відкату і розмежування прав.
