ზღაპარი იმის შესახებ, თუ როგორ მოიგო კასკადის წაშლა სამეფოში

ყველა მომხმარებელი თავისთავად იღებს სწრაფ გაშვებას და რეაგირებას მობილურ აპლიკაციებში. თუ აპლიკაციის გაშვებას დიდი დრო დასჭირდება, მომხმარებელი იწყებს სევდას და გაბრაზებას. თქვენ შეგიძლიათ მარტივად გააფუჭოთ მომხმარებლის გამოცდილება ან მთლიანად დაკარგოთ მომხმარებელი, სანამ ის აპლიკაციის გამოყენებას დაიწყებს.

ერთხელ აღმოვაჩინეთ, რომ Dodo Pizza აპლიკაციის გაშვებას საშუალოდ 3 წამი სჭირდება, ზოგიერთ „იღბლიანს“ კი 15-20 წამი.

ფრაგმენტის ქვემოთ არის ამბავი ბედნიერი დასასრულით: Realm მონაცემთა ბაზის ზრდაზე, მეხსიერების გაჟონვის შესახებ, როგორ დავაგროვეთ წყობილი ობიექტები, შემდეგ კი შევკრიბეთ თავი და დავაფიქსირეთ ყველაფერი.

სტატიის ავტორი: მაქსიმ კაჩინკინი — Android-ის დეველოპერი Dodo Pizza-ში.

სამი წამი აპლიკაციის ხატულაზე დაწკაპუნებიდან პირველი აქტივობის onResume()-მდე არის უსასრულობა. ზოგიერთი მომხმარებლისთვის კი გაშვების დრო 15-20 წამს აღწევდა. როგორ არის ეს საერთოდ შესაძლებელი?

ძალიან მოკლე რეზიუმე მათთვის, ვისაც წაკითხვის დრო არ აქვს
ჩვენი Realm მონაცემთა ბაზა უსასრულოდ გაიზარდა. ზოგიერთი წყობილი ობიექტი არ წაიშალა, მაგრამ მუდმივად გროვდებოდა. აპლიკაციის გაშვების დრო თანდათან გაიზარდა. მერე გავასწორეთ და გაშვების დრო მიზანს მიაღწია - 1 წამზე ნაკლები გახდა და აღარ გაიზარდა. სტატიაში მოცემულია სიტუაციის ანალიზი და ორი გამოსავალი - სწრაფი და ნორმალური.

პრობლემის ძიება და ანალიზი

დღეს ნებისმიერი მობილური აპლიკაცია უნდა დაიწყოს სწრაფად და იყოს პასუხისმგებელი. მაგრამ ეს არ ეხება მხოლოდ მობილურ აპლიკაციას. სერვისთან და კომპანიასთან ურთიერთქმედების მომხმარებლის გამოცდილება რთული საკითხია. მაგალითად, ჩვენს შემთხვევაში, მიწოდების სიჩქარე პიცის სერვისის ერთ-ერთი მთავარი მაჩვენებელია. თუ მიწოდება სწრაფია, პიცა ცხელი იქნება და მომხმარებელს, რომელსაც ახლა სურს ჭამა, დიდხანს ლოდინი არ მოუწევს. აპლიკაციისთვის, თავის მხრივ, მნიშვნელოვანია სწრაფი სერვისის განცდის შექმნა, რადგან თუ აპლიკაციის გაშვებას მხოლოდ 20 წამი სჭირდება, მაშინ რამდენი ხანი მოგიწევთ პიცას ლოდინი?

თავიდან ჩვენ თვითონ დავდექით იმ ფაქტის წინაშე, რომ ზოგჯერ აპლიკაციის გაშვებას რამდენიმე წამი სჭირდებოდა, შემდეგ კი სხვა კოლეგებისგან ჩივილების მოსმენა დავიწყეთ იმის შესახებ, თუ რამდენ ხანს სჭირდებოდა. მაგრამ ჩვენ ვერ შევძელით ამ მდგომარეობის გამუდმებით გამეორება.

რამდენი ხანია? Მიხედვით Google დოკუმენტაცია, თუ განაცხადის ცივი დაწყებას 5 წამზე ნაკლები სჭირდება, მაშინ ეს ითვლება "თითქოს ნორმალურად". Dodo Pizza Android აპი ამოქმედდა (Firebase მეტრიკის მიხედვით _app_start) ზე ცივი დაწყება საშუალოდ 3 წამში - "არც შესანიშნავი, არც ისე საშინელი", როგორც ამბობენ.

მაგრამ შემდეგ გამოჩნდა ჩივილები, რომ განაცხადის გაშვებას ძალიან, ძალიან, ძალიან დიდი დრო დასჭირდა! დასაწყისისთვის, ჩვენ გადავწყვიტეთ გაგვეზომა რა არის „ძალიან, ძალიან, ძალიან გრძელი“. ამისათვის ჩვენ გამოვიყენეთ Firebase კვალი აპის დაწყების კვალი.

ეს სტანდარტული კვალი ზომავს დროს იმ მომენტს შორის, როდესაც მომხმარებელი გახსნის აპლიკაციას და პირველი აქტივობის onResume() შესრულებას შორის. Firebase Console-ში ამ მეტრიკას ეწოდება _app_start. აღმოჩნდა, რომ:

• გაშვების დრო 95-ე პროცენტულზე ზემოთ მომხმარებლებისთვის არის თითქმის 20 წამი (ზოგიერთი უფრო გრძელი), მიუხედავად იმისა, რომ ცივი გაშვების საშუალო დრო 5 წამზე ნაკლებია.
• გაშვების დრო არ არის მუდმივი მნიშვნელობა, მაგრამ დროთა განმავლობაში იზრდება. მაგრამ ზოგჯერ არის წვეთები. ჩვენ აღმოვაჩინეთ ეს ნიმუში, როდესაც ჩვენ გავზარდეთ ანალიზის მასშტაბი 90 დღემდე.

ორი აზრი მომივიდა თავში:

1. რაღაც ჟონავს.
2. ეს "რაღაც" გადატვირთულია გამოშვების შემდეგ და შემდეგ ისევ გაჟონავს.

„ალბათ რაღაც მონაცემთა ბაზაშია“, ვფიქრობდით და მართალი ვიყავით. პირველ რიგში, ჩვენ ვიყენებთ მონაცემთა ბაზას, როგორც ქეში; მიგრაციის დროს ვასუფთავებთ მას. მეორეც, მონაცემთა ბაზა იტვირთება განაცხადის დაწყებისას. ყველაფერი ერთმანეთში ჯდება.

რა ჭირს Realm მონაცემთა ბაზას

ჩვენ დავიწყეთ იმის შემოწმება, თუ როგორ იცვლება მონაცემთა ბაზის შინაარსი აპლიკაციის სიცოცხლის განმავლობაში, პირველი ინსტალაციის შემდეგ და შემდგომ აქტიური გამოყენების დროს. თქვენ შეგიძლიათ ნახოთ Realm მონაცემთა ბაზის შინაარსი სტეტო ან უფრო დეტალურად და ნათლად ფაილის გახსნით მეშვეობით Realm Studio. ADB-ის საშუალებით მონაცემთა ბაზის შინაარსის სანახავად დააკოპირეთ Realm მონაცემთა ბაზის ფაილი:

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

სხვადასხვა დროს დავაკვირდით მონაცემთა ბაზის შინაარსს, აღმოვაჩინეთ, რომ გარკვეული ტიპის ობიექტების რაოდენობა მუდმივად იზრდება.

სურათზე ნაჩვენებია Realm Studio-ს ფრაგმენტი ორი ფაილისთვის: მარცხნივ - აპლიკაციის ბაზა ინსტალაციის შემდეგ, მარჯვნივ - აქტიური გამოყენების შემდეგ. ჩანს, რომ ობიექტების რაოდენობა ImageEntity и MoneyType მნიშვნელოვნად გაიზარდა (სკრინშოტი აჩვენებს თითოეული ტიპის ობიექტების რაოდენობას).

კავშირი მონაცემთა ბაზის ზრდასა და გაშვების დროს შორის

მონაცემთა უკონტროლო ზრდა ძალიან ცუდია. მაგრამ როგორ მოქმედებს ეს აპლიკაციის გაშვების დროზე? ამის გაზომვა ActivityManager-ის მეშვეობით საკმაოდ მარტივია. Android 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 მბ-მდე. საერთო ჯამში, გამოდის, რომ დროთა განმავლობაში (ცივი დაწყების ზრდასთან ერთად) გაიზარდა როგორც განაცხადის გაშვების დრო, ასევე მონაცემთა ბაზის ზომა. ჩვენ გვაქვს ჰიპოთეზა ხელში. ახლა დარჩა მხოლოდ დამოკიდებულების დადასტურება. ამიტომ, ჩვენ გადავწყვიტეთ ამოგვეღო „გაჟონვები“ და ვნახოთ, დააჩქარებდა თუ არა ეს გაშვებას.

მონაცემთა ბაზის გაუთავებელი ზრდის მიზეზები

"გაჟონვის" ამოღებამდე, ღირს იმის გაგება, თუ რატომ გამოჩნდნენ ისინი პირველ რიგში. ამისათვის გავიხსენოთ რა არის სამეფო.

Realm არის არარელაციური მონაცემთა ბაზა. ის საშუალებას გაძლევთ აღწეროთ ობიექტებს შორის ურთიერთობები ისე, როგორც აღწერილია Android-ზე ORM-ის რელაციური მონაცემთა ბაზა. ამავდროულად, Realm ინახავს ობიექტებს უშუალოდ მეხსიერებაში მინიმალური ტრანსფორმაციებითა და რუკებით. ეს საშუალებას გაძლევთ წაიკითხოთ მონაცემები დისკიდან ძალიან სწრაფად, რაც არის Realm-ის სიძლიერე და რატომ არის ის საყვარელი.

(ამ სტატიის მიზნებისთვის ეს აღწერა საკმარისი იქნება ჩვენთვის. თქვენ შეგიძლიათ წაიკითხოთ მეტი Realm-ის შესახებ cool-ში დოკუმენტაცია ან მათში აკადემიები).

ბევრი დეველოპერი მიჩვეულია უფრო მეტად მუშაობას რელაციურ მონაცემთა ბაზებთან (მაგალითად, ORM მონაცემთა ბაზები SQL-ის ქვეშ). და ისეთი რამ, როგორიცაა კასკადური მონაცემების წაშლა, ხშირად მიჩნეულია. მაგრამ არა სამეფოში.

სხვათა შორის, კასკადის წაშლის ფუნქცია დიდი ხანია ითხოვა. ეს გადახედვა и სხვამასთან დაკავშირებული, აქტიურად განიხილებოდა. იყო განცდა, რომ ეს მალე მოხდებოდა. მაგრამ შემდეგ ყველაფერი გადაიზარდა ძლიერი და სუსტი ბმულების დანერგვაში, რაც ასევე ავტომატურად მოაგვარებდა ამ პრობლემას. საკმაოდ აქტიური და აქტიური იყო ამ საქმეში გაყვანის მოთხოვნა, რომელიც ამ დროისთვის შეჩერებულია შიდა სირთულეების გამო.

მონაცემთა გაჟონვა კასკადური წაშლის გარეშე

ზუსტად როგორ ხდება მონაცემების გაჟონვა, თუ ეყრდნობით არარსებულ კასკადურ წაშლას? თუ თქვენ გაქვთ ჩასმული Realm ობიექტები, მაშინ ისინი უნდა წაიშალოს.
მოდით შევხედოთ (თითქმის) რეალურ მაგალითს. ჩვენ გვაქვს ობიექტი 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()) იგივე ID-ით, მაშინ ეს ობიექტი მთლიანად გადაიწერება. მაგრამ ყველა შიდა ობიექტი (image, 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()
}
// и потом уже сохраняем

თუ ამას გააკეთებთ, მაშინ ყველაფერი ისე იმუშავებს, როგორც უნდა. ამ მაგალითში, ჩვენ ვვარაუდობთ, რომ არ არსებობს სხვა ჩადგმული სფეროს ობიექტები გამოსახულების შიგნით, customizationEntity და cartComboProducts, ასე რომ, არ არსებობს სხვა ჩადგმული მარყუჟები და წაშლები.

"სწრაფი" გამოსავალი

პირველი, რაც გადავწყვიტეთ, იყო ყველაზე სწრაფად მზარდი ობიექტების გაწმენდა და შედეგების გადამოწმება, გადაჭრის თუ არა ეს ჩვენს თავდაპირველ პრობლემას. პირველი, გაკეთდა უმარტივესი და ყველაზე ინტუიციური გადაწყვეტა, კერძოდ: თითოეული ობიექტი პასუხისმგებელი უნდა იყოს თავისი შვილების ამოღებაზე. ამისათვის ჩვენ შემოვიღეთ ინტერფეისი, რომელიც აბრუნებდა მისი დადგმული სფეროს ობიექტების სიას:

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 ინტერფეისი, რაც მიუთითებს, რომ მას აქვს შიდა სფეროს ობიექტები წასაშლელი, მაგალითად. 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-ში. ამიტომ, თითოეული ობიექტისთვის ყველა ჩადგმული ობიექტის ჩაწერა შრომატევადია, გარდა ამისა, შეცდომების რისკი იზრდება, რადგან კოდის შეცვლისას შეგიძლიათ დაივიწყოთ ობიექტების მითითება.

მინდოდა დავრწმუნებულიყავი, რომ არ ვიყენებდი ინტერფეისებს, მაგრამ ყველაფერი თავისთავად მუშაობდა.

როდესაც ჩვენ გვინდა, რომ რაღაც დამოუკიდებლად იმუშაოს, უნდა გამოვიყენოთ რეფლექსია. ამისათვის ჩვენ შეგვიძლია გავიაროთ თითოეული კლასის ველი და შევამოწმოთ არის ის 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 ფილტრავს და გადის მხოლოდ სფეროს ობიექტებს. მეთოდი getNestedRealmObjects რეფლექსიის საშუალებით, ის პოულობს სამეფოს ყველა ჩადგმულ ობიექტს და ათავსებს მათ ხაზოვან სიაში. შემდეგ იგივეს ვაკეთებთ რეკურსიულად. წაშლისას, თქვენ უნდა შეამოწმოთ ობიექტი ვალიდობისთვის isValid, რადგან შესაძლოა სხვადასხვა მშობელ ობიექტს ჰქონდეთ ბუდობრივი იდენტური ობიექტები. უმჯობესია თავიდან აიცილოთ ეს და უბრალოდ გამოიყენოთ id-ის ავტომატური გენერაცია ახალი ობიექტების შექმნისას.

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 მონაცემთა ბაზა იწვევდა აპლიკაციის ძალიან ნელა გაშვებას. ჩვენ გამოვაქვეყნეთ განახლება ჩადგმული ობიექტების საკუთარი „კასკადური წაშლით“. ახლა ჩვენ ვაკვირდებით და ვაფასებთ, თუ როგორ იმოქმედა ჩვენმა გადაწყვეტილებამ აპლიკაციის გაშვების დროზე _app_start მეტრიკის მეშვეობით.

ანალიზისთვის, ჩვენ ვიღებთ 90 დღის პერიოდს და ვხედავთ: აპლიკაციის გაშვების დრო, როგორც მედიანური, ასევე ის, რომელიც მოდის მომხმარებელთა 95-ე პროცენტულზე, დაიწყო კლება და აღარ იზრდება.

თუ გადავხედავთ შვიდდღიან დიაგრამას, _app_start მეტრიკა გამოიყურება სრულიად ადეკვატური და 1 წამზე ნაკლებია.

ასევე ღირს იმის დამატება, რომ ნაგულისხმევად, Firebase აგზავნის შეტყობინებებს, თუ _app_start-ის საშუალო მნიშვნელობა 5 წამს აღემატება. თუმცა, როგორც ვხედავთ, თქვენ არ უნდა დაეყრდნოთ ამას, არამედ შეხვიდეთ და პირდაპირ შეამოწმოთ იგი.

Realm მონაცემთა ბაზაში განსაკუთრებული რამ არის ის, რომ ეს არის არარელაციური მონაცემთა ბაზა. გამოყენების სიმარტივის, ORM გადაწყვეტილებების მსგავსებისა და ობიექტების დაკავშირების მიუხედავად, მას არ აქვს კასკადური წაშლა.

თუ ეს მხედველობაში არ მიიღება, მაშინ დაბუდებული ობიექტები დაგროვდება და „გაჟონავს“. მონაცემთა ბაზა მუდმივად გაიზრდება, რაც თავის მხრივ აისახება აპლიკაციის შენელებაზე ან გაშვებაზე.

მე გავუზიარე ჩვენი გამოცდილება იმის შესახებ, თუ როგორ სწრაფად გავაკეთოთ ობიექტების კასკადის წაშლა Realm-ში, რომელიც ჯერ არ არის გამოსული, მაგრამ ამაზე დიდი ხანია საუბრობენ ისინი ამბობენ, რომ и ისინი ამბობენ, რომ. ჩვენს შემთხვევაში, ამან მნიშვნელოვნად დააჩქარა აპლიკაციის გაშვების დრო.

მიუხედავად დისკუსიისა ამ ფუნქციის გარდაუვალი გარეგნობის შესახებ, კასკადის წაშლის არარსებობა Realm-ში კეთდება დიზაინით. თუ თქვენ ქმნით ახალ აპლიკაციას, მაშინ გაითვალისწინეთ ეს. და თუ უკვე იყენებთ Realm-ს, შეამოწმეთ თუ გაქვთ ასეთი პრობლემები.

წყარო: www.habr.com