Firebase Crashlytics — এটি কী, ক্র্যাশ এবং ত্রুটি নির্ণয়

Firebase Crashlytics কী

Firebase Crashlytics মোবাইল অ্যাপ্লিকেশন স্থিতিশীলতা পর্যবেক্ষণের জন্য Google-এর একটি বিনামূল্যের পরিষেবা, যা Google 2017 সালে Fabric কোম্পানির সাথে অধিগ্রহণ করেছিল। Crashlytics স্বয়ংক্রিয়ভাবে প্রতিটি অ্যাপ্লিকেশন ক্র্যাশ সম্পর্কে তথ্য সংগ্রহ করে, স্ট্যাক স্বাক্ষর দ্বারা একই ক্র্যাশ গ্রুপ করে এবং Firebase কনসোলে আক্রান্ত ব্যবহারকারীর সংখ্যা অনুসারে অগ্রাধিকার সহ প্রদর্শন করে।

ইতিহাস এবং বিবর্তন

Crashlytics 2011 সালে Fabric প্ল্যাটফর্মের অংশ হিসেবে চালু হয়েছিল এবং দ্রুত iOS-এ ক্র্যাশ রিপোর্টিংয়ের জন্য ডি-ফ্যাক্টো মান হয়ে ওঠে। 2017 সালে Google-এর দ্বারা আনুমানিক 2 বিলিয়ন ডলারে (পুরো Fabric) অধিগ্রহণের পরে, Crashlytics Firebase SDK-তে সংহত হয়। সংস্করণ 18.0.0 (2021) Kotlin Multiplatform সমর্থন যোগ করে, এবং সংস্করণ 19.0.0 (2024) অতিরিক্ত কনফিগারেশন ছাড়াই Android-এ স্বয়ংক্রিয় ANR সংগ্রহ চালু করে। Google (2026) অনুসারে, Crashlytics মাসিক 10 বিলিয়নেরও বেশি ক্র্যাশ প্রক্রিয়া করে।

Crashlytics-এর বিনামূল্যের সীমা

Crashlytics প্রতি Firebase প্রকল্পে প্রতিদিন 500 হাজার সেশনের সীমা সহ বিনামূল্যে প্রদান করা হয়। এটি বেশিরভাগ অ্যাপ্লিকেশনের জন্য যথেষ্ট — Google (2026) অনুসারে, 95% প্রকল্প সীমা অতিক্রম করে না। সীমা অতিক্রম করলে, ডেটা সংগ্রহ বন্ধ হয় না, কিন্তু রিপোর্ট পরের দিন পর্যন্ত আপডেট হওয়া বন্ধ করে দেয়। উচ্চ ট্রাফিকের প্রকল্পের জন্য, Firebase-এর Spark এবং Blaze ট্যারিফ উপলব্ধ — Crashlytics উভয় ট্যারিফেই বিনামূল্যে থাকে এবং সেশন সীমা আলাদাভাবে গণনা করা হয়।

Crashlytics কীভাবে ক্র্যাশ সনাক্ত করে এবং সংগ্রহ করে

Crashlytics-এর সংগ্রহ প্রক্রিয়া প্ল্যাটফর্ম এবং রানটাইম স্তরে এক্সেপশন ইন্টারসেপ্ট করার উপর ভিত্তি করে। Android-এ, SDK একটি UncaughtExceptionHandler ইনস্টল করে যা সমস্ত আনহ্যান্ডল্ড Kotlin এবং Java এক্সেপশন ধরে। iOS-এ, Crashlytics Objective-C/Swift-এর জন্য NSSetUncaughtExceptionHandler এবং নেটিভ কোড ক্র্যাশের জন্য নিজস্ব Mach এক্সেপশন হ্যান্ডলার ব্যবহার করে।

ইন্টারসেপ্ট করা ক্র্যাশের প্রকার

Crashlytics পাঁচ ধরনের ক্র্যাশ আলাদা করে: fatal (মারাত্মক ক্র্যাশ), non-fatal (ম্যানুয়ালি পাঠানো অ-মারাত্মক এক্সেপশন), ANR (Android — অ্যাপ্লিকেশন সাড়া দিচ্ছে না), signal (OS সিগন্যাল — SIGSEGV, SIGABRT) এবং OOM (iOS-এ মেমরি শেষ)। প্রতিটি প্রকার একটি পৃথক প্রক্রিয়া দ্বারা পরিচালিত হয় এবং সংশ্লিষ্ট লেবেল সহ কনসোলে প্রদর্শিত হয়।

ক্র্যাশ রিপোর্ট ফরম্যাট

প্রতিটি Crashlytics রিপোর্টে ব্যাপক তথ্য থাকে: ক্লাস নাম এবং লাইন নম্বর সহ পূর্ণ স্ট্যাক ট্রেস, অ্যাপ্লিকেশন সংস্করণ (versionName + versionCode), ডিভাইস মডেল, OS সংস্করণ, খালি মেমরি, স্ক্রিন ওরিয়েন্টেশন এবং লঞ্চের পর থেকে সময়। যদি Firebase Analytics সংযুক্ত থাকে, রিপোর্টে ক্র্যাশের আগে শেষ 50টি ব্যবহারকারী ইভেন্টের পথও অন্তর্ভুক্ত থাকে — এটি ক্র্যাশ পুনরুৎপাদনের জন্য গুরুত্বপূর্ণ।

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Android প্রকল্পে Crashlytics সংহতকরণ

Android অ্যাপ্লিকেশনে Crashlytics সংযোগ করতে build.gradle-এ দুটি নির্ভরতা যোগ করতে হবে এবং Google Services প্লাগইন কনফিগার করতে হবে। SDK অতিরিক্ত কোড ছাড়াই Firebase আরম্ভকরণে স্বয়ংক্রিয়ভাবে ক্র্যাশ রিপোর্টিং সক্ষম করে। সঠিক পরিচালনার জন্য, google-services প্লাগইন এবং Firebase কনসোল থেকে google-services.json ফাইলও প্রয়োজন।

// build.gradle (প্রকল্প-স্তর)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (অ্যাপ্লিকেশন-স্তর)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Crashlytics প্লাগইন কনফিগারেশন

com.google.firebase.crashlytics প্লাগইন দুটি কাজ করে: অস্পষ্ট স্ট্যাক ম্যাপিংয়ের জন্য একটি অনন্য বিল্ড আইডি (build ID) তৈরি করে এবং Crashlytics SDK-এর জন্য স্বয়ংক্রিয়ভাবে রিসোর্স তৈরি করে। প্লাগইন ছাড়া, ক্র্যাশ "unmapped" হিসেবে চিহ্নিত হবে — আপনি শুধু অস্পষ্ট ক্লাস নাম (a.b.c) দেখবেন, সোর্স কোড খুঁজে পেতে অক্ষম হবেন। প্লাগইন রুট build.gradle এবং অ্যাপ্লিকেশন মডিউলের build.gradle-এ যোগ করা হয়।

সংহতকরণ যাচাইকরণ

Crashlytics সংহতকরণ পরীক্ষা করার জন্য বিশেষ পদ্ধতি forceCrash() ব্যবহার করা হয়, যা একটি পরীক্ষা এক্সেপশন তৈরি করে। এই পদ্ধতি প্রোডাকশন বিল্ডে উপলব্ধ নয়। পরীক্ষা ক্র্যাশ চালানোর পরে, রিপোর্ট 1-5 মিনিটের মধ্যে Firebase কনসোলে দেখা যায়। যদি রিপোর্ট না দেখা যায়, তবে পরীক্ষা করুন যে google-services.json অ্যাপ্লিকেশন প্যাকেজের সাথে মেলে এবং AndroidManifest-এ ডেটা সংগ্রহ অক্ষম করার কোনো ফ্ল্যাগ নেই।

ক্র্যাশ বিশ্লেষণ এবং রিপোর্ট গ্রুপিং

Crashlytics কনসোল দেখার দুটি স্তর প্রদান করে: ক্র্যাশ প্রকার অনুসারে গ্রুপিত সমস্ত ক্র্যাশের (Issues) তালিকা, এবং ট্রেস, পরিসংখ্যান এবং কাস্টম ডেটা সহ প্রতিটি Issue-এর বিস্তারিত রিপোর্ট। প্রতিটি Issue একই স্বাক্ষরযুক্ত সমস্ত ক্র্যাশ একত্রিত করে — একই এক্সেপশন প্রকার এবং ম্যাচিং স্ট্যাক ট্রেস।

Issues এবং গ্রুপিং

ক্র্যাশ গ্রুপিং Crashlytics-এর একটি মূল বৈশিষ্ট্য। হাজার হাজার পৃথক ক্র্যাশ দেখানোর পরিবর্তে, পরিষেবা সেগুলিকে ফিংগারপ্রিন্টের ভিত্তিতে Issues-এ একত্রিত করে — স্ট্যাক ট্রেসের একটি চেকসাম। একটি Issue-এ 1 থেকে কয়েক মিলিয়ন ক্র্যাশ থাকতে পারে। প্রতিটি Issue প্রদর্শন করে: মারাত্মক ঘটনার সংখ্যা, অনন্য ব্যবহারকারীর সংখ্যা, অ্যাপ্লিকেশন সংস্করণ যেখানে ক্র্যাশ দেখা দিয়েছে এবং সমস্যার সম্মুখীন ব্যবহারকারীর শতাংশ।

Google (2026) অনুসারে, গড়ে 20% Issues সমস্ত মারাত্মক অ্যাপ্লিকেশন ক্র্যাশের 80% (প্যারেটো নীতি) গঠন করে। Crashlytics স্বয়ংক্রিয়ভাবে Issues-কে গুরুত্ব অনুসারে সাজায় — যত বেশি ব্যবহারকারী আক্রান্ত, তত বেশি অগ্রাধিকার। এটি ডেভেলপারকে প্রথমে সবচেয়ে ব্যাপক সমস্যাগুলি সমাধান করতে দেয়।

সংস্করণ পরিসংখ্যান

Crashlytics প্রতিটি অ্যাপ্লিকেশন সংস্করণের স্থিতিশীলতা আলাদাভাবে ট্র্যাক করে। ক্র্যাশ-মুক্ত ব্যবহারকারীদের গ্রাফ প্রতিটি সংস্করণে মারাত্মক ক্র্যাশের সম্মুখীন না হওয়া ব্যবহারকারীর শতাংশ দেখায়। যদি আপডেটে শতাংশ একটি সীমার (ডিফল্ট 99%) নিচে নেমে যায়, Crashlytics ইমেল এবং Firebase কনসোলে বিজ্ঞপ্তি পাঠায়। এটি সমস্যাযুক্ত সংস্করণ দ্রুত প্রত্যাহার বা হটফিক্স প্রকাশের অনুমতি দেয়।

কাস্টম কী, লগ এবং Breadcrumbs

Crashlytics রিপোর্টকে প্রসঙ্গে সমৃদ্ধ করার জন্য তিনটি প্রক্রিয়া প্রদান করে: কাঠামোবদ্ধ ডেটার জন্য কাস্টম কী (keys), টেক্সট ট্রেসিংয়ের জন্য লগ (logs), এবং ব্যবহারকারীর পথের জন্য Analytics থেকে Breadcrumbs। তিন ধরনের ডেটাই ক্র্যাশ রিপোর্টের সাথে সংযুক্ত হয় এবং তার বিবরণ কার্ডে দৃশ্যমান হয়।

কাস্টম কী

Custom Keys হলো কী-মান জোড়া যা প্রতিটি ক্র্যাশের সাথে পাঠানো হয়। প্রতি অ্যাপ্লিকেশনে সর্বোচ্চ 64টি কী, প্রতিটি কী 1024 অক্ষর পর্যন্ত স্ট্রিং। অ্যাপ্লিকেশন অবস্থা লেবেল করার জন্য কীগুলি উপযোগী: সাবস্ক্রিপশন স্তর, অনুমোদন অবস্থা, শেষ স্ক্রিন, VPN সক্ষম কিনা। মানগুলি ওভাররাইট হয় — একই নামের একটি নতুন কী পুরানোটি প্রতিস্থাপন করে।

ইভেন্ট লগিং

Custom Logs হলো টেক্সট বার্তা যা Crashlytics 64 KB রিং বাফারে সংরক্ষণ করে। লগ স্বয়ংক্রিয়ভাবে পরবর্তী ক্র্যাশের সাথে সংযুক্ত হয়। যদি কোনো ক্র্যাশ না ঘটে, লগ সার্ভারে পাঠানো হয় না (ট্রাফিক ব্যবহার করে না)। লগিং ক্র্যাশের আগে ব্যবহারকারীর পদক্ষেপ রেকর্ড করতে ব্যবহৃত হয়: "payment_processing_started", "api_call_initiated", "response_received_200"।

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Analytics থেকে Breadcrumbs

যদি প্রকল্পে Firebase Analytics সংযুক্ত থাকে, Crashlytics স্বয়ংক্রিয়ভাবে Breadcrumbs গ্রহণ করে — ক্র্যাশের আগে শেষ 50টি বিশ্লেষণ ইভেন্ট। প্রতিটি breadcrumb-এ ইভেন্টের নাম এবং তার প্যারামিটার থাকে। এটি ক্র্যাশের কারণ ক্রিয়াগুলির সঠিক ক্রম পুনর্গঠনের অনুমতি দেয়: ব্যবহারকারী স্ক্রিন খুলেছে → পণ্য যোগ করেছে → পেমেন্টে গেছে → ক্র্যাশ হয়েছে। Breadcrumbs Issue কার্ডে একটি পৃথক "Logs" ট্যাবে প্রদর্শিত হয়।

ক্র্যাশ নিয়ে কাজ করার সেরা অনুশীলন

Crashlytics সবচেয়ে কার্যকর হয় যখন প্রসঙ্গ এবং Issue প্রক্রিয়াকরণ প্রক্রিয়া সঠিকভাবে কনফিগার করা হয়। অনুশীলন দেখায় যে যে দলগুলি ক্র্যাশ ব্যবস্থাপনা কর্মপ্রবাহ বাস্তবায়ন করেছে তারা গুরুত্বপূর্ণ বাগ ফিক্সিং সময় 60% কমিয়ে দেয় (Google ডেটা, 2026)।

Issue অগ্রাধিকার নির্ধারণ

সমস্ত ক্র্যাশ সমানভাবে গুরুত্বপূর্ণ নয়। ব্যবহারকারীর সংখ্যা এবং ফ্রিকোয়েন্সি অনুসারে অগ্রাধিকার নির্ধারণ সবচেয়ে গুরুত্বপূর্ণ সমস্যাগুলিতে মনোযোগ দিতে সাহায্য করে। সাধারণ নিয়ম: 24 ঘন্টার মধ্যে 0.1% এর বেশি ব্যবহারকারীকে প্রভাবিত করে এমন Issues সমাধান করুন। একক ঘটনা সহ Issues (< 0.01%) পরবর্তী পরিকল্পিত রিলিজ পর্যন্ত স্থগিত করা যেতে পারে। Crashlytics স্বয়ংক্রিয়ভাবে রিগ্রেশন চিহ্নিত করে — যে Issues সমাধান হয়েছিল কিন্তু নতুন সংস্করণে আবার দেখা দিয়েছে।

CI/CD-এর সাথে সংহতকরণ

Crashlytics API REST API বা Firebase CLI-এর মাধ্যমে CI/CD পাইপলাইনে ক্র্যাশ রিপোর্ট সংহত করার অনুমতি দেয়। প্রতিটি নতুন রিলিজের সাথে, আপনি স্বয়ংক্রিয়ভাবে পরীক্ষা করতে পারেন যে ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ একটি সীমা অতিক্রম করে কিনা। যদি সীমা অতিক্রম করা হয়, CI/CD রোলআউট ব্লক করে এবং দলকে বিজ্ঞপ্তি পাঠায়। Firebase CLI ProGuard/R8 ম্যাপিং ফাইল আপলোড করার জন্য firebase crashlytics:builds:upload কমান্ড সমর্থন করে — এগুলি ছাড়া স্ট্যাক অপঠনযোগ্য হবে।

Google (2026) অনুসারে, CI/CD-তে স্বয়ংক্রিয় ক্র্যাশ-মুক্ত সীমা পরীক্ষা ব্যবহার করে এমন অ্যাপ্লিকেশন প্রোডাকশনে 40% কম রিগ্রেশন প্রকাশ করে। প্রস্তাবিত সীমা: গুরুত্বপূর্ণ রিলিজের জন্য ক্র্যাশ-মুক্ত ব্যবহারকারী >= 99.5% এবং সাধারণ রিলিজের জন্য >= 99.0%।