این صفحه، راهنمایی برای عیب‌یابی و پاسخ به سوالات متداول در مورد استفاده از Crashlytics را ارائه می‌دهد. اگر نمی‌توانید آنچه را که به دنبالش هستید پیدا کنید یا به کمک بیشتری نیاز دارید، با پشتیبانی Firebase تماس بگیرید.
عیب‌یابی عمومی/سوالات متداول
ممکن است متوجه دو فرمت مختلف برای مشکلات ذکر شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است متوجه ویژگی‌ای به نام "انواع" در برخی از مشکلات خود شوید. دلیل آن این است!
در اوایل سال ۲۰۲۳، ما یک موتور تحلیل بهبود یافته برای گروه‌بندی رویدادها و همچنین یک طراحی به‌روز شده و برخی ویژگی‌های پیشرفته برای مسائل جدید (مانند انواع مختلف!) را ارائه دادیم. برای جزئیات بیشتر، به پست وبلاگ اخیر ما مراجعه کنید، اما می‌توانید نکات برجسته را در زیر بخوانید.
Crashlytics تمام رویدادهای برنامه شما (مانند خرابی‌ها، خطاهای غیرفاجعه‌آمیز و ANRها) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مشکلات (issues ) ایجاد می‌کند - همه رویدادهای یک مشکل (issue) یک نقطه شکست مشترک دارند.
برای گروه‌بندی رویدادها در این مسائل، موتور تحلیل بهبود یافته اکنون جنبه‌های زیادی از رویداد، از جمله فریم‌های موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگی‌های پلتفرم یا نوع خطا را بررسی می‌کند.
با این حال، در این گروه از رویدادها، ممکن است ردپاهای پشته منجر به خرابی متفاوت باشند. یک ردپای پشته متفاوت می‌تواند به معنای علت ریشه‌ای متفاوت باشد. برای نمایش این تفاوت احتمالی در یک مسئله، اکنون انواعی را در مسائل ایجاد می‌کنیم - هر نوع، زیرگروهی از رویدادها در یک مسئله است که نقطه خرابی یکسانی دارند و یک ردپای پشته مشابه. با انواع، می‌توانید رایج‌ترین ردپاهای پشته را در یک مسئله اشکال‌زدایی کنید و تعیین کنید که آیا علل ریشه‌ای متفاوتی منجر به خرابی می‌شوند یا خیر.
در اینجا چیزی است که با این پیشرفت‌ها تجربه خواهید کرد:
فراداده‌های اصلاح‌شده در ردیف مشکل نمایش داده می‌شوند
اکنون درک و اولویت‌بندی مشکلات در برنامه شما آسان‌تر است.مسائل تکراری کمتر
تغییر شماره خط منجر به مشکل جدیدی نمی‌شود.اشکال‌زدایی آسان‌تر مسائل پیچیده با علل ریشه‌ای مختلف
از انواع مختلف برای اشکال‌زدایی رایج‌ترین ردپاهای پشته در یک مسئله استفاده کنید.هشدارها و سیگنال‌های معنادارتر
یک مشکل جدید در واقع نشان دهنده یک باگ جدید است.جستجوی قدرتمندتر
هر شماره شامل فراداده‌های قابل جستجوی بیشتری مانند نوع استثنا و نام بسته است.
نحوه‌ی اعمال این بهبودها به شرح زیر است:
وقتی رویدادهای جدیدی از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا با مشکل موجود مطابقت دارند یا خیر.
اگر هیچ تطابقی وجود نداشته باشد، ما به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندتر خود را برای رویداد اعمال می‌کنیم و یک issue جدید با طراحی فراداده اصلاح‌شده ایجاد می‌کنیم.
این اولین به‌روزرسانی بزرگی است که ما در گروه‌بندی رویدادهای خود انجام می‌دهیم. اگر بازخوردی دارید یا با مشکلی مواجه شده‌اید، لطفاً با ثبت گزارش به ما اطلاع دهید.
اگر گزارش‌های breadcrumb را مشاهده نمی‌کنید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را رعایت می‌کنید:
شما اشتراک‌گذاری داده‌ها را برای Google Analytics فعال کرده‌اید. برای اطلاعات بیشتر در مورد این تنظیم، به مدیریت تنظیمات اشتراک‌گذاری داده‌های آنالیتیکس خود مراجعه کنید.
شماکیت توسعه نرم‌افزار فایربیس برای Google Analytics اضافه شد.به برنامه شما. این SDK باید علاوه بر Crashlytics SDK اضافه شود.
شما در حال استفاده ازآخرین نسخه‌های Firebase SDKبرای تمام محصولاتی که در برنامه خود استفاده می‌کنید.
به خصوص بررسی کنید که حداقل از نسخه زیر از Firebase SDK برای Google Analytics استفاده می‌کنید:
اندروید — نسخه 17.2.3+ ( BoM v24.7.1+).
اگر هشدارهای سرعت را نمی‌بینید، مطمئن شوید که از ... استفاده می‌کنید.Crashlytics SDK نسخه ۱۸.۶.۰+ (یا Firebase BoM نسخه ۳۲.۶.۰+).
اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) را نمی‌بینید یا معیارهای غیرقابل اعتمادی را می‌بینید، موارد زیر را بررسی کنید:
مطمئن شوید که از ... استفاده می‌کنیدCrashlytics SDK نسخه ۱۸.۶.۰+ (یا Firebase BoM نسخه ۳۲.۶.۰+).
مطمئن شوید که تنظیمات جمع‌آوری داده‌های شما بر کیفیت معیارهای بدون خرابی شما تأثیر نمی‌گذارد:
اگر با غیرفعال کردن گزارش خودکار خرابی، گزارش‌دهی اختیاری را فعال کنید ، اطلاعات خرابی فقط از کاربرانی که صریحاً در جمع‌آوری داده‌ها مشارکت داشته‌اند، می‌تواند به Crashlytics ارسال شود. بنابراین، دقت معیارهای بدون خرابی تحت تأثیر قرار خواهد گرفت زیرا Crashlytics فقط اطلاعات خرابی این کاربران انتخابی (و نه همه کاربران شما) را دارد. این بدان معناست که معیارهای بدون خرابی شما ممکن است کمتر قابل اعتماد باشند و کمتر نشان‌دهنده پایداری کلی برنامه شما باشند.
اگر جمع‌آوری خودکار داده‌ها را غیرفعال کرده‌اید، می‌توانید از
sendUnsentReportsبرای ارسال گزارش‌های ذخیره‌شده روی دستگاه به Crashlytics استفاده کنید. استفاده از این روش، داده‌های خرابی را به Crashlytics ارسال می‌کند، اما داده‌های جلسات را نه، که باعث می‌شود نمودارهای کنسول مقادیر کم یا صفر را برای معیارهای بدون خرابی نشان دهند.
به بخش «معیارهای بدون خرابی را درک کنید» مراجعه کنید.
Crashlytics از گزارش‌دهی ANR برای برنامه‌های اندروید از دستگاه‌هایی که اندروید ۱۱ و بالاتر را اجرا می‌کنند، پشتیبانی می‌کند. API زیربنایی که ما برای جمع‌آوری ANRها استفاده می‌کنیم ( getHistoricalProcessExitReasons ) نسبت به رویکردهای مبتنی بر SIGQUIT یا watchdog قابل اعتمادتر است. این API فقط در دستگاه‌های اندروید ۱۱+ در دسترس است.
اگر برخی از ANR های شما BuildId های خود را ندارند، به روش زیر عیب یابی کنید:
مطمئن شوید که از نسخه به‌روز Crashlytics Android SDK و افزونه Crashlytics Gradle استفاده می‌کنید.
اگر
BuildIdهای اندروید ۱۱ و برخی از ANR های اندروید ۱۲ را ندارید، احتمالاً از SDK، افزونه Gradle یا هر دوی آنها استفاده می‌کنید که قدیمی هستند. برای جمع‌آوری صحیحBuildIdهای این ANR ها، باید از نسخه‌های زیر استفاده کنید:- Crashlytics Android SDK نسخه ۱۸.۳.۵+ ( Firebase BoM نسخه ۳۱.۲.۲+)
- افزونه Crashlytics Gradle نسخه ۲.۹.۴+
بررسی کنید که آیا از مکان غیر استانداردی برای کتابخانه‌های اشتراکی خود استفاده می‌کنید یا خیر.
اگر فقط
BuildIdهای کتابخانه‌های اشتراکی برنامه‌تان را ندارید، احتمالاً از مکان استاندارد و پیش‌فرض برای کتابخانه‌های اشتراکی استفاده نمی‌کنید. در این صورت، Crashlytics ممکن است نتواندBuildIdهای مرتبط را پیدا کند. توصیه می‌کنیم از مکان استاندارد برای کتابخانه‌های اشتراکی استفاده کنید.مطمئن شوید که
BuildIdها را در طول فرآیند ساخت حذف نمی‌کنید.توجه داشته باشید که نکات عیب‌یابی زیر هم برای ANRها و هم برای خرابی‌های بومی (native crashes) کاربرد دارند.
با اجرای
readelf -nروی فایل‌های باینری خود، وجودBuildIdها را بررسی کنید. اگرBuildIdها وجود ندارند،-Wl,--build-idرا به پرچم‌های سیستم ساخت خود اضافه کنید.بررسی کنید که ناخواسته برای کاهش حجم APK،
BuildIdها را حذف نکنید.اگر نسخه‌های ساده و بدون تغییر یک کتابخانه را نگه می‌دارید، حتماً در کد خود به نسخه صحیح اشاره کنید.
ممکن است بین تعداد ANR های گوگل پلی و Crashlytics اختلاف وجود داشته باشد. این به دلیل تفاوت در مکانیسم جمع‌آوری و گزارش داده‌های ANR قابل پیش‌بینی است. Crashlytics داده‌های ANR را هنگام راه‌اندازی مجدد برنامه گزارش می‌دهد، در حالی که Android Vitals داده‌های ANR را پس از وقوع ANR ارسال می‌کند.
علاوه بر این، Crashlytics فقط ANRهایی را نمایش می‌دهد که در دستگاه‌های دارای اندروید ۱۱+ رخ می‌دهند، در مقایسه با Google Play که ANRهایی را از دستگاه‌هایی با سرویس‌های Google Play و رضایت جمع‌آوری داده‌ها که پذیرفته شده‌اند، نمایش می‌دهد.
زنجیره ابزارهای LLVM و GNU پیش‌فرض‌ها و رویه‌های متمایزی برای بخش فقط خواندنی فایل‌های باینری برنامه شما دارند که ممکن است باعث ایجاد ردپاهای پشته‌ای متناقض در کنسول Firebase شود. برای کاهش این مشکل، پرچم‌های پیونددهنده زیر را به فرآیند ساخت خود اضافه کنید:
اگر از لینکر
lldاز مجموعه ابزار LLVM استفاده می‌کنید، موارد زیر را اضافه کنید:-Wl,--no-rosegmentاگر از لینکر
ld.goldاز مجموعه ابزار GNU استفاده می‌کنید، موارد زیر را اضافه کنید:-Wl,--rosegment
اگر هنوز شاهد ناسازگاری‌های ردیابی پشته هستید (یا اگر هیچ یک از پرچم‌ها به زنجیره ابزار شما مربوط نمی‌شوند)، سعی کنید موارد زیر را به فرآیند ساخت خود اضافه کنید:
-fno-omit-frame-pointer افزونه‌ی Crashlytics یک مولد فایل نماد Breakpad سفارشی‌سازی‌شده را در خود جای داده است. اگر ترجیح می‌دهید از فایل باینری خودتان برای تولید فایل‌های نماد Breakpad استفاده کنید (برای مثال، اگر ترجیح می‌دهید تمام فایل‌های اجرایی بومی را در زنجیره‌ی ساخت خود از منبع بسازید)، از ویژگی افزونه‌ی اختیاری symbolGeneratorBinary برای مشخص کردن مسیر فایل اجرایی استفاده کنید.
شما می‌توانید مسیر فایل باینری تولیدکننده فایل نماد Breakpad را به یکی از دو روش زیر مشخص کنید:
گزینه ۱ : مسیر را از طریق افزونه
firebaseCrashlyticsدر فایلbuild.gradleخود مشخص کنیدموارد زیر را به فایل
build.gradle.ktsدر سطح برنامه خود اضافه کنید:افزونه Gradle نسخه ۳.۰.۰+
android { buildTypes { release { configure<CrashlyticsExtension> { nativeSymbolUploadEnabled = true // Add these optional fields to specify the path to the executable symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } }
نسخه‌های پایین‌تر افزونه
android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
گزینه ۲ : مسیر را از طریق یک خط ویژگی در فایل ویژگی‌های Gradle خود مشخص کنید
شما می‌توانید از ویژگی
com.google.firebase.crashlytics.breakpadBinaryبرای مشخص کردن مسیر فایل اجرایی استفاده کنید.شما می‌توانید فایل ویژگی‌های Gradle خود را به صورت دستی به‌روزرسانی کنید یا فایل را از طریق خط فرمان به‌روزرسانی کنید. به عنوان مثال، برای مشخص کردن مسیر از طریق خط فرمان، از دستوری مانند زیر استفاده کنید:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
اگر با خطای زیر مواجه شدید، احتمالاً از نسخه‌ای از DexGuard استفاده می‌کنید که با Firebase Crashlytics SDK سازگار نیست:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
این استثنا برنامه شما را از کار نمی‌اندازد، اما از ارسال گزارش‌های خرابی جلوگیری می‌کند. برای رفع این مشکل:
مطمئن شوید که از آخرین نسخه DexGuard 8.x استفاده می‌کنید. آخرین نسخه شامل قوانینی است که توسط Firebase Crashlytics SDK الزامی است.
اگر نمی‌خواهید نسخه DexGuard خود را تغییر دهید، خط زیر را به قوانین مبهم‌سازی (در فایل پیکربندی DexGuard) خود اضافه کنید:
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
وقتی یک برنامه از یک مبهم‌ساز استفاده می‌کند که پسوند فایل را افشا نمی‌کند، Crashlytics به طور پیش‌فرض هر مشکل را با پسوند فایل .java تولید می‌کند.
برای اینکه Crashlytics بتواند با پسوند صحیح فایل مشکل ایجاد کند، مطمئن شوید که برنامه شما از تنظیمات زیر استفاده می‌کند:
- از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند
- از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند. برای به‌روزرسانی برنامه خود به R8، این مستندات را دنبال کنید.
توجه داشته باشید که پس از به‌روزرسانی به تنظیمات شرح داده شده در بالا، ممکن است با مشکلات جدید .kt مواجه شوید که تکرار مشکلات موجود .java هستند. برای کسب اطلاعات بیشتر در مورد این شرایط، به سوالات متداول مراجعه کنید.
از اواسط دسامبر ۲۰۲۱، Crashlytics پشتیبانی از برنامه‌هایی که از Kotlin استفاده می‌کنند را بهبود بخشید.
تا همین اواخر، ابزارهای مبهم‌سازی موجود، پسوند فایل را نمایش نمی‌دادند، بنابراین Crashlytics هر مشکل را به طور پیش‌فرض با پسوند فایل .java تولید می‌کرد. با این حال، از اندروید Gradle 4.2.0 به بعد، R8 از پسوند فایل پشتیبانی می‌کند.
با این به‌روزرسانی، Crashlytics اکنون می‌تواند تشخیص دهد که آیا هر کلاس مورد استفاده در برنامه با کاتلین نوشته شده است یا خیر و نام فایل صحیح را در امضای مشکل لحاظ کند. اگر برنامه شما تنظیمات زیر را داشته باشد، اکنون خرابی‌ها به درستی به فایل‌های .kt (به صورت مناسب) نسبت داده می‌شوند:
- برنامه شما از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند.
- برنامه شما از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند.
از آنجایی که کرش‌های جدید اکنون پسوند فایل صحیح را در امضای مشکل خود قرار می‌دهند، ممکن است مشکلات جدید .kt را ببینید که در واقع فقط کپی‌هایی از مشکلات موجود با برچسب .java هستند. در کنسول Firebase ، ما سعی می‌کنیم شناسایی کنیم و به شما اطلاع دهیم که آیا یک مشکل جدید .kt کپی احتمالی یک مشکل موجود با برچسب .java است یا خیر.
یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سوالات، به‌روزرسانی وضعیت و غیره اظهار نظر کنند.
وقتی یکی از اعضای پروژه یادداشتی ارسال می‌کند، ایمیل حساب گوگل او روی آن یادداشت برچسب‌گذاری می‌شود. این آدرس ایمیل، به همراه یادداشت، برای همه اعضای پروژه که دسترسی مشاهده یادداشت را دارند، قابل مشاهده است.
در ادامه، دسترسی‌های لازم برای مشاهده، نوشتن و حذف یادداشت‌ها شرح داده شده است:
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک مسئله بنویسند.
- مالک یا ویرایشگر پروژه، مدیر Firebase ، مدیر Quality یا مدیر Crashlytics
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های ارسال شده در مورد یک مسئله را مشاهده کنند، اما نمی‌توانند یادداشتی را حذف یا بنویسند.
- نمایشگر پروژه، نمایشگر فایربیس ، نمایشگر کیفیت یا نمایشگر Crashlytics
ادغام‌ها
اگر پروژه شما از Crashlytics در کنار SDK Google Mobile Ads استفاده می‌کند، احتمالاً گزارش‌دهنده‌های خرابی هنگام ثبت کنترل‌کننده‌های خطا تداخل ایجاد می‌کنند. برای رفع این مشکل، با فراخوانی disableSDKCrashReporting ، گزارش خرابی را در SDK Mobile Ads غیرفعال کنید.
پس از اینکه Crashlytics به BigQuery متصل کردید، مجموعه داده‌های جدیدی که ایجاد می‌کنید، صرف نظر از موقعیت مکانی پروژه Firebase شما، به طور خودکار در ایالات متحده قرار می‌گیرند.
پشتیبانی پلتفرم
Firebase Crashlytics NDK از ARMv5 (armeabi) پشتیبانی نمی‌کند. پشتیبانی از این ABI از NDK r17 حذف شده است.
مسائل پسرفت کرده
زمانی که قبلاً یک مشکل را بسته‌اید، اما Crashlytics گزارش جدیدی مبنی بر وقوع مجدد آن مشکل دریافت می‌کند، یک مشکل پسرفت داشته است. Crashlytics به‌طور خودکار این مشکلات پسرفت‌شده را دوباره باز می‌کند تا بتوانید آنها را متناسب با برنامه خود برطرف کنید.
در اینجا یک سناریوی مثالی آورده شده است که توضیح می‌دهد چگونه Crashlytics یک مسئله را به عنوان یک رگرسیون طبقه‌بندی می‌کند:
- برای اولین بار، Crashlytics گزارشی از خرابی مربوط به خرابی "A" دریافت می‌کند. Crashlytics یک شماره مربوطه برای آن خرابی (شماره "A") ایجاد می‌کند.
- شما این اشکال را سریع برطرف می‌کنید، مشکل «الف» را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
- Crashlytics پس از اینکه مشکل را بستید، گزارش دیگری در مورد مشکل «الف» دریافت می‌کند.
- اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که آن نسخه برای هرگونه خرابی، گزارش خرابی ارسال کرده است)، Crashlytics مشکل را به عنوان مشکل رفع‌شده در نظر نمی‌گیرد. مشکل بسته باقی خواهد ماند.
- اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن اطلاعی نداشته است (به این معنی که آن نسخه هرگز هیچ گزارش خرابی برای هیچ خرابی ارسال نکرده است)، Crashlytics مشکل را رفع شده در نظر می‌گیرد و دوباره آن را باز می‌کند.
وقتی یک مشکل دوباره حل می‌شود، ما یک هشدار تشخیص حل مشکل ارسال می‌کنیم و یک سیگنال حل مشکل به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics مشکل را دوباره باز کرده است. اگر نمی‌خواهید مشکلی به دلیل الگوریتم حل مشکل ما دوباره باز شود، به جای بستن آن، مشکل را «بی‌صدا» کنید.
اگر گزارشی از نسخه قدیمی برنامه باشد که هنگام بستن مشکل، هیچ گزارش خرابی ارسال نکرده باشد، Crashlytics مشکل را برطرف شده در نظر می‌گیرد و آن را دوباره باز می‌کند.
این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما هنوز کاربرانی روی نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر به‌طور اتفاقی، یکی از آن نسخه‌های قدیمی‌تر هنگام بستن مشکل، هیچ گزارش خرابی ارسال نکرده باشد و آن کاربران شروع به مواجهه با اشکال کنند، آن گزارش‌های خرابی باعث ایجاد یک مشکل رگرسیون می‌شوند.
اگر نمی‌خواهید به دلیل الگوریتم رگرسیون ما، مسئله دوباره باز شود، به جای بستن آن، آن را «بی‌صدا» کنید.