🥇 कसरी Realm मा क्यास्केड मेटाउने लामो प्रक्षेपण मा जित्यो को कथा

सबै प्रयोगकर्ताहरूले मोबाइल अनुप्रयोगहरूमा छिटो प्रक्षेपण र उत्तरदायी UI लिन्छन्। यदि एप्लिकेसन सुरु हुन लामो समय लाग्छ भने, प्रयोगकर्ता उदास र रिसाउन थाल्छ। तपाईले सजिलैसँग ग्राहकको अनुभव बिगार्न सक्नुहुन्छ वा प्रयोगकर्तालाई पूर्ण रूपमा गुमाउन सक्नुहुन्छ उसले अनुप्रयोग प्रयोग गर्न सुरु गर्नु अघि नै।

हामीले एक पटक पत्ता लगायौं कि डोडो पिज्जा एप औसतमा सुरु हुन ३ सेकेन्ड लाग्छ, र केही "भाग्यवानहरू" को लागि यसले १५-२० सेकेन्ड लिन्छ।

कटको तल एक सुखद अन्त्यको साथ एउटा कथा छ: क्षेत्र डाटाबेसको वृद्धिको बारेमा, मेमोरी चुहावट, हामीले कसरी नेस्टेड वस्तुहरू जम्मा गर्यौं, र त्यसपछि आफूलाई सँगै तान्यौं र सबै कुरा ठीक गर्यौं।

लेख लेखक: म्याक्सिम काचिनकिन — डोडो पिज्जामा एन्ड्रोइड विकासकर्ता।

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

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

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

आज, कुनै पनि मोबाइल अनुप्रयोग चाँडै लन्च गर्नुपर्छ र उत्तरदायी हुनुपर्छ। तर यो मोबाइल एपको बारेमा मात्र होइन। सेवा र कम्पनी संग अन्तरक्रिया को प्रयोगकर्ता अनुभव एक जटिल कुरा हो। उदाहरण को लागी, हाम्रो मामला मा, वितरण गति पिज्जा सेवा को लागि प्रमुख सूचकहरु मध्ये एक हो। यदि डेलिभरी छिटो भयो भने, पिज्जा तातो हुनेछ, र अब खान चाहने ग्राहकले लामो समय कुर्नु पर्दैन। एप्लिकेसनको लागि, बारीमा, छिटो सेवाको भावना सिर्जना गर्न महत्त्वपूर्ण छ, किनकि यदि अनुप्रयोग सुरु हुन 20 सेकेन्ड मात्र लाग्छ भने, तपाइँ पिज्जाको लागि कति लामो पर्खनु पर्छ?

सुरुमा, हामी आफैंले यस तथ्यको सामना गरेका थियौं कि कहिलेकाहीँ अनुप्रयोग सुरु हुन केही सेकेन्ड लाग्थ्यो, र त्यसपछि हामीले अन्य सहकर्मीहरूबाट कति समय लाग्यो भनेर गुनासोहरू सुन्न थाल्यौं। तर हामीले यो अवस्थालाई निरन्तर दोहोर्याउन सकेनौं।

यो कति लामो छ? यस अनुसार गुगल कागजात, यदि एप्लिकेसनको चिसो सुरुवातले 5 सेकेन्ड भन्दा कम समय लिन्छ भने, यसलाई "सामान्य जस्तै" मानिन्छ। डोडो पिज्जा एन्ड्रोइड एप सुरु भयो (फायरबेस मेट्रिक्स अनुसार _app_start) मा चिसो सुरुवात औसतमा 3 सेकेन्डमा - "ठूलो छैन, भयानक छैन," तिनीहरू भन्छन्।

तर त्यसपछि गुनासोहरू देखा पर्न थाले कि अनुप्रयोग सुरु गर्न धेरै, धेरै, धेरै लामो समय लाग्यो! सुरुमा, हामीले "धेरै, धेरै, धेरै लामो" के हो मापन गर्ने निर्णय गर्यौं। र हामीले यसको लागि फायरबेस ट्रेस प्रयोग गर्यौं अनुप्रयोग सुरु ट्रेस.

यो मानक ट्रेसले प्रयोगकर्ताले एप खोल्ने क्षण र पहिलो गतिविधिको onResume() कार्यान्वयन भएको क्षण बीचको समयलाई नाप्छ। फायरबेस कन्सोलमा यो मेट्रिकलाई _app_start भनिन्छ। यो बाहिर भयो कि:

95 औं प्रतिशत भन्दा माथिका प्रयोगकर्ताहरूका लागि स्टार्टअप समय लगभग 20 सेकेन्ड (केही लामो) हो, औसत चिसो स्टार्टअप समय 5 सेकेन्ड भन्दा कम भए तापनि।
स्टार्टअप समय एक स्थिर मूल्य होइन, तर समय संग बढ्छ। तर कहिलेकाहीँ त्यहाँ थोपाहरू छन्। हामीले यो ढाँचा भेट्टायौं जब हामीले विश्लेषणको स्केललाई 90 दिनमा बढाएका थियौं।

मनमा दुईवटा विचार आयो:

केही चुहिरहेको छ।
यो "केहि" रिलीज पछि रिसेट हुन्छ र त्यसपछि फेरि लीक हुन्छ।

"सायद डाटाबेसको साथ केहि," हामीले सोच्यौं, र हामी सही थियौं। सर्वप्रथम, हामी डाटाबेसलाई क्यासको रूपमा प्रयोग गर्छौं; माइग्रेसनको क्रममा हामी यसलाई खाली गर्छौं। दोस्रो, डाटाबेस लोड हुन्छ जब अनुप्रयोग सुरु हुन्छ। सबै कुरा मिल्छ।

Realm डाटाबेसमा के गलत छ

हामीले पहिलो स्थापनादेखि र सक्रिय प्रयोगको बखत थप डाटाबेसका सामग्रीहरू अनुप्रयोगको जीवनमा कसरी परिवर्तन हुन्छ भनेर जाँच गर्न थाल्यौं। तपाईं मार्फत क्षेत्र डाटाबेसको सामग्रीहरू हेर्न सक्नुहुन्छ स्टेथो वा थप विवरणमा र स्पष्ट रूपमा फाइल खोलेर क्षेत्र स्टुडियो। ADB मार्फत डाटाबेसका सामग्रीहरू हेर्नको लागि, Realm डाटाबेस फाइल प्रतिलिपि गर्नुहोस्:

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

विभिन्न समयमा डाटाबेसका सामग्रीहरू हेरेपछि, हामीले पत्ता लगायौं कि एक निश्चित प्रकारका वस्तुहरूको संख्या निरन्तर बढिरहेको छ।

तस्विरले दुई फाईलहरूको लागि रियलम स्टुडियोको टुक्रा देखाउँदछ: बायाँमा - स्थापना पछि केही समय पछि अनुप्रयोग आधार, दायाँ - सक्रिय प्रयोग पछि। यो देख्न सकिन्छ कि वस्तुहरूको संख्या ImageEntity и MoneyType उल्लेखनीय रूपमा बढेको छ (स्क्रिनसटले प्रत्येक प्रकारका वस्तुहरूको संख्या देखाउँछ)।

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

अनियन्त्रित डाटाबेस वृद्धि धेरै खराब छ। तर यसले कसरी अनुप्रयोग स्टार्टअप समयलाई असर गर्छ? ActivityManager मार्फत यो मापन गर्न एकदम सजिलो छ। एन्ड्रोइड 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 MB बाट 15 MB मा बढ्यो। कुलमा, यो बाहिर जान्छ कि समयको साथ (चिसो सुरुको वृद्धि संग), दुबै अनुप्रयोग लन्च समय र डाटाबेसको आकार बढ्यो। हाम्रो हातमा परिकल्पना छ। अब केवल निर्भरता पुष्टि गर्न बाँकी थियो। त्यसकारण, हामीले "लीक" हटाउने निर्णय गर्यौं र हेर्नुहोस् कि यसले प्रक्षेपणलाई गति दिन्छ।

अनन्त डाटाबेस वृद्धि को कारण

"लीक" हटाउनु अघि, यो बुझ्न लायक छ किन तिनीहरू पहिलो स्थानमा देखा पर्यो। यो गर्नको लागि, क्षेत्र के हो सम्झौं।

क्षेत्र एक गैर-रिलेशनल डाटाबेस हो। यसले तपाइँलाई एन्ड्रोइडमा कतिवटा 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()) सम्मिलित गर्छौं भने, यो वस्तु पूर्ण रूपमा ओभरराइट हुनेछ। तर सबै आन्तरिक वस्तुहरू (छवि, अनुकूलनEntity र cartComboProducts) अभिभावकसँगको सम्बन्ध गुमाउनेछन् र डाटाबेसमा रहनेछन्।

तिनीहरूसँगको जडान हराएको हुनाले, हामी तिनीहरूलाई अब पढ्दैनौं वा तिनीहरूलाई मेटाउँदैनौं (जबसम्म हामी तिनीहरूलाई स्पष्ट रूपमा पहुँच गर्दैनौं वा सम्पूर्ण "तालिका" खाली गर्दैनौं)। हामीले यसलाई "मेमोरी लीक" भन्यौं।

जब हामी क्षेत्रसँग काम गर्छौं, हामीले स्पष्ट रूपमा सबै तत्वहरू मार्फत जानुपर्छ र त्यस्ता अपरेशनहरू अघि सबै कुरा स्पष्ट रूपमा मेटाउनुपर्दछ। यो गर्न सकिन्छ, उदाहरण को लागी, यो जस्तै:

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()
}
// и потом уже сохраняем

यदि तपाईंले यसो गर्नुभयो भने, त्यसपछि सबै कुराले जस्तै काम गर्नेछ। यस उदाहरणमा, हामी छवि, अनुकूलनEntity, र 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()
   }
 }
}

हामीले यो सबैभन्दा छिटो बढ्दो वस्तुहरूसँग गर्यौं र के भयो जाँच गर्यौं।

नतिजाको रूपमा, ती वस्तुहरू जुन हामीले यो समाधानले कभर गरेका थियौं बढ्दै रोकियो। र आधारको समग्र वृद्धि सुस्त भयो, तर रोकिएन।

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

आधार बिस्तारै बढ्न थाले पनि, यो अझै बढ्यो। त्यसैले हामीले अगाडि हेर्न थाल्यौं। हाम्रो परियोजनाले दायरामा डाटा क्यासिङको धेरै सक्रिय प्रयोग गर्दछ। तसर्थ, प्रत्येक वस्तुको लागि सबै नेस्टेड वस्तुहरू लेख्नु श्रम-गहन हो, साथै त्रुटिहरूको जोखिम बढ्छ, किनकि तपाईंले कोड परिवर्तन गर्दा वस्तुहरू निर्दिष्ट गर्न बिर्सन सक्नुहुन्छ।

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

जब हामी केहि आफैंमा काम गर्न चाहन्छौं, हामीले प्रतिबिम्ब प्रयोग गर्नुपर्छ। यो गर्नको लागि, हामी प्रत्येक वर्ग फिल्ड मार्फत जान सक्छौं र जाँच गर्न सक्छौं कि यो क्षेत्र वस्तु हो वा वस्तुहरूको सूची:

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 नयाँ लेख्नु अघि सबै सङ्कलन वस्तुहरू पुनरावर्ती मेटाउँछ। हामी सम्पूर्ण अनुप्रयोगमा यो दृष्टिकोण प्रयोग गरेर अन्त्य गर्छौं। Realm मा मेमोरी लीक पूर्ण रूपमा गएको छ। एप्लिकेसनको चिसो सुरुवातको संख्यामा स्टार्टअप समयको निर्भरताको समान मापन गरिसकेपछि, हामी परिणाम देख्छौं।

हरियो रेखाले नेस्टेड वस्तुहरूको स्वचालित क्यास्केड मेटाउने क्रममा कोल्ड स्टार्टहरूको संख्यामा एप्लिकेसन स्टार्टअप समयको निर्भरता देखाउँदछ।

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

सँधै बढ्दो रियलम डाटाबेसले अनुप्रयोगलाई धेरै ढिलो सुरु गर्नको लागि कारण बनाउँदै थियो। हामीले नेस्टेड वस्तुहरूको आफ्नै "क्यास्केडिङ डिलिट" सँग अद्यावधिक जारी गर्यौं। र अब हामी _app_start मेट्रिक मार्फत हाम्रो निर्णयले एप्लिकेसन स्टार्टअप समयलाई कसरी असर गर्छ भनेर निगरानी र मूल्याङ्कन गर्छौं।

विश्लेषणको लागि, हामी 90 दिनको समयावधि लिन्छौं र हेर्छौं: अनुप्रयोग सुरु हुने समय, दुबै मध्य र जुन प्रयोगकर्ताहरूको 95 औं प्रतिशतमा पर्दछ, घट्न थाल्यो र अब बढ्दैन।

यदि तपाइँ सात-दिनको चार्ट हेर्नुहुन्छ भने, _app_start मेट्रिक पूर्ण रूपमा पर्याप्त देखिन्छ र 1 सेकेन्ड भन्दा कम छ।

यो पनि थप्न लायक छ कि पूर्वनिर्धारित रूपमा, यदि _app_start को मध्य मान 5 सेकेन्ड भन्दा बढी छ भने Firebase ले सूचनाहरू पठाउँछ। यद्यपि, हामी देख्न सक्छौं, तपाईले यसमा भर पर्नु हुँदैन, बरु भित्र जानुहोस् र यसलाई स्पष्ट रूपमा जाँच गर्नुहोस्।

Realm डाटाबेसको बारेमा विशेष कुरा यो हो कि यो एक गैर-रिलेशनल डाटाबेस हो। यसको प्रयोगको सहजता, ORM समाधानहरू र वस्तु लिङ्किङसँग समानता भए तापनि, यसमा क्यास्केड मेटाउने छैन।

यदि यसलाई ध्यानमा राखिएको छैन भने, त्यसपछि नेस्टेड वस्तुहरू जम्मा हुनेछन् र "लिक" हुनेछन्। डाटाबेस निरन्तर बढ्नेछ, जसले बारीमा अनुप्रयोगको ढिलो वा स्टार्टअपलाई असर गर्नेछ।

मैले Realm मा वस्तुहरूको क्यास्केड मेटाउने कसरी गर्ने भन्ने बारे हाम्रो अनुभव साझा गरें, जुन अझै बक्स बाहिर छैन, तर लामो समयदेखि कुरा गरिएको छ। भन्नु и भन्नु। हाम्रो केसमा, यसले एप्लिकेसन स्टार्टअप समयलाई धेरै गति दियो।

यस सुविधाको आसन्न उपस्थितिको बारेमा छलफलको बावजुद, दायरामा क्यास्केड मेटाउने अनुपस्थिति डिजाइन द्वारा गरिन्छ। यदि तपाइँ नयाँ अनुप्रयोग डिजाइन गर्दै हुनुहुन्छ भने, त्यसपछि यो खातामा लिनुहोस्। र यदि तपाइँ पहिले नै Realm प्रयोग गर्दै हुनुहुन्छ भने, यदि तपाइँसँग त्यस्ता समस्याहरू छन् भने जाँच गर्नुहोस्।

स्रोत: www.habr.com

कसरी Realm मा क्यास्केड मेटाउने को कथा एक लामो प्रक्षेपण मा जित्यो