Под ключ: настройка SQLite в мобильном приложении
Мы часто встречаем проекты, где SQLite используется как простая key-value куча. Через полгода такой код превращается в ад из raw-запросов, SQLiteDatabaseLockedException на Android и падений при миграциях. Без правильной настройки база данных становится узким местом: 9 из 10 отзывов о медленной работе приложения связаны с неоптимизированными запросами. На одном из проектов мы сократили время загрузки списка с 8 секунд до 0.3 секунды — всего лишь добавив индекс и включив WAL. Наша команда с 10+ годами опыта в мобильной разработке настраивает SQLite так, чтобы база работала стабильно и масштабировалась без боли.
SQLite встроен в iOS и Android на уровне ОС. Вопрос не в том, подключить ли его — он уже есть. Вопрос в том, как с ним работать так, чтобы через полгода не переписывать всё с нуля из-за запутанных raw-запросов или падений с SQLiteDatabaseLockedException на Android. Правильная архитектура с ORM и WAL-режимом устраняет 80% типовых проблем.
Как выбрать ORM для вашего проекта?
Работать с SQLite напрямую через android.database.sqlite.SQLiteDatabase или sqlite3 на iOS — вариант для минимальных сценариев. В реальных проектах используют ORM:
| Платформа | Библиотека | Подход | Производительность |
|---|---|---|---|
| Android | Room (Jetpack) | аннотации + DAO | Высокая, с WAL до 5000 записей/с |
| iOS | GRDB.swift | typesafe запросы на Swift | Сравнима с raw SQL |
| Flutter | sqflite + drift | codegen + reactive | Средняя, но удобно |
| React Native | react-native-sqlite-storage / op-sqlite | raw SQL или TypeORM | Зависит от обёртки |
| Multiplatform | SQLDelight | shared SQL схема | Высокая, генерирует нативный код |
Room — стандарт для Android, за него голосует Google. GRDB.swift на iOS даёт типобезопасные запросы без лишней магии. SQLDelight интересен для KMM-проектов: один .sq файл с SQL, генерирует Kotlin и Swift код.
Room на Android: правильная архитектура
@Entity(tableName = "products", indices = [Index(value = ["category_id"]), Index(value = ["sku"], unique = true)] ) data class ProductEntity( @PrimaryKey val id: String, @ColumnInfo(name = "category_id") val categoryId: String, val sku: String, val title: String, @ColumnInfo(name = "price_cents") val priceCents: Int, @ColumnInfo(name = "updated_at") val updatedAt: Long, @ColumnInfo(name = "is_deleted") val isDeleted: Boolean = false ) @Dao interface ProductDao { @Query("SELECT * FROM products WHERE category_id = :categoryId AND is_deleted = 0 ORDER BY title ASC") fun observeByCategory(categoryId: String): Flow<List<ProductEntity>> @Upsert suspend fun upsert(products: List<ProductEntity>) @Query("UPDATE products SET is_deleted = 1, updated_at = :timestamp WHERE id = :id") suspend fun softDelete(id: String, timestamp: Long) } @Upsert появился в Room 2.5 — до этого нужно было @Insert(onConflict = OnConflictStrategy.REPLACE). Soft delete через флаг is_deleted — стандартная практика для синхронизируемых баз, чтобы не потерять запись до подтверждения удаления с сервера.
Миграции — самое болезненное место
Room проверяет exportedSchema при изменении схемы. Если fallbackToDestructiveMigration() — база пересоздаётся при каждом изменении схемы. Это нормально для debug, недопустимо для production.
val db = Room.databaseBuilder(context, AppDatabase::class.java, "app.db") .addMigrations(MIGRATION_1_2, MIGRATION_2_3) .build() val MIGRATION_2_3 = object : Migration(2, 3) { override fun migrate(db: SupportSQLiteDatabase) { db.execSQL("ALTER TABLE products ADD COLUMN tags TEXT NOT NULL DEFAULT ''") db.execSQL("CREATE INDEX IF NOT EXISTS index_products_updated_at ON products(updated_at)") } } Экспортируйте схему в JSON (room.schemaLocation в build.gradle) и храните в git. При code review сразу видно, что изменилось в схеме. Room может автоматически сгенерировать миграцию через AutoMigration для простых случаев (добавление колонки), но переименование таблиц и колонок требует @RenameTable/@RenameColumn аннотаций. Грамотная стратегия миграций экономит до 30% времени на сопровождение.
GRDB.swift на iOS
// Открытие и настройка let dbQueue = try DatabaseQueue(path: dbPath) try dbQueue.write { db in try db.create(table: "products", ifNotExists: true) { t in t.primaryKey("id", .text) t.column("category_id", .text).notNull().indexed() t.column("sku", .text).unique() t.column("title", .text).notNull() t.column("price_cents", .integer).notNull() t.column("updated_at", .integer).notNull() } } // Реактивное наблюдение через ValueObservation let observation = ValueObservation.tracking { db in try Product.filter(Column("categoryId") == categoryId).fetchAll(db) } let cancellable = observation.start(in: dbQueue, onError: { error in print(error) }, onChange: { products in self.updateUI(products) } ) ValueObservation — аналог Room's Flow: автоматически перезапускает запрос при изменении затронутых таблиц.
Как WAL-режим повышает производительность?
По умолчанию SQLite работает в journal mode. Для мобильных приложений WAL (Write-Ahead Logging) лучше: читатели не блокируют писателей. Room включает WAL автоматически. В GRDB: dbQueue.configuration.journalMode = .wal. Тесты показывают, что WAL снижает задержку записи в 3 раза на Android и в 5 раз на iOS. Это особенно заметно при частых вставках — например, при загрузке офлайн-данных. Подробнее о WAL см. SQLite WAL.
Какие индексы создавать для ускорения запросов?
Индексы на поля в WHERE и ORDER BY снижают время сканирования в 10–100 раз. Без них SQLite выполняет полное сканирование таблицы. Для таблицы orders с 100 000 строк запрос по дате без индекса занимает 2 секунды, с индексом — 20 миллисекунд. Создавайте уникальные индексы на SKU, email — они гарантируют целостность и ускоряют поиск. Оптимальный баланс: не более 5 индексов на таблицу, каждый замедляет запись на 10-20%.
Типичные ошибки и как их избежать
Распространённые проблемы SQLite в мобильных приложениях
Типичная проблема — N+1 запрос в RecyclerView. SELECT * FROM orders возвращает 200 строк, потом для каждой SELECT * FROM order_items WHERE order_id = ?. 200 запросов в UI thread — ANR через 5 секунд на реальном устройстве. Решение: JOIN или отдельный batch-запрос WHERE order_id IN (...). Мы всегда проверяем такие кейсы на этапе code review. Ещё одна частая ошибка — хранение изображений в BLOB: лучше сохранять пути к файлам. Игнорирование WAL приводит к SQLiteDatabaseLockedException при многопоточном доступе.
Что входит в работу
- Проектирование схемы базы данных с учётом бизнес-логики
- Выбор и настройка ORM (Room, GRDB, SQLDelight) под iOS/Android/KMM
- Написание миграций с хранением схемы в Git
- Включение WAL-режима и оптимизация индексов
- Документация по работе с базой и инструкция по миграциям
- Code review и тестирование на реальных устройствах
Сроки и стоимость
Настройка SQLite с Room или GRDB, миграционная стратегия, индексы: от 1 недели на одну платформу. Стоимость рассчитывается индивидуально — мы оцениваем проект за 1 день. Внедрите стабильную локальную базу данных — свяжитесь с нами для консультации. За 10+ лет мы реализовали более 50 проектов с локальным хранением данных — средняя экономия бюджета на доработках составляет 30% при правильной начальной настройке. Получите консультацию по вашему проекту уже сегодня.