این صفحه راهنمایی عیب‌یابی و پاسخ‌هایی به سؤالات متداول درباره استفاده از Crashlytics ارائه می‌دهد. اگر چیزی را که به دنبالش هستید پیدا نکردید یا به کمک بیشتری نیاز دارید، با پشتیبانی Firebase تماس بگیرید.
عیب یابی عمومی/سؤالات متداول
ممکن است متوجه دو قالب مختلف برای مشکلات فهرست شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است در برخی از مشکلات خود متوجه ویژگی به نام "Variants" شوید. در اینجا دلیل آن است!
در اوایل سال 2023، موتور تجزیه و تحلیل بهبود یافته ای را برای گروه بندی رویدادها و همچنین طراحی به روز شده و برخی ویژگی های پیشرفته برای مسائل جدید (مانند انواع!) ارائه کردیم. برای همه جزئیات، پست اخیر وبلاگ ما را بررسی کنید، اما می توانید برای نکات مهم در زیر بخوانید.
Crashlytics همه رویدادهای برنامه شما (مانند خرابی‌ها، موارد غیرمرگبار و ANR) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مسائل ایجاد می‌کند — همه رویدادها در یک شماره یک نقطه شکست مشترک دارند.
برای گروه‌بندی رویدادها در این مسائل، موتور تجزیه و تحلیل بهبودیافته اکنون به بسیاری از جنبه‌های رویداد، از جمله فریم‌های موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگی‌های پلتفرم یا نوع خطا نگاه می‌کند.
با این حال، در این گروه از رویدادها، ردیابی پشته منجر به شکست ممکن است متفاوت باشد. ردیابی پشته‌ای متفاوت می‌تواند به معنای ریشه‌ای متفاوت باشد. برای نشان دادن این تفاوت احتمالی در یک شماره، اکنون انواع مختلفی را در شماره ایجاد می کنیم - هر گونه یک زیرگروه از رویدادها در یک شماره است که دارای نقطه شکست یکسان و ردیابی پشته مشابه است. با انواع مختلف، می‌توانید رایج‌ترین ردیابی‌های پشته را در یک موضوع اشکال زدایی کنید و تعیین کنید که آیا دلایل اصلی مختلف منجر به شکست می‌شوند یا خیر.
در اینجا چیزی است که با این بهبودها تجربه خواهید کرد:
ابرداده اصلاح شده در ردیف شماره نمایش داده می شود
اکنون درک و تریاژ مسائل در برنامه شما آسان تر شده است.مسائل تکراری کمتر
تغییر شماره خط منجر به مشکل جدیدی نمی شود.اشکال زدایی آسانتر مسائل پیچیده با دلایل ریشه ای مختلف
از انواع برای اشکال زدایی رایج ترین ردیابی پشته در یک شماره استفاده کنید.هشدارها و سیگنال های معنی دار تر
یک شماره جدید در واقع نشان دهنده یک باگ جدید است.جستجوی قدرتمندتر
هر شماره حاوی فراداده قابل جستجوی بیشتری است، مانند نوع استثنا و نام بسته.
در اینجا نحوه اجرای این بهبودها آمده است:
وقتی رویدادهای جدیدی را از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا آنها با مشکل موجود مطابقت دارند یا خیر.
اگر مطابقت وجود نداشته باشد، به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندانه‌تر خود را در رویداد اعمال می‌کنیم و یک مشکل جدید با طراحی ابرداده اصلاح‌شده ایجاد می‌کنیم.
این اولین به‌روزرسانی بزرگی است که ما در حال ایجاد گروه‌بندی رویداد خود هستیم. اگر بازخوردی دارید یا با مشکلی مواجه شدید، لطفاً با ارسال گزارش به ما اطلاع دهید.
اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) و/یا هشدارهای سرعت را نمی‌بینید، مطمئن شوید که ازCrashlytics SDK نسخه 10.8.0+.
اگر گزارش‌های خرده نان را نمی‌بینید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را دارید:
شما اشتراک گذاری داده را برای Google Analytics فعال کرده اید. درباره این تنظیم در مدیریت تنظیمات به اشتراک گذاری داده Analytics خود بیشتر بیاموزید
شما داریدFirebase SDK را برای Google Analytics اضافه کردبه برنامه شما این SDK باید علاوه بر Crashlytics SDK اضافه شود.
شما ازآخرین نسخه Firebase SDKبرای همه محصولاتی که در برنامه خود استفاده می کنید.
به خصوص بررسی کنید که حداقل از نسخه زیر Firebase SDK برای Google Analytics استفاده می کنید:
iOS+ — نسخه 6.3.1+ (نسخه 8.9.0+ برای macOS و tvOS).
برای آپلود dSYM های پروژه خود و دریافت خروجی مفصل، موارد زیر را بررسی کنید:
مطمئن شوید که فاز ساخت پروژه شما حاوی اسکریپت اجرا Crashlytics است که به Xcode اجازه می دهد تا dSYM های پروژه شما را در زمان ساخت آپلود کند (برای دستورالعمل های مربوط به افزودن اسکریپت ، Initializing Crashlytics را بخوانید). پس از به‌روزرسانی پروژه، خرابی را مجبور کنید و تأیید کنید که خرابی در داشبورد Crashlytics ظاهر می‌شود.
اگر در کنسول Firebase هشدار "DSYM گم شده" را مشاهده کردید، Xcode را بررسی کنید تا مطمئن شوید که dSYM ها را به درستی برای ساخت تولید می کند .
اگر Xcode به درستی dSYM ها را تولید می کند، و شما همچنان dSYM های گم شده را می بینید، به احتمال زیاد ابزار اجرای اسکریپت هنگام آپلود dSYM ها گیر کرده است. در این مورد، هر یک از موارد زیر را امتحان کنید:
مطمئن شوید که از آخرین نسخه Crashlytics استفاده می‌کنید.
فایل های dSYM گم شده را به صورت دستی آپلود کنید:
- گزینه 1: از گزینه "Drag and Drop" مبتنی بر کنسول در برگه dSYMs برای آپلود یک بایگانی فشرده حاوی فایل های dSYM گم شده استفاده کنید.
- گزینه 2: از اسکریپت
upload-symbolsبرای آپلود فایل های dSYM مفقود، برای UUID های ارائه شده در برگه dSYMs استفاده کنید.
اگر همچنان dSYM های گم شده را می بینید یا بارگذاری ها هنوز ناموفق هستند، با پشتیبانی Firebase تماس بگیرید و حتما گزارش های خود را اضافه کنید.
اگر به نظر می‌رسد که نشانه‌های پشته شما ضعیف است، موارد زیر را بررسی کنید:
اگر فریم های کتابخانه برنامه شما فاقد ارجاع به کد برنامه شما هستند، مطمئن شوید
-fomit-frame-pointerبه عنوان یک پرچم تلفیقی تنظیم نشده است.اگر چندین فریم
(Missing)برای کتابخانه برنامه خود می‌بینید، بررسی کنید که آیا dSYMهای اختیاری به‌عنوان مفقود (برای نسخه برنامه آسیب‌دیده) در برگه Crashlytics dSYMs کنسول Firebase فهرست شده‌اند. اگر چنین است، مرحله عیب‌یابی «هشدار گمشده dSYM» را در سؤالات متداول موجود در این صفحه دنبال کنید. توجه داشته باشید که آپلود این dSYM ها نماد خرابی هایی نیست که قبلاً رخ داده است، اما به اطمینان از نمادسازی برای خرابی های آینده کمک می کند.
یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سؤالات، به‌روزرسانی وضعیت و غیره نظر دهند.
هنگامی که یک عضو پروژه یادداشتی را پست می کند، با ایمیل حساب 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 Mobile Ads خاموش کنید.
پس از اینکه Crashlytics به BigQuery پیوند دادید، مجموعه داده‌های جدیدی که ایجاد می‌کنید به‌طور خودکار در ایالات متحده قرار می‌گیرند، بدون در نظر گرفتن مکان پروژه Firebase شما.
پشتیبانی از پلتفرم
بله، می‌توانید Crashlytics در پروژه‌های macOS و tvOS پیاده‌سازی کنید. مطمئن شوید نسخه 8.9.0+ از Firebase SDK برای Google Analytics را اضافه کنید تا خرابی‌ها به معیارهای جمع‌آوری‌شده توسط Google Analytics (کاربران بدون خرابی، آخرین نسخه، هشدارهای سرعت، و گزارش‌های خرده نان) دسترسی داشته باشند.
اکنون می‌توانید خرابی‌های چند برنامه را در یک پروژه Firebase گزارش کنید، حتی زمانی که برنامه‌ها برای پلتفرم‌های مختلف اپل (مانند iOS، tvOS و Mac Catalyst) ساخته شده‌اند. قبلاً، اگر برنامه‌ها دارای شناسه بسته یکسانی بودند، باید آنها را به پروژه‌های Firebase جداگانه جدا می‌کردید.
مسائل پسرفته
زمانی که شما قبلاً آن را بسته اید، یک مشکل پسرفت داشته است، اما Crashlytics گزارش جدیدی دریافت می کند مبنی بر اینکه مشکل دوباره رخ داده است. Crashlytics به طور خودکار این مشکلات پسرفته را مجدداً باز می کند تا بتوانید آنها را مطابق با برنامه خود برطرف کنید.
در اینجا یک سناریوی مثال آمده است که توضیح می دهد چگونه Crashlytics یک موضوع را به عنوان یک رگرسیون طبقه بندی می کند:
- برای اولین بار، Crashlytics یک گزارش خرابی در مورد Crash "A" دریافت می کند. Crashlytics یک مشکل مربوط به آن خرابی را باز می کند (مساله "A").
- شما این اشکال را به سرعت برطرف می‌کنید، شماره A را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
- Crashlytics پس از بسته شدن این موضوع، گزارش دیگری در مورد مشکل "A" دریافت می کند.
- اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که نسخه اصلاً گزارش خرابی را برای هر خرابی ارسال کرده است)، Crashlytics این مشکل را پسرفته در نظر نخواهد گرفت. موضوع بسته خواهد ماند.
- اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics از آن اطلاعی نداشته است (به این معنی که این نسخه هرگز هیچ گزارش خرابی برای هر خرابی ارسال نکرده است)، Crashlytics مشکل را پسرفته در نظر می‌گیرد و دوباره آن را باز می‌کند.
وقتی مشکلی پسرفت می‌کند، یک هشدار تشخیص رگرسیون ارسال می‌کنیم و یک سیگنال رگرسیون به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics دوباره مشکل را باز کرده است. اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.
اگر گزارشی از یک نسخه برنامه قدیمی است که در هنگام بسته شدن مشکل، هیچ گزارش خرابی ارسال نکرده است، Crashlytics مشکل را پسرفته می‌داند و دوباره آن را باز می‌کند.
این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما همچنان کاربرانی در نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر به‌طور تصادفی، یکی از آن نسخه‌های قدیمی‌تر هیچ‌وقت هیچ گزارش خرابی ارسال نکرده بود، و آن کاربران شروع به مواجهه با باگ کردند، آن گزارش‌های خرابی باعث ایجاد یک مشکل پسرفته می‌شوند.
اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.