این صفحه، راهنمایی برای عیب‌یابی و پاسخ به سوالات متداول در مورد استفاده از Crashlytics را ارائه می‌دهد. اگر نمی‌توانید آنچه را که به دنبالش هستید پیدا کنید یا به کمک بیشتری نیاز دارید، با پشتیبانی Firebase تماس بگیرید.
عیب‌یابی عمومی/سوالات متداول
ممکن است متوجه دو فرمت مختلف برای مشکلات ذکر شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است متوجه ویژگی‌ای به نام "انواع" در برخی از مشکلات خود شوید. دلیل آن این است!
در اوایل سال ۲۰۲۳، ما یک موتور تحلیل بهبود یافته برای گروه‌بندی رویدادها و همچنین یک طراحی به‌روز شده و برخی ویژگی‌های پیشرفته برای مسائل جدید (مانند انواع مختلف!) را ارائه دادیم. برای جزئیات بیشتر، به پست وبلاگ اخیر ما مراجعه کنید، اما می‌توانید نکات برجسته را در زیر بخوانید.
Crashlytics تمام رویدادهای برنامه شما (مانند خرابی‌ها، خطاهای غیرفاجعه‌آمیز و ANRها) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مشکلات (issues ) ایجاد می‌کند - همه رویدادهای یک مشکل (issue) یک نقطه شکست مشترک دارند.
برای گروه‌بندی رویدادها در این مسائل، موتور تحلیل بهبود یافته اکنون جنبه‌های زیادی از رویداد، از جمله فریم‌های موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگی‌های پلتفرم یا نوع خطا را بررسی می‌کند.
با این حال، در این گروه از رویدادها، ممکن است ردپاهای پشته منجر به خرابی متفاوت باشند. یک ردپای پشته متفاوت می‌تواند به معنای علت ریشه‌ای متفاوت باشد. برای نمایش این تفاوت احتمالی در یک مسئله، اکنون انواعی را در مسائل ایجاد می‌کنیم - هر نوع، زیرگروهی از رویدادها در یک مسئله است که نقطه خرابی یکسانی دارند و یک ردپای پشته مشابه. با انواع، می‌توانید رایج‌ترین ردپاهای پشته را در یک مسئله اشکال‌زدایی کنید و تعیین کنید که آیا علل ریشه‌ای متفاوتی منجر به خرابی می‌شوند یا خیر.
در اینجا چیزی است که با این پیشرفت‌ها تجربه خواهید کرد:
فراداده‌های اصلاح‌شده در ردیف مشکل نمایش داده می‌شوند
اکنون درک و اولویت‌بندی مشکلات در برنامه شما آسان‌تر است.مسائل تکراری کمتر
تغییر شماره خط منجر به مشکل جدیدی نمی‌شود.اشکال‌زدایی آسان‌تر مسائل پیچیده با علل ریشه‌ای مختلف
از انواع مختلف برای اشکال‌زدایی رایج‌ترین ردپاهای پشته در یک مسئله استفاده کنید.هشدارها و سیگنال‌های معنادارتر
یک مشکل جدید در واقع نشان دهنده یک باگ جدید است.جستجوی قدرتمندتر
هر شماره شامل فراداده‌های قابل جستجوی بیشتری مانند نوع استثنا و نام بسته است.
نحوه‌ی اعمال این بهبودها به شرح زیر است:
وقتی رویدادهای جدیدی از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا با مشکل موجود مطابقت دارند یا خیر.
اگر هیچ تطابقی وجود نداشته باشد، ما به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندتر خود را برای رویداد اعمال می‌کنیم و یک issue جدید با طراحی فراداده اصلاح‌شده ایجاد می‌کنیم.
این اولین به‌روزرسانی بزرگی است که ما در گروه‌بندی رویدادهای خود انجام می‌دهیم. اگر بازخوردی دارید یا با مشکلی مواجه شده‌اید، لطفاً با ثبت گزارش به ما اطلاع دهید.
اگر گزارش‌های breadcrumb را مشاهده نمی‌کنید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را رعایت می‌کنید:
شما اشتراک‌گذاری داده‌ها را برای Google Analytics فعال کرده‌اید. برای اطلاعات بیشتر در مورد این تنظیم، به مدیریت تنظیمات اشتراک‌گذاری داده‌های آنالیتیکس خود مراجعه کنید.
شمابه برنامه شما. این SDK باید علاوه بر Crashlytics SDK اضافه شود.
شما در حال استفاده ازبرای تمام محصولاتی که در برنامه خود استفاده می‌کنید.
اگر هشدارهای سرعت را نمی‌بینید، مطمئن شوید که از ... استفاده می‌کنید.
اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) را نمی‌بینید یا معیارهای غیرقابل اعتمادی را می‌بینید، موارد زیر را بررسی کنید:
مطمئن شوید که از ... استفاده می‌کنید
مطمئن شوید که تنظیمات جمع‌آوری داده‌های شما بر کیفیت معیارهای بدون خرابی شما تأثیر نمی‌گذارد:
اگر با غیرفعال کردن گزارش خودکار خرابی، گزارش‌دهی اختیاری را فعال کنید ، اطلاعات خرابی فقط از کاربرانی که صریحاً در جمع‌آوری داده‌ها مشارکت داشته‌اند، می‌تواند به Crashlytics ارسال شود. بنابراین، دقت معیارهای بدون خرابی تحت تأثیر قرار خواهد گرفت زیرا Crashlytics فقط اطلاعات خرابی این کاربران انتخابی (و نه همه کاربران شما) را دارد. این بدان معناست که معیارهای بدون خرابی شما ممکن است کمتر قابل اعتماد باشند و کمتر نشان‌دهنده پایداری کلی برنامه شما باشند.
اگر جمع‌آوری خودکار داده‌ها را غیرفعال کرده‌اید، می‌توانید از
sendUnsentReportsبرای ارسال گزارش‌های ذخیره‌شده روی دستگاه به Crashlytics استفاده کنید. استفاده از این روش، داده‌های خرابی را به Crashlytics ارسال می‌کند، اما داده‌های جلسات را نه، که باعث می‌شود نمودارهای کنسول مقادیر کم یا صفر را برای معیارهای بدون خرابی نشان دهند.
به بخش «معیارهای بدون خرابی را درک کنید» مراجعه کنید.
یادداشت‌ها به اعضای پروژه اجازه می‌دهند تا در مورد مسائل خاص با سوالات، به‌روزرسانی وضعیت و غیره اظهار نظر کنند.
وقتی یکی از اعضای پروژه یادداشتی ارسال می‌کند، ایمیل حساب گوگل او روی آن یادداشت برچسب‌گذاری می‌شود. این آدرس ایمیل، به همراه یادداشت، برای همه اعضای پروژه که دسترسی مشاهده یادداشت را دارند، قابل مشاهده است.
در ادامه، دسترسی‌های لازم برای مشاهده، نوشتن و حذف یادداشت‌ها شرح داده شده است:
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک مسئله بنویسند.
- مالک یا ویرایشگر پروژه، مدیر Firebase ، مدیر Quality یا مدیر Crashlytics
اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های ارسال شده در مورد یک مسئله را مشاهده کنند، اما نمی‌توانند یادداشتی را حذف یا بنویسند.
- نمایشگر پروژه، نمایشگر فایربیس ، نمایشگر کیفیت یا نمایشگر Crashlytics
ادغام‌ها
اگر پروژه شما از Crashlytics در کنار SDK Google Mobile Ads استفاده می‌کند، احتمالاً گزارش‌دهنده‌های خرابی هنگام ثبت کنترل‌کننده‌های خطا تداخل ایجاد می‌کنند. برای رفع این مشکل، با فراخوانی disableSDKCrashReporting ، گزارش خرابی را در SDK Mobile Ads غیرفعال کنید.
پس از اینکه Crashlytics به BigQuery متصل کردید، مجموعه داده‌های جدیدی که ایجاد می‌کنید، صرف نظر از موقعیت مکانی پروژه Firebase شما، به طور خودکار در ایالات متحده قرار می‌گیرند.
پشتیبانی پلتفرم
مسائل پسرفت کرده
زمانی که قبلاً یک مشکل را بسته‌اید، اما Crashlytics گزارش جدیدی مبنی بر وقوع مجدد آن مشکل دریافت می‌کند، یک مشکل پسرفت داشته است. Crashlytics به‌طور خودکار این مشکلات پسرفت‌شده را دوباره باز می‌کند تا بتوانید آنها را متناسب با برنامه خود برطرف کنید.
در اینجا یک سناریوی مثالی آورده شده است که توضیح می‌دهد چگونه Crashlytics یک مسئله را به عنوان یک رگرسیون طبقه‌بندی می‌کند:
- برای اولین بار، Crashlytics گزارشی از خرابی مربوط به خرابی "A" دریافت می‌کند. Crashlytics یک شماره مربوطه برای آن خرابی (شماره "A") ایجاد می‌کند.
- شما این اشکال را سریع برطرف می‌کنید، مشکل «الف» را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
- Crashlytics پس از اینکه مشکل را بستید، گزارش دیگری در مورد مشکل «الف» دریافت می‌کند.
- اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که آن نسخه برای هرگونه خرابی، گزارش خرابی ارسال کرده است)، Crashlytics مشکل را به عنوان مشکل رفع‌شده در نظر نمی‌گیرد. مشکل بسته باقی خواهد ماند.
- اگر گزارش از نسخه‌ای از برنامه باشد که Crashlytics هنگام بستن مشکل از آن اطلاعی نداشته است (به این معنی که آن نسخه هرگز هیچ گزارش خرابی برای هیچ خرابی ارسال نکرده است)، Crashlytics مشکل را رفع شده در نظر می‌گیرد و دوباره آن را باز می‌کند.
وقتی یک مشکل دوباره حل می‌شود، ما یک هشدار تشخیص حل مشکل ارسال می‌کنیم و یک سیگنال حل مشکل به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics مشکل را دوباره باز کرده است. اگر نمی‌خواهید مشکلی به دلیل الگوریتم حل مشکل ما دوباره باز شود، به جای بستن آن، مشکل را «بی‌صدا» کنید.
اگر گزارشی از نسخه قدیمی برنامه باشد که هنگام بستن مشکل، هیچ گزارش خرابی ارسال نکرده باشد، Crashlytics مشکل را برطرف شده در نظر می‌گیرد و آن را دوباره باز می‌کند.
این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما هنوز کاربرانی روی نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر به‌طور اتفاقی، یکی از آن نسخه‌های قدیمی‌تر هنگام بستن مشکل، هیچ گزارش خرابی ارسال نکرده باشد و آن کاربران شروع به مواجهه با اشکال کنند، آن گزارش‌های خرابی باعث ایجاد یک مشکل رگرسیون می‌شوند.
اگر نمی‌خواهید به دلیل الگوریتم رگرسیون ما، مسئله دوباره باز شود، به جای بستن آن، آن را «بی‌صدا» کنید.