این صفحه راهنمایی عیب‌یابی و پاسخ به سؤالات متداول در مورد استفاده از Crashlytics را ارائه می‌کند. اگر چیزی را که به دنبالش هستید پیدا نکردید یا به کمک بیشتری نیاز دارید، با پشتیبانی Firebase تماس بگیرید.
عیب یابی عمومی/سؤالات متداول
ممکن است متوجه دو قالب مختلف برای مشکلات فهرست شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است در برخی از مشکلات خود متوجه ویژگی به نام "Variants" شوید. در اینجا دلیل آن است!
در اوایل سال 2023، موتور تجزیه و تحلیل بهبود یافته ای را برای گروه بندی رویدادها و همچنین طراحی به روز شده و برخی ویژگی های پیشرفته برای مسائل جدید (مانند انواع!) ارائه کردیم. برای همه جزئیات، پست اخیر وبلاگ ما را بررسی کنید، اما می توانید برای نکات مهم در زیر بخوانید.
Crashlytics همه رویدادهای برنامه شما (مانند خرابی‌ها، موارد غیرمرگبار و ANR) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مسائل ایجاد می‌کند — همه رویدادها در یک شماره یک نقطه شکست مشترک دارند.
برای گروه‌بندی رویدادها در این مسائل، موتور تجزیه و تحلیل بهبودیافته اکنون به بسیاری از جنبه‌های رویداد، از جمله فریم‌های موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگی‌های پلتفرم یا نوع خطا نگاه می‌کند.
با این حال، در این گروه از رویدادها، ردیابی پشته منجر به شکست ممکن است متفاوت باشد. ردیابی پشته‌ای متفاوت می‌تواند به معنای ریشه‌ای متفاوت باشد. برای نشان دادن این تفاوت احتمالی در یک شماره، اکنون انواع مختلفی را در شماره ایجاد می کنیم - هر گونه یک زیرگروه از رویدادها در یک شماره است که دارای نقطه شکست یکسان و ردیابی پشته مشابه است. با انواع مختلف، می‌توانید رایج‌ترین ردیابی‌های پشته را در یک موضوع اشکال زدایی کنید و تعیین کنید که آیا دلایل اصلی مختلف منجر به شکست می‌شوند یا خیر.
در اینجا چیزی است که با این بهبودها تجربه خواهید کرد:
ابرداده اصلاح شده در ردیف شماره نمایش داده می شود
اکنون درک و تریاژ مسائل در برنامه شما آسان تر شده است.مسائل تکراری کمتر
تغییر شماره خط منجر به مشکل جدیدی نمی شود.اشکال زدایی آسانتر مسائل پیچیده با دلایل ریشه ای مختلف
از انواع برای اشکال زدایی رایج ترین ردیابی پشته در یک شماره استفاده کنید.هشدارها و سیگنال های معنی دار تر
یک شماره جدید در واقع نشان دهنده یک باگ جدید است.جستجوی قدرتمندتر
هر شماره حاوی فراداده قابل جستجوی بیشتری است، مانند نوع استثنا و نام بسته.
در اینجا نحوه اجرای این بهبودها آمده است:
وقتی رویدادهای جدیدی را از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا آنها با مشکل موجود مطابقت دارند یا خیر.
اگر مطابقت وجود نداشته باشد، به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندانه‌تر خود را در رویداد اعمال می‌کنیم و یک مشکل جدید با طراحی ابرداده اصلاح‌شده ایجاد می‌کنیم.
این اولین به‌روزرسانی بزرگی است که ما در حال ایجاد گروه‌بندی رویداد خود هستیم. اگر بازخوردی دارید یا با مشکلی مواجه شدید، لطفاً با ارسال گزارش به ما اطلاع دهید.
اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) و/یا هشدارهای سرعت را نمی‌بینید، مطمئن شوید که ازCrashlytics SDK 11.7.0+.
اگر گزارش‌های پودر سوخاری را نمی‌بینید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را دارید:
شما Google Analytics را در پروژه Firebase خود فعال کرده اید.
اشتراک گذاری داده را برای Google Analytics فعال کرده اید. درباره این تنظیم در مدیریت تنظیمات به اشتراک گذاری داده Analytics خود بیشتر بیاموزید
شماSDK Firebase را برای Google Analyticsبرنامه شما اضافه کرد. این SDK باید علاوه بر Crashlytics SDK اضافه شود.
شما ازآخرین نسخه های Firebase SDKبرای همه محصولات برنامه خود استفاده می کنید.
اگر از Unity IL2CPP استفاده می‌کنید و ردپای پشته بدون نماد می‌بینید، موارد زیر را امتحان کنید:
مطمئن شوید که از نسخه ۸.۶.۱ یا بالاتر از Crashlytics Unity SDK استفاده می‌کنید.
مطمئن شوید که برای ایجاد و آپلود فایل نماد خود، دستور Firebase CLI
crashlytics:symbols:uploadتنظیم کرده اید و اجرا می کنید.شما باید این دستور CLI را هر بار که یک نسخه انتشار یا هر بیلدی ایجاد می کنید که می خواهید نشانه های پشته نمادین آن را در کنسول Firebase ببینید، اجرا کنید. در صفحه دریافت گزارش‌های خرابی خواندنی بیشتر بیاموزید.
بله، Crashlytics می‌تواند ردپای پشته نمادین را برای برنامه‌های شما که از IL2CPP استفاده می‌کنند نمایش دهد. این قابلیت برای برنامه های منتشر شده بر روی پلتفرم های اندروید یا اپل در دسترس است. در اینجا چیزی است که شما باید انجام دهید:
مطمئن شوید که از نسخه 8.6.0 یا بالاتر از Crashlytics Unity SDK استفاده می‌کنید.
وظایف لازم برای پلتفرم خود را تکمیل کنید:
برای برنامه های پلتفرم اپل : هیچ اقدام خاصی لازم نیست. برای برنامه های پلتفرم اپل، افزونه Firebase Unity Editor به طور خودکار پروژه Xcode شما را برای آپلود نمادها پیکربندی می کند.
برای برنامه‌های Android : مطمئن شوید که برای ایجاد و آپلود فایل نماد خود، دستور Firebase CLI
crashlytics:symbols:uploadتنظیم کرده‌اید و آن را اجرا می‌کنید.شما باید این دستور CLI را هر بار که یک نسخه انتشار یا هر بیلدی ایجاد می کنید که می خواهید نشانه های پشته نمادین آن را در کنسول Firebase ببینید، اجرا کنید. در صفحه دریافت گزارش‌های خرابی خواندنی بیشتر بیاموزید.
مقدار بدون خرابی نشان‌دهنده درصد کاربرانی است که با برنامه شما درگیر بوده‌اند اما در یک بازه زمانی خاص دچار خرابی نشده‌اند .
در اینجا فرمول محاسبه درصد کاربران بدون خرابی وجود دارد. مقادیر ورودی آن توسط Google Analytics ارائه شده است.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
وقتی خرابی رخ می‌دهد، Google Analytics یک نوع رویداد
app_exceptionارسال می‌کند و CRASHED_USERS تعداد کاربران مرتبط با آن نوع رویداد را نشان می‌دهد.ALL_USERS تعداد کل کاربرانی را نشان می‌دهد که در طول دوره زمانی که از منوی کشویی در سمت راست بالای داشبورد Crashlytics انتخاب کرده‌اید، با برنامه شما درگیر شده‌اند.
درصد کاربران بدون خرابی یک تجمع در طول زمان است، نه میانگین.
به عنوان مثال، تصور کنید برنامه شما سه کاربر دارد. ما آنها را User A، User B و User C می نامیم. جدول زیر نشان می دهد که چه کاربرانی هر روز با برنامه شما درگیر بوده اند و کدام یک از آن کاربران در آن روز خراب شده اند:
| دوشنبه | سهشنبه | چهار شنبه | |
|---|---|---|---|
| کاربرانی که با برنامه شما درگیر هستند | الف، ب، ج | الف، ب، ج | الف، ب |
| کاربری که دچار خرابی شده است | سی | ب | آ |
در روز چهارشنبه، درصد کاربران بدون خرابی شما 50٪ است (از هر 2 کاربر، 1 کاربر بدون خرابی بود).
دو نفر از کاربران شما روز چهارشنبه با برنامه شما درگیر شدند، اما تنها یکی از آنها (کاربر B) هیچ خرابی نداشت.در 2 روز گذشته، درصد کاربران بدون خرابی شما 33.3٪ است (از هر 3 کاربر، 1 کاربر بدون خرابی بود).
سه نفر از کاربران شما در دو روز گذشته با برنامه شما درگیر بودند، اما فقط یکی از آنها (کاربر C) هیچ خرابی نداشت.در 3 روز گذشته، درصد کاربران بدون خرابی شما 0٪ است (0 کاربر از 3 کاربر بدون خرابی بودند).
سه نفر از کاربران شما در سه روز گذشته با برنامه شما تعامل داشتند، اما هیچ کدام از آنها هیچ خرابی نداشتند.
ارزش کاربران بدون خرابی را نباید در دوره های زمانی مختلف مقایسه کرد. احتمال اینکه یک کاربر با دفعات بیشتری از برنامه شما استفاده کند، افزایش می‌یابد، بنابراین ارزش کاربران بدون خرابی احتمالاً برای دوره‌های زمانی طولانی‌تر کمتر خواهد بود.
یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سؤالات، به‌روزرسانی وضعیت و غیره نظر دهند.
هنگامی که یک عضو پروژه یادداشتی را پست می کند، با ایمیل حساب Google خود برچسب گذاری می شود. این آدرس ایمیل همراه با یادداشت برای همه اعضای پروژه که به مشاهده یادداشت دسترسی دارند قابل مشاهده است.
موارد زیر دسترسی مورد نیاز برای مشاهده، نوشتن و حذف یادداشت ها را شرح می دهد:
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک موضوع بنویسند.
- مالک یا ویرایشگر پروژه، مدیر Firebase ، سرپرست کیفیت ، یا سرپرست Crashlytics
اعضای پروژه با هر یک از نقش های زیر می توانند یادداشت های ارسال شده در مورد یک موضوع را مشاهده کنند، اما نمی توانند یادداشتی را حذف یا بنویسند.
- Project Viewer ، Firebase Viewer ، Quality Viewer یا Crashlytics Viewer
به درک معیارهای بدون خرابی مراجعه کنید.
یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سؤالات، به‌روزرسانی وضعیت و غیره نظر دهند.
هنگامی که یک عضو پروژه یادداشتی را پست می کند، با ایمیل حساب Google خود برچسب گذاری می شود. این آدرس ایمیل همراه با یادداشت برای همه اعضای پروژه که به مشاهده یادداشت دسترسی دارند قابل مشاهده است.
موارد زیر دسترسی مورد نیاز برای مشاهده، نوشتن و حذف یادداشت ها را شرح می دهد:
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک موضوع بنویسند.
- مالک یا ویرایشگر پروژه، مدیر Firebase ، سرپرست کیفیت ، یا سرپرست Crashlytics
اعضای پروژه با هر یک از نقش های زیر می توانند یادداشت های ارسال شده در مورد یک موضوع را مشاهده کنند، اما نمی توانند یادداشتی را حذف یا بنویسند.
- Project Viewer ، Firebase Viewer ، Quality Viewer یا Crashlytics Viewer
ادغام ها
اگر پروژه شما از Crashlytics در کنار Google Mobile Ads SDK استفاده می کند، احتمالاً گزارشگران خرابی هنگام ثبت کنترل کننده های استثنا دخالت می کنند. برای رفع مشکل، با تماس با disableSDKCrashReporting ، گزارش خرابی را در SDK تبلیغات موبایل خاموش کنید.
پس از اینکه Crashlytics را به BigQuery پیوند دادید، مجموعه داده‌های جدیدی که ایجاد می‌کنید به‌طور خودکار در ایالات متحده قرار می‌گیرند، بدون در نظر گرفتن مکان پروژه Firebase شما.
مسائل پسرفته
زمانی که شما قبلاً آن را بسته اید، یک مشکل پسرفت داشته است، اما Crashlytics گزارش جدیدی دریافت می کند مبنی بر اینکه مشکل دوباره رخ داده است. Crashlytics به طور خودکار این مشکلات پسرفته را مجدداً باز می کند تا بتوانید آنها را مطابق با برنامه خود برطرف کنید.
در اینجا یک سناریوی مثال آمده است که توضیح می دهد چگونه Crashlytics یک موضوع را به عنوان یک رگرسیون طبقه بندی می کند:
- برای اولین بار، Crashlytics یک گزارش خرابی در مورد Crash "A" دریافت می کند. Crashlytics یک مشکل مربوط به آن خرابی را باز می کند (مساله "A").
- شما این اشکال را به سرعت برطرف می‌کنید، شماره A را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
- Crashlytics پس از بسته شدن این موضوع، گزارش دیگری در مورد مشکل "A" دریافت می کند.
- اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که نسخه اصلاً گزارش خرابی را برای هر خرابی ارسال کرده است)، Crashlytics این مشکل را پسرفته در نظر نخواهد گرفت. موضوع بسته خواهد ماند.
- اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics از آن اطلاعی نداشته است (به این معنی که نسخه هرگز گزارش خرابی برای هر خرابی ارسال نکرده است)، Crashlytics مشکل را پسرفت‌شده در نظر می‌گیرد و دوباره آن را باز می‌کند. .
وقتی مشکلی پسرفت می‌کند، یک هشدار تشخیص رگرسیون ارسال می‌کنیم و یک سیگنال رگرسیون به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics دوباره مشکل را باز کرده است. اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.
اگر گزارشی از یک نسخه برنامه قدیمی است که در هنگام بسته شدن مشکل، هیچ گزارش خرابی ارسال نکرده است، Crashlytics مشکل را پسرفته می‌داند و دوباره آن را باز می‌کند.
این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما همچنان کاربرانی در نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر به‌طور تصادفی، یکی از آن نسخه‌های قدیمی‌تر هیچ‌وقت هیچ گزارش خرابی ارسال نکرده بود، و آن کاربران شروع به مواجهه با باگ کردند، آن گزارش‌های خرابی باعث ایجاد یک مشکل پسرفته می‌شوند.
اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.
گزارش استثناهای کشف نشده به عنوان کشنده
Crashlytics می‌تواند استثناهای کشف نشده را به‌عنوان مرگبار گزارش کند (با نسخه 10.4.0 Unity SDK شروع می‌شود). سوالات متداول زیر به توضیح منطق و بهترین شیوه های استفاده از این ویژگی کمک می کند.
با گزارش موارد استثنایی به‌عنوان مرگبار، نشانه‌های واقعی‌تری از این که چه استثناهایی ممکن است منجر به غیرقابل بازی شدن بازی شوند، به دست می‌آورید - حتی اگر برنامه همچنان به کار خود ادامه دهد.
توجه داشته باشید که اگر شروع به گزارش دادن مرگ و میر کنید، درصد کاربران بدون خرابی (CFU) شما احتمالاً کاهش می‌یابد، اما معیار CFU بیشتر معرف تجربیات کاربران نهایی با برنامه شما خواهد بود.
برای اینکه Crashlytics یک استثناء کشف نشده را به‌عنوان کشنده گزارش کند، باید هر دو شرط زیر رعایت شود:
در طول شروع اولیه در برنامه شما، ویژگی
ReportUncaughtExceptionsAsFatalباید رویtrueتنظیم شود .برنامه شما (یا یک کتابخانه شامل) استثنایی ایجاد می‌کند که شناسایی نمی‌شود. استثنایی که ایجاد می‌شود، اما پرتاب نمی‌شود ، نامشخص محسوب نمی‌شود.
وقتی شروع به دریافت گزارش‌هایی از استثناهای کشف نشده خود به‌عنوان مرگبار می‌کنید، در اینجا چند گزینه برای مدیریت این استثنائات کشف نشده وجود دارد:
- در نظر بگیرید که چگونه می توانید شروع به گرفتن و رسیدگی به این استثنائات ناشناخته کنید.
- گزینه های مختلفی را برای ثبت استثناهای کنسول اشکال زدایی Unity و Crashlytics در نظر بگیرید.
استثناهای پرتاب شده را بگیرید و رسیدگی کنید
استثناها ایجاد و پرتاب می شوند تا حالت های غیر منتظره یا استثنایی را منعکس کنند. حل مسائل منعکس شده توسط یک استثنا پرتاب شده شامل بازگرداندن برنامه به یک وضعیت شناخته شده است (فرآیندی که به عنوان مدیریت استثنا شناخته می شود).
بهترین کار این است که همه استثنائات پیش‌بینی‌شده را بگیرید و مدیریت کنید، مگر اینکه برنامه را نتوان به حالت شناخته شده بازگرداند.
برای کنترل اینکه کدام نوع از استثناها گرفته شده و توسط چه کدی مدیریت می شوند، کدی را بپیچید که ممکن است در یک بلوک try-catch استثنا ایجاد کند . اطمینان حاصل کنید که شرایط در عبارات catch تا حد امکان محدود است تا استثناهای خاص را به درستی مدیریت کنید.
موارد استثنا را در Unity یا Crashlytics ثبت کنید
راه های متعددی برای ثبت استثناها در Unity یا Crashlytics وجود دارد تا به رفع اشکال کمک کند.
هنگام استفاده از Crashlytics، در اینجا دو گزینه رایج و توصیه شده وجود دارد:
گزینه 1: در کنسول Unity چاپ کنید، اما در طول توسعه یا عیب‌یابی به Crashlytics گزارش ندهید
- با استفاده از
Debug.Log(exception)،Debug.LogWarning(exception)وDebug.LogError(exception)در کنسول Unity چاپ کنید که محتویات استثنا را در کنسول Unity چاپ می کنند و استثنا را دوباره پرتاب نمی کنند.
- با استفاده از
گزینه 2: برای گزارش تلفیقی در داشبورد Crashlytics برای شرایط زیر در Crashlytics بارگذاری کنید:
- اگر یک استثنا ارزش ورود به سیستم را برای اشکال زدایی رویداد احتمالی بعدی Crashlytics دارد، از
Crashlytics.Log(exception.ToString())استفاده کنید. - اگر یک استثنا همچنان باید به Crashlytics گزارش شود، با وجود دستگیری و رسیدگی، از
Crashlytics.LogException(exception)برای ثبت آن به عنوان یک رویداد غیرکشنده استفاده کنید.
- اگر یک استثنا ارزش ورود به سیستم را برای اشکال زدایی رویداد احتمالی بعدی Crashlytics دارد، از
با این حال، اگر می خواهید به صورت دستی یک رویداد مرگبار را به Unity Cloud Diagnostics گزارش دهید، می توانید از Debug.LogException استفاده کنید. این گزینه استثنا را در کنسول Unity مانند گزینه 1 چاپ می کند، اما استثنا را نیز پرتاب می کند (خواه هنوز پرتاب شده باشد یا نشده باشد). خطا را به صورت غیر محلی پرتاب می کند. این به این معنی است که حتی یک Debug.LogException(exception) اطراف با بلوک‌های try-catch همچنان منجر به یک استثنا غیرقابل کشف می‌شود.
بنابراین، Debug.LogException را اگر و فقط در صورتی که می‌خواهید تمام کارهای زیر را انجام دهید، فراخوانی کنید:
- برای چاپ استثنا در کنسول Unity.
- برای آپلود استثنا در Crashlytics به عنوان یک رویداد مرگبار.
- برای پرتاب کردن استثنا، باید آن را به عنوان یک استثناء کشف نشده در نظر بگیرید و به Unity Cloud Diagnostics گزارش دهید.
توجه داشته باشید که اگر می‌خواهید یک استثنا در کنسول یونیتی چاپ کنید و به‌عنوان یک رویداد غیرمرگبار در 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
//
}