عیب یابی Crashlytics و سوالات متداول

مشاهده‌ی قالب‌های مختلف (و گاهی اوقات «انواع») برای برخی از مسائل در جدول مسائل

ممکن است متوجه دو فرمت مختلف برای مشکلات ذکر شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است متوجه ویژگی‌ای به نام "انواع" در برخی از مشکلات خود شوید. دلیل آن این است!

در اوایل سال ۲۰۲۳، ما یک موتور تحلیل بهبود یافته برای گروه‌بندی رویدادها و همچنین یک طراحی به‌روز شده و برخی ویژگی‌های پیشرفته برای مسائل جدید (مانند انواع مختلف!) را ارائه دادیم. برای جزئیات بیشتر، به پست وبلاگ اخیر ما مراجعه کنید، اما می‌توانید نکات برجسته را در زیر بخوانید.

Crashlytics تمام رویدادهای برنامه شما (مانند خرابی‌ها، خطاهای غیرفاجعه‌آمیز و ANRها) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مشکلات (issues ) ایجاد می‌کند - همه رویدادهای یک مشکل (issue) یک نقطه شکست مشترک دارند.

برای گروه‌بندی رویدادها در این مسائل، موتور تحلیل بهبود یافته اکنون جنبه‌های زیادی از رویداد، از جمله فریم‌های موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگی‌های پلتفرم یا نوع خطا را بررسی می‌کند.

با این حال، در این گروه از رویدادها، ممکن است ردپاهای پشته منجر به خرابی متفاوت باشند. یک ردپای پشته متفاوت می‌تواند به معنای علت ریشه‌ای متفاوت باشد. برای نمایش این تفاوت احتمالی در یک مسئله، اکنون انواعی را در مسائل ایجاد می‌کنیم - هر نوع، زیرگروهی از رویدادها در یک مسئله است که نقطه خرابی یکسانی دارند و یک ردپای پشته مشابه. با انواع، می‌توانید رایج‌ترین ردپاهای پشته را در یک مسئله اشکال‌زدایی کنید و تعیین کنید که آیا علل ریشه‌ای متفاوتی منجر به خرابی می‌شوند یا خیر.

در اینجا چیزی است که با این پیشرفت‌ها تجربه خواهید کرد:

• فراداده‌های اصلاح‌شده در ردیف مشکل نمایش داده می‌شوند
  اکنون درک و اولویت‌بندی مشکلات در برنامه شما آسان‌تر است.

• مسائل تکراری کمتر
  تغییر شماره خط منجر به مشکل جدیدی نمی‌شود.

• اشکال‌زدایی آسان‌تر مسائل پیچیده با علل ریشه‌ای مختلف
  از انواع مختلف برای اشکال‌زدایی رایج‌ترین ردپاهای پشته در یک مسئله استفاده کنید.

• هشدارها و سیگنال‌های معنادارتر
  یک مشکل جدید در واقع نشان دهنده یک باگ جدید است.

• جستجوی قدرتمندتر
  هر شماره شامل فراداده‌های قابل جستجوی بیشتری مانند نوع استثنا و نام بسته است.

نحوه‌ی اعمال این بهبودها به شرح زیر است:

• وقتی رویدادهای جدیدی از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا با مشکل موجود مطابقت دارند یا خیر.

• اگر هیچ تطابقی وجود نداشته باشد، ما به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندتر خود را برای رویداد اعمال می‌کنیم و یک issue جدید با طراحی فراداده اصلاح‌شده ایجاد می‌کنیم.

این اولین به‌روزرسانی بزرگی است که ما در گروه‌بندی رویدادهای خود انجام می‌دهیم. اگر بازخوردی دارید یا با مشکلی مواجه شده‌اید، با ثبت گزارش به ما اطلاع دهید.

عدم مشاهده لاگ‌های breadcrumb

اگر گزارش‌های breadcrumb را مشاهده نمی‌کنید ( iOS+ | Android | Flutter | Unity )، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را برآورده می‌کنید:

• شما Google Analytics در پروژه فایربیس خود فعال کرده‌اید .

• شما اشتراک‌گذاری داده‌ها را برای Google Analytics فعال کرده‌اید. برای اطلاعات بیشتر در مورد این تنظیم، به مدیریت تنظیمات اشتراک‌گذاری داده‌های آنالیتیکس خود مراجعه کنید.

• شما کیت توسعه نرم‌افزار Firebase برای Google Analytics را به برنامه خود اضافه کرده‌اید: iOS+ | اندروید | فلاتر | یونیتی .
  این SDK باید علاوه بر Crashlytics SDK اضافه شود.

• شما از آخرین نسخه‌های Firebase SDK برای تمام محصولاتی که در برنامه خود استفاده می‌کنید ( iOS+ | Android | Flutter | Unity ) استفاده می‌کنید.

  برای پلتفرم‌های اپل و برنامه‌های اندروید، به خصوص بررسی کنید که حداقل از نسخه زیر از Firebase SDK برای Google Analytics استفاده می‌کنید: iOS+ — نسخه ۶.۳.۱+ (نسخه ۸.۹.۰+ برای macOS و tvOS) | اندروید — نسخه 17.2.3+ ( BoM v24.7.1+).

عدم مشاهده هشدارهای سرعت

اگر هشدارهای سرعت را نمی‌بینید، مطمئن شوید که از ... استفاده می‌کنید.

عدم مشاهده معیارهای بدون خرابی (یا مشاهده معیارهای غیرقابل اعتماد)

اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) را نمی‌بینید یا معیارهای غیرقابل اعتمادی را می‌بینید، موارد زیر را بررسی کنید:

• مطمئن شوید که از ... استفاده می‌کنید

• مطمئن شوید که تنظیمات جمع‌آوری داده‌های شما بر کیفیت معیارهای بدون خرابی شما تأثیر نمی‌گذارد:

  • اگر با غیرفعال کردن گزارش خودکار خرابی، گزارش‌دهی اختیاری را فعال کنید ، اطلاعات خرابی فقط از کاربرانی که صریحاً در جمع‌آوری داده‌ها مشارکت داشته‌اند، می‌تواند به Crashlytics ارسال شود. بنابراین، دقت معیارهای بدون خرابی تحت تأثیر قرار خواهد گرفت زیرا Crashlytics فقط اطلاعات خرابی این کاربران انتخابی (و نه همه کاربران شما) را دارد. این بدان معناست که معیارهای بدون خرابی شما ممکن است کمتر قابل اعتماد باشند و کمتر نشان‌دهنده پایداری کلی برنامه شما باشند.

  • اگر جمع‌آوری خودکار داده‌ها را غیرفعال کرده‌اید، می‌توانید sendUnsentReports برای ارسال گزارش‌های ذخیره‌شده روی دستگاه به Crashlytics استفاده کنید. استفاده از این روش، داده‌های خرابی را به Crashlytics ارسال می‌کند، اما داده‌های جلسات را نه، که باعث می‌شود نمودارهای کنسول مقادیر کم یا صفر را برای معیارهای بدون خرابی نشان دهند.

کاربران بدون خرابی چگونه محاسبه می‌شوند؟

به بخش «معیارهای بدون خرابی را درک کنید» مراجعه کنید.

چه کسی می‌تواند یادداشت‌های مربوط به یک مسئله را مشاهده، بنویسد و حذف کند؟

یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سوالات، به‌روزرسانی وضعیت و غیره اظهار نظر کنند.

وقتی یکی از اعضای پروژه یادداشتی ارسال می‌کند، ایمیل حساب گوگل او روی آن یادداشت برچسب‌گذاری می‌شود. این آدرس ایمیل، به همراه یادداشت، برای همه اعضای پروژه که دسترسی مشاهده یادداشت را دارند، قابل مشاهده است.

در ادامه، دسترسی‌های لازم برای مشاهده، نوشتن و حذف یادداشت‌ها شرح داده شده است:

• اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک مسئله بنویسند.

  • مالک یا ویرایشگر پروژه، مدیر Firebase ، مدیر Quality یا مدیر Crashlytics

• اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های ارسال شده در مورد یک مسئله را مشاهده کنند، اما نمی‌توانند یادداشتی را حذف یا بنویسند.

  • نمایشگر پروژه، نمایشگر فایربیس ، نمایشگر کیفیت یا نمایشگر Crashlytics

مسئله‌ی پس‌رفته چیست؟

زمانی که قبلاً یک مشکل را بسته‌اید، اما Crashlytics گزارش جدیدی مبنی بر وقوع مجدد آن مشکل دریافت می‌کند، یک مشکل پسرفت داشته است. Crashlytics به‌طور خودکار این مشکلات پسرفت‌شده را دوباره باز می‌کند تا بتوانید آن‌ها را متناسب با برنامه خود برطرف کنید.

در اینجا یک سناریوی مثالی آورده شده است که توضیح می‌دهد چگونه Crashlytics یک مسئله را به عنوان یک رگرسیون طبقه‌بندی می‌کند:

1. برای اولین بار، Crashlytics گزارشی از خرابی مربوط به خرابی "A" دریافت می‌کند. Crashlytics یک شماره مربوطه برای آن خرابی (شماره "A") ایجاد می‌کند.
2. شما این اشکال را سریع برطرف می‌کنید، مشکل «الف» را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
3. Crashlytics پس از اینکه مشکل را بستید، گزارش دیگری در مورد مشکل «الف» دریافت می‌کند.
   • اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که آن نسخه برای هرگونه خرابی، گزارش خرابی ارسال کرده است)، Crashlytics مشکل را به عنوان مشکل رفع‌شده در نظر نمی‌گیرد. مشکل بسته باقی خواهد ماند.
   • اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن اطلاعی نداشته است (به این معنی که آن نسخه هرگز هیچ گزارش خرابی برای هیچ خرابی ارسال نکرده است)، Crashlytics مشکل را رفع شده در نظر می‌گیرد و دوباره آن را باز می‌کند.

وقتی یک مشکل دوباره حل می‌شود، ما یک هشدار تشخیص حل مشکل ارسال می‌کنیم و یک سیگنال حل مشکل به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics مشکل را دوباره باز کرده است. اگر نمی‌خواهید مشکلی به دلیل الگوریتم حل مشکل ما دوباره باز شود، به جای بستن آن، آن را «بی‌صدا» کنید.

چرا مشکلات مربوط به نسخه‌های قدیمی‌تر برنامه را می‌بینم؟

اگر گزارشی از نسخه قدیمی برنامه باشد که هنگام بستن مشکل، هیچ گزارش خرابی ارسال نکرده باشد، Crashlytics مشکل را برطرف شده در نظر می‌گیرد و آن را دوباره باز می‌کند.

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

اگر نمی‌خواهید به دلیل الگوریتم رگرسیون ما، مسئله دوباره باز شود، به جای بستن آن، آن را «بی‌صدا» کنید.

برنامه همچنین از SDK Google Mobile Ads استفاده می‌کند اما دچار خرابی نمی‌شود

اگر پروژه شما از Crashlytics در کنار SDK Google Mobile Ads استفاده می‌کند، احتمالاً گزارش‌دهنده‌های خرابی هنگام ثبت کنترل‌کننده‌های خطا تداخل ایجاد می‌کنند. برای رفع این مشکل، با فراخوانی disableSDKCrashReporting ، گزارش خرابی را در SDK Mobile Ads غیرفعال کنید.

مجموعه داده‌های BigQuery من کجا قرار دارد؟

پس از اینکه Crashlytics به BigQuery پیوند دادید، مجموعه داده‌های جدیدی که ایجاد می‌کنید، صرف نظر از موقعیت مکانی پروژه Firebase شما، به طور خودکار در ایالات متحده قرار می‌گیرند.

dSYM ها گم شده اند/آپلود نمی شوند

برای آپلود dSYM های پروژه خود و دریافت خروجی واضح، موارد زیر را بررسی کنید:

1. مطمئن شوید که مرحله ساخت پروژه شما شامل اسکریپت اجرای Crashlytics است، که به Xcode اجازه می‌دهد dSYM های پروژه شما را در زمان ساخت آپلود کند (برای دستورالعمل‌های افزودن اسکریپت، بخش «راهنمای اولیه Crashlytics » را مطالعه کنید). پس از به‌روزرسانی پروژه، یک کرش اجباری ایجاد کنید و تأیید کنید که کرش در داشبورد Crashlytics ظاهر می‌شود.

2. اگر در کنسول Firebase هشدار "Missing dSYM" را مشاهده کردید، Xcode را بررسی کنید تا مطمئن شوید که dSYM های لازم برای ساخت را به درستی تولید می‌کند .

3. اگر Xcode به درستی dSYM ها را تولید می‌کند، و شما هنوز dSYM های از دست رفته را می‌بینید، احتمالاً ابزار اجرای اسکریپت هنگام آپلود dSYM ها گیر کرده است. در این حالت، هر یک از موارد زیر را امتحان کنید:

   • مطمئن شوید که از آخرین نسخه Crashlytics استفاده می‌کنید.

   • فایل‌های dSYM مفقود شده را به صورت دستی آپلود کنید:

     • گزینه ۱: از گزینه «کشیدن و رها کردن» مبتنی بر کنسول در تب dSYMs برای آپلود یک آرشیو زیپ حاوی فایل‌های dSYM مفقود شده استفاده کنید.
     • گزینه ۲: از اسکریپت upload-symbols برای آپلود فایل‌های dSYM مفقود شده، برای UUID های ارائه شده در تب dSYMs، استفاده کنید.

4. اگر همچنان dSYM های از دست رفته را مشاهده می‌کنید، یا آپلودها هنوز ناموفق هستند، با پشتیبانی Firebase تماس بگیرید و حتماً گزارش‌های خود را وارد کنید.

تصادفات به خوبی نمادین‌سازی نشده‌اند

اگر به نظر می‌رسد که نشانه‌های پشته شما به خوبی نمادین‌سازی نشده‌اند، موارد زیر را بررسی کنید:

• اگر فریم‌های کتابخانه برنامه شما فاقد ارجاع به کد برنامه هستند، مطمئن شوید که -fomit-frame-pointer به عنوان یک پرچم کامپایل تنظیم نشده است.

• اگر چندین فریم (Missing) برای کتابخانه برنامه خود مشاهده می‌کنید، بررسی کنید که آیا dSYM های اختیاری به عنوان گم‌شده (برای نسخه برنامه آسیب‌دیده) در برگه dSYM های Crashlytics در کنسول Firebase وجود دارد یا خیر. در این صورت، مرحله عیب‌یابی "هشدار dSYM گم‌شده" را در بخش سوالات متداول dSYM های گم‌شده/ آپلود نشده در این صفحه دنبال کنید. توجه داشته باشید که آپلود این dSYM ها، خرابی‌هایی را که قبلاً رخ داده‌اند، نمادین نمی‌کند، اما این به تضمین نمادین‌سازی برای خرابی‌های آینده کمک می‌کند.

آیا می‌توانم Crashlytics برای macOS یا tvOS استفاده کنم؟

بله، می‌توانید Crashlytics در پروژه‌های macOS و tvOS پیاده‌سازی کنید. مطمئن شوید که نسخه ۸.۹.۰+ از Firebase SDK for Google Analytics را شامل می‌شود تا خرابی‌ها به معیارهای جمع‌آوری‌شده توسط Google Analytics (کاربران بدون خرابی، آخرین نسخه، هشدارهای سرعت و گزارش‌های breadcrumb) دسترسی داشته باشند.

آیا می‌توانم Crashlytics در یک پروژه Firebase با چندین برنامه در پلتفرم‌های مختلف اپل استفاده کنم؟

اکنون می‌توانید خرابی‌ها را برای چندین برنامه در یک پروژه Firebase گزارش دهید، حتی زمانی که برنامه‌ها برای پلتفرم‌های مختلف اپل (مثلاً iOS، tvOS و Mac Catalyst) ساخته شده‌اند. پیش از این، اگر برنامه‌ها دارای شناسه بسته یکسانی بودند، باید آنها را به پروژه‌های Firebase جداگانه تقسیم می‌کردید.

چرا ANRها فقط برای اندروید ۱۱+ گزارش می‌شوند؟

Crashlytics از گزارش‌دهی ANR برای برنامه‌های اندروید از دستگاه‌هایی که اندروید ۱۱ و بالاتر را اجرا می‌کنند، پشتیبانی می‌کند. API زیربنایی که ما برای جمع‌آوری ANRها استفاده می‌کنیم ( getHistoricalProcessExitReasons ) نسبت به رویکردهای مبتنی بر SIGQUIT یا watchdog قابل اعتمادتر است. این API فقط در دستگاه‌های اندروید ۱۱+ در دسترس است.

چرا بعضی از ANR ها BuildId خود را ندارند؟

اگر برخی از 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 قابل پیش‌بینی است. Crashlytics داده‌های ANR را هنگام راه‌اندازی مجدد برنامه گزارش می‌دهد، در حالی که Android Vitals داده‌های ANR را پس از وقوع ANR ارسال می‌کند.

علاوه بر این، Crashlytics فقط ANRهایی را نمایش می‌دهد که در دستگاه‌های دارای اندروید ۱۱+ رخ می‌دهند، در مقایسه با Google Play که ANRهایی را از دستگاه‌هایی با سرویس‌های Google Play و رضایت جمع‌آوری داده‌ها که پذیرفته شده‌اند، نمایش می‌دهد.

چرا شاهد خرابی‌هایی از فایل‌های .kt هستم که با برچسب مشکلات .java مشخص شده‌اند؟

وقتی یک برنامه از یک مبهم‌ساز استفاده می‌کند که پسوند فایل را افشا نمی‌کند، Crashlytics به طور پیش‌فرض هر مشکل را با پسوند فایل .java تولید می‌کند.

برای اینکه Crashlytics بتواند با پسوند صحیح فایل مشکل ایجاد کند، مطمئن شوید که برنامه شما از تنظیمات زیر استفاده می‌کند:

• از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند
• از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند. برای به‌روزرسانی برنامه خود به R8، این مستندات را دنبال کنید.

توجه داشته باشید که پس از به‌روزرسانی به تنظیمات شرح داده شده در بالا، ممکن است با مشکلات جدید .kt مواجه شوید که تکرار مشکلات موجود .java هستند. برای کسب اطلاعات بیشتر در مورد این شرایط، به سوالات متداول مراجعه کنید.

چرا مشکلات .kt را می‌بینم که کپی مشکلات .java موجود هستند؟

از اواسط دسامبر ۲۰۲۱، Crashlytics پشتیبانی از برنامه‌هایی که از Kotlin استفاده می‌کنند را بهبود بخشید.

تا همین اواخر، ابزارهای مبهم‌سازی موجود، پسوند فایل را نمایش نمی‌دادند، بنابراین Crashlytics هر مشکل را به طور پیش‌فرض با پسوند فایل .java تولید می‌کرد. با این حال، از اندروید Gradle 4.2.0 به بعد، R8 از پسوند فایل پشتیبانی می‌کند.

با این به‌روزرسانی، Crashlytics اکنون می‌تواند تشخیص دهد که آیا هر کلاس مورد استفاده در برنامه با کاتلین نوشته شده است یا خیر و نام فایل صحیح را در امضای مشکل لحاظ کند. اگر برنامه شما تنظیمات زیر را داشته باشد، اکنون خرابی‌ها به درستی به فایل‌های .kt (به صورت مناسب) نسبت داده می‌شوند:

• برنامه شما از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند.
• برنامه شما از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند.

از آنجایی که کرش‌های جدید اکنون پسوند فایل صحیح را در امضای مشکل خود قرار می‌دهند، ممکن است مشکلات جدید .kt را ببینید که در واقع فقط کپی‌هایی از مشکلات موجود با برچسب .java هستند. در کنسول Firebase ، ما سعی می‌کنیم شناسایی کنیم و به شما اطلاع دهیم که آیا یک مشکل جدید .kt کپی احتمالی یک مشکل موجود با برچسب .java است یا خیر.

عدم خرابی با Dexguard

اگر با خطای زیر مواجه شدید، احتمالاً از نسخه‌ای از DexGuard استفاده می‌کنید که با Firebase Crashlytics SDK سازگار نیست:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

تفاوت‌های بین ردپاهای پشته NDK در داشبورد Crashlytics و logcat

زنجیره ابزارهای LLVM و GNU پیش‌فرض‌ها و رویه‌های متمایزی برای بخش فقط خواندنی فایل‌های باینری برنامه شما دارند که ممکن است باعث ایجاد ردپاهای پشته‌ای متناقض در کنسول Firebase شود. برای کاهش این مشکل، پرچم‌های پیونددهنده زیر را به فرآیند ساخت خود اضافه کنید:

• اگر از لینکر lld از مجموعه ابزار LLVM استفاده می‌کنید، موارد زیر را اضافه کنید:

  -Wl,--no-rosegment

• اگر از لینکر ld.gold از مجموعه ابزار GNU استفاده می‌کنید، موارد زیر را اضافه کنید:

  -Wl,--rosegment

اگر هنوز شاهد ناسازگاری‌های ردیابی پشته هستید (یا اگر هیچ یک از پرچم‌ها به زنجیره ابزار شما مربوط نمی‌شوند)، سعی کنید موارد زیر را به فرآیند ساخت خود اضافه کنید:

-fno-omit-frame-pointer

چگونه می‌توانم از فایل باینری تولیدکننده‌ی نماد Breakpad خودم برای NDK استفاده کنم؟

افزونه‌ی 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
  

آیا Crashlytics از armeabi پشتیبانی می‌کند؟

Firebase Crashlytics NDK از ARMv5 (armeabi) پشتیبانی نمی‌کند. پشتیبانی از این ABI از NDK r17 حذف شده است.

مشاهده‌ی ردپاهای پشته‌ای بدون نمادگذاری برای برنامه‌های اندروید در داشبورد Crashlytics

اگر از Unity IL2CPP استفاده می‌کنید و ردپاهای پشته بدون نماد را مشاهده می‌کنید، موارد زیر را امتحان کنید:

1. مطمئن شوید که از نسخه ۸.۶.۱ یا بالاتر Crashlytics Unity SDK استفاده می‌کنید.

2. مطمئن شوید که برای تولید و آپلود فایل نماد خود، دستور crashlytics:symbols:upload در Firebase CLI را تنظیم و اجرا کرده‌اید.

   شما باید هر بار که یک نسخه آزمایشی یا هر نسخه‌ای که می‌خواهید ردپاهای پشته نمادین آن را در کنسول Firebase ببینید، ایجاد می‌کنید، این دستور CLI را اجرا کنید. برای کسب اطلاعات بیشتر به بخش «گزارش‌های خرابی خوانا» مراجعه کنید.

آیا می‌توان Crashlytics با برنامه‌هایی که از IL2CPP استفاده می‌کنند، استفاده کرد؟

بله، Crashlytics می‌تواند ردیابی‌های پشته نمادین را برای برنامه‌های شما که از IL2CPP استفاده می‌کنند، نمایش دهد. این قابلیت برای برنامه‌های منتشر شده در پلتفرم‌های اندروید یا اپل در دسترس است. در اینجا کاری که باید انجام دهید آمده است:

1. مطمئن شوید که از نسخه ۸.۶.۰ یا بالاتر Crashlytics Unity SDK استفاده می‌کنید.

2. وظایف لازم برای پلتفرم خود را انجام دهید:

   • برای برنامه‌های پلتفرم اپل : هیچ اقدام خاصی لازم نیست. برای برنامه‌های پلتفرم اپل، افزونه Firebase Unity Editor به طور خودکار پروژه Xcode شما را برای آپلود نمادها پیکربندی می‌کند.

   • برای برنامه‌های اندروید : مطمئن شوید که برای ایجاد و آپلود فایل نماد خود، دستور crashlytics:symbols:upload در Firebase CLI را تنظیم و اجرا کرده‌اید.

     شما باید هر بار که یک نسخه آزمایشی یا هر نسخه‌ای که می‌خواهید ردپاهای پشته نمادین آن را در کنسول Firebase ببینید، ایجاد می‌کنید، این دستور CLI را اجرا کنید. برای کسب اطلاعات بیشتر به بخش «گزارش‌های خرابی خوانا» مراجعه کنید.

چرا یک برنامه باید استثنائاتِ پیش‌بینی‌نشده را به عنوان خطای مهلک گزارش کند؟

با گزارش استثنائاتِ شناسایی‌نشده به عنوان مواردِ بحرانی، شما می‌توانید نشانه‌ی واقع‌بینانه‌تری از اینکه چه استثنائاتی ممکن است منجر به غیرقابل‌بازی شدن بازی شوند، حتی اگر برنامه همچنان به اجرا ادامه دهد، داشته باشید.

توجه داشته باشید که اگر شروع به گزارش تصادفات منجر به فوت کنید، احتمالاً درصد کاربران بدون تصادف (CFU) شما کاهش می‌یابد، اما معیار CFU بیشتر نمایانگر تجربیات کاربران نهایی با برنامه شما خواهد بود.

کدام موارد استثنا به عنوان فوتی گزارش خواهند شد؟

برای اینکه Crashlytics یک استثنای ناشناخته را به عنوان خطای مهلک گزارش کند، باید هر دو شرط زیر برقرار باشد:

• در طول مقداردهی اولیه برنامه، ویژگی ReportUncaughtExceptionsAsFatal باید روی true تنظیم شود .

• برنامه شما (یا یک کتابخانه شامل) یک استثنا را صادر می‌کند که دریافت نشده است. استثنایی که ایجاد شده است، اما دریافت نشده است ، به عنوان استثنای دریافت نشده در نظر گرفته نمی‌شود.

بعد از فعال کردن گزارش استثنائاتِ بررسی نشده به عنوان خطاهای مهلک، حالا خطاهای مهلک جدید زیادی دارم. چگونه می‌توانم این خطاها را به درستی مدیریت کنم؟

وقتی گزارش‌هایی از استثنائاتِ مدیریت نشده به عنوان خطاهای مهلک دریافت می‌کنید، در اینجا چند گزینه برای مدیریت این استثنائاتِ مدیریت نشده ارائه شده است:

• در نظر بگیرید که چگونه می‌توانید شروع به دریافت و مدیریت این استثنائاتِ دریافت نشده کنید.
• گزینه‌های مختلفی را برای ثبت خطاها در کنسول اشکال‌زدایی Unity و Crashlytics در نظر بگیرید.

گرفتن و مدیریت استثنائات پرتاب شده

استثنائات برای انعکاس حالت‌های غیرمنتظره یا استثنایی ایجاد و ارسال می‌شوند. حل مشکلاتی که توسط یک استثنای ارسال شده منعکس می‌شوند، شامل بازگرداندن برنامه به حالت شناخته شده است (فرآیندی که به عنوان مدیریت استثنا شناخته می‌شود).

بهترین روش این است که تمام استثنائات پیش‌بینی‌شده را دریافت و مدیریت کنید، مگر اینکه برنامه را نتوان به حالت شناخته‌شده‌ای برگرداند.

برای کنترل اینکه کدام نوع استثنائات توسط چه کدی گرفته و مدیریت می‌شوند، کدی را که ممکن است استثنا ایجاد کند، در یک بلوک try-catch قرار دهید . مطمئن شوید که شرایط موجود در دستورات catch تا حد امکان محدود هستند تا استثنائات خاص را به طور مناسب مدیریت کنند.

ثبت خطاها در Unity یا Crashlytics

روش‌های مختلفی برای ثبت استثنائات در Unity یا Crashlytics وجود دارد تا به رفع اشکال کمک کند.

هنگام استفاده از Crashlytics ، دو گزینه رایج و توصیه‌شده در اینجا آمده است:

• گزینه ۱: در کنسول Unity چاپ کنید، اما در طول توسعه یا عیب‌یابی به Crashlytics گزارش ندهید

  • با استفاده از Debug.Log(exception) ، Debug.LogWarning(exception) و Debug.LogError(exception) که محتوای استثنا را در کنسول Unity چاپ می‌کنند و استثنا را دوباره پرتاب نمی‌کنند، در کنسول Unity چاپ کنید.

• گزینه ۲: برای گزارش‌های تلفیقی در داشبورد Crashlytics برای موقعیت‌های زیر، در Crashlytics آپلود کنید:

  • اگر یک استثنا ارزش ثبت شدن برای اشکال‌زدایی یک رویداد احتمالی بعدی Crashlytics را دارد، از Crashlytics.Log(exception.ToString()) استفاده کنید.
  • اگر یک استثنا، علیرغم شناسایی و مدیریت شدن، همچنان باید به Crashlytics گزارش شود، از Crashlytics.LogException(exception) برای ثبت آن به عنوان یک رویداد غیرمهلک استفاده کنید.

با این حال، اگر می‌خواهید یک رویداد مهلک را به صورت دستی به Unity Cloud Diagnostics گزارش دهید، می‌توانید از Debug.LogException استفاده کنید. این گزینه مانند گزینه ۱، استثنا را در کنسول Unity چاپ می‌کند، اما استثنا را نیز ارسال می‌کند (چه هنوز ارسال شده باشد و چه دریافت شده باشد). این خطا را به صورت غیر محلی ارسال می‌کند. این بدان معناست که حتی یک Debug.LogException(exception) اطراف با بلوک‌های try-catch همچنان منجر به یک استثنای دریافت نشده می‌شود.

بنابراین، اگر و فقط اگر می‌خواهید تمام موارد زیر را انجام دهید، Debug.LogException را فراخوانی کنید:

• برای چاپ استثنا در کنسول Unity.
• برای آپلود کردن استثنا به عنوان یک رویداد مهلک در Crashlytics .
• برای ایجاد استثنا، آن را به عنوان یک استثنای کنترل نشده در نظر بگیرید و آن را به Unity Cloud Diagnostics گزارش دهید.

توجه داشته باشید که اگر می‌خواهید یک استثنای گرفته شده را در کنسول Unity چاپ کنید و آن را به عنوان یک رویداد غیرفاتال در Crashlytics آپلود کنید، به جای آن موارد زیر را انجام دهید:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}