> Какие пакеты для локального хранения данных во Flutter использовать (Flutter, Android)

Короткий ответ

Для локального хранения данных во Flutter выбор зависит от типа данных: для простых ключ-значение - shared_preferences, для структурированных реляционных данных - sqflite или drift, для документо-ориентированных - hive или isar. Для файлов и бинарных данных используйте path_provider в связке с dart:io. На практике чаще всего комбинируют shared_preferences для настроек и drift или isar для основной бизнес-логики.

Подробное объяснение

Основные пакеты и их назначение:

• shared_preferences - обёртка над SharedPreferences (Android) и NSUserDefaults (iOS). Подходит для небольших объёмов: токены, настройки, флаги. Не предназначен для больших или сложных структур.
• sqflite - прямой доступ к SQLite. Требует ручного написания SQL-запросов и управления схемой. Хорош для простых реляционных моделей, но при росте проекта становится сложно поддерживать.
• drift (ранее moor) - реактивная ORM поверх SQLite. Даёт типизацию, миграции, streams для реактивного обновления UI. Рекомендуется для средних и крупных проектов с реляционными данными.
• hive - быстрый key-value store без зависимостей от нативных библиотек. Хорош для кэширования и простых объектов, но нет поддержки сложных запросов и индексов.
• isar - современная замена hive, с поддержкой индексов, полнотекстового поиска, отношений. Быстрее, но требует генерации кода и менее зрелый, чем drift.
• path_provider - не хранилище, но необходим для получения путей к директориям приложения (Documents, Cache, Temporary) при работе с файлами.

Ключевые trade-off:

• shared_preferences - простота, но блокирующий API и ограниченный размер.
• sqflite - контроль над SQL, но ручная работа с миграциями и отсутствие типизации.
• drift - безопасность типов и реактивность, но сложность настройки и генерация кода.
• hive/isar - скорость и простота, но ограниченная модель запросов (isar лучше в этом плане).

Для Android-специфичных сценариев (например, большие файлы) стоит использовать path_provider + dart:io, а не пытаться засунуть всё в базу.

На практике

Типичный подход для production-приложения:

1. Настройки и лёгкие данные - shared_preferences.
2. Основные сущности (пользователи, заказы, сообщения) - drift или isar, если нужна реактивность и сложные запросы.
3. Кэш изображений или больших объектов - файловая система через path_provider + cached_network_image для изображений.
4. Если нужен офлайн-режим с синхронизацией - рассмотрите drift с поддержкой миграций и версионирования.

При выборе между drift и isar учитывайте: drift - если уже используете SQL или нужна сложная реляционная логика; isar - если важна скорость и простота, но не нужны сложные JOIN.

Пример кода

// shared_preferences
final prefs = await SharedPreferences.getInstance();
await prefs.setString('auth_token', token);
final token = prefs.getString('auth_token');

// drift
@DriftDatabase(tables: [Users])
class AppDatabase extends _$AppDatabase {
  AppDatabase() : super(_openConnection());

  @override
  int get schemaVersion => 1;

  Future<List<User>> getAllUsers() => select(users).get();
  Stream<List<User>> watchUsers() => select(users).watch();
}

// isar
final isar = await Isar.open([UserSchema]);
final user = User()..name = 'Alice';
await isar.writeTxn(() => isar.users.put(user));
final allUsers = await isar.users.where().findAll();

Как отвечать на собеседовании

Начните с классификации по типам данных, затем переходите к конкретным пакетам. Обязательно упомяните trade-off между ними и критерии выбора. Покажите, что понимаете ограничения shared_preferences и когда нужна полноценная БД. Если спросят про производительность - сравните скорость чтения/записи и влияние на размер бандла. Хорошо добавить пример из реального проекта, где вы выбирали между drift и isar.

Что проверяет интервьюер

• Понимание различий между key-value и реляционными хранилищами.
• Умение обосновать выбор пакета под конкретную задачу.
• Знание ограничений и подводных камней (например, блокирующий API у shared_preferences).
• Опыт работы с миграциями и реактивными потоками.
• Способность оценить сложность поддержки и масштабируемость решения.

Типичные ошибки

• Использование shared_preferences для хранения больших JSON-объектов или списков.
• Выбор sqflite без необходимости в SQL, когда достаточно hive или isar.
• Игнорирование миграций при изменении схемы в drift или sqflite.
• Забывают про path_provider для файлов, пытаясь хранить всё в БД.
• Не учитывают накладные расходы на генерацию кода (build_runner) в CI/CD.
• Путают hive и isar - hive не поддерживает индексы и сложные запросы, isar - поддерживает.