ডিভেলপমেন্টে লেগ করা — এটি কি, কারণ ও অপ্টিমাইজেশন পদ্ধতি

মোবাইল ডিভেলপমেন্টে “লেগ করা” মানে কি

লেগ করা একটি অনৌপচারিক পরিভাষা যা ব্যবহারকারীরা ব্যবহার করে ব্যক্তিগতভাবে ধীর অ্যাপ পরিবেশন বর্ণনা করতে। লেগের বিপরীতে, যা একটি নিরন্তর বিলম্ব হিসাবে প্রকাশ পায়, লেগ করা অনিয়মিত জমা যাওয়া নিয়ে গঠিত: অ্যাপটি কয়েক সেকেন্ড নির্ভুলভাবে কাজ করতে পারে ও তারপর হঠাৎ 1–3 সেকেন্ডের জন্য “চিন্তা করতে” পারে।

পরিঘটনার কারিগরিক বর্ণনা

প্রোফাইলিং দৃষ্টিকোণ থেকে, লেগ করা হারানো ফ্রেম (jank) এর একটি ধারাবাহিকতা হিসাবে প্রকাশ পায় যার শীর্ষ বিলম্ব 100 মিলিসেকেন্ড অতিক্রম করে। FPS গ্রাফে, এটি ধারদ্বারা পতন হিসাবে দেখায়: 60 → 20 → 55 → 10 ফ্রেম প্রতি সেকেন্ড। সমানভাবে কম FPS বিশিষ্ট লেগের বিপরীতে, লেগ করার স্পষ্ট পরিবর্তনশীলতা রয়েছে।

ব্যবহারকারী ধারণা

যখন একটি অ্যাপ লেগ করে, ব্যবহারকারী মন্থরতার যুক্তি বুঝতে পারে না: স্ক্রিন মোটামুটি স্ক্রল হতে পারে ও তারপর হঠাৎ এক সেকেন্ডের জন্য থেমে যেতে পারে। এটি হতাশার কারণ হয় ও অ্যাপের প্রতি আস্থা হ্রাস করে। Google এর মতে, 53% ব্যবহারকারী একটি সাইট বা অ্যাপ ত্যাগ করে যদি লোড হতে 3 সেকেন্ডের বেশি সময় লাগে।

অ্যাপে হঠাৎ ধীর হওয়ার কারণ

লেগ করার অনিয়মিত প্রকৃতি ইংগিত করে যে সমস্যাটি নিরন্তর ওভারলোডের পরিবর্তে ইভেন্ট-চালিত কারকের কারণে হয়। আসুন নির্দিষ্ট পরিদৃশ্যগুলি দেখি।

অবজেক্ট বন্টনের সময় GC বিরতি

Android এ, ART রানটাইমে, আবজরজন সংগ্রহ অ্যাপের সকল থ্রেড বন্ধ করে দেয়। যদি কোড অনেক অস্থায়ী অবজেক্ট তৈরি করে — উদাহরণস্বরূপ, প্রতিটি onBindViewHolder কলে কন্কাটেনেশনের মাধ্যমে একটি নতুন String তৈরি করা — GC অধিক বার চলে। হীপ আকার ও অবজেক্ট প্রজন্মের উপর নির্ভর করে একটি বিরতি 5–50 মিলিসেকেন্ড স্থায়ী হতে পারে। ব্যবহারকারী এটিকে হঠাৎ “চিন্তাশীলতা” হিসাবে অনুভব করে।

UI থ্রেডে সিংক্রোনাংস SQL ক্যোরি

Android এ Room ও iOS এ Core Data অ্যাসিংক্রোনাংস ক্যোরি সমর্থন করে, কিন্তু ডিভেলপাররা সরলতার জন্য প্রায়শই getValue() ডাকে বা runBlocking এর মাধ্যমে ক্যোরি চালায়। 10,000 সারির একটি টেবিলে জয়েনের সাথে একটি ভারী SELECT এ 200–500 মিলিসেকেন্ড লাগতে পারে, সেই সময়ের জন্য UI সম্পূর্ণরূপে অবরুদ্ধ করে।

ডাউনস্কেল ছাড়া ইমেজ ডিকোডিং

একটি ক্যামেরা ইমেজ (12 MP, 4000x3000 পিক্সেল) স্কেলিং ছাড়া লোড করতে Bitmap ডিকোডিংএ 200 মিলিসেকেন্ড পর্যন্ত লাগতে পারে। যদি ইমেজগুলি অ্যাসিংক্রোনাংসভাবে লোড করা হয় কিন্তু একটি সীমাবদ্ধ থ্রেড পূল ছাড়া, তবে যুগপত্বে 5–6 ডিকোড চালালে CPU ওভারলোড হতে পারে, যা স্থানান্তরিত মন্থরতা সৃষ্টি করে।

• Android — লূপে স্ট্রিং কন্কাটেনেশন, 㦹াট পাথে অবজেক্ট তৈরি, inSampleSize ছাড়া Bitmap
• iOS — বর্পিল সংখ্যক অবজেক্ট সহ অটোরিলিজ় পূল, স্কেলিং ছাড়া imageWithContentsOfFile, সিংক্রোনাংস URLSession
• ক্রস-প্লেটফর্ম — UI থ্রেডে JSON পার্সিং, সরভারের প্রতিক্রিয়ার জন্য অপেক্ষা করার সময় মূল থ্রেডে ডেটা লোড করা

Android ও iOS এ জমে যাওয়া নির্ণয় কিভাবে করবেন

অনিয়মিত মন্থরতা নির্ণয় নিরন্তর লেগ নির্ণয়ের চেয়ে কঠিন কারণ প্রতিটি চালুতে সমস্যাটি পুনরায় না-ও হতে পারে। দীর্ঘ সময় ধরে পরিসংখ্যান সংগ্রহ করা প্রয়োজন।

GC ইভেন্ট রিকর্ডিং সহ Memory Profiler

Android Studio Memory Profiler শুধু মেমরি ব্যবহারই নয়, GC ইভেন্টও দেখায়: ফ্রিকোয়েন্সি, ধরন (Concurrent, Full), ডেরেশন। নিষ্ক্রিয় অবস্থায় প্রতি 5 সেকেন্ডে একবারের বেশি GC হলে — এটি অত্যধিক আবন্টনের লক্ষণ। লেগ করার সময় একটি 㧉িপ ডাম্প নিলে কোন অবজেক্টগুলি মেমরি দখল করছে তা দেখা যায়।

Allocation Tracking সহ Xcode Instruments

iOS এ, অবজেক্ট তৈরি ও মুক্তি ট্রেক করতে Instruments এ Allocations টেমপ্লেট ব্যবহার করুন। জেনারেশন সক্ষম করুন — এগুলি আপনাকে কাজের মধ্যে 㧉িপ স্ন্যাপশট নিতে ও কোন অবজেক্টগুলি মেমরিতে থাকে তা দেখতে সহায়তা করে। যে স্থায়ী অবজেক্টগুলি মুক্ত হয় না, তারা মেমরি সংচয় ও পরবর্তী বিরতির উৎস।

Android এ JankStats API

JankStats একটি Android লাইব্রেরি যা রিয়াল টাইমে হারানো ফ্রেম মীট্রিক্স সংগ্রহ করে। এটি প্রত্যেক jank কে বর্তমান পরিদৃশ্যের (যেমন, “লিস্ট স্ক্রলিং”, “স্ক্রিন খোলা”) সাথে যুক্ত করে, যা দ্বারা কোন নির্দিষ্ট কাজটি লেগ করা ট্রিগার করে তা বোঝা সম্ভব হয়।

Android এ জমা যাওয়া ট্রেকিংয়ের জন্য JankStats সংযুক্তির উদাহরণ:

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

ধীর কাজ দূর করার পদ্ধতি

লেগ করা দূর করতে প্রতিটি কারণের জন্য নির্দিষ্ট কাজ প্রয়োজন। কোন সার্বজনীন সমাধান নেই — নির্দিষ্ট পরিবেশন প্রোফাইল বিশ্লেষণ প্রয়োজন।

Paging 3 এর মাধ্যমে পেজিনেশন বাস্তবায়ন

যদি একটি লিস্টে 1000+ আইটেম থাকে ও সকল একসাথে লোড করা হয় — এটি নিশ্চিত লেগ করা। Android এ Paging 3 ও iOS এ NSFetchedResultsController ব্যবহারকারী স্ক্রল করার সাথে ডেটা অংশে লোড করে। ব্যবহারকারী কেবল প্রথম 10–20 আইটেম দেখতে পান; বাকিগুলো পশ্চাত্ ভূমিতে লোড হয়।

SQL ক্যোরি ও ইন্ডেক্স অপ্টিমাইজ

Room Android Studio এর ইনস্পেকশন টুলের মাধ্যমে ক্যোরি প্রোফাইলিং করার অনুমতি দেয়: নিষ্পাদন সময়, ফিরিয়ে আনা সারির সংখ্যা ও ক্যোরি পরিকল্পনা দেখা যায়। WHERE ও ORDER BY কলামে ইন্ডেক্স যোগ করা ক্যোরি সময় 300 মিলিসেকেন্ড থেকে 5 মিলিসেকেন্ড কমাতে পারে। iOS এ, Instruments এ Core Data Profiler একটি অনুরূপ পরিক্ষা করে।

কাজ WorkManager এ সরানো

পশ্চাত্ ভূমির সিংক, ফাইল ডাউনলোড, ডেটা প্রক্রিয়া — এগুলো WorkManager (Android) বা Background Tasks (iOS) এর মাধ্যমে সম্পাদিত হওয়া উচিত। যদি সিংক রাশি UI থ্রেডে চলে, তবে অ্যাপ নিষ্পাদনের সময় লেগ করবে। WorkManager ব্যাটারি ও নেটওয়ার্ক অবস্থা সম্পর্কে সচেতনতা সহ একটি পশ্চাত্ ভূমির থ্রেডে নিষ্পাদনের গারন্টি দেয়।

Android এ WorkManager এর মাধ্যমে পশ্চাত্ ভূমির সিংকের উদাহরণ:

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("সিংক", "পশ্চাত্ ভূমির থ্রেডে ডেটা সিংক করা হচ্ছে")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

ডিভেলপমেন্ট পর্যায়ে লেগ করা প্রতিরোধ

দক্ষ মেমরি ও থ্রেড পরিচালনার নীতি অনুসরণ করে কোডিং পর্যায়েই লেগ করা প্রতিরোধ করা যাতে পারে।

AOT কম্পাইলেশনের জন্য Baseline Profiles

Baseline Profiles হল ক্লাস ও পদ্ধতির একটি তালিকা যা Android JIT এর পরিবর্তে আগে থেকে (AOT) কম্পাইল করে। প্রোফাইল ছাড়া, প্রতিটি নতুন স্ক্রিন প্রথম বার খোলার সময় কম্পাইল হয়, যা 100–500 মিলিসেকেন্ড বিলম্ব সৃষ্টি করে। মূখ্য স্ক্রিনের জন্য একটি Baseline Profile প্রস্তুত করুন ও baseline-profile-gradle-plugin এর মাধ্যমে Gradle এ জনরেশন সক্ষম করুন।

㦹াট পাথে আবন্টন সক্ষিত্র করা

㦹াট পাথ হল কোড যা প্রতিটি ফ্রেমে নিষ্পাদিত হয়: onBindViewHolder, draw, layoutSubviews। এই পদ্ধতিগুলিতে অবজেক্ট তৈরি করা এড়িয়ে চলুন: অবজেক্ট পূল, কন্কাটেনেশনের পরিবর্তে StringBuilder, ফর্মেটেড স্ট্রিং ও ফর্মেটার ক্যাশ করুন। প্রতিটি অতিরিক্ত আবন্টন পরবর্তী GC কে নিকটবর্তী করে আনে।

CI এ Baseline Profiles এর মাধ্যমে প্রোফাইলিং

আপনার CI পাইপলাইনে লিস্ট স্ক্রলিং ও স্ক্রিন খোলার পরিদৃশ্য সহ Macrobenchmark যোগ করুন। একটি সীমা নির্ধারণ করুন: 99তম পার্সেন্টাইল ফ্রেম সময় 16 মিলিসেকেন্ড অতিক্রম করতে পারবে না। সীমা অতিক্রম হলে — অপ্টিমাইজেশন পর্যন্ত বিল্ড প্রত্যাখ্যান করা হয়।

• Android — Baseline Profiles, Macrobenchmark, JankStats, penaltyDeath সহ StrictMode
• iOS — MetricKit, os_signpost, XCTMetric, Debug স্কিমে Main Thread Checker
• সাধারণ পদ্ধতি — নিয়মিত প্রোফাইলিং, 㦹াট পাথে আবন্টন কেন্দ্রিক কোড পর্যালোচনা