הסיפור על איך מחיקת אשד ב-Realm ניצחה על השקה ארוכה

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

גילינו פעם שלאפליקציה Dodo Pizza לוקח 3 שניות להפעיל בממוצע, ולכמה "ברי מזל" זה לוקח 15-20 שניות.

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

מחבר המאמר: מקסים קצ'ינקין - מפתח אנדרואיד ב-Dodo Pizza.

שלוש שניות מלחיצה על סמל האפליקציה ל-onResume() של הפעילות הראשונה הן אינסוף. ועבור חלק מהמשתמשים, זמן ההפעלה הגיע ל-15-20 שניות. איך זה בכלל אפשרי?

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

חיפוש וניתוח הבעיה

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

בהתחלה, אנחנו עצמנו עמדנו בפני העובדה שלפעמים האפליקציה לקחה כמה שניות להפעלה, ואז התחלנו לשמוע תלונות מעמיתים אחרים על כמה זמן זה לקח. אבל לא הצלחנו לחזור על המצב הזה באופן עקבי.

כמה ארוך זה? לפי תיעוד של גוגל, אם התחלה קרה של יישום נמשכת פחות מ-5 שניות, אז זה נחשב "כאילו נורמלי". אפליקציית אנדרואיד Dodo Pizza הושקה (לפי מדדי Firebase _app_start) בשעה התחלה קרה בממוצע תוך 3 שניות - "לא נהדר, לא נורא", כמו שאומרים.

אבל אז התחילו להופיע תלונות על כך שהאפליקציה לקחה הרבה מאוד מאוד זמן להשיק! מלכתחילה החלטנו למדוד מה זה "מאוד, מאוד, מאוד ארוך". והשתמשנו ב-Firebase Trace בשביל זה מעקב אחר התחלת האפליקציה.

מעקב סטנדרטי זה מודד את הזמן בין הרגע שבו המשתמש פותח את האפליקציה ועד לרגע ביצוע onResume() של הפעילות הראשונה. ב-Firebase Console המדד הזה נקרא _app_start. התברר ש:

• זמני האתחול של משתמשים מעל האחוזון ה-95 הם כמעט 20 שניות (חלקם אף ארוכים יותר), למרות שזמן האתחול הקר החציוני הוא פחות מ-5 שניות.
• זמן ההפעלה אינו ערך קבוע, אלא גדל עם הזמן. אבל לפעמים יש טיפות. מצאנו דפוס זה כשהגדלנו את סולם הניתוח ל-90 ימים.

שתי מחשבות עלו בראש:

1. משהו דולף.
2. ה"משהו" הזה מתאפס לאחר השחרור ואז דולף שוב.

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

מה רע במסד הנתונים של Realm

התחלנו לבדוק כיצד משתנה התוכן של בסיס הנתונים במהלך חיי האפליקציה, מההתקנה הראשונה ובהמשך במהלך השימוש הפעיל. אתה יכול להציג את התוכן של מסד הנתונים של הממלכה דרך סטטו או ביתר פירוט וברור על ידי פתיחת הקובץ דרך סטודיו ממלכה. כדי להציג את תוכן מסד הנתונים באמצעות ADB, העתק את קובץ מסד הנתונים של Realm:

adb exec-out run-as ${PACKAGE_NAME} cat files/${DB_NAME}

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

התמונה מציגה קטע של Realm Studio עבור שני קבצים: משמאל - בסיס האפליקציה זמן מה לאחר ההתקנה, מימין - לאחר שימוש פעיל. ניתן לראות שמספר החפצים ImageEntity и MoneyType גדל באופן משמעותי (צילום המסך מציג את מספר החפצים מכל סוג).

הקשר בין צמיחת מסד הנתונים וזמן ההפעלה

צמיחה בלתי מבוקרת של מסדי נתונים היא גרועה מאוד. אבל איך זה משפיע על זמן ההפעלה של האפליקציה? זה די קל למדוד את זה דרך ActivityManager. מאז אנדרואיד 4.4, logcat מציג את היומן עם המחרוזת המוצגת והשעה. זמן זה שווה למרווח מרגע הפעלת האפליקציה ועד לסיום עיבוד הפעילות. במהלך תקופה זו מתרחשים האירועים הבאים:

• התחל את התהליך.
• אתחול של אובייקטים.
• יצירה ואתחול פעילויות.
• יצירת פריסה.
• עיבוד יישומים.

מתאים לנו. אם אתה מפעיל את ADB עם הדגלים -S ו-W, אתה יכול לקבל פלט מורחב עם זמן האתחול:

adb shell am start -S -W ru.dodopizza.app/.MainActivity -c android.intent.category.LAUNCHER -a android.intent.action.MAIN

אם אתה תופס את זה משם grep -i WaitTime זמן, אתה יכול להפוך את איסוף המדד הזה לאוטומטי ולהסתכל חזותית על התוצאות. הגרף שלהלן מציג את התלות של זמן ההפעלה של האפליקציה במספר ההתחלות הקרות של האפליקציה.

יחד עם זאת, היה אותו אופי של הקשר בין גודל וצמיחה של בסיס הנתונים, שצמח מ-4 מגה-בייט ל-15 מגה-בייט. בסך הכל מסתבר שעם הזמן (עם צמיחת ההתחלות הקרות), גם זמן השקת האפליקציה וגם גודל בסיס הנתונים גדלו. יש לנו השערה על הידיים. כעת נותר רק לאשר את התלות. לכן, החלטנו להסיר את ה"דליפות" ולראות אם זה יזרז את ההשקה.

סיבות לצמיחה אינסופית של מסדי נתונים

לפני הסרת "דליפות", כדאי להבין מדוע הן הופיעו מלכתחילה. כדי לעשות זאת, בואו נזכור מה זה תחום.

תחום הוא מסד נתונים לא יחסי. זה מאפשר לך לתאר קשרים בין אובייקטים באופן דומה למספר מסדי נתונים יחסיים של ORM באנדרואיד. במקביל, Realm מאחסנת אובייקטים ישירות בזיכרון עם הכמות הקטנה ביותר של טרנספורמציות ומיפויים. זה מאפשר לך לקרוא נתונים מהדיסק במהירות רבה, וזה הכוח של Realm ולמה הוא אהוב.

(לצורך מאמר זה, תיאור זה יספיק לנו. תוכל לקרוא עוד על תחום במגניב תיעוד או אצלם האקדמיה).

מפתחים רבים רגילים לעבוד יותר עם מסדי נתונים יחסיים (למשל, מסדי נתונים של ORM עם SQL מתחת למכסה המנוע). ודברים כמו מחיקת נתונים מדורגת נראים לרוב כמו דבר מובן מאליו. אבל לא בממלכה.

אגב, תכונת מחיקת המפל נשאלה כבר זמן רב. זֶה עדכון и אחר, הקשורים אליו, נדון באופן פעיל. הייתה תחושה שזה ייעשה בקרוב. אבל אז הכל תורגם להכנסת קישורים חזקים וחלשים, שגם יפתור אוטומטית את הבעיה הזו. היה די תוסס ופעיל במשימה זו בקשה למשוך, שהופסק לעת עתה עקב קשיים פנימיים.

דליפת נתונים ללא מחיקה מדורגת

איך בדיוק הנתונים דולפים אם אתה מסתמך על מחיקה מדורגת שלא קיימת? אם יש לך אובייקטי תחום מקוננים, יש למחוק אותם.
בואו נסתכל על דוגמה (כמעט) אמיתית. יש לנו חפץ CartItemEntity:

@RealmClass
class CartItemEntity(
 @PrimaryKey
 override var id: String? = null,
 ...
 var name: String = "",
 var description: String = "",
 var image: ImageEntity? = null,
 var category: String = MENU_CATEGORY_UNKNOWN_ID,
 var customizationEntity: CustomizationEntity? = null,
 var cartComboProducts: RealmList<CartProductEntity> = RealmList(),
 ...
) : RealmObject()

למוצר בעגלה יש שדות שונים, כולל תמונה ImageEntity, מרכיבים מותאמים אישית CustomizationEntity. כמו כן, המוצר בעגלה יכול להיות שילוב עם סט מוצרים משלו RealmList (CartProductEntity). כל השדות הרשומים הם אובייקטי תחום. אם נכניס אובייקט חדש (copyToRealm() / copyToRealmOrUpdate()) עם אותו מזהה, אזי האובייקט הזה יוחלף לחלוטין. אבל כל האובייקטים הפנימיים (תמונה, customizationEntity ו-cartComboProducts) יאבדו את הקשר עם האב ויישארו במסד הנתונים.

מכיוון שהקשר איתם אבד, אנחנו כבר לא קוראים אותם או מוחקים אותם (אלא אם כן ניגשים אליהם במפורש או מנקים את כל ה"טבלה"). קראנו לזה "דליפות זיכרון".

כאשר אנו עובדים עם Realm, עלינו לעבור במפורש על כל האלמנטים ולמחוק במפורש הכל לפני פעולות כאלה. זה יכול להיעשות, למשל, כך:

val entity = realm.where(CartItemEntity::class.java).equalTo("id", id).findFirst()
if (first != null) {
 deleteFromRealm(first.image)
 deleteFromRealm(first.customizationEntity)
 for(cartProductEntity in first.cartComboProducts) {
   deleteFromRealm(cartProductEntity)
 }
 first.deleteFromRealm()
}
// и потом уже сохраняем

אם תעשה זאת, הכל יעבוד כמו שצריך. בדוגמה זו, אנו מניחים שאין אובייקטי Realm מקוננים אחרים בתוך image, customizationEntity ו-cartComboProducts, כך שאין לולאות מקוננות ומחיקות אחרות.

פתרון "מהיר".

הדבר הראשון שהחלטנו לעשות הוא לנקות את החפצים הצומחים ביותר ולבדוק את התוצאות כדי לראות אם זה יפתור את הבעיה המקורית שלנו. ראשית, נוצר הפתרון הפשוט והאינטואיטיבי ביותר, כלומר: כל חפץ צריך להיות אחראי על הוצאת ילדיו. לשם כך, הצגנו ממשק שהחזיר רשימה של אובייקטי Realm המקוננים שלו:

interface NestedEntityAware {
 fun getNestedEntities(): Collection<RealmObject?>
}

ויישמנו את זה באובייקטי התחום שלנו:

@RealmClass
class DataPizzeriaEntity(
 @PrimaryKey
 var id: String? = null,
 var name: String? = null,
 var coordinates: CoordinatesEntity? = null,
 var deliverySchedule: ScheduleEntity? = null,
 var restaurantSchedule: ScheduleEntity? = null,
 ...
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       coordinates,
       deliverySchedule,
       restaurantSchedule
   )
 }
}

В getNestedEntities אנחנו מחזירים את כל הילדים כרשימה שטוחה. וכל אובייקט צאצא יכול גם ליישם את ממשק NestedEntityAware, מה שמציין שיש לו אובייקטים פנימיים של Realm למחוק, למשל ScheduleEntity:

@RealmClass
class ScheduleEntity(
 var monday: DayOfWeekEntity? = null,
 var tuesday: DayOfWeekEntity? = null,
 var wednesday: DayOfWeekEntity? = null,
 var thursday: DayOfWeekEntity? = null,
 var friday: DayOfWeekEntity? = null,
 var saturday: DayOfWeekEntity? = null,
 var sunday: DayOfWeekEntity? = null
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       monday, tuesday, wednesday, thursday, friday, saturday, sunday
   )
 }
}

וכן הלאה, ניתן לחזור על קינון חפצים.

לאחר מכן אנו כותבים שיטה שמוחקת באופן רקורסיבי את כל האובייקטים המקוננים. שיטה (נעשתה כהרחבה) deleteAllNestedEntities מקבל את כל האובייקטים והשיטה ברמה העליונה deleteNestedRecursively מסיר באופן רקורסיבי את כל האובייקטים המקוננים באמצעות ממשק NestedEntityAware:

fun <T> Realm.deleteAllNestedEntities(entities: Collection<T>,
 entityClass: Class<out RealmObject>,
 idMapper: (T) -> String,
 idFieldName : String = "id"
 ) {

 val existedObjects = where(entityClass)
     .`in`(idFieldName, entities.map(idMapper).toTypedArray())
     .findAll()

 deleteNestedRecursively(existedObjects)
}

private fun Realm.deleteNestedRecursively(entities: Collection<RealmObject?>) {
 for(entity in entities) {
   entity?.let { realmObject ->
     if (realmObject is NestedEntityAware) {
       deleteNestedRecursively((realmObject as NestedEntityAware).getNestedEntities())
     }
     realmObject.deleteFromRealm()
   }
 }
}

עשינו זאת עם החפצים הגדלים הכי מהר ובדקנו מה קרה.

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

הפתרון ה"רגיל".

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

רציתי לוודא שאני לא משתמש בממשקים, אבל שהכל עובד לבד.

כשאנחנו רוצים שמשהו יעבוד לבד, עלינו להשתמש בהשתקפות. לשם כך, נוכל לעבור על כל שדה מחלקה ולבדוק אם זה אובייקט Realm או רשימה של אובייקטים:

RealmModel::class.java.isAssignableFrom(field.type)

RealmList::class.java.isAssignableFrom(field.type)

אם השדה הוא RealmModel או RealmList, הוסף את האובייקט של שדה זה לרשימה של אובייקטים מקוננים. הכל בדיוק כמו שעשינו למעלה, רק שכאן זה ייעשה מעצמו. שיטת מחיקת המפל עצמה היא פשוטה מאוד ונראית כך:

fun <T : Any> Realm.cascadeDelete(entities: Collection<T?>) {
 if(entities.isEmpty()) {
   return
 }

 entities.filterNotNull().let { notNullEntities ->
   notNullEntities
       .filterRealmObject()
       .flatMap { realmObject -> getNestedRealmObjects(realmObject) }
       .also { realmObjects -> cascadeDelete(realmObjects) }

   notNullEntities
       .forEach { entity ->
         if((entity is RealmObject) && entity.isValid) {
           entity.deleteFromRealm()
         }
       }
 }
}

סיומת filterRealmObject מסנן ומעביר רק אובייקטי Realm. שיטה getNestedRealmObjects באמצעות השתקפות, הוא מוצא את כל אובייקטי הממלכה המקוננים ומכניס אותם לרשימה ליניארית. ואז אנחנו עושים את אותו הדבר רקורסיבית. בעת המחיקה, עליך לבדוק את תקפות האובייקט isValid, מכיוון שיכול להיות שלאובייקטי אב שונים יכולים להיות אובייקטים זהים מקוננים. עדיף להימנע מכך ופשוט להשתמש ביצירה אוטומטית של מזהה בעת יצירת אובייקטים חדשים.

יישום מלא של שיטת getNestedRealmObjects

private fun getNestedRealmObjects(realmObject: RealmObject) : List<RealmObject> {
 val nestedObjects = mutableListOf<RealmObject>()
 val fields = realmObject.javaClass.superclass.declaredFields

// Проверяем каждое поле, не является ли оно RealmModel или списком RealmList
 fields.forEach { field ->
   when {
     RealmModel::class.java.isAssignableFrom(field.type) -> {
       try {
         val child = getChildObjectByField(realmObject, field)
         child?.let {
           if (isInstanceOfRealmObject(it)) {
             nestedObjects.add(child as RealmObject)
           }
         }
       } catch (e: Exception) { ... }
     }

     RealmList::class.java.isAssignableFrom(field.type) -> {
       try {
         val childList = getChildObjectByField(realmObject, field)
         childList?.let { list ->
           (list as RealmList<*>).forEach {
             if (isInstanceOfRealmObject(it)) {
               nestedObjects.add(it as RealmObject)
             }
           }
         }
       } catch (e: Exception) { ... }
     }
   }
 }

 return nestedObjects
}

private fun getChildObjectByField(realmObject: RealmObject, field: Field): Any? {
 val methodName = "get${field.name.capitalize()}"
 val method = realmObject.javaClass.getMethod(methodName)
 return method.invoke(realmObject)
}

כתוצאה מכך, בקוד הלקוח שלנו אנו משתמשים ב"מחיקה מדורגת" עבור כל פעולת שינוי נתונים. לדוגמה, עבור פעולת הוספה זה נראה כך:

override fun <T : Entity> insert(
 entityInformation: EntityInformation,
 entities: Collection<T>): Collection<T> = entities.apply {
 realmInstance.cascadeDelete(getManagedEntities(entityInformation, this))
 realmInstance.copyFromRealm(
     realmInstance
         .copyToRealmOrUpdate(this.map { entity -> entity as RealmModel }
 ))
}

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

הקו הירוק מציג את התלות של זמן ההפעלה של האפליקציה במספר ההתחלות הקרות במהלך מחיקת מפל אוטומטית של אובייקטים מקוננים.

תוצאות ומסקנות

מסד הנתונים של Realm שגדל ללא הרף גרם ליישום להפעיל לאט מאוד. פרסמנו עדכון עם "מחיקה מדורגת" משלנו של אובייקטים מקוננים. ועכשיו אנו עוקבים ומעריכים כיצד ההחלטה שלנו השפיעה על זמן ההפעלה של האפליקציה באמצעות המדד _app_start.

לצורך ניתוח, אנחנו לוקחים פרק זמן של 90 יום ורואים: זמן השקת האפליקציה, הן החציון והן זה שנופל על האחוזון ה-95 של המשתמשים, החל לרדת ואינו עולה עוד.

אם אתה מסתכל על תרשים שבעת הימים, המדד _app_start נראה הולם לחלוטין והוא פחות משנייה אחת.

כדאי גם להוסיף כי כברירת מחדל, Firebase שולח התראות אם הערך החציוני של _app_start עולה על 5 שניות. אולם, כפי שאנו רואים, אין להסתמך על כך, אלא להיכנס ולבדוק זאת במפורש.

הדבר המיוחד במסד הנתונים של Realm הוא שזהו מסד נתונים לא יחסי. למרות קלות השימוש שלו, הדמיון לפתרונות ORM וקישור אובייקטים, אין לו מחיקה מדורגת.

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

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

למרות הדיון על הופעתו הקרובה של תכונה זו, היעדר מחיקת אשד ב-Realm נעשה על ידי עיצוב. אם אתה מעצב אפליקציה חדשה, קח זאת בחשבון. ואם אתה כבר משתמש ב-Realm, בדוק אם יש לך בעיות כאלה.

מקור: www.habr.com