दायरे में कैस्केड विलोपन ने एक लंबे लॉन्च पर कैसे जीत हासिल की, इसकी कहानी

सभी उपयोगकर्ता मोबाइल एप्लिकेशन में तेज़ लॉन्च और प्रतिक्रियाशील यूआई को हल्के में लेते हैं। यदि एप्लिकेशन लॉन्च होने में अधिक समय लेता है, तो उपयोगकर्ता दुखी और क्रोधित होने लगता है। आप एप्लिकेशन का उपयोग शुरू करने से पहले ही ग्राहक अनुभव को आसानी से खराब कर सकते हैं या उपयोगकर्ता को पूरी तरह से खो सकते हैं।

हमें एक बार पता चला कि डोडो पिज़्ज़ा ऐप को लॉन्च होने में औसतन 3 सेकंड लगते हैं, और कुछ "भाग्यशाली लोगों" को 15-20 सेकंड लगते हैं।

कट के नीचे एक सुखद अंत वाली एक कहानी है: रीयलम डेटाबेस के विकास के बारे में, एक मेमोरी लीक के बारे में, कैसे हमने नेस्टेड ऑब्जेक्ट जमा किए, और फिर खुद को एक साथ खींच लिया और सब कुछ ठीक कर लिया।

लेख के लेखक: मैक्सिम काचिन्किन - डोडो पिज्जा में एंड्रॉइड डेवलपर।

एप्लिकेशन आइकन पर क्लिक करने से लेकर पहली गतिविधि के onResume() तक के तीन सेकंड अनंत हैं। और कुछ उपयोगकर्ताओं के लिए, स्टार्टअप समय 15-20 सेकंड तक पहुंच गया। यह संभव ही कैसे है?

उन लोगों के लिए एक बहुत ही संक्षिप्त सारांश जिनके पास पढ़ने का समय नहीं है
हमारा रीयलम डेटाबेस अंतहीन रूप से बढ़ा। कुछ नेस्टेड ऑब्जेक्ट हटाए नहीं गए थे, लेकिन लगातार जमा हुए थे। एप्लिकेशन स्टार्टअप समय धीरे-धीरे बढ़ता गया। फिर हमने इसे ठीक किया, और स्टार्टअप का समय लक्ष्य पर आ गया - यह 1 सेकंड से भी कम हो गया और अब नहीं बढ़ा। लेख में स्थिति का विश्लेषण और दो समाधान शामिल हैं - एक त्वरित और एक सामान्य।

समस्या की खोज एवं विश्लेषण

आज, किसी भी मोबाइल एप्लिकेशन को शीघ्रता से लॉन्च होना चाहिए और प्रतिक्रियाशील होना चाहिए। लेकिन यह सिर्फ मोबाइल ऐप के बारे में नहीं है। किसी सेवा और कंपनी के साथ बातचीत का उपयोगकर्ता अनुभव एक जटिल चीज़ है। उदाहरण के लिए, हमारे मामले में, डिलीवरी की गति पिज़्ज़ा सेवा के प्रमुख संकेतकों में से एक है। अगर डिलीवरी तेज होगी तो पिज्जा गर्म होगा और जो ग्राहक अभी खाना चाहेगा उसे ज्यादा देर तक इंतजार नहीं करना पड़ेगा. एप्लिकेशन के लिए, बदले में, तेज सेवा की भावना पैदा करना महत्वपूर्ण है, क्योंकि यदि एप्लिकेशन को लॉन्च होने में केवल 20 सेकंड लगते हैं, तो आपको पिज्जा के लिए कितनी देर तक इंतजार करना होगा?

सबसे पहले, हमें स्वयं इस तथ्य का सामना करना पड़ा कि कभी-कभी एप्लिकेशन को लॉन्च होने में कुछ सेकंड लगते थे, और फिर हमें अन्य सहयोगियों से शिकायतें सुनने लगीं कि इसमें कितना समय लगा। लेकिन हम इस स्थिति को लगातार दोहराने में असमर्थ रहे.

यह कितना लंबा है? के अनुसार गूगल दस्तावेज़ीकरण, यदि किसी एप्लिकेशन की कोल्ड स्टार्ट में 5 सेकंड से कम समय लगता है, तो इसे "मानो सामान्य" माना जाता है। डोडो पिज़्ज़ा एंड्रॉइड ऐप लॉन्च किया गया (फायरबेस मेट्रिक्स के अनुसार)। _ऐप_स्टार्ट) पर ठंडी शुरुआत औसतन 3 सेकंड में - "महान नहीं, भयानक नहीं," जैसा कि वे कहते हैं।

लेकिन फिर शिकायतें सामने आने लगीं कि एप्लिकेशन को लॉन्च होने में बहुत, बहुत, बहुत लंबा समय लगा! आरंभ करने के लिए, हमने यह मापने का निर्णय लिया कि "बहुत, बहुत, बहुत लंबा" क्या है। और हमने इसके लिए फायरबेस ट्रेस का उपयोग किया ऐप प्रारंभ ट्रेस.

यह मानक ट्रेस उस क्षण के बीच के समय को मापता है जब उपयोगकर्ता एप्लिकेशन खोलता है और उस क्षण के बीच जब पहली गतिविधि का onResume() निष्पादित होता है। फायरबेस कंसोल में इस मीट्रिक को _app_start कहा जाता है। ऐसा पता चला कि:

• औसत कोल्ड स्टार्टअप समय 95 सेकंड से कम होने के बावजूद, 20वें प्रतिशत से ऊपर के उपयोगकर्ताओं के लिए स्टार्टअप समय लगभग 5 सेकंड (कुछ इससे भी अधिक) है।
• स्टार्टअप समय कोई स्थिर मान नहीं है, बल्कि समय के साथ बढ़ता है। लेकिन कभी-कभी बूंदें भी आ जाती हैं. हमें यह पैटर्न तब मिला जब हमने विश्लेषण का पैमाना बढ़ाकर 90 दिन कर दिया।

मन में दो विचार आये:

1. कुछ लीक हो रहा है.
2. यह "कुछ" रिलीज़ के बाद रीसेट हो जाता है और फिर लीक हो जाता है।

"संभवतः डेटाबेस के साथ कुछ है," हमने सोचा, और हम सही थे। सबसे पहले, हम डेटाबेस को कैश के रूप में उपयोग करते हैं; माइग्रेशन के दौरान हम इसे साफ़ करते हैं। दूसरे, एप्लिकेशन शुरू होने पर डेटाबेस लोड हो जाता है। सब कुछ एक साथ फिट बैठता है.

दायरे डेटाबेस में क्या खराबी है?

हमने यह जांचना शुरू किया कि डेटाबेस की सामग्री एप्लिकेशन के जीवनकाल में, पहली स्थापना से लेकर आगे सक्रिय उपयोग के दौरान कैसे बदलती है। आप दायरे डेटाबेस की सामग्री को इसके माध्यम से देख सकते हैं स्टेथो या फ़ाइल को खोलकर अधिक विस्तार से और स्पष्ट रूप से दायरे स्टूडियो. ADB के माध्यम से डेटाबेस की सामग्री देखने के लिए, Realm डेटाबेस फ़ाइल की प्रतिलिपि बनाएँ:

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

अलग-अलग समय पर डेटाबेस की सामग्री को देखने पर हमें पता चला कि एक निश्चित प्रकार की वस्तुओं की संख्या लगातार बढ़ रही है।

चित्र दो फ़ाइलों के लिए रीयलम स्टूडियो का एक टुकड़ा दिखाता है: बाईं ओर - इंस्टॉलेशन के कुछ समय बाद एप्लिकेशन बेस, दाईं ओर - सक्रिय उपयोग के बाद। इसमें वस्तुओं की संख्या देखी जा सकती है ImageEntity и MoneyType उल्लेखनीय रूप से बढ़ गया है (स्क्रीनशॉट प्रत्येक प्रकार की वस्तुओं की संख्या दिखाता है)।

डेटाबेस वृद्धि और स्टार्टअप समय के बीच संबंध

अनियंत्रित डेटाबेस वृद्धि बहुत खराब है. लेकिन यह एप्लिकेशन स्टार्टअप समय को कैसे प्रभावित करता है? एक्टिविटी मैनेजर के माध्यम से इसे मापना काफी आसान है। एंड्रॉइड 4.4 के बाद से, लॉगकैट प्रदर्शित स्ट्रिंग और समय के साथ लॉग प्रदर्शित करता है। यह समय एप्लिकेशन लॉन्च होने से लेकर गतिविधि रेंडरिंग के अंत तक के अंतराल के बराबर है। इस दौरान निम्नलिखित घटनाएँ घटित होती हैं:

• प्रक्रिया प्रारंभ करें.
• वस्तुओं का आरंभीकरण.
• गतिविधियों का निर्माण और आरंभीकरण.
• एक लेआउट बनाना.
• अनुप्रयोग प्रतिपादन.

हमें सूट करता है। यदि आप 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 संबंधपरक डेटाबेस का वर्णन किया गया है। साथ ही, रीयलम कम से कम परिवर्तनों और मैपिंग के साथ वस्तुओं को सीधे मेमोरी में संग्रहीत करता है। यह आपको डिस्क से डेटा को बहुत तेज़ी से पढ़ने की अनुमति देता है, जो कि रीयलम की ताकत है और इसे क्यों पसंद किया जाता है।

(इस लेख के प्रयोजनों के लिए, यह विवरण हमारे लिए पर्याप्त होगा। आप कूल में दायरे के बारे में अधिक पढ़ सकते हैं प्रलेखन या उनके में अकादमी).

कई डेवलपर्स रिलेशनल डेटाबेस के साथ अधिक काम करने के आदी हैं (उदाहरण के लिए, हुड के नीचे एसक्यूएल के साथ ओआरएम डेटाबेस)। और कैस्केडिंग डेटा विलोपन जैसी चीजें अक्सर दी गई लगती हैं। लेकिन दायरे में नहीं.

वैसे, कैस्केड डिलीट फीचर की मांग काफी समय से की जा रही है। यह दोहराव и एक और, इससे जुड़े, सक्रिय रूप से चर्चा की गई। ऐसा लग रहा था कि यह जल्द ही पूरा हो जायेगा. लेकिन फिर सब कुछ मजबूत और कमजोर कड़ियों की शुरूआत में बदल गया, जिससे यह समस्या भी स्वचालित रूप से हल हो जाएगी। इस कार्य को लेकर काफी सक्रिय एवं सक्रिय थे पुल अनुरोधजिसे आंतरिक कठिनाइयों के कारण फिलहाल रोक दिया गया है।

व्यापक विलोपन के बिना डेटा लीक

यदि आप गैर-मौजूद कैस्केडिंग डिलीट पर भरोसा करते हैं तो डेटा वास्तव में कैसे लीक होता है? यदि आपके पास नेस्टेड रीयलम ऑब्जेक्ट हैं, तो उन्हें हटा दिया जाना चाहिए।
आइए एक (लगभग) वास्तविक उदाहरण देखें। हमारे पास एक वस्तु है 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()) डालते हैं, तो यह ऑब्जेक्ट पूरी तरह से ओवरराइट हो जाएगा। लेकिन सभी आंतरिक ऑब्जेक्ट (छवि, कस्टमाइज़ेशनएंटिटी और कार्टकॉम्बोप्रोडक्ट्स) पैरेंट के साथ कनेक्शन खो देंगे और डेटाबेस में बने रहेंगे।

चूंकि उनके साथ कनेक्शन टूट गया है, हम अब उन्हें नहीं पढ़ते हैं या उन्हें हटा नहीं देते हैं (जब तक कि हम स्पष्ट रूप से उन तक नहीं पहुंचते हैं या संपूर्ण "तालिका" को साफ़ नहीं करते हैं)। हमने इसे "मेमोरी लीक" कहा।

जब हम दायरे के साथ काम करते हैं, तो हमें स्पष्ट रूप से सभी तत्वों से गुजरना होगा और ऐसे संचालन से पहले स्पष्ट रूप से सब कुछ हटाना होगा। उदाहरण के लिए, यह इस प्रकार किया जा सकता है:

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()
   }
 }
}

हमने इसे सबसे तेजी से बढ़ने वाली वस्तुओं के साथ किया और जाँच की कि क्या हुआ।

परिणामस्वरूप, जिन वस्तुओं को हमने इस घोल से ढक दिया था, उनका बढ़ना बंद हो गया। और आधार की समग्र वृद्धि धीमी हो गई, लेकिन रुकी नहीं।

"सामान्य" समाधान

हालाँकि आधार धीरे-धीरे बढ़ने लगा, फिर भी यह बढ़ता गया। इसलिए हमने आगे देखना शुरू किया। हमारा प्रोजेक्ट दायरे में डेटा कैशिंग का बहुत सक्रिय उपयोग करता है। इसलिए, प्रत्येक ऑब्जेक्ट के लिए सभी नेस्टेड ऑब्जेक्ट लिखना श्रम-गहन है, साथ ही त्रुटियों का जोखिम भी बढ़ जाता है, क्योंकि कोड बदलते समय आप ऑब्जेक्ट निर्दिष्ट करना भूल सकते हैं।

मैं यह सुनिश्चित करना चाहता था कि मैं इंटरफ़ेस का उपयोग न करूं, बल्कि यह कि सब कुछ अपने आप काम करे।

जब हम चाहते हैं कि कोई चीज़ अपने आप काम करे, तो हमें प्रतिबिंब का उपयोग करना होगा। ऐसा करने के लिए, हम प्रत्येक वर्ग फ़ील्ड में जा सकते हैं और जाँच सकते हैं कि क्या यह एक दायरे की वस्तु है या वस्तुओं की सूची है:

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, क्योंकि ऐसा हो सकता है कि अलग-अलग मूल वस्तुओं में समान वस्तुएं नेस्टेड हो सकती हैं। इससे बचना बेहतर है और नए ऑब्जेक्ट बनाते समय आईडी के ऑटो-जनरेशन का उपयोग करें।

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 नए लिखने से पहले सभी एकत्रित ऑब्जेक्ट को पुनरावर्ती रूप से हटा देता है। हम पूरे एप्लिकेशन में इस दृष्टिकोण का उपयोग करते हैं। दायरे में मेमोरी लीक पूरी तरह से ख़त्म हो गए हैं। एप्लिकेशन के कोल्ड स्टार्ट की संख्या पर स्टार्टअप समय की निर्भरता का समान माप करने पर, हम परिणाम देखते हैं।

हरी रेखा नेस्टेड ऑब्जेक्ट के स्वचालित कैस्केड विलोपन के दौरान कोल्ड स्टार्ट की संख्या पर एप्लिकेशन स्टार्टअप समय की निर्भरता को दर्शाती है।

परिणाम और निष्कर्ष

लगातार बढ़ते दायरे डेटाबेस के कारण एप्लिकेशन बहुत धीमी गति से लॉन्च हो रहा था। हमने नेस्टेड ऑब्जेक्ट्स के अपने "कैस्केडिंग डिलीट" के साथ एक अपडेट जारी किया। और अब हम _app_start मीट्रिक के माध्यम से निगरानी और मूल्यांकन करते हैं कि हमारे निर्णय ने एप्लिकेशन स्टार्टअप समय को कैसे प्रभावित किया।

विश्लेषण के लिए, हम 90 दिनों की समयावधि लेते हैं और देखते हैं: एप्लिकेशन लॉन्च समय, दोनों माध्यिका और वह जो उपयोगकर्ताओं के 95वें प्रतिशतक पर पड़ता है, घटने लगा और अब नहीं बढ़ता है।

यदि आप सात-दिवसीय चार्ट को देखें, तो _app_start मीट्रिक पूरी तरह से पर्याप्त दिखती है और 1 सेकंड से भी कम है।

यह भी जोड़ने योग्य है कि डिफ़ॉल्ट रूप से, यदि _app_start का औसत मान 5 सेकंड से अधिक हो जाता है, तो फायरबेस सूचनाएं भेजता है। हालाँकि, जैसा कि हम देख सकते हैं, आपको इस पर भरोसा नहीं करना चाहिए, बल्कि अंदर जाकर इसे स्पष्ट रूप से जांचना चाहिए।

रीयलम डेटाबेस की खास बात यह है कि यह एक नॉन-रिलेशनल डेटाबेस है। इसके उपयोग में आसानी, ओआरएम समाधानों और ऑब्जेक्ट लिंकिंग की समानता के बावजूद, इसमें कैस्केड विलोपन नहीं है।

यदि इस पर ध्यान नहीं दिया गया, तो नेस्टेड वस्तुएं जमा हो जाएंगी और "रिस जाएंगी।" डेटाबेस लगातार बढ़ेगा, जो बदले में एप्लिकेशन की मंदी या स्टार्टअप को प्रभावित करेगा।

मैंने रीयलम में वस्तुओं को तेजी से कैस्केड रूप से हटाने के तरीके पर अपना अनुभव साझा किया, जो अभी तक बॉक्स से बाहर नहीं है, लेकिन लंबे समय से इसके बारे में बात की गई है वे कहते हैं и वे कहते हैं. हमारे मामले में, इससे एप्लिकेशन स्टार्टअप समय में काफी तेजी आई।

इस सुविधा की आसन्न उपस्थिति के बारे में चर्चा के बावजूद, दायरे में कैस्केड विलोपन की अनुपस्थिति डिज़ाइन द्वारा की गई है। अगर आप कोई नया एप्लिकेशन डिजाइन कर रहे हैं तो इस बात का ध्यान रखें। और यदि आप पहले से ही Realm का उपयोग कर रहे हैं, तो जांचें कि क्या आपको ऐसी कोई समस्या है।

स्रोत: www.habr.com