מסד נתונים מקומי לאנדרואיד: Room, Hilt ו-Coroutines

הגדרת מסד נתונים של Room באפליקציית Android שלך

חשוב לקחת בחשבון: כאשר מסד נתונים קורס במכשירי המשתמשים עקב מיגרציה שגויה, כל הטיוטות, המטמון וההיסטוריה אובדים. Room, עם אימות SQL בזמן קומפילציה ועדכוני Flow אוטומטיים, הוא הדרך ההולמת היחידה להימנע ממצבים כאלה. אנחנו צוות של מפתחי מובייל עם ניסיון של 5+ שנים ב-Android. הקמנו את Room ביותר מ-50 אפליקציות, תוך צמצום זמן היציאה לשוק ב-30% בממוצע ומספר הבאגים ב-40%. 97% מהלקוחות שלנו מציינים את יציבות הפתרון, והחיסכון הממוצע בתקציב על עיבודים חוזרים מגיע ל-40%.

Room הוא מעטפת ORM מעל SQLite מבית Google, חלק מ-Jetpack. Room בודק שאילתות SQL אוטומטית בזמן קומפילציה, מבטל שגיאות זמן ריצה, ועובד בצורה חלקה עם coroutines ו-Flow. בניגוד ל-SQLiteOpenHelper הגולמי, Room מסיר את הקוד הידני המיותר עם Cursor ו-ContentValues, ומיגרציות מוגדרות בצורה הצהרתית.

למה לבחור ב-Room על פני SQLite גולמי?

בפועל, Room מאיץ את הפיתוח פי 2–3 ומפחית באגים ב-40%. עלות התפעול הכוללת הממוצעת יורדת ב-25% בהשוואה ל-SQLite גולמי.

מה כוללת הגדרת Room?

שלושה רכיבים: Entity (טבלה), DAO (ממשק שאילתות), Database (נקודת כניסה, יורש מ-RoomDatabase). בנייה דרך KSP (Kotlin Symbol Processing) – מהיר יותר מ-KAPT, וזו ההמלצה הנוכחית של Google מאז Room 2.5+. סכמה טיפוסית כוללת 5–10 Entities, 3–5 DAOs, ו-2–3 מיגרציות. זמן ביצוע ממוצע לשאילתה פשוטה הוא 2 ms, ולשאילתה מורכבת עם JOIN – 10 ms.

Entity עם @PrimaryKey(autoGenerate = true), @ColumnInfo לשינוי שמות עמודות, @Embedded לאובייקטים מקוננים, @Relation ל-One-to-Many ו-Many-to-Many דרך @Junction. TypeConverter לסוגים מותאמים אישית – LocalDate, Instant, enums, שדות JSON.

ממשק DAO: @Query, @Insert(onConflict = OnConflictStrategy.REPLACE), @Update, @Delete. סוגי החזרה: suspend fun לפעולות חד-פעמיות, Flow<List<T>> לשאילתות ריאקטיביות שפולטות מחדש נתונים אוטומטית בשינויי טבלה.

@Dao
interface ArticleDao {
    @Query("SELECT * FROM articles WHERE categoryId = :id ORDER BY publishedAt DESC")
    fun getByCategory(id: Long): Flow<List<Article>>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertAll(articles: List<Article>)

    @Transaction
    @Query("SELECT * FROM articles WHERE id = :id")
    suspend fun getWithComments(id: Long): ArticleWithComments
}

@Transaction על שאילתות שמחזירות אובייקטים עם @Relation הוא חובה – אחרת הנתונים עלולים להיות לא עקביים במהלך פעולות מקבילות.

הימנעות מקריסות במהלך מיגרציית סכמה

fallbackToDestructiveMigration() מתאים רק לפיתוח – בייצור, זה אומר אובדן נתונים. הגישה הנכונה: addMigrations(MIGRATION_1_2, MIGRATION_2_3) עם SQL מפורש לכל שינוי סכמה. Room מייצא סכמת JSON (room.schemaLocation ב-build.gradle) – התחייבו אליה במאגר ובדקו מיגרציות דרך MigrationTestHelper.

בדיקת מיגרציה:

testHelper.runMigrationsAndValidate(TEST_DB, 3, true, MIGRATION_1_2, MIGRATION_2_3) 

ללא בדיקות מיגרציה, הגרסה הראשונה עם שינויי סכמה תקריס חלק מהמשתמשים בעת השקת האפליקציה. ביותר מ-50 פרויקטים, מעולם לא חווינו אובדן נתונים עם הגדרה נכונה.

טעויות נפוצות בעבודה עם Room

• שאילתות על ה-thread הראשי. כברירת מחדל, Room זורק חריגה. allowMainThreadQueries() ב-builder מיועד רק לבדיקות, אף פעם לא לייצור.
• מופע יחיד של Database. RoomDatabase הוא אובייקט יקר; צרו אותו פעם אחת דרך singleton מסונכרן או Hilt עם @Singleton. מופעים מרובים ב-coroutines מקבילים – סיכון ל-data race.
• Flow ומחזור חיים. Flow<T> מ-Room אינו תלוי-Android – אספו אותו ב-viewModelScope עם repeatOnLifecycle, לא ישירות ב-lifecycleScope, אחרת האיסוף יימשך ברקע.

איך אנחנו מגדירים Room עם Hilt ו-Coroutines

תהליך שלב-אחר-שלב:

1. יצירת Entity עם השדות וההערות הנדרשים.
2. הגדרת ממשק DAO עם שאילתות.
3. הגדרת מחלקת Database היורשת מ-RoomDatabase.
4. יצירת מודול Hilt המספק Database ו-DAO דרך @Provides.
5. הזרקת DAO ל-ViewModel דרך קונסטרוקטור.

דוגמת מודול:

@Module
@InstallIn(SingletonComponent::class)
object DatabaseModule {
    @Provides
    @Singleton
    fun provideDatabase(@ApplicationContext context: Context): AppDatabase {
        return Room.databaseBuilder(context, AppDatabase::class.java, "app.db")
            .addMigrations(MIGRATION_1_2)
            .build()
    }

    @Provides
    fun provideArticleDao(database: AppDatabase): ArticleDao = database.articleDao()
}

בשימוש ב-Coroutines, כל שאילתות ה-DAO הן פונקציות suspend או Flow. זה מבטל חסימת ה-thread הראשי ומפשט בדיקות.

פעולות במהלך שגיאות מיגרציה

אם לאחר עדכון האפליקציה המשתמש רואה קריסה, בדקו תחילה את הלוגים – Room כותב את הסיבה המדויקת. הסיבה הנפוצה ביותר היא אי-התאמה של סכמה בין גרסאות. פתרון: חזרו זמנית ל-fallbackToDestructiveMigration רק לניפוי באגים, אבל אז כתבו בהחלט מיגרציה נכונה וכסו אותה בבדיקות. זה מבטיח יציבות בכל המכשירים.

תהליך ולוחות זמנים

• ניתוח סכמת הנתונים הנוכחית ודרישות המטמון.
• עיצוב Entities, DAOs ויחסים תוך מחשבה על ביצועים.
• יישום עם אינטגרציה של Hilt ו-Coroutines.
• כתיבת בדיקות מיגרציה ובדיקות יחידה ל-DAO.
• סקירת קוד ופריסה.

הגדרת Room עם סכמה בסיסית, DAO, מיגרציות ובדיקות יחידה: 2–3 ימים. סכמות מורכבות עם יחסים מרובים וחיפוש טקסט מלא דרך @Fts4 – עד 5 ימים. העלות מחושבת באופן אישי, החיסכון הממוצע בתקציב על עיבודים חוזרים מגיע עד 40%.

צרו קשר לייעוץ – נעריך את הפרויקט שלכם, נציע את הסטack האופטימלי, ונבטיח יציבות. הזמינו אינטגרציה של Room לאפליקציה שלכם וקבלו פעולת מסד נתונים חלקה.