রিয়েলমের দীর্ঘ লঞ্চে ক্যাসকেডিং মুছে ফেলার গল্পটি কীভাবে জিতেছে

সমস্ত ব্যবহারকারীরা মোবাইল অ্যাপ্লিকেশনগুলিতে দ্রুত লঞ্চ এবং প্রতিক্রিয়াশীল UI গ্রহণ করে। যদি অ্যাপ্লিকেশনটি চালু হতে দীর্ঘ সময় নেয় তবে ব্যবহারকারী দুঃখিত এবং রাগান্বিত বোধ করতে শুরু করে। আপনি সহজেই গ্রাহকের অভিজ্ঞতা লুণ্ঠন করতে পারেন বা ব্যবহারকারীকে সম্পূর্ণরূপে হারাতে পারেন এমনকি তিনি অ্যাপ্লিকেশনটি ব্যবহার শুরু করার আগেই৷

আমরা একবার আবিষ্কার করেছি যে Dodo Pizza অ্যাপটি চালু হতে গড়ে 3 সেকেন্ড সময় নেয় এবং কিছু "ভাগ্যবানদের" জন্য এটি 15-20 সেকেন্ড সময় নেয়।

কাটের নীচে একটি সুখী সমাপ্তি সহ একটি গল্প রয়েছে: রিয়েলম ডাটাবেসের বৃদ্ধি সম্পর্কে, একটি মেমরি লিক, কীভাবে আমরা নেস্টেড অবজেক্টগুলি সংগ্রহ করেছি এবং তারপরে নিজেদেরকে একসাথে টেনে নিয়েছি এবং সবকিছু ঠিক করেছি।

প্রবন্ধ লেখক: ম্যাক্সিম কাচিনকিন — ডোডো পিজ্জাতে অ্যান্ড্রয়েড বিকাশকারী।

অ্যাপ্লিকেশান আইকনে ক্লিক করার তিন সেকেন্ডের মধ্যে প্রথম অ্যাক্টিভিটির অনরিজুম() ইনফিনিটি। এবং কিছু ব্যবহারকারীদের জন্য, স্টার্টআপ সময় 15-20 সেকেন্ডে পৌঁছেছে। এটা কিভাবে সম্ভব?

যাদের পড়ার সময় নেই তাদের জন্য একটি খুব সংক্ষিপ্ত সারাংশ
আমাদের রাজ্যের ডাটাবেস অবিরাম বৃদ্ধি পেয়েছে। কিছু নেস্টেড অবজেক্ট মুছে ফেলা হয়নি, কিন্তু ক্রমাগত জমা হয়েছে। অ্যাপ্লিকেশন শুরুর সময় ধীরে ধীরে বৃদ্ধি পায়। তারপরে আমরা এটি ঠিক করেছি, এবং স্টার্টআপের সময় টার্গেটে এসেছে - এটি 1 সেকেন্ডের কম হয়ে গেছে এবং আর বাড়েনি। নিবন্ধটিতে পরিস্থিতির বিশ্লেষণ এবং দুটি সমাধান রয়েছে - একটি দ্রুত এবং একটি সাধারণ।

অনুসন্ধান এবং সমস্যা বিশ্লেষণ

আজ, যে কোনো মোবাইল অ্যাপ্লিকেশন দ্রুত লঞ্চ এবং প্রতিক্রিয়াশীল হতে হবে। কিন্তু এটা শুধু মোবাইল অ্যাপের কথা নয়। একটি পরিষেবা এবং একটি কোম্পানির সাথে মিথস্ক্রিয়া ব্যবহারকারীর অভিজ্ঞতা একটি জটিল জিনিস। উদাহরণস্বরূপ, আমাদের ক্ষেত্রে, ডেলিভারির গতি হল পিৎজা পরিষেবার অন্যতম প্রধান সূচক। যদি ডেলিভারি দ্রুত হয়, তাহলে পিজ্জা গরম হবে, এবং যে গ্রাহক এখন খেতে চান তাদের বেশিক্ষণ অপেক্ষা করতে হবে না। অ্যাপ্লিকেশনটির জন্য, পরিবর্তে, দ্রুত পরিষেবার অনুভূতি তৈরি করা গুরুত্বপূর্ণ, কারণ অ্যাপ্লিকেশনটি চালু হতে যদি মাত্র 20 সেকেন্ড সময় লাগে, তবে আপনাকে পিজ্জার জন্য কতক্ষণ অপেক্ষা করতে হবে?

প্রথমে, আমরা নিজেরাই এই সত্যটির মুখোমুখি হয়েছিলাম যে কখনও কখনও অ্যাপ্লিকেশনটি চালু হতে কয়েক সেকেন্ড সময় নেয় এবং তারপরে আমরা অন্যান্য সহকর্মীদের কাছ থেকে অভিযোগ শুনতে শুরু করি যে এটি কত সময় নেয়। কিন্তু আমরা ধারাবাহিকভাবে এই পরিস্থিতির পুনরাবৃত্তি করতে পারিনি।

এটা কতক্ষণ? অনুসারে গুগল ডকুমেন্টেশন, যদি একটি অ্যাপ্লিকেশনের ঠান্ডা শুরুতে 5 সেকেন্ডের কম সময় লাগে, তাহলে এটিকে "স্বাভাবিক হিসাবে" হিসাবে বিবেচনা করা হয়। Dodo Pizza Android অ্যাপ চালু হয়েছে (Firebase মেট্রিক্স অনুযায়ী _অ্যাপ_শুরু) এ ঠান্ডা শুরু গড়ে 3 সেকেন্ডে - "মহান নয়, ভয়ানক নয়," যেমন তারা বলে।

কিন্তু তারপরে অভিযোগ আসতে শুরু করে যে অ্যাপ্লিকেশনটি চালু হতে খুব, খুব, খুব দীর্ঘ সময় লেগেছে! শুরু করার জন্য, আমরা "খুব, খুব, খুব দীর্ঘ" কী তা পরিমাপ করার সিদ্ধান্ত নিয়েছি। এবং আমরা এর জন্য ফায়ারবেস ট্রেস ব্যবহার করেছি অ্যাপ্লিকেশন শুরু ট্রেস.

এই স্ট্যান্ডার্ড ট্রেস ব্যবহারকারী অ্যাপ্লিকেশনটি খোলার মুহুর্ত এবং প্রথম কার্যকলাপের onResume() সম্পাদিত হওয়ার মুহুর্তের মধ্যে সময় পরিমাপ করে। Firebase কনসোলে এই মেট্রিকটিকে _app_start বলা হয়। এটা প্রমাণিত যে:

• 95 তম পার্সেন্টাইলের উপরে ব্যবহারকারীদের জন্য স্টার্টআপ সময় প্রায় 20 সেকেন্ড (কিছু আরও বেশি), যদিও মাঝারি কোল্ড স্টার্টআপ সময় 5 সেকেন্ডের কম।
• স্টার্টআপ সময় একটি ধ্রুবক মান নয়, কিন্তু সময়ের সাথে বৃদ্ধি পায়। কিন্তু কখনও কখনও ফোঁটা আছে। আমরা এই প্যাটার্নটি খুঁজে পেয়েছি যখন আমরা বিশ্লেষণের স্কেল 90 দিনে বাড়িয়েছি।

দুটি চিন্তা মাথায় এল:

1. কিছু লিক হচ্ছে.
2. এই "কিছু" রিলিজের পরে রিসেট করা হয় এবং তারপর আবার লিক হয়।

"সম্ভবত ডাটাবেসের সাথে কিছু," আমরা ভেবেছিলাম, এবং আমরা ঠিক ছিলাম। প্রথমত, আমরা ডাটাবেসকে ক্যাশে হিসাবে ব্যবহার করি; মাইগ্রেশনের সময় আমরা এটি পরিষ্কার করি। দ্বিতীয়ত, অ্যাপ্লিকেশন শুরু হলে ডাটাবেস লোড হয়। সবকিছু মিলে যায়।

রিয়েলম ডাটাবেসের সাথে কি ভুল

আমরা প্রথম ইনস্টলেশন থেকে এবং সক্রিয় ব্যবহারের সময় অ্যাপ্লিকেশনের জীবনে কীভাবে ডাটাবেসের বিষয়বস্তু পরিবর্তিত হয় তা পরীক্ষা করতে শুরু করি। আপনি এর মাধ্যমে রিয়েলম ডাটাবেসের বিষয়বস্তু দেখতে পারেন স্টেথো অথবা আরও বিস্তারিতভাবে এবং স্পষ্টভাবে ফাইলটি খোলার মাধ্যমে রিয়েলম স্টুডিও. ADB এর মাধ্যমে ডাটাবেসের বিষয়বস্তু দেখতে, Realm ডাটাবেস ফাইলটি অনুলিপি করুন:

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

বিভিন্ন সময়ে ডাটাবেসের বিষয়বস্তু দেখে আমরা জানতে পেরেছি যে একটি নির্দিষ্ট ধরণের বস্তুর সংখ্যা ক্রমাগত বাড়ছে।

ছবিটি দুটি ফাইলের জন্য রিয়েলম স্টুডিওর একটি খণ্ড দেখায়: বামদিকে - ইনস্টলেশনের কিছু সময় পরে অ্যাপ্লিকেশন বেস, ডানদিকে - সক্রিয় ব্যবহারের পরে। এতে বস্তুর সংখ্যা দেখা যায় 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 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). সমস্ত তালিকাভুক্ত ক্ষেত্র হল Realm অবজেক্ট। যদি আমরা একই আইডি সহ একটি নতুন অবজেক্ট (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 ফিল্টার আউট এবং শুধুমাত্র Realm বস্তু পাস. পদ্ধতি getNestedRealmObjects প্রতিফলনের মাধ্যমে, এটি সমস্ত নেস্টেড রিয়েলম অবজেক্ট খুঁজে পায় এবং তাদের একটি রৈখিক তালিকায় রাখে। তারপর আমরা একই জিনিস recursively না. মুছে ফেলার সময়, আপনাকে বৈধতার জন্য বস্তুটি পরীক্ষা করতে হবে 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 সেকেন্ডের বেশি হলে Firebase বিজ্ঞপ্তি পাঠায়। যাইহোক, আমরা দেখতে পাচ্ছি, আপনার এটির উপর নির্ভর করা উচিত নয়, বরং ভিতরে যান এবং এটি স্পষ্টভাবে পরীক্ষা করুন।

Realm ডাটাবেস সম্পর্কে বিশেষ জিনিস হল এটি একটি অ-রিলেশনাল ডাটাবেস। ব্যবহারের সহজতা, ORM সমাধান এবং অবজেক্ট লিঙ্কিংয়ের সাথে সাদৃশ্য থাকা সত্ত্বেও, এটিতে ক্যাসকেড মুছে ফেলা নেই।

যদি এটি বিবেচনায় না নেওয়া হয়, তাহলে নেস্টেড অবজেক্টগুলি জমে যাবে এবং "ছিদ্র হয়ে যাবে।" ডাটাবেস ক্রমাগত বৃদ্ধি পাবে, যা ফলস্বরূপ অ্যাপ্লিকেশনটির ধীরগতি বা স্টার্টআপকে প্রভাবিত করবে।

আমি কীভাবে রিয়েলমে বস্তুর একটি ক্যাসকেড মুছে ফেলার বিষয়ে আমাদের অভিজ্ঞতা শেয়ার করেছি, যা এখনও বাক্সের বাইরে নয়, তবে দীর্ঘদিন ধরে কথা বলা হচ্ছে বলুন и বলুন. আমাদের ক্ষেত্রে, এটি অ্যাপ্লিকেশন স্টার্টআপের সময়কে ব্যাপকভাবে গতি বাড়িয়েছে।

এই বৈশিষ্ট্যের আসন্ন চেহারা সম্পর্কে আলোচনা সত্ত্বেও, Realm মধ্যে ক্যাসকেড মুছে ফেলার অনুপস্থিতি ডিজাইন দ্বারা সম্পন্ন করা হয়। আপনি যদি একটি নতুন অ্যাপ্লিকেশন ডিজাইন করছেন, তাহলে এটি বিবেচনায় নিন। এবং আপনি যদি ইতিমধ্যে Realm ব্যবহার করে থাকেন তবে আপনার এই ধরনের সমস্যা আছে কিনা তা পরীক্ষা করে দেখুন।

উত্স: www.habr.com