रिअलममधील कॅस्केड हटवण्याने दीर्घ प्रक्षेपणावर कसे विजय मिळवले याची कथा

सर्व वापरकर्ते मोबाईल ऍप्लिकेशन्समध्‍ये जलद लाँच आणि प्रतिसाद देणारे UI गृहीत धरतात. ऍप्लिकेशन लाँच होण्यास बराच वेळ लागल्यास, वापरकर्त्याला दुःख आणि राग येऊ लागतो. तुम्ही ग्राहकाचा अनुभव सहजपणे खराब करू शकता किंवा वापरकर्त्याने अॅप्लिकेशन वापरणे सुरू करण्यापूर्वीच तो पूर्णपणे गमावू शकता.

आम्ही एकदा शोधून काढले की डोडो पिझ्झा अॅप ला लॉन्च होण्यासाठी सरासरी 3 सेकंद लागतात आणि काही "भाग्यवानांसाठी" 15-20 सेकंद लागतात.

कटच्या खाली एक आनंदी शेवट असलेली एक कथा आहे: क्षेत्र डेटाबेसच्या वाढीबद्दल, मेमरी लीक, आम्ही नेस्टेड वस्तू कशा जमा केल्या आणि नंतर स्वतःला एकत्र खेचले आणि सर्वकाही निश्चित केले.

लेख लेखक: मॅक्सिम काचिनकिन - डोडो पिझ्झा येथे Android विकसक.

ऍप्लिकेशन आयकॉनवर क्लिक केल्यापासून ऑनरेझ्युम() पर्यंत पहिल्या ऍक्टिव्हिटीचा तीन सेकंद म्हणजे अनंत. आणि काही वापरकर्त्यांसाठी, स्टार्टअप वेळ 15-20 सेकंदांपर्यंत पोहोचला. हे तरी कसे शक्य आहे?

ज्यांना वाचायला वेळ नाही त्यांच्यासाठी एक छोटासा सारांश
आमचा क्षेत्र डेटाबेस अविरतपणे वाढला. काही नेस्टेड वस्तू हटविल्या गेल्या नाहीत, परंतु सतत जमा केल्या गेल्या. अनुप्रयोग सुरू होण्याची वेळ हळूहळू वाढली. मग आम्ही ते निश्चित केले, आणि स्टार्टअपची वेळ लक्ष्यावर आली - ती 1 सेकंदापेक्षा कमी झाली आणि यापुढे वाढली नाही. लेखात परिस्थितीचे विश्लेषण आणि दोन उपाय आहेत - एक द्रुत आणि एक सामान्य.

समस्येचा शोध आणि विश्लेषण

आज, कोणतेही मोबाइल अॅप्लिकेशन त्वरीत लाँच करणे आणि प्रतिसाद देणारे असणे आवश्यक आहे. पण हे फक्त मोबाईल अॅपबद्दल नाही. सेवा आणि कंपनी यांच्यातील परस्परसंवादाचा वापरकर्ता अनुभव ही एक जटिल गोष्ट आहे. उदाहरणार्थ, आमच्या बाबतीत, वितरण गती पिझ्झा सेवेसाठी प्रमुख निर्देशकांपैकी एक आहे. डिलिव्हरी जलद असेल तर पिझ्झा गरम होईल आणि आता खायचे असलेल्या ग्राहकाला जास्त वेळ थांबावे लागणार नाही. ऍप्लिकेशनसाठी, त्या बदल्यात, जलद सेवेची भावना निर्माण करणे महत्वाचे आहे, कारण जर ऍप्लिकेशन लॉन्च होण्यासाठी फक्त 20 सेकंद लागतात, तर पिझ्झासाठी तुम्हाला किती वेळ प्रतीक्षा करावी लागेल?

सुरुवातीला, आम्हाला स्वतःला या वस्तुस्थितीचा सामना करावा लागला की कधीकधी अनुप्रयोग लॉन्च होण्यास काही सेकंद लागतात आणि नंतर आम्हाला इतर सहकार्यांकडून किती वेळ लागला याबद्दल तक्रारी ऐकू येऊ लागल्या. पण या परिस्थितीची सातत्याने पुनरावृत्ती करू शकलो नाही.

किती वेळ आहे? त्यानुसार Google दस्तऐवजीकरण, जर एखाद्या ऍप्लिकेशनच्या कोल्ड स्टार्टला 5 सेकंदांपेक्षा कमी वेळ लागला, तर हे "सामान्य असल्यासारखे" मानले जाते. डोडो पिझ्झा अँड्रॉइड अॅप लाँच केले (फायरबेस मेट्रिक्सनुसार _app_start) येथे थंड सुरुवात सरासरी 3 सेकंदात - "महान नाही, भयंकर नाही," जसे ते म्हणतात.

पण नंतर तक्रारी येऊ लागल्या की अॅप्लिकेशन लॉन्च व्हायला खूप, खूप, खूप वेळ लागला! सुरुवातीला, आम्ही "खूप, खूप, खूप लांब" म्हणजे काय मोजायचे ठरवले. आणि आम्ही यासाठी फायरबेस ट्रेस वापरला अॅप प्रारंभ ट्रेस.

हा स्टँडर्ड ट्रेस वापरकर्त्याने अॅप्लिकेशन उघडण्याच्या क्षणापासून आणि पहिल्या क्रियाकलापाचा onResume() कार्यान्वित केल्याच्या क्षणादरम्यानचा वेळ मोजतो. फायरबेस कन्सोलमध्ये या मेट्रिकला _app_start म्हणतात. असे दिसून आले की:

• 95 व्या पर्सेंटाइलच्या वरील वापरकर्त्यांसाठी स्टार्टअप वेळ जवळपास 20 सेकंद (काही जास्त जास्त) आहे, मध्यम कोल्ड स्टार्टअप वेळ 5 सेकंदांपेक्षा कमी असूनही.
• स्टार्टअप वेळ हे स्थिर मूल्य नसते, परंतु कालांतराने वाढते. परंतु कधीकधी थेंब असतात. जेव्हा आम्ही विश्लेषणाचे प्रमाण 90 दिवसांपर्यंत वाढवले ​​तेव्हा आम्हाला हा नमुना आढळला.

मनात दोन विचार आले:

1. काहीतरी गळत आहे.
2. हे "काहीतरी" रिलीझ झाल्यानंतर रीसेट केले जाते आणि नंतर पुन्हा लीक होते.

"कदाचित डेटाबेससह काहीतरी," आम्ही विचार केला आणि आम्ही बरोबर होतो. प्रथम, आम्ही डेटाबेस कॅशे म्हणून वापरतो; स्थलांतर दरम्यान आम्ही ते साफ करतो. दुसरे म्हणजे, जेव्हा अनुप्रयोग सुरू होतो तेव्हा डेटाबेस लोड केला जातो. सर्व काही एकत्र बसते.

Realm डेटाबेसमध्ये काय चूक आहे

आम्ही प्रथम इंस्टॉलेशनपासून आणि सक्रिय वापरादरम्यान डेटाबेसमधील सामग्री अनुप्रयोगाच्या जीवनात कशी बदलते हे तपासण्यास सुरुवात केली. तुम्ही Realm डेटाबेसची सामग्री द्वारे पाहू शकता स्टेथो किंवा द्वारे फाइल उघडून अधिक तपशीलवार आणि स्पष्टपणे क्षेत्र स्टुडिओ. ADB द्वारे डेटाबेसमधील सामग्री पाहण्यासाठी, Realm डेटाबेस फाइल कॉपी करा:

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

वेगवेगळ्या वेळी डेटाबेसमधील सामग्री पाहिल्यानंतर, आम्हाला आढळले की विशिष्ट प्रकारच्या वस्तूंची संख्या सतत वाढत आहे.

चित्र दोन फाइल्ससाठी Realm Studio चा एक तुकडा दर्शवितो: डावीकडे - ऍप्लिकेशन बेस इंस्टॉलेशन नंतर काही वेळाने, उजवीकडे - सक्रिय वापरानंतर. हे पाहिले जाऊ शकते की वस्तूंची संख्या ImageEntity и MoneyType लक्षणीय वाढ झाली आहे (स्क्रीनशॉट प्रत्येक प्रकारच्या वस्तूंची संख्या दर्शवितो).

डेटाबेस वाढ आणि स्टार्टअप वेळ दरम्यान संबंध

अनियंत्रित डेटाबेस वाढ खूप वाईट आहे. पण याचा ऍप्लिकेशन स्टार्टअप वेळेवर कसा परिणाम होतो? ActivityManager द्वारे हे मोजणे खूप सोपे आहे. Android 4.4 पासून, logcat प्रदर्शित केलेल्या स्ट्रिंग आणि वेळेसह लॉग प्रदर्शित करते. ही वेळ ऍप्लिकेशन लाँच झाल्यापासून अ‍ॅक्टिव्हिटी रेंडरिंगच्या समाप्तीपर्यंतच्या अंतराच्या बरोबरीची आहे. या काळात खालील घटना घडतात:

• प्रक्रिया सुरू करा.
• वस्तूंचे आरंभीकरण.
• क्रियाकलापांची निर्मिती आणि प्रारंभ.
• लेआउट तयार करत आहे.
• अनुप्रयोग प्रस्तुतीकरण.

आम्हाला सूट. तुम्ही -S आणि -W ध्वजांसह ADB चालवल्यास, तुम्ही स्टार्टअप वेळेसह विस्तारित आउटपुट मिळवू शकता:

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 एमबी पर्यंत वाढले. एकूणच, असे दिसून आले की कालांतराने (कोल्ड स्टार्टच्या वाढीसह), अनुप्रयोग लॉन्च होण्याची वेळ आणि डेटाबेसचा आकार दोन्ही वाढले. आमच्या हातात एक गृहितक आहे. आता फक्त अवलंबित्वाची पुष्टी करणे बाकी होते. म्हणून, आम्ही "गळती" काढून टाकण्याचे ठरवले आणि हे प्रक्षेपण वेगवान करते की नाही ते पहा.

अंतहीन डेटाबेस वाढीची कारणे

"गळती" काढून टाकण्यापूर्वी, ते प्रथम स्थानावर का दिसले हे समजून घेणे योग्य आहे. हे करण्यासाठी, क्षेत्र म्हणजे काय हे लक्षात ठेवूया.

क्षेत्र हा एक नॉन-रिलेशनल डेटाबेस आहे. हे तुम्हाला ऑब्जेक्ट्समधील संबंधांचे वर्णन करण्याची अनुमती देते जसे की Android वर किती ORM रिलेशनल डेटाबेसचे वर्णन केले आहे. त्याच वेळी, Realm कमीत कमी ट्रान्सफॉर्मेशन आणि मॅपिंगसह वस्तू थेट मेमरीमध्ये संग्रहित करते. हे आपल्याला डिस्कवरील डेटा फार लवकर वाचण्यास अनुमती देते, जी रीयलमची ताकद आहे आणि ती का आवडते.

(या लेखाच्या हेतूंसाठी, हे वर्णन आमच्यासाठी पुरेसे असेल. तुम्ही कूलमध्ये क्षेत्राबद्दल अधिक वाचू शकता दस्तऐवजीकरण किंवा त्यांच्या मध्ये अकादमी).

बर्याच विकासकांना रिलेशनल डेटाबेससह अधिक काम करण्याची सवय आहे (उदाहरणार्थ, हुड अंतर्गत SQL सह ORM डेटाबेस). आणि कॅस्केडिंग डेटा हटवण्यासारख्या गोष्टी अनेकदा दिल्यासारख्या दिसतात. पण क्षेत्रात नाही.

तसे, कॅस्केड हटविण्याचे वैशिष्ट्य बर्याच काळापासून विचारले गेले आहे. या पुनरावृत्ती и दुसरा, त्याच्याशी संबंधित, सक्रियपणे चर्चा केली गेली. लवकरच होईल अशी भावना होती. परंतु नंतर सर्व काही मजबूत आणि कमकुवत दुव्यांच्या परिचयामध्ये अनुवादित केले गेले, जे या समस्येचे स्वयंचलितपणे निराकरण करेल. या कार्यात ते खूप उत्साही आणि सक्रिय होते पुल विनंती, जे अंतर्गत अडचणींमुळे सध्या थांबवण्यात आले आहे.

कॅस्केडिंग हटविल्याशिवाय डेटा लीक

तुम्ही अस्तित्वात नसलेल्या कॅस्केडिंग डिलीटवर विसंबून राहिल्यास डेटा लीक कसा होतो? जर तुमच्याकडे नेस्टेड रियल्म ऑब्जेक्ट्स असतील, तर ते हटवले जाणे आवश्यक आहे.
चला एक (जवळजवळ) वास्तविक उदाहरण पाहू. आमच्याकडे एक वस्तू आहे 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()) समाविष्ट केला, तर हा ऑब्जेक्ट पूर्णपणे ओव्हरराईट होईल. परंतु सर्व अंतर्गत वस्तू (इमेज, कस्टमाइजेशन एंटिटी आणि कार्टकॉम्बोप्रॉडक्ट्स) पालकांशी कनेक्शन गमावतील आणि डेटाबेसमध्ये राहतील.

त्‍यांच्‍याशी कनेक्‍शन तुटल्‍याने, आम्‍ही यापुढे ते वाचणार नाही किंवा हटवणार नाही (जोपर्यंत आम्‍ही त्‍यांना स्‍पष्‍टपणे प्रवेश करत नाही किंवा संपूर्ण "टेबल" साफ करत नाही). आम्ही याला "मेमरी लीक" म्हटले.

जेव्हा आम्ही 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()
}
// и потом уже сохраняем

आपण असे केल्यास, सर्वकाही जसे पाहिजे तसे कार्य करेल. या उदाहरणात, आम्ही असे गृहीत धरतो की इमेज, कस्टमाइजेशन एंटिटी आणि कार्टकॉम्बो प्रॉडक्ट्समध्ये इतर कोणतेही नेस्टेड रीयलम ऑब्जेक्ट नाहीत, त्यामुळे इतर कोणतेही नेस्टेड लूप आणि डिलीट नाहीत.

जलद उपाय

आम्ही ठरवलेली पहिली गोष्ट म्हणजे सर्वात वेगाने वाढणार्‍या वस्तू स्वच्छ करणे आणि यामुळे आमची मूळ समस्या सुटेल का हे पाहण्यासाठी परिणाम तपासणे. प्रथम, सर्वात सोपा आणि सर्वात अंतर्ज्ञानी उपाय तयार केला गेला, म्हणजे: प्रत्येक ऑब्जेक्ट त्याच्या मुलांना काढून टाकण्यासाठी जबाबदार असावा. हे करण्यासाठी, आम्ही एक इंटरफेस सादर केला ज्याने त्याच्या नेस्टेड क्षेत्र ऑब्जेक्ट्सची सूची परत केली:

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 मध्ये डेटा कॅशिंगचा अतिशय सक्रिय वापर करतो. म्हणून, प्रत्येक ऑब्जेक्टसाठी सर्व नेस्टेड ऑब्जेक्ट्स लिहिणे श्रम-केंद्रित आहे, तसेच त्रुटींचा धोका वाढतो, कारण कोड बदलताना आपण ऑब्जेक्ट निर्दिष्ट करणे विसरू शकता.

मला खात्री करायची होती की मी इंटरफेस वापरत नाही, परंतु सर्वकाही स्वतःच कार्य करते.

जेव्हा आपल्याला एखादी गोष्ट स्वतःहून कार्य करायची असते तेव्हा आपल्याला प्रतिबिंब वापरावे लागते. हे करण्यासाठी, आम्ही प्रत्येक वर्ग फील्डमधून जाऊ शकतो आणि ते क्षेत्र ऑब्जेक्ट आहे की ऑब्जेक्ट्सची सूची आहे हे तपासू शकतो:

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 मेट्रिक पूर्णपणे पुरेसा दिसतो आणि 1 सेकंदापेक्षा कमी आहे.

हे देखील जोडण्यासारखे आहे की डीफॉल्टनुसार, _app_start चे सरासरी मूल्य 5 सेकंदांपेक्षा जास्त असल्यास फायरबेस सूचना पाठवते. तथापि, जसे आपण पाहू शकतो, आपण यावर विसंबून राहू नये, उलट आत जा आणि ते स्पष्टपणे तपासा.

Realm डेटाबेसची खास गोष्ट म्हणजे तो एक नॉन-रिलेशनल डेटाबेस आहे. वापरणी सोपी, ORM सोल्यूशन्स आणि ऑब्जेक्ट लिंकिंगशी समानता असूनही, त्यात कॅस्केड हटवणे नाही.

हे विचारात न घेतल्यास, नेस्टेड वस्तू जमा होतील आणि "गळती" होतील. डेटाबेस सतत वाढेल, ज्यामुळे अनुप्रयोगाच्या मंदी किंवा स्टार्टअपवर परिणाम होईल.

मी रिअलममधील ऑब्जेक्ट्सचे कॅस्केड द्रुतपणे कसे हटवायचे याबद्दल आमचा अनुभव सामायिक केला, जो अद्याप बॉक्सच्या बाहेर नाही, परंतु बर्याच काळापासून याबद्दल बोलले जात आहे. म्हणा и म्हणा. आमच्या बाबतीत, यामुळे ऍप्लिकेशन स्टार्टअप वेळेत मोठ्या प्रमाणात वेग आला.

या वैशिष्ट्याच्या नजीकच्या देखाव्याबद्दल चर्चा असूनही, क्षेत्रामध्ये कॅस्केड हटविण्याची अनुपस्थिती डिझाइनद्वारे केली जाते. तुम्ही नवीन अॅप्लिकेशन डिझाइन करत असाल तर हे लक्षात घ्या. आणि जर तुम्ही आधीच Realm वापरत असाल तर तुम्हाला अशा समस्या आहेत का ते तपासा.

स्त्रोत: www.habr.com