Чому мобільний застосунок гальмує на зростаючих даних
Застосунок, який на старті літає, починає помітно гальмувати, коли локальна база переростає перші десятки тисяч записів.
Список контактів або стрічка замовлень підвантажується ривками, пошук відповідає із затримкою, а прокрутка смикається — бо кожен запит до локального сховища мобільного застосунку тепер проходить по диску, а не по кешу, і виконується в головному потоці інтерфейсу.
Далі підключається друга проблема — розсинхрон. Частина даних встигла поїхати на сервер, частина залишилася в черзі, і після перезапуску користувач бачить застарілу картину: замовлення, яке він уже надіслав, знову висить як чернетка.
При обриві зв'язку в метро чи ліфті незаписані зміни губляться зовсім, якщо сховище не вміє переживати переривання транзакції.
Окрема історія — синхронізація даних офлайн. Коли застосунок повертається в мережу, він намагається злити накопичені правки одним залпом: конфлікти версій вирішуються «хто останній, той і правий», а важкий прохід по всій таблиці блокує інтерфейс на секунди.
Користувач бачить завислий екран і закриває застосунок — рівно в момент, коли запис ще не зафіксовано.
Корінь усіх трьох збоїв один: локальне сховище проєктували під демо-обсяг, а не під реальне зростання.
Тут і виходить на перший план realm база даних — об'єктне сховище, де записи читаються як звичайні об'єкти, запити йдуть по індексах, а зміни прилітають в інтерфейс реактивно, без ручного перечитування таблиць.
Розбираємо, як це закривається на практиці: від схеми зберігання та індексів до черги відкладеної синхронізації та правил розв'язання конфліктів.
Що дає правильно налаштована realm база даних
Схема даних як фундамент відгуку інтерфейсу
Швидкість відгуку інтерфейсу визначається не потужністю пристрою, а тим, як спроєктовано схему даних застосунку.
Коли об'єкти описані зв'язками, а не вкладеними копіями, вибірка списку йде за індексованим полем і вкладається в частки кадру — прокручування залишається плавним навіть на великих колекціях.
Плоска схема без індексів дає зворотний ефект: кожен екран перезбирає дані заново, і інтерфейс «залипає» при зростанні бази.
Режими синхронізації та стійкість до обривів зв'язку
Ключовий параметр — режим синхронізації. Локальний запис із фоновим довантаженням дозволяє застосунку працювати офлайн: користувач бачить актуальні дані з локального сховища, а зміни вирушають на сервер, щойно зв'язок відновився.
Черга змін переживає перезапуск застосунку, тому жодна правка не губиться при обриві мережі в метро чи ліфті. Це знімає цілий клас відмов — «дані не збереглися» та «екран порожній без інтернету».
Що дає налаштування на практиці
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальна база без синхронізації | Довідники, кеш, офлайн-режим | Немає спільних даних між пристроями |
| Локальний запис + фонова синхронізація | Більшість продуктових застосунків | Потрібна обробка конфліктів версій |
| Пряма робота через сервер | Дані завжди онлайн, малий обсяг | Інтерфейс залежить від якості зв'язку |
Ми працюємо на Realm — об'єктна база дає відгук списків у рази швидше порівняно з побудовою запитів поверх файлового сховища, а обсяг службових даних за коректної схеми скорочується втричі.
Вимірюваний результат
Після налаштування схеми та режимів синхронізації час відкриття важких екранів скорочується із секунд до часток секунди, частка звернень, що завершилися помилкою за нестабільної мережі, падає до одиниць відсотків.
Окремо зникає клас відмов, пов'язаних із розсинхронізацією: користувач більше не бачить застарілі дані після повернення в застосунок.
Як ми налаштовуємо сховище: етапи інженерної роботи
Налаштування локального сховища починається не з коду, а з аудиту: дивимося, які сутності вже живуть на пристрої, як вони пов'язані, де дублюються записи і які запити виконуються на головному потоці.
Часто з'ясовується, що частину даних взагалі не потрібно зберігати офлайн, а частина, навпаки, губиться при оновленні застосунку. Від цього залежить схема, індекси та стратегія синхронізації з сервером.
- Аудит сховища. Розбираємо поточну схему, обсяг даних, частоту читання і запису, поведінку при виході з акаунта і перевстановленні. Фіксуємо вузькі місця: важкі вибірки, відсутність індексів, блокування при записі.
- Проєктування схеми даних. Визначаємо сутності, зв'язки і типи полів під реальні сценарії екрана, а не «на майбутнє». Закладаємо версіонування схеми, щоб наступне оновлення застосунку не ламало дані користувача.
- Налаштування конфігурації та міграцій. Описуємо правила переходу між версіями схеми, порядок додавання і видалення полів, поведінку при відкаті на попередню збірку. Міграція даних застосунку проходить без втрати користувацьких записів.
- Оптимізація запитів. Переносимо важкі вибірки з головного потоку, додаємо індекси під конкретні фільтри і сортування, перевіряємо поведінку на слабких пристроях і при заповненому сховищі.
- Тестування на реальних даних. Проганяємо сценарії оновлення, переривання запису, нестачі місця і паралельного доступу. Дивимося, що відбувається при конфлікті локальної та серверної версії запису.
- Передача документації. Віддаємо схему, правила міграцій, опис індексів та інструкцію щодо додавання нових полів — щоб команда замовника могла розвивати сховище без нас.
Схему і правила міграцій описуємо так, щоб їх можна було читати без занурення в код: таблиця сутностей, зв'язки, версії та порядок змін. Це знімає типову проблему, коли через пів року ніхто не пам'ятає, чому поле називається саме так і що з ним робити при наступному релізі.
Чим локальна база відрізняється від хмарної синхронізації?
Realm база даних вирішує дві різні задачі, які часто плутають: зберігання даних на пристрої та їх синхронізацію між пристроями і сервером. Локальне зберігання — це файл на диску телефона, до якого застосунок звертається напряму, без мережі.
Хмарна синхронізація — надбудова, яка відстежує зміни об'єктів і передає їх між пристроями через сервер, розв'язуючи конфлікти за заданими правилами. Це не «або-або»: синхронізація працює поверх локального сховища, а не замість нього.
Різниця проявляється в момент, коли мережа зникає. У локальному режимі застосунок продовжує читати й писати в базу з тією ж швидкістю — запити йдуть до файлу, а не до сервера, тому інтерфейс не блокується і не показує нескінченні індикатори завантаження.
Під час синхронізації без продуманого офлайн-режиму застосунку частина операцій стає в чергу й чекає відновлення зв'язку, а конфліктні правки доводиться розв'язувати постфактум.
Саме тому вибір режиму зберігання починається не з питання «чи потрібна синхронізація», а з питання «що має працювати без мережі».
Є й друга ціна — складність моделі даних. Локальна схема живе за правилами одного пристрою: міграції застосовуються під час оновлення застосунку, версія схеми зростає лінійно, відкат передбачуваний.
Синхронізація додає виміри — кілька пристроїв правлять один об'єкт, частина змін надходить із затримкою, а серверна логіка доступу має збігатися з клієнтською.
Чим більше сутностей бере участь в обміні, тим дорожча помилка в правилах розв'язання конфліктів: розходження даних між пристроями користувач помітить раніше, ніж ви отримаєте сигнал.
Практичне правило просте. Якщо дані належать одному пристрою й одному користувачеві — нотатки, кеш каталогу, чернетки, налаштування — локального зберігання достатньо, і воно дає мінімальний час відгуку.
Якщо той самий набір даних має бути видимим на кількох пристроях або підтягуватися на новому телефоні після входу — потрібна синхронізація, але з явно описаним офлайн-режимом застосунку: що пишеться локально, що йде в чергу, що конфліктує і як.
Змішаний варіант теж робочий: довідники й користувацький контент синхронізуються, а важкі локальні дані залишаються на пристрої.
Помилка, яку ми бачимо найчастіше, — увімкнути синхронізацію «про всяк випадок» і отримати зростаючий трафік, затримки інтерфейсу та розходження, які неможливо відтворити. Зворотна помилка — тримати все локально там, де користувач чекає свої дані на другому пристрої.
Ми розбираємо сценарії використання, визначаємо, які сутності зобов'язані переживати зміну пристрою, і лише потім обираємо режим зберігання. Опишіть задачу — повернемося з оцінкою та планом.
Кейс: прискорили застосунок на зростаючій базі втричі
Клієнт звернувся зі скаргою: застосунок «підвисає» під час відкриття списку замовлень.
На тестовому наборі з кількох сотень записів усе літало, а в бою в менеджерів накопичилося кілька десятків тисяч об'єктів — і екран відкривався 2,5–3 секунди, прокрутка смикалася, пошук по історії працював із помітною затримкою.
Вимірювання показали: основний час ішов не на відмальовування, а на читання зі сховища — запити виконувалися в головному потоці, схема була плоскою, а синхронізація тягнула весь набір об'єктів під час кожного запуску.
Що змінили
Переробили схему: рознесли пов'язані сутності по окремих таблицях, додали індексовані поля для фільтрів і сортування, прибрали дубльовані вкладені колекції.
Важкі читання перенесли у фонові черги, а результат віддавали в інтерфейс через спостереження за змінами — список оновлюється сам, без ручних повторних запитів.
Синхронізацію перевели з повного вивантаження на інкрементальну: клієнт запитує лише змінені записи за міткою часу, а конфлікти розв'язуються за правилом «остання зміна перемагає» з журналом для розбору спірних випадків.
Паралельно налаштували політику очищення: застарілі записи, старші за заданий термін, видаляються фоновою задачею, обсяг сховища перестав зростати нескінченно.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Відкриття списку | 2,5–3 с | 0,8–0,9 с |
| Прокрутка | ривками | стабільні кадри |
| Повна синхронізація під час старту | весь набір | лише зміни |
| Зростання сховища | лінійне | обмежене політикою очищення |
Окремо заміряли холодний старт: час до готового екрана скоротився майже втричі, а споживання пам'яті на слабких пристроях упало приблизно на третину — застосунок перестав вивантажуватися системою у фоні.
Результат впровадження
Швидкість зросла втричі на реальних обсягах даних, а не на демо-наборі. Відмови через нестачу пам'яті зникли, скарги на «гальмування» припинилися. Схему та правила синхронізації задокументували, щоб команда клієнта могла розвивати її без нас.
Працювали з Realm — об'єктною базою, яка зберігає дані прямо на пристрої та не потребує окремого сервера.
Сумніви перед впровадженням: сумісність, міграція, відкат
Що станеться зі схемою даних під час оновлення застосунку — чи не втратяться дані користувачів?
Схема версіонується, і перехід між версіями описується явними правилами: які поля додані, перейменовані або видалені та як переносяться значення.
Під час запуску застосунок застосовує перехід один раз, у транзакції — якщо він не пройшов, база залишається в попередньому стані, а не в напівзібраному.
Перед першим запуском нової версії на пристрої робиться резервна копія файлу сховища, тому відкат до попередньої версії застосунку не залишає користувача без даних.
Що якщо потрібно повернутися до попередньої версії? Відкат змін — це не лише повернення збірки, а й зворотний перехід схеми. Ми описуємо його заздалегідь для кожного релізу, щоб повернення не перетворювалося на ручне редагування даних на пристроях.
Як розмежовуються доступи до сховища? Доступи до сховища описуються за ролями: хто читає, хто пише, хто змінює схему. Це фіксується в документації по базі, а не залишається в голові розробника.
Що якщо в частини користувачів стара версія застосунку? Кілька версій схеми підтримуються паралельно, поки триває поступове оновлення, — синхронізація не ламається в тих, хто ще не оновився.
Після здачі замовник отримує на руки:
- опис схеми даних з версіями та правилами переходу між ними;
- набір правил міграції даних для кожного релізу, з перевіркою на реальних обсягах;
- процедуру відкату змін — і схеми, і застосунку;
- матрицю доступів до сховища за ролями;
- документацію по базі: структура, зв'язки, обмеження, порядок резервного копіювання;
- набір автоматичних перевірок, які проганяються перед кожним оновленням;
- інструкцію для команди підтримки: як читати стан бази та що робити при збої.
Опишіть вашу задачу — повернемося з оцінкою та планом: покажемо, як ляже схема на поточні дані та які кроки знадобляться при першому оновленні.
