റിയൽമിലെ കാസ്കേഡ് ഡിലീഷൻ എങ്ങനെ നീണ്ട ലോഞ്ചിൽ വിജയിച്ചു എന്നതിന്റെ കഥ

എല്ലാ ഉപയോക്താക്കളും മൊബൈൽ ആപ്ലിക്കേഷനുകളിൽ വേഗത്തിലുള്ള ലോഞ്ചും പ്രതികരിക്കുന്ന യുഐയും എടുക്കുന്നു. ആപ്ലിക്കേഷൻ ലോഞ്ച് ചെയ്യാൻ വളരെ സമയമെടുക്കുകയാണെങ്കിൽ, ഉപയോക്താവിന് സങ്കടവും ദേഷ്യവും അനുഭവപ്പെടാൻ തുടങ്ങുന്നു. നിങ്ങൾക്ക് ഉപഭോക്തൃ അനുഭവം എളുപ്പത്തിൽ നശിപ്പിക്കാം അല്ലെങ്കിൽ ഉപയോക്താവ് ആപ്ലിക്കേഷൻ ഉപയോഗിക്കാൻ തുടങ്ങുന്നതിന് മുമ്പുതന്നെ അവനെ പൂർണ്ണമായും നഷ്‌ടപ്പെടുത്താം.

Dodo Pizza ആപ്പ് സമാരംഭിക്കാൻ ശരാശരി 3 സെക്കൻഡ് എടുക്കുമെന്നും ചില "ഭാഗ്യവാന്മാർക്ക്" 15-20 സെക്കൻഡ് എടുക്കുമെന്നും ഞങ്ങൾ ഒരിക്കൽ കണ്ടെത്തി.

കട്ടിന് താഴെ സന്തോഷകരമായ ഒരു കഥയുണ്ട്: റിയൽം ഡാറ്റാബേസിന്റെ വളർച്ച, മെമ്മറി ലീക്ക്, ഞങ്ങൾ എങ്ങനെ നെസ്റ്റഡ് ഒബ്‌ജക്റ്റുകൾ ശേഖരിച്ചു, തുടർന്ന് സ്വയം വലിച്ചിഴച്ച് എല്ലാം ശരിയാക്കി.

ലേഖന രചയിതാവ്: മാക്സിം കാച്ചിൻകിൻ — ഡോഡോ പിസ്സയിലെ ആൻഡ്രോയിഡ് ഡെവലപ്പർ.

ആപ്ലിക്കേഷൻ ഐക്കണിൽ ക്ലിക്കുചെയ്യുന്നത് മുതൽ ആദ്യ പ്രവർത്തനത്തിന്റെ onResume() വരെയുള്ള മൂന്ന് സെക്കൻഡ് അനന്തമാണ്. ചില ഉപയോക്താക്കൾക്ക്, സ്റ്റാർട്ടപ്പ് സമയം 15-20 സെക്കൻഡിൽ എത്തി. ഇത് പോലും എങ്ങനെ സാധ്യമാകും?

വായിക്കാൻ സമയമില്ലാത്തവർക്കായി വളരെ ചെറിയ ഒരു സംഗ്രഹം
ഞങ്ങളുടെ Realm ഡാറ്റാബേസ് അനന്തമായി വളർന്നു. ചില നെസ്റ്റഡ് ഒബ്‌ജക്റ്റുകൾ ഇല്ലാതാക്കിയില്ല, പക്ഷേ നിരന്തരം ശേഖരിക്കപ്പെട്ടു. ആപ്ലിക്കേഷൻ ആരംഭിക്കുന്ന സമയം ക്രമേണ വർദ്ധിച്ചു. തുടർന്ന് ഞങ്ങൾ അത് പരിഹരിച്ചു, സ്റ്റാർട്ടപ്പ് സമയം ലക്ഷ്യത്തിലെത്തി - ഇത് 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}

വ്യത്യസ്ത സമയങ്ങളിൽ ഡാറ്റാബേസിന്റെ ഉള്ളടക്കങ്ങൾ പരിശോധിച്ച ശേഷം, ഒരു പ്രത്യേക തരത്തിലുള്ള ഒബ്‌ജക്റ്റുകളുടെ എണ്ണം നിരന്തരം വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി.

രണ്ട് ഫയലുകൾക്കായി റിയൽം സ്റ്റുഡിയോയുടെ ഒരു ഭാഗം ചിത്രം കാണിക്കുന്നു: ഇടതുവശത്ത് - ഇൻസ്റ്റാളേഷന് ശേഷം കുറച്ച് സമയത്തിന് ശേഷം ആപ്ലിക്കേഷൻ ബേസ്, വലതുവശത്ത് - സജീവ ഉപയോഗത്തിന് ശേഷം. വസ്തുക്കളുടെ എണ്ണം എന്ന് കാണാം ImageEntity и MoneyType ഗണ്യമായി വളർന്നു (സ്ക്രീൻഷോട്ട് ഓരോ തരത്തിലുമുള്ള ഒബ്ജക്റ്റുകളുടെ എണ്ണം കാണിക്കുന്നു).

ഡാറ്റാബേസ് വളർച്ചയും സ്റ്റാർട്ടപ്പ് സമയവും തമ്മിലുള്ള ബന്ധം

അനിയന്ത്രിതമായ ഡാറ്റാബേസ് വളർച്ച വളരെ മോശമാണ്. എന്നാൽ ഇത് ആപ്ലിക്കേഷൻ സ്റ്റാർട്ടപ്പ് സമയത്തെ എങ്ങനെ ബാധിക്കുന്നു? ActivityManager വഴി ഇത് അളക്കുന്നത് വളരെ എളുപ്പമാണ്. ആൻഡ്രോയിഡ് 4.4 മുതൽ, ലോഗ്കാറ്റ് സ്ട്രിംഗും സമയവും ഉപയോഗിച്ച് ലോഗ് പ്രദർശിപ്പിക്കുന്നു. ഈ സമയം ആപ്ലിക്കേഷൻ സമാരംഭിച്ച നിമിഷം മുതൽ പ്രവർത്തന റെൻഡറിംഗിന്റെ അവസാനം വരെയുള്ള ഇടവേളയ്ക്ക് തുല്യമാണ്. ഈ സമയത്ത്, ഇനിപ്പറയുന്ന സംഭവങ്ങൾ സംഭവിക്കുന്നു:

• പ്രക്രിയ ആരംഭിക്കുക.
• വസ്തുക്കളുടെ ആരംഭം.
• പ്രവർത്തനങ്ങളുടെ സൃഷ്ടിയും സമാരംഭവും.
• ഒരു ലേഔട്ട് സൃഷ്ടിക്കുന്നു.
• ആപ്ലിക്കേഷൻ റെൻഡറിംഗ്.

ഞങ്ങൾക്ക് അനുയോജ്യമാണ്. നിങ്ങൾ -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 എംബിയായി വളർന്നു. മൊത്തത്തിൽ, കാലക്രമേണ (തണുത്ത ആരംഭത്തിന്റെ വളർച്ചയോടെ), ആപ്ലിക്കേഷൻ ലോഞ്ച് സമയവും ഡാറ്റാബേസിന്റെ വലുപ്പവും വർദ്ധിച്ചതായി മാറുന്നു. ഞങ്ങളുടെ കൈകളിൽ ഒരു സിദ്ധാന്തമുണ്ട്. ആശ്രിതത്വം സ്ഥിരീകരിക്കുക മാത്രമാണ് ഇപ്പോൾ അവശേഷിക്കുന്നത്. അതിനാൽ, "ചോർച്ചകൾ" നീക്കം ചെയ്യാനും ഇത് വിക്ഷേപണം വേഗത്തിലാക്കുമോ എന്ന് നോക്കാനും ഞങ്ങൾ തീരുമാനിച്ചു.

അനന്തമായ ഡാറ്റാബേസ് വളർച്ചയുടെ കാരണങ്ങൾ

"ചോർച്ചകൾ" നീക്കം ചെയ്യുന്നതിനുമുമ്പ്, അവർ ആദ്യം പ്രത്യക്ഷപ്പെട്ടത് എന്തുകൊണ്ടാണെന്ന് മനസ്സിലാക്കേണ്ടതാണ്. ഇത് ചെയ്യുന്നതിന്, Realm എന്താണെന്ന് നമുക്ക് ഓർക്കാം.

Realm ഒരു നോൺ റിലേഷണൽ ഡാറ്റാബേസ് ആണ്. Android-ലെ എത്ര ORM റിലേഷണൽ ഡാറ്റാബേസുകൾ വിവരിച്ചിരിക്കുന്നു എന്നതിന് സമാനമായി ഒബ്‌ജക്റ്റുകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ വിവരിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. അതേ സമയം, ഏറ്റവും കുറഞ്ഞ പരിവർത്തനങ്ങളും മാപ്പിംഗുകളും ഉള്ള ഒബ്ജക്റ്റുകൾ മെമ്മറിയിൽ നേരിട്ട് Realm സംഭരിക്കുന്നു. ഡിസ്കിൽ നിന്നുള്ള ഡാറ്റ വളരെ വേഗത്തിൽ വായിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, ഇത് Realm-ന്റെ ശക്തിയാണ്, എന്തുകൊണ്ട് അത് പ്രിയപ്പെട്ടതാണ്.

(ഈ ലേഖനത്തിന്റെ ആവശ്യങ്ങൾക്ക്, ഈ വിവരണം ഞങ്ങൾക്ക് മതിയാകും. നിങ്ങൾക്ക് Realm-നെ കുറിച്ച് കൂടുതൽ വായിക്കാം. പ്രമാണീകരണം അല്ലെങ്കിൽ അവരുടെ അക്കാദമി).

പല ഡെവലപ്പർമാരും റിലേഷണൽ ഡാറ്റാബേസുകളിൽ കൂടുതൽ പ്രവർത്തിക്കാൻ ശീലിച്ചിരിക്കുന്നു (ഉദാഹരണത്തിന്, ഹൂഡിന് കീഴിലുള്ള SQL ഉള്ള ORM ഡാറ്റാബേസുകൾ). കാസ്‌കേഡിംഗ് ഡാറ്റ ഇല്ലാതാക്കൽ പോലെയുള്ള കാര്യങ്ങൾ പലപ്പോഴും നൽകിയിരിക്കുന്നതായി തോന്നുന്നു. എന്നാൽ മണ്ഡലത്തിലല്ല.

വഴിയിൽ, കാസ്കേഡ് ഇല്ലാതാക്കൽ സവിശേഷത വളരെക്കാലമായി ആവശ്യപ്പെട്ടിരുന്നു. ഈ പുനരവലോകനം и മറ്റൊന്ന്, അതുമായി ബന്ധപ്പെട്ടത്, സജീവമായി ചർച്ച ചെയ്യപ്പെട്ടു. വൈകാതെ അത് നടക്കുമെന്ന തോന്നലുണ്ടായി. എന്നാൽ പിന്നീട് എല്ലാം ശക്തവും ദുർബലവുമായ ലിങ്കുകളുടെ ആമുഖത്തിലേക്ക് വിവർത്തനം ചെയ്യപ്പെട്ടു, അത് ഈ പ്രശ്നം യാന്ത്രികമായി പരിഹരിക്കും. ഈ ദൗത്യത്തിൽ വളരെ സജീവവും സജീവവുമായിരുന്നു അഭ്യർത്ഥന വലിക്കുക, ആന്തരിക ബുദ്ധിമുട്ടുകൾ കാരണം ഇപ്പോൾ താൽക്കാലികമായി നിർത്തി.

കാസ്കേഡിംഗ് ഇല്ലാതാക്കാതെ ഡാറ്റ ചോർച്ച

നിങ്ങൾ നിലവിലില്ലാത്ത കാസ്‌കേഡിംഗ് ഡിലീറ്റിനെ ആശ്രയിക്കുകയാണെങ്കിൽ കൃത്യമായി എങ്ങനെയാണ് ഡാറ്റ ചോർത്തുന്നത്? നിങ്ങൾ 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). ലിസ്റ്റുചെയ്ത എല്ലാ ഫീൽഡുകളും Realm ഒബ്ജക്റ്റുകളാണ്. അതേ ഐഡിയിൽ ഞങ്ങൾ ഒരു പുതിയ ഒബ്‌ജക്റ്റ് (copyToRealm() / copyToRealmOrUpdate()) ചേർത്താൽ, ഈ ഒബ്‌ജക്റ്റ് പൂർണ്ണമായും തിരുത്തിയെഴുതപ്പെടും. എന്നാൽ എല്ലാ ആന്തരിക ഒബ്‌ജക്‌റ്റുകളും (ചിത്രം, ഇഷ്‌ടാനുസൃതമാക്കൽ എന്റിറ്റി, 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()
}
// и потом уже сохраняем

നിങ്ങൾ ഇത് ചെയ്യുകയാണെങ്കിൽ, എല്ലാം ശരിയായി പ്രവർത്തിക്കും. ഈ ഉദാഹരണത്തിൽ, ഇമേജ്, ഇഷ്‌ടാനുസൃതമാക്കൽ എന്റിറ്റി, cartComboProducts എന്നിവയ്‌ക്കുള്ളിൽ മറ്റ് നെസ്റ്റഡ് Realm ഒബ്‌ജക്‌റ്റുകൾ ഇല്ലെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു, അതിനാൽ മറ്റ് നെസ്റ്റഡ് ലൂപ്പുകളും ഡിലീറ്റുകളും ഇല്ല.

"വേഗത്തിലുള്ള" പരിഹാരം

ഞങ്ങൾ ആദ്യം ചെയ്യാൻ തീരുമാനിച്ചത് അതിവേഗം വളരുന്ന വസ്തുക്കളെ വൃത്തിയാക്കുകയും ഇത് ഞങ്ങളുടെ യഥാർത്ഥ പ്രശ്‌നം പരിഹരിക്കുമോയെന്നറിയാൻ ഫലങ്ങൾ പരിശോധിക്കുകയുമാണ്. ആദ്യം, ഏറ്റവും ലളിതവും അവബോധജന്യവുമായ പരിഹാരം ഉണ്ടാക്കി, അതായത്: ഓരോ വസ്തുവും അതിന്റെ കുട്ടികളെ നീക്കംചെയ്യുന്നതിന് ഉത്തരവാദിയായിരിക്കണം. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഒരു ഇന്റർഫേസ് അവതരിപ്പിച്ചു, അത് അതിന്റെ നെസ്റ്റഡ് Realm ഒബ്‌ജക്റ്റുകളുടെ ഒരു ലിസ്റ്റ് നൽകുന്നു:

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

ഞങ്ങളുടെ Realm ഒബ്‌ജക്‌റ്റുകളിൽ ഞങ്ങൾ ഇത് നടപ്പിലാക്കി:

@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-ൽ ഡാറ്റ കാഷിംഗ് വളരെ സജീവമായി ഉപയോഗിക്കുന്നു. അതിനാൽ, ഓരോ ഒബ്‌ജക്റ്റിനും എല്ലാ നെസ്റ്റഡ് ഒബ്‌ജക്റ്റുകളും എഴുതുന്നത് അധ്വാനമാണ്, കൂടാതെ പിശകുകളുടെ അപകടസാധ്യത വർദ്ധിക്കുന്നു, കാരണം കോഡ് മാറ്റുമ്പോൾ ഒബ്‌ജക്റ്റുകൾ വ്യക്തമാക്കാൻ നിങ്ങൾക്ക് മറക്കാം.

ഞാൻ ഇന്റർഫേസുകൾ ഉപയോഗിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ ഞാൻ ആഗ്രഹിച്ചു, എന്നാൽ എല്ലാം സ്വന്തമായി പ്രവർത്തിക്കുന്നു.

എന്തെങ്കിലും സ്വന്തമായി പ്രവർത്തിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ, നാം പ്രതിഫലനം ഉപയോഗിക്കേണ്ടതുണ്ട്. ഇത് ചെയ്യുന്നതിന്, നമുക്ക് ഓരോ ക്ലാസ് ഫീൽഡിലൂടെയും പോയി ഇത് ഒരു 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 പ്രതിഫലനത്തിലൂടെ, അത് എല്ലാ നെസ്റ്റഡ് Realm ഒബ്ജക്റ്റുകളും കണ്ടെത്തുകയും അവയെ ഒരു രേഖീയ പട്ടികയിൽ ഉൾപ്പെടുത്തുകയും ചെയ്യുന്നു. അപ്പോൾ നമ്മൾ അതേ കാര്യം ആവർത്തിച്ച് ചെയ്യുന്നു. ഇല്ലാതാക്കുമ്പോൾ, സാധുതയ്ക്കായി നിങ്ങൾ ഒബ്ജക്റ്റ് പരിശോധിക്കേണ്ടതുണ്ട് 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 സെക്കൻഡിൽ കൂടുതലാണെങ്കിൽ, സ്ഥിരസ്ഥിതിയായി, Firebase അറിയിപ്പുകൾ അയയ്‌ക്കുന്നു എന്നതും ചേർക്കേണ്ടതാണ്. എന്നിരുന്നാലും, ഞങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, നിങ്ങൾ ഇതിൽ ആശ്രയിക്കരുത്, പകരം അകത്ത് പോയി അത് വ്യക്തമായി പരിശോധിക്കുക.

Realm ഡാറ്റാബേസിന്റെ പ്രത്യേകത അത് ഒരു നോൺ റിലേഷണൽ ഡാറ്റാബേസ് ആണ് എന്നതാണ്. ഉപയോഗത്തിന്റെ എളുപ്പവും ORM സൊല്യൂഷനുകളുമായുള്ള സാമ്യവും ഒബ്ജക്റ്റ് ലിങ്കിംഗും ഉണ്ടെങ്കിലും, ഇതിന് കാസ്കേഡ് ഇല്ലാതാക്കൽ ഇല്ല.

ഇത് കണക്കിലെടുക്കുന്നില്ലെങ്കിൽ, നെസ്റ്റഡ് വസ്തുക്കൾ അടിഞ്ഞുകൂടുകയും "ചോർന്നുപോകുകയും ചെയ്യും." ഡാറ്റാബേസ് നിരന്തരം വളരും, ഇത് ആപ്ലിക്കേഷന്റെ സ്ലോഡൗൺ അല്ലെങ്കിൽ സ്റ്റാർട്ടപ്പിനെ ബാധിക്കും.

റിയൽമിലെ ഒബ്‌ജക്‌റ്റുകളുടെ ഒരു കാസ്‌കേഡ് ഇല്ലാതാക്കൽ എങ്ങനെ വേഗത്തിൽ ചെയ്യാമെന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അനുഭവം ഞാൻ പങ്കിട്ടു, അത് ഇതുവരെ ബോക്‌സിന് പുറത്തായിട്ടില്ല, എന്നാൽ വളരെക്കാലമായി സംസാരിക്കുന്നു പറയുക и പറയുക. ഞങ്ങളുടെ കാര്യത്തിൽ, ഇത് ആപ്ലിക്കേഷൻ സ്റ്റാർട്ടപ്പ് സമയത്തെ വളരെയധികം വേഗത്തിലാക്കി.

ഈ സവിശേഷതയുടെ ആസന്നമായ രൂപത്തെക്കുറിച്ചുള്ള ചർച്ചകൾക്കിടയിലും, Realm-ൽ കാസ്കേഡ് ഇല്ലാതാക്കലിന്റെ അഭാവം ഡിസൈൻ വഴിയാണ് ചെയ്യുന്നത്. നിങ്ങൾ ഒരു പുതിയ ആപ്ലിക്കേഷൻ രൂപകൽപ്പന ചെയ്യുകയാണെങ്കിൽ, ഇത് കണക്കിലെടുക്കുക. നിങ്ങൾ ഇതിനകം Realm ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അത്തരം പ്രശ്‌നങ്ങളുണ്ടോയെന്ന് പരിശോധിക്കുക.

അവലംബം: www.habr.com