કેવી રીતે રિયલમમાં કાસ્કેડ કાઢી નાખવાની વાર્તા લાંબા લૉન્ચ પર જીતી ગઈ

બધા વપરાશકર્તાઓ મોબાઇલ એપ્લિકેશન્સમાં ઝડપી લોંચ અને પ્રતિભાવશીલ UI ને માન્ય રાખે છે. જો એપ્લિકેશન લોન્ચ થવામાં લાંબો સમય લે છે, તો વપરાશકર્તા ઉદાસી અને ગુસ્સે થવા લાગે છે. તમે ગ્રાહકના અનુભવને સરળતાથી બગાડી શકો છો અથવા વપરાશકર્તા એપ્લિકેશનનો ઉપયોગ કરવાનું શરૂ કરે તે પહેલાં જ તેને સંપૂર્ણપણે ગુમાવી શકો છો.

અમે એકવાર શોધ્યું કે ડોડો પિઝા એપને સરેરાશ લોન્ચ થવામાં 3 સેકન્ડનો સમય લાગે છે અને કેટલાક "નસીબદાર લોકો" માટે તે 15-20 સેકન્ડ લે છે.

કટની નીચે સુખદ અંત સાથેની વાર્તા છે: રિયલમ ડેટાબેઝની વૃદ્ધિ વિશે, મેમરી લીક વિશે, અમે કેવી રીતે નેસ્ટેડ ઑબ્જેક્ટ્સ એકઠા કર્યા, અને પછી અમારી જાતને એકસાથે ખેંચી અને બધું ઠીક કર્યું.

લેખ લેખક: મેક્સિમ કાચિનકીન - ડોડો પિઝા ખાતે એન્ડ્રોઇડ ડેવલપર.

એપ્લીકેશન આયકન પર ક્લિક કરવાથી ઓનરેઝ્યુમ() સુધીની પ્રથમ પ્રવૃત્તિની ત્રણ સેકન્ડ અનંત છે. અને કેટલાક વપરાશકર્તાઓ માટે, સ્ટાર્ટઅપ સમય 15-20 સેકંડ સુધી પહોંચ્યો. આ પણ કેવી રીતે શક્ય છે?

જેમની પાસે વાંચવાનો સમય નથી તેમના માટે ખૂબ જ ટૂંકો સારાંશ
અમારું ક્ષેત્ર ડેટાબેઝ અવિરતપણે વધ્યું. કેટલાક નેસ્ટેડ ઑબ્જેક્ટ્સ કાઢી નાખવામાં આવ્યા ન હતા, પરંતુ સતત સંચિત થયા હતા. એપ્લિકેશન શરૂ થવાનો સમય ધીમે ધીમે વધતો ગયો. પછી અમે તેને ઠીક કર્યું, અને સ્ટાર્ટઅપનો સમય લક્ષ્ય પર આવ્યો - તે 1 સેકંડથી ઓછો થઈ ગયો અને હવે વધ્યો નહીં. લેખમાં પરિસ્થિતિનું વિશ્લેષણ અને બે ઉકેલો છે - એક ઝડપી અને સામાન્ય.

સમસ્યાની શોધ અને વિશ્લેષણ

આજે, કોઈપણ મોબાઇલ એપ્લિકેશન ઝડપથી શરૂ થવી જોઈએ અને પ્રતિભાવશીલ હોવી જોઈએ. પરંતુ તે માત્ર મોબાઇલ એપ્લિકેશન વિશે નથી. સેવા અને કંપની સાથેની ક્રિયાપ્રતિક્રિયાનો વપરાશકર્તા અનુભવ એ એક જટિલ બાબત છે. ઉદાહરણ તરીકે, અમારા કિસ્સામાં, ડિલિવરીની ઝડપ એ પિઝા સેવા માટેના મુખ્ય સૂચકોમાંનું એક છે. જો ડિલિવરી ઝડપી છે, તો પિઝા ગરમ થશે, અને જે ગ્રાહક હવે ખાવા માંગે છે તેણે વધુ રાહ જોવી પડશે નહીં. એપ્લિકેશન માટે, બદલામાં, ઝડપી સેવાની અનુભૂતિ કરવી મહત્વપૂર્ણ છે, કારણ કે જો એપ્લિકેશનને લોન્ચ કરવામાં માત્ર 20 સેકન્ડનો સમય લાગે છે, તો તમારે પિઝા માટે કેટલો સમય રાહ જોવી પડશે?

શરૂઆતમાં, અમે પોતે જ એ હકીકતનો સામનો કરી રહ્યા હતા કે કેટલીકવાર એપ્લિકેશનને લોન્ચ કરવામાં થોડી સેકંડ લાગી, અને પછી અમને અન્ય સાથીદારોની ફરિયાદો સાંભળવા લાગી કે તે કેટલો સમય લે છે. પરંતુ અમે આ પરિસ્થિતિનું સતત પુનરાવર્તન કરવામાં અસમર્થ હતા.

તે કેટલો સમય છે? અનુસાર Google દસ્તાવેજીકરણ, જો એપ્લિકેશનની કોલ્ડ સ્ટાર્ટમાં 5 સેકન્ડથી ઓછો સમય લાગે છે, તો તેને "સામાન્ય તરીકે" ગણવામાં આવે છે. ડોડો પિઝા એન્ડ્રોઇડ એપ લોન્ચ કરવામાં આવી છે (ફાયરબેસ મેટ્રિક્સ અનુસાર _app_start) ખાતે ઠંડી શરૂઆત સરેરાશ 3 સેકન્ડમાં - "મહાન નથી, ભયંકર નથી," જેમ તેઓ કહે છે.

પરંતુ પછી ફરિયાદો દેખાવા લાગી કે એપ્લિકેશનને લોન્ચ કરવામાં ખૂબ જ, ખૂબ જ લાંબો સમય લાગ્યો! શરૂઆતમાં, અમે "ખૂબ, ખૂબ, ખૂબ લાંબુ" શું છે તે માપવાનું નક્કી કર્યું. અને અમે આ માટે ફાયરબેઝ ટ્રેસનો ઉપયોગ કર્યો એપ્લિકેશન પ્રારંભ ટ્રેસ.

આ પ્રમાણભૂત ટ્રેસ વપરાશકર્તા એપ્લિકેશન ખોલે તે ક્ષણ અને પ્રથમ પ્રવૃત્તિની onResume() એક્ઝિક્યુટ થાય તે ક્ષણ વચ્ચેના સમયને માપે છે. ફાયરબેઝ કન્સોલમાં આ મેટ્રિકને _app_start કહેવામાં આવે છે. તે બહાર આવ્યું છે કે:

• સરેરાશ કોલ્ડ સ્ટાર્ટઅપ સમય 95 સેકન્ડથી ઓછો હોવા છતાં, 20મી પર્સેન્ટાઇલથી ઉપરના વપરાશકર્તાઓ માટે સ્ટાર્ટઅપ સમય લગભગ 5 સેકન્ડ (કેટલાક વધુ લાંબો) છે.
• સ્ટાર્ટઅપ સમય એ સતત મૂલ્ય નથી, પરંતુ સમય સાથે વધે છે. પરંતુ કેટલીકવાર ટીપાં હોય છે. જ્યારે અમે વિશ્લેષણનો સ્કેલ વધારીને 90 દિવસ કર્યો ત્યારે અમને આ પેટર્ન મળી.

મનમાં બે વિચારો આવ્યા:

1. કંઈક લીક થઈ રહ્યું છે.
2. આ "કંઈક" પ્રકાશન પછી રીસેટ થાય છે અને પછી ફરીથી લીક થાય છે.

"કદાચ ડેટાબેઝ સાથે કંઈક," અમે વિચાર્યું, અને અમે સાચા હતા. સૌપ્રથમ, અમે કેશ તરીકે ડેટાબેઝનો ઉપયોગ કરીએ છીએ; સ્થળાંતર દરમિયાન અમે તેને સાફ કરીએ છીએ. બીજું, જ્યારે એપ્લિકેશન શરૂ થાય છે ત્યારે ડેટાબેઝ લોડ થાય છે. બધું એકસાથે બંધબેસે છે.

Realm ડેટાબેઝમાં શું ખોટું છે

અમે તપાસવાનું શરૂ કર્યું કે ડેટાબેઝની સામગ્રી પ્રથમ ઇન્સ્ટોલેશનથી અને સક્રિય ઉપયોગ દરમિયાન એપ્લિકેશનના જીવન દરમિયાન કેવી રીતે બદલાય છે. તમે રિયલમ ડેટાબેઝની સામગ્રીઓ દ્વારા જોઈ શકો છો સ્ટેથો અથવા વધુ વિગતવાર અને સ્પષ્ટ રીતે ફાઇલ ખોલીને ક્ષેત્ર સ્ટુડિયો. ADB દ્વારા ડેટાબેઝની સામગ્રી જોવા માટે, Realm ડેટાબેઝ ફાઇલની નકલ કરો:

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

અલગ-અલગ સમયે ડેટાબેઝની સામગ્રીઓ જોયા પછી, અમને જાણવા મળ્યું કે ચોક્કસ પ્રકારની વસ્તુઓની સંખ્યા સતત વધી રહી છે.

ચિત્ર બે ફાઇલો માટે રિયલમ સ્ટુડિયોનો ટુકડો બતાવે છે: ડાબી બાજુએ - ઇન્સ્ટોલેશન પછી થોડા સમય પછી એપ્લિકેશનનો આધાર, જમણી બાજુએ - સક્રિય ઉપયોગ પછી. તે જોઈ શકાય છે કે વસ્તુઓની સંખ્યા ImageEntity и MoneyType નોંધપાત્ર રીતે વૃદ્ધિ પામી છે (સ્ક્રીનશોટ દરેક પ્રકારની વસ્તુઓની સંખ્યા બતાવે છે).

ડેટાબેઝ વૃદ્ધિ અને સ્ટાર્ટઅપ સમય વચ્ચેનો સંબંધ

અનિયંત્રિત ડેટાબેઝ વૃદ્ધિ ખૂબ જ ખરાબ છે. પરંતુ આ એપ્લિકેશન સ્ટાર્ટઅપ સમયને કેવી રીતે અસર કરે છે? એક્ટિવિટી મેનેજર દ્વારા આને માપવું એકદમ સરળ છે. એન્ડ્રોઇડ 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 સુધી વધી હતી. કુલ મળીને, તે તારણ આપે છે કે સમય જતાં (ઠંડાની શરૂઆતની વૃદ્ધિ સાથે), એપ્લિકેશન લોંચ થવાનો સમય અને ડેટાબેઝનું કદ બંનેમાં વધારો થયો છે. અમારા હાથ પર એક પૂર્વધારણા છે. હવે જે બાકી હતું તે અવલંબનની પુષ્ટિ કરવાનું હતું. તેથી, અમે "લીક્સ" દૂર કરવાનું નક્કી કર્યું અને જુઓ કે શું આનાથી લોંચને વેગ મળશે.

અનંત ડેટાબેઝ વૃદ્ધિ માટેનાં કારણો

"લીક્સ" ને દૂર કરતા પહેલા, તે સમજવું યોગ્ય છે કે તેઓ શા માટે પ્રથમ સ્થાને દેખાયા. આ કરવા માટે, ચાલો યાદ કરીએ કે ક્ષેત્ર શું છે.

ક્ષેત્ર એ બિન-સંબંધિત ડેટાબેઝ છે. તે તમને ઑબ્જેક્ટ્સ વચ્ચેના સંબંધોને Android પર કેટલા ORM રિલેશનલ ડેટાબેસેસ વર્ણવવામાં આવ્યા છે તે જ રીતે વર્ણવવાની મંજૂરી આપે છે. તે જ સમયે, રિયલમ ઓછામાં ઓછા રૂપાંતરણો અને મેપિંગ્સ સાથે ઑબ્જેક્ટ્સને સીધી મેમરીમાં સ્ટોર કરે છે. આ તમને ડિસ્કમાંથી ડેટાને ખૂબ જ ઝડપથી વાંચવાની મંજૂરી આપે છે, જે ક્ષેત્રની શક્તિ છે અને તે શા માટે પ્રિય છે.

(આ લેખના હેતુઓ માટે, આ વર્ણન અમારા માટે પૂરતું હશે. તમે કૂલમાં ક્ષેત્ર વિશે વધુ વાંચી શકો છો દસ્તાવેજીકરણ અથવા તેમનામાં અકાદમી).

ઘણા વિકાસકર્તાઓ રિલેશનલ ડેટાબેસેસ (ઉદાહરણ તરીકે, હૂડ હેઠળ 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). બધા સૂચિબદ્ધ ક્ષેત્રો ક્ષેત્ર પદાર્થો છે. જો આપણે એ જ આઈડી સાથે નવો ઑબ્જેક્ટ (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, કારણ કે એવું બની શકે છે કે અલગ-અલગ પેરેન્ટ ઑબ્જેક્ટમાં સમાન નેસ્ટેડ હોય શકે છે. આને ટાળવું વધુ સારું છે અને નવા ઑબ્જેક્ટ બનાવતી વખતે 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 નવા લખતા પહેલા તમામ એકત્રિત વસ્તુઓને વારંવાર કાઢી નાખે છે. અમે સમગ્ર એપ્લિકેશન દરમિયાન આ અભિગમનો ઉપયોગ કરીએ છીએ. ક્ષેત્રમાં મેમરી લિક સંપૂર્ણપણે અદૃશ્ય થઈ ગઈ છે. એપ્લિકેશનની કોલ્ડ સ્ટાર્ટ્સની સંખ્યા પર સ્ટાર્ટઅપ સમયની અવલંબનનું સમાન માપન કર્યા પછી, અમે પરિણામ જોઈએ છીએ.

ગ્રીન લાઇન નેસ્ટેડ ઑબ્જેક્ટના સ્વચાલિત કાસ્કેડ કાઢી નાખવા દરમિયાન કોલ્ડ સ્ટાર્ટ્સની સંખ્યા પર એપ્લિકેશન સ્ટાર્ટઅપ સમયની નિર્ભરતા દર્શાવે છે.

પરિણામો અને તારણો

સતત વિકસતા રિયલમ ડેટાબેઝને કારણે એપ્લીકેશન ખૂબ જ ધીમી ગતિએ શરૂ થઈ રહી હતી. અમે નેસ્ટેડ ઑબ્જેક્ટના અમારા પોતાના "કાસ્કેડિંગ ડિલીટ" સાથે અપડેટ રિલીઝ કર્યું છે. અને હવે અમે _app_start મેટ્રિક દ્વારા અમારા નિર્ણયથી એપ્લિકેશન સ્ટાર્ટઅપ સમયને કેવી રીતે અસર થઈ તેનું અમે નિરીક્ષણ અને મૂલ્યાંકન કરીએ છીએ.

વિશ્લેષણ માટે, અમે 90 દિવસનો સમયગાળો લઈએ છીએ અને જુઓ: એપ્લિકેશન લોંચ થવાનો સમય, સરેરાશ અને જે વપરાશકર્તાઓની 95મી પર્સેન્ટાઈલ પર આવે છે, તે ઘટવા લાગ્યું અને હવે વધતું નથી.

જો તમે સાત-દિવસના ચાર્ટ પર નજર નાખો, તો _app_start મેટ્રિક સંપૂર્ણપણે પર્યાપ્ત લાગે છે અને તે 1 સેકન્ડથી ઓછી છે.

તે ઉમેરવું પણ યોગ્ય છે કે ડિફૉલ્ટ રૂપે, જો _app_start નું સરેરાશ મૂલ્ય 5 સેકન્ડ કરતાં વધી જાય તો Firebase સૂચનાઓ મોકલે છે. જો કે, જેમ આપણે જોઈ શકીએ છીએ, તમારે આના પર આધાર રાખવો જોઈએ નહીં, પરંતુ અંદર જાઓ અને તેને સ્પષ્ટપણે તપાસો.

રિયલમ ડેટાબેઝની ખાસ વાત એ છે કે તે નોન-રિલેશનલ ડેટાબેઝ છે. ઉપયોગમાં સરળતા, ORM સોલ્યુશન્સ અને ઑબ્જેક્ટ લિંકિંગની સમાનતા હોવા છતાં, તેમાં કાસ્કેડ કાઢી નાખવામાં આવતું નથી.

જો આને ધ્યાનમાં લેવામાં નહીં આવે, તો નેસ્ટેડ ઑબ્જેક્ટ્સ એકઠા થશે અને "લીક થઈ જશે." ડેટાબેઝ સતત વધશે, જે બદલામાં એપ્લિકેશનના મંદી અથવા સ્ટાર્ટઅપને અસર કરશે.

મેં રિયલમમાં ઑબ્જેક્ટ્સને ઝડપથી કેવી રીતે કાસ્કેડ ડિલીટ કરવું તે અંગેનો અમારો અનુભવ શેર કર્યો, જે હજી સુધી બોક્સની બહાર નથી, પરંતુ લાંબા સમયથી તેના વિશે વાત કરવામાં આવી રહી છે. તેઓ કહે છે и તેઓ કહે છે. અમારા કિસ્સામાં, આનાથી એપ્લીકેશન સ્ટાર્ટઅપનો સમય ખૂબ જ ઝડપી બન્યો.

આ સુવિધાના નિકટવર્તી દેખાવ વિશે ચર્ચા હોવા છતાં, ક્ષેત્રમાં કાસ્કેડ કાઢી નાખવાની ગેરહાજરી ડિઝાઇન દ્વારા કરવામાં આવે છે. જો તમે નવી એપ્લિકેશન ડિઝાઇન કરી રહ્યા છો, તો આને ધ્યાનમાં લો. અને જો તમે પહેલેથી જ Realm નો ઉપયોગ કરી રહ્યા છો, તો તપાસો કે તમને આવી સમસ્યાઓ છે કે નહીં.

સોર્સ: www.habr.com