گزارش خرابی در توسعه موبایل — چیست، سرویس‌ها و تنظیمات

گزارش خرابی چیست؟

گزارش خرابی — فرآیند جمع‌آوری خودکار اطلاعات فنی درباره خرابی‌های برنامه و ارسال متمرکز آن به سرور برای تحلیل است. برخلاف ثبت‌وقایع، گزارش خرابی دقیقاً موقعیت‌های اضطراری را ثبت می‌کند — لحظه‌ای که برنامه به‌اجبار توسط سیستم یا سیستم‌عامل خاتمه یافته است.

هر گزارش خرابی شامل سه مؤلفه کلیدی است: نوع استثنا (NullPointerException، SIGSEGV، NSInternalInconsistencyException)، پشته فراخوانی کامل با شماره خطوط و اطلاعات محیط — نسخه سیستم‌عامل، مدل دستگاه، میزان حافظه آزاد. بر اساس Sentry Engineering, 2024، ترکیب این سه عنصر امکان بازتولید و رفع ۸۵٪ از خطاهای بحرانی را فراهم می‌کند.

سیستم‌های مدرن گزارش خرابی قابلیت را فراتر از خرابی‌های معمولی گسترش می‌دهند. Firebase Crashlytics به‌طور خودکار خرابی‌های تکراری را در issues گروه‌بندی می‌کند، Sentry پسرفت‌های بین انتشارها را ردیابی می‌کند و Bugsnag مسیر کاربر به خطا را نشان می‌دهد. هر سه سرویس از iOS، Android، React Native و Flutter پشتیبانی می‌کنند.

بر اساس Google I/O 2024، برنامه‌های بدون گزارش خرابی به طور متوسط ۳–۵ روز کاری را صرف تشخیص یک خطای بحرانی می‌کنند، در حالی که با Crashlytics — ۱۵–۳۰ دقیقه. صرفه‌جویی در زمان برای هر رویداد بیش از ۹۰٪ است.

سیستم جمع‌آوری گزارش‌های خرابی چگونه کار می‌کند

معماری سیستم گزارش خرابی از سه لایه تشکیل شده است: SDK مشتری نصب‌شده در برنامه، API سرور برای دریافت و پردازش گزارش‌ها و داشبورد وب برای تحلیل. SDK مشتری استثناهای مدیریت‌نشده را می‌گیرد، آنها را به JSON سریالیزه می‌کند و در راه‌اندازی بعدی برنامه به سرور ارسال می‌کند.

ارسال گزارش خرابی به‌صورت ناهمگام پس از راه‌اندازی مجدد برنامه انجام می‌شود. این یک نکته اساسی است: در لحظه خرابی، برنامه نمی‌تواند ارسال موفق داده‌ها را از طریق شبکه تضمین کند. SDK گزارش را در ذخیره‌سازی محلی ذخیره می‌کند و در راه‌اندازی بعدی آن را از طریق یک نخ پس‌زمینه ارسال می‌کند. بر اساس Firebase Engineering, 2024، این رویکرد تحویل ۹۹٫۷٪ از گزارش‌های خرابی را تضمین می‌کند.

برای استثناهای غیربحرانی (استثناهای مدیریت‌شده در داخل try-catch)، SDK گزارش را فوراً ارسال می‌کند، زیرا برنامه به کار ادامه می‌دهد. گزارش‌های غیربحرانی همان داده‌های خرابی را دارند اما جلسه کاربر را قطع نمی‌کنند. این به‌ویژه برای ردیابی خطاهای درخواست API، اعتبارسنجی داده و منطق تجاری مفید است.

گروه‌بندی خرابی — الگوریتم سروری که خرابی‌های یکسان را بر اساس هش آخرین ۵–۱۰ فریم پشته ترکیب می‌کند. این به توسعه‌دهنده اجازه می‌دهد نه ۱۰۰۰ گزارش جداگانه، بلکه یک issue با ۱۰۰۰ رخداد که دستگاه‌ها و نسخه‌های مختلف سیستم‌عامل را پوشش می‌دهد، ببیند.

Firebase Crashlytics: یکپارچه‌سازی و قابلیت‌ها

Firebase Crashlytics — محبوب‌ترین سرویس گزارش خرابی برای برنامه‌های موبایل است که در بیش از ۳ میلیون پروژه در سراسر جهان استفاده می‌شود. طرح رایگان شامل تعداد نامحدود گزارش، یکپارچه‌سازی با Google Analytics و گروه‌بندی خودکار خرابی است.

یکپارچه‌سازی Crashlytics در Android

اتصال Crashlytics در Android حداقلی است: وابستگی را به build.gradle اضافه کنید و SDK را در Application.onCreate مقداردهی کنید. Crashlytics به‌طور خودکار Thread.setDefaultUncaughtExceptionHandler خود را تنظیم می‌کند و تمام استثناهای مدیریت‌نشده را می‌گیرد.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

قابلیت کلیدی Crashlytics — کلیدها و لاگ‌های سفارشی. توسعه‌دهنده می‌تواند تا ۶۴ جفت کلید-مقدار به هر گزارش خرابی اضافه کند: وضعیت صفحه، طرح انتخابی، سطح کاربر. همچنین ثبت پیام‌های لاگ سفارشی که به ترتیب زمانی وارد گزارش می‌شوند در دسترس است.

Velocity Alert — تشخیص خودکار پسرفت

Velocity Alert — قابلیتی از Crashlytics که افزایش ناگهانی تعداد خرابی‌ها را برای یک issue خاص ردیابی می‌کند. اگر پس از انتشار جدید تعداد خرابی‌ها از مقدار آستانه فراتر رود، تیم اعلان پوش و ایمیل ۵–۱۵ دقیقه قبل از شکایات دسته‌جمعی کاربران دریافت می‌کند.

تنظیم آستانه فعال‌سازی: ۲ برابر در ۱ ساعت برای issues بحرانی. بر اساس Google, 2024، تیم‌های دارای Velocity Alert فعال، نسخه‌های رفع سریع را به طور متوسط ۴۰٪ سریع‌تر از تیم‌هایی که بر نظارت دستی داشبورد تکیه می‌کنند، منتشر می‌کنند.

یکپارچه‌سازی Crashlytics در iOS

در iOS، Crashlytics SDK از طریق CocoaPods یا Swift Package Manager یکپارچه می‌شود. SDK هم استثناهای Objective-C (از طریق NSSetUncaughtExceptionHandler) و هم سیگنال‌های سیستم‌عامل (SIGSEGV، SIGABRT) را از طریق mach exception handler خود می‌گیرد.

بر اساس Apple Developer, 2024، Crashlytics برای iOS تا ۹۸٪ از همه انواع خرابی را پردازش می‌کند، از جمله خطاهای حافظه سطح پایین که توسط مکانیزم‌های استاندارد گرفته نمی‌شوند. این Crashlytics را به استاندارد دوفاکتو برای توسعه iOS تبدیل می‌کند.

Sentry و Bugsnag: پلتفرم‌های جایگزین

Sentry — پلتفرم متن‌باز نظارت بر خطا که از ۸۰+ زبان و فریم‌ورک پشتیبانی می‌کند. برخلاف Crashlytics، Sentry به توسعه‌دهندگان بک‌اند جهت‌گیری دارد اما SDK کامل برای iOS، Android، React Native و Flutter ارائه می‌دهد.

مزیت اصلی Sentry — نظارت بر عملکرد در یک داشبورد واحد. توسعه‌دهنده نه تنها خرابی‌ها، بلکه تراکنش‌هایی را که به آنها منجر شده‌اند می‌بیند: درخواست‌های شبکه کند، یخ‌زدگی UI، عملیات طولانی پایگاه داده. بر اساس Sentry, 2024، ۴۰٪ از خرابی‌ها مشکلات عملکردی قبلی دارند که بدون چنین رویکردی نادیده گرفته می‌شوند.

Bugsnag در رویکرد گروه‌بندی خطا متفاوت است — به جای پشته فراخوانی، مسیر کاربر (user journey) را تحلیل می‌کند. هر گزارش خرابی شامل دنباله‌ای از صفحه‌ها و اقدامات کاربر است که به خطا منجر شده‌اند. این به‌ویژه برای فرآیندهای پیچیده تجاری مفید است: ثبت سفارش، ثبت‌نام، پرداخت.

قیمت سرویس‌ها متفاوت است: Crashlytics در چارچوب Firebase رایگان است، Sentry طرح رایگان برای ۵۰۰۰ رویداد در ماه ارائه می‌دهد، Bugsnag از ۲۹ دلار در ماه شروع می‌شود. هر سه پلتفرم SDK با کد منبع باز ارائه می‌دهند. انتخاب سرویس به اندازه تیم، بودجه و الزامات امنیت داده بستگی دارد.

گزارش خرابی در iOS: ویژگی‌ها و NSException

ویژگی iOS — معماری چندلایه مدیریت خطا. SDKهای گزارش خرابی باید استثناهای Objective-C (NSException)، خطاهای Swift (Error)، سیگنال‌های POSIX (SIGSEGV, SIGBUS) و استثناهای mach را بگیرند. هر نوع نیاز به مکانیزم جداگانه‌ای برای گرفتن دارد.

NSException — ساده‌ترین نوع برای گرفتن از طریق NSSetUncaughtExceptionHandler. با این حال، بر اساس Apple, 2024، تنها ۳۰٪ از خرابی‌ها در برنامه‌های Swift مدرن NSException هستند. ۷۰٪ باقیمانده سیگنال‌های سیستم‌عامل و خطاهای زمان اجرای Swift هستند که به مکانیزم mach exception handler نیاز دارند.

توسعه‌دهندگان iOS باید گزارش خرابی را از طریق تولید محلی خرابی از انواع مختلف آزمایش کنند: __builtin_trap() برای سیگنال‌ها، [NSException raise:...] برای استثناها، fatalError() برای Swift. تنها از این طریق می‌توان اطمینان حاصل کرد که SDK همه انواع خرابی را پوشش می‌دهد.

گزارش خرابی در Android: ANR و خرابی‌های بومی

Android دو نوع خرابی خاص را اضافه می‌کند که در iOS وجود ندارند: ANR (برنامه پاسخ نمی‌دهد) و خرابی بومی در کد C/C++. ANR زمانی رخ می‌دهد که نخ UI بیش از ۵ ثانیه مسدود شده باشد — سیستم دیالوگ «برنامه پاسخ نمی‌دهد» را نشان می‌دهد و پیشنهاد بستن آن را می‌دهد.

Thread.setDefaultUncaughtExceptionHandler استاندارد ANR را نمی‌گیرد، زیرا این یک استثنا نیست، بلکه سیگنالی از ActivityManager است. برای ردیابی ANR، Crashlytics و Sentry از یک نخ watchdog پس‌زمینه استفاده می‌کنند که هر ۵ ثانیه پاسخگویی نخ UI را بررسی می‌کند. بر اساس Firebase, 2024، ۱۵٪ از همه مشکلات در Android ANR هستند، نه خرابی.

خرابی بومی در Android در کد C/C++ که از طریق JNI (رابط بومی جاوا) اجرا می‌شود رخ می‌دهد. این خرابی‌ها استثناهای Java نیستند و توسط Thread.setDefaultUncaughtExceptionHandler گرفته نمی‌شوند. برای پردازش آنها از Google Breakpad یا Crashpad استفاده می‌شود که برای سیگنال‌های SIGSEGV، SIGABRT، SIGBUS handlerهای sigaction نصب می‌کنند.

بر اساس Google I/O 2024، تعداد خرابی‌های بومی با گسترش موتورهای بازی (Unity، Unreal Engine) و کتابخانه‌های بینایی کامپیوتر (ML Kit، OpenCV) در حال افزایش است. به توسعه‌دهندگان برنامه‌های ترکیبی توصیه می‌شود همیشه گزارش خرابی بومی را متصل کنند.