Налаштування Hive для Flutter: швидка локальна база даних

Швидка локальна база даних у Flutter: налаштування Hive

При завантаженні даних у Flutter-додатку часто виникають гальма, які дратують користувачів. Ми бачимо такі проблеми в проєктах, де використовують SharedPreferences для складних об'єктів або перевантажують SQLite запитами. Для кешування відповідей API, зберігання налаштувань або простих довідників оптимально Hive — швидка key-value база даних на чистому Dart. Вона працює на всіх платформах (iOS, Android, Web, macOS, Windows, Linux) без нативних залежностей. Hive здатен обробляти понад 1000 запитів на секунду при розмірі боксу до 100 МБ. Це знижує навантаження на сервер і прискорює відгук додатка. Згідно з офіційною документацією Hive, локальне зберігання даних прискорює роботу додатка в 3–5 разів. Ми маємо більше 5 років досвіду у Flutter та реалізували понад 20 проєктів з локальним зберіганням, гарантуючи якість і підтримку.

Hive на GitHub — відкритий вихідний код, активно підтримується. Ми використовуємо його в продакшені для кешування довідників і користувацьких токенів.

Чому Hive швидший за SQLite та SharedPreferences?

Hive зберігає дані в бінарному форматі і тримає часто використовувані боксами в пам'яті. Для читання одного об'єкта він витрачає в середньому 0.02 ms проти 0.3 ms у SQLite, тобто Hive швидше за SQLite в 15 разів при читанні. SharedPreferences ж не підтримує складні структури та блокує UI при записі. Hive вирішує обидві проблеми: швидкість і типобезпека. Додатково, Hive підтримує ліниве відкриття боксів та композитні ключі для ефективної організації даних.

Порівняємо продуктивність:

Захист даних в Hive за допомогою шифрування

Для чутливих даних (токени, особисті дані користувача) використовуйте зашифрований бокс. Ключ шифрування генерується через Hive.generateSecureKey() і зберігається у flutter_secure_storage — не в SharedPreferences і не в самому Hive. Це виключає розшифровку при витоку файлів. Шифрування AES-256 додає близько 10% накладних витрат, що критично тільки для дуже частих операцій. В якості альтернативи можна використовувати часткове шифрування — тільки певні поля.

final secureStorage = const FlutterSecureStorage();
var encryptionKey = await secureStorage.read(key: 'hive_key');
if (encryptionKey == null) {
  final key = Hive.generateSecureKey();
  await secureStorage.write(key: 'hive_key', value: base64Url.encode(key));
  encryptionKey = base64Url.encode(key);
}
final encryptedBox = await Hive.openBox('secureBox',
  encryptionCipher: HiveAesCipher(base64Url.decode(encryptionKey)));

Вирішення проблеми повільного завантаження даних з Hive

Якщо ваш додаток підвантажує довідники або кеш з мережі, Hive дозволяє скоротити час відгуку: дані лежать локально і доступні миттєво. Композитні ключі та префіксні запити пришвидшують пошук за категоріями. Наприклад, для списку товарів можна зберігати бокс з типом Box<Product>, а ключами зробити ідентифікатори. Завантаження 10 000 записів займає менше 0.1 секунди. Ми економимо до 30% часу розробки за рахунок готових адаптерів. Середня економія на серверній інфраструктурі становить близько $150 на місяць, а клієнти економлять до $500 на рік за рахунок зниження кількості запитів до API. Базове налаштування Hive з CRUD та 2–3 моделями коштує від $400 до $1000. Повне налаштування з шифруванням та кодогенерацією — від $1500 до $3000.

Що входить в роботу з налаштування Hive?

Результат налаштування включає:

• CRUD-операції для всіх моделей даних.
• TypeAdapter для кожної кастомної моделі з кодогенерацією.
• Шифрування AES-256 для конфіденційних боксів.
• Документація з архітектури зберігання та інструкція з експлуатації.
• Навчання команди роботі з Hive (1–2 години онлайн).
• Технічна підтримка протягом 2 тижнів після здачі. Ми гарантуємо якість усіх робіт.

Процес налаштування Hive під ваш проєкт

Налаштування включає кілька обов'язкових етапів:

1. Підключення залежностей у pubspec.yaml — hive, hive_flutter, hive_generator та build_runner.
2. Ініціалізація Hive в main() — await Hive.initFlutter() та відкриття необхідних боксів.
3. Створення TypeAdapter для кожної кастомної моделі з анотаціями @HiveType та @HiveField, після чого запуск кодогенерації (flutter pub run build_runner build).
4. Налаштування шифрування для боксів з конфіденційними даними.
5. Тестування продуктивності — перевірка часу читання/запису та стабільності при багатопоточному доступі.

TypeAdapters для кастомних об'єктів

Hive не вміє зберігати довільні Dart-класи без адаптера. Анотуємо модель:

@HiveType(typeId: 0)
class User extends HiveObject {
  @HiveField(0)
  late String id;

  @HiveField(1)
  late String name;
}

Запускаємо кодогенерацію: flutter pub run build_runner build. Генерується user.g.dart з UserAdapter. typeId має бути унікальним у всьому додатку — конфлікт typeId призводить до HiveError при відкритті боксу.

Типові помилки та як їх уникнути

• HiveError при доступі до невідкритого боксу — відкривайте всі боксу в main(), а потім використовуйте Hive.box<T>('name').
• Втрата даних при вивантаженні з пам'яті — закривайте боксу через Hive.close() у WidgetsBindingObserver.
• Конфлікт typeId — призначайте унікальні ідентифікатори для кожного TypeAdapter.

Етапи та терміни робіт

Вартість та терміни

Базове налаштування з CRUD та 2–3 моделями — від $400 до $1000 (2–5 днів). З шифруванням та кодогенерацією під весь проєкт — від $1500 до $3000 (до 2 тижнів). Ми маємо досвід розробки Flutter-додатків понад 5 років і реалізували більше 20 проєктів з локальним зберіганням. Зв'яжіться з нами для безкоштовного аудиту вашого поточного сховища — це допоможе вибрати оптимальну архітектуру зберігання. Замовте налаштування Hive під ключ і прискорте свій додаток.

Як обрати кроссплатформну розробку: Flutter, React Native чи KMM?

Коли потрібен додаток на iOS та Android, а бюджет на дві окремі команди — постає питання вибору фреймворку. Ми бачили проєкти, де неправильний вибір призводив до переписування через півроку. Кожен інструмент диктує свій стек і накладає обмеження. Перед стартом проводимо аудит технологічних вимог та експертизи команди.

Три основні гравці зараз: Flutter, React Native та Kotlin Multiplatform Mobile. Вони вирішують різні проблеми і погано порівнюються в лоб. Нижче розберемо, як обрати оптимальний варіант під ваш проєкт.

Кроссплатформна розробка: основні критерії вибору

Перше — зрозуміти, що саме ви будете робити: багатий брендовий UI чи нативний look and feel? Друге — якою мовою володіє команда. Якщо це JavaScript/TypeScript — React Native дає швидкий старт. Якщо Dart — Flutter. Якщо хочуть оптимізувати логіку — KMM. Третє — які нативні API будуть задіяні: камера, Bluetooth, фонові оновлення. Для деяких стеків інтеграція складніша.

Як ми обираємо кроссплатформний фреймворк?

1. Аналіз вимог — список нативних API, необхідність автономної роботи, брендовий UI або стандартний.
2. Оцінка команди — експертиза в Dart, JavaScript/Kotlin, наявність iOS-розробника.
3. Прототип (proof-of-concept) — реалізація критичного сценарію на обраному стеку за 2–3 дні.
4. Фінальне рішення — на основі бенчмарків продуктивності та вартості підтримки.

Чим відрізняються Flutter і React Native?

Це порівняння, яке реально впливає на вибір. Розберемо за конкретними технічними характеристиками.

Модель рендерингу

Flutter рендерить UI самостійно через Impeller (замінив Skia починаючи з версії 3.10). Платформа надає лише canvas — Flutter малює кожен піксель сам. Це означає:

• Піксельна точність на всіх платформах. Один і той же віджет виглядає однаково на iOS та Android — добре для брендових додатків, погано якщо потрібно виглядати «нативно» на кожній платформі.
• Немає залежності від версії ОС. Material 3 у Flutter працює однаково на Android 8 та Android 14. Системні компоненти Android не беруть участі.
• Platform channels для нативного коду. Доступ до камери, Bluetooth, NFC — через MethodChannel або EventChannel. flutter_camera, flutter_blue_plus — це обгортки над platform channels.

React Native використовує нативні компоненти платформи. <View> на iOS — це UIView. <Text> — це UILabel. Це означає:

• Нативний look and feel без додаткових зусиль.
• New Architecture (Fabric + TurboModules) з JSI прибрала JSON-міст між JS та нативним кодом. Синхронні виклики працюють без серіалізації. Це критично для анімацій та жестів.
• React Native Reanimated 3 запускає worklets на UI thread — анімації в 60/120 fps без блокування JS thread.

Продуктивність на практиці

Для більшості бізнес-додатків різниця в продуктивності між Flutter та React Native New Architecture непомітна користувачеві. Різниця з’являється в граничних випадках.

Flutter повільніший при взаємодії з платформеними API через platform channels — кожен виклик асинхронний, є накладні витрати на серіалізацію даних. google_maps_flutter рендерить карту через PlatformView — це нативний UIView/View, вбудований у Flutter-дерево. До Impeller це викликало проблеми з продуктивністю (Hybrid Composition vs Virtual Display). З Impeller ситуація покращилась, але PlatformView все ще дорожчий за чистий Flutter-віджет.

React Native повільніший у сценаріях з важкою JS-логікою на main thread. Парсинг великого JSON, складні обчислення — це блокує JS thread і видно як фриз UI. Рішення: Hermes (JS-двигун, оптимізований для RN) + винесення обчислень у нативний модуль або react-native-workers. З Hermes час холодного старту знижується на 30–40% порівняно з JavaScriptCore, тобто Hermes у 1,3–1,4 раза швидше за старий двигун.

Екосистема та зрілість

Dart — бар’єр входу для команд з JS/TS-бекграундом. Освоїти базовий Dart за тиждень реально. Перебудувати мислення під Flutter-віджети та widget tree — займає більше. TypeScript у React Native — стандарт де-факто. Команда з React-досвідом починає продуктивно швидше.

Коли обирати Flutter?

Коли обирати React Native?

• Команда з React/TypeScript-експертизою.
• Потрібен нативний look and feel платформи.
• Активне використання нативних компонентів (Maps, Camera з нативними можливостями).
• Шарінг коду з React-вебом через монорепозиторій.

Чи варто обирати KMM для вашого проєкту?

KMM вирішує не UI-проблему, а проблему дублювання бізнес-логіки. Концепція: пишемо бізнес-логіку, роботу з мережею, кеш, валідацію один раз на Kotlin. iOS отримує .framework через Kotlin/Native, Android використовує бібліотеку безпосередньо. UI на кожній платформі — нативний.

// Спільний Kotlin код — працює на iOS та Android
class UserRepository(
    private val httpClient: HttpClient, // Ktor
    private val database: AppDatabase   // SQLDelight
) {
    suspend fun getUser(id: String): User {
        return database.userQueries.selectById(id).executeAsOneOrNull()
            ?: httpClient.get("$BASE_URL/users/$id").body<User>().also {
                database.userQueries.insert(it)
            }
    }
}

Ktor — HTTP-клієнт для KMM (працює на iOS через Darwin engine, на Android через OkHttp). SQLDelight генерує typesafe Kotlin API для SQLite, працює на обох платформах.

Реальні обмеження KMM

Coroutines на iOS: suspend-функції з shared коду викликаються через автоматично згенеровані обгортки. SKIE (Swift/Kotlin Interface Enhancer) від Touchlab значно покращує Swift-інтерфейс: async/await замість callback, AsyncStream для Flow. Без SKIE працювати з coroutines із Swift незручно.

Compose Multiplatform: JetBrains розвиває Compose для iOS — UI на Compose працює на iOS через Metal. Це стирає межу з Flutter: один Compose-код для обох платформ. Статус на сьогодні: Beta, у production є ранні adopters (Touchlab, JetBrains власні продукти), але стабільність нижче Flutter.

Складність iOS-інтеграції: XCFramework з KMM-модуля додається в Xcode-проєкт. SPM-інтеграція з’явилась і працює. Але iOS-розробники повинні розуміти Kotlin-API та правила роботи з пам’яттю через Kotlin/Native (ARC + Kotlin GC працюють разом, це не завжди очевидно).

Коли KMM виправданий

У компанії вже є зрілі iOS та Android команди, які дублюють бізнес-логіку. Переводити все на Flutter або React Native — занадто радикально. KMM дозволяє почати з малого: винести мережевий шар і моделі в shared, залишити UI нативним. Поступова міграція без переписування всього.

«Маєте нативний досвід — використовуйте React Native, хочете контролювати кожен піксель — Flutter» — один із принципів, який ми застосовуємо під час консультацій.

Помилки, яких варто уникати при виборі стеку

Вибір Flutter «тому що одна кодова база» для додатку, який сильно зав’язаний на нативні API (custom camera, BLE, background processing). Реалізовувати це через platform channels — додаткова складність, яка з’їдає виграш у швидкості розробки.

React Native без розуміння JS-thread. Важкі операції на JS thread дають видимі фризи. Це вирішувано, але потребує розуміння архітектури — інакше додаток працюватиме гірше нативного.

KMM без iOS-розробника в команді. Shared Kotlin-код потребує iOS-інженера, який інтегрує фреймворк у Xcode, пише SwiftUI поверх KMM API та дебажить Kotlin/Native-краші.

Процес і терміни

Кроссплатформний проєкт проходить ті ж етапи, що й нативний: аудит вимог → вибір стеку → дизайн → розробка → тестування на реальних пристроях обох платформ → публікація в App Store та Google Play → підтримка.

Тестування на реальних пристроях — не опціональний етап. Емулятор не відтворює проблеми з пам’яттю на бюджетних Android-телефонах і не показує різницю в поведінці жестів на iOS.

Економія бюджету порівняно з двома нативними командами сягає 40–50%. Для проєкту середньої складності це становить $40,000–$80,000 на етапі MVP. Вартість розраховується індивідуально після аналізу стеку та вимог.

Що входить у нашу роботу

• Технічний аудит та вибір стеку під ваш проєкт.
• Проєктування архітектури (чиста архітектура, MVVM, BLoC/Redux).
• Розробка UI за макетами дизайну на обидві платформи.
• Інтеграція нативних модулів (камера, геолокація, пуш-повідомлення).
• Налаштування CI/CD (GitHub Actions, Codemagic).
• Тестування на реальних пристроях (iOS/Android) — не менше 40 сценаріїв.
• Підготовка та публікація в App Store і Google Play з урахуванням гайдлайнів (App Store Review, Google Play Policy).
• Технічна підтримка 3 місяці після запуску.
• Передача вихідного коду, документації, доступів — все під ключ.

Ми маємо 5+ років досвіду в кроссплатформній розробці, реалізували понад 30 успішних проєктів. Гарантуємо дотримання строків та якість коду. Зв'яжіться з нами для аудиту вашого проєкту — підберемо оптимальний стек за один день. Отримайте консультацію з вибору стеку вже сьогодні, замовте розробку під ключ та отримайте готовий кроссплатформний додаток в обумовлені терміни.