این صفحه راهنمایی عیب‌یابی و پاسخ به سؤالات متداول در مورد استفاده از Crashlytics را ارائه می‌کند. اگر چیزی را که به دنبالش هستید پیدا نکردید یا به کمک بیشتری نیاز دارید، با پشتیبانی Firebase تماس بگیرید.
عیب یابی عمومی/سؤالات متداول
اگر کاربران بدون خرابی، گزارش‌های خرده نان، و/یا هشدارهای سرعت را نمی‌بینید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید.
مطمئن شوید که Google Analytics را در پروژه Firebase خود فعال کرده اید.
مطمئن شوید که اشتراک گذاری داده برای Google Analytics در صفحه Integrations > Google Analytics کنسول Firebase فعال است. توجه داشته باشید که تنظیمات اشتراک گذاری داده در کنسول Firebase نمایش داده می شود اما در کنسول Google Analytics مدیریت می شود.
علاوه بر Firebase Crashlytics SDK، مطمئن شوید که Firebase SDK برای Google Analytics را به برنامه خود اضافه کرده اید ( iOS+ | Android ).
مطمئن شوید که از جدیدترین نسخه ها برای همه SDK های Firebase خود ( iOS+ | Android ) استفاده می کنید.
به خصوص بررسی کنید که حداقل از نسخه های زیر Firebase SDK برای Google Analytics استفاده می کنید: iOS+ — نسخه 6.3.1+ (نسخه 8.9.0+ برای macOS و tvOS) | Android — نسخه 17.2.3+(BoM v24.7.1+) .
درصد کاربران بدون خرابی یک تجمع در طول زمان است، نه میانگین.
مقدار بدون خرابی نشان‌دهنده درصد کاربرانی است که با برنامه شما درگیر بوده‌اند اما در یک دوره زمانی خاص دچار خرابی نشده‌اند. این بازه زمانی را از منوی کشویی در سمت راست بالای داشبورد Crashlytics انتخاب می‌کنید.
به عنوان مثال، تصور کنید برنامه شما سه کاربر دارد. ما آنها را User A، User B و User C می نامیم. جدول زیر نشان می دهد که کدام کاربران هر روز با برنامه شما درگیر هستند و کدام یک از آن کاربران در آن روز خراب شده اند:
| دوشنبه | سهشنبه | چهار شنبه | |
|---|---|---|---|
| کاربرانی که با برنامه شما درگیر هستند | الف، ب، ج | الف، ب، ج | الف، ب |
| کاربری که دچار خرابی شده است | سی | ب | آ |
در روز چهارشنبه، درصد کاربران بدون خرابی شما 50٪ است (از هر 2 کاربر، 1 کاربر بدون خرابی بود).
دو نفر از کاربران شما روز چهارشنبه با برنامه شما درگیر شدند، اما تنها یکی از آنها (کاربر B) هیچ خرابی نداشت.در 2 روز گذشته، درصد کاربران بدون خرابی شما 33.3٪ بوده است (از هر 3 کاربر، 1 کاربر بدون خرابی بوده است).
سه نفر از کاربران شما در دو روز گذشته با برنامه شما درگیر بودند، اما تنها یکی از آنها (کاربر C) هیچ خرابی نداشت.در 3 روز گذشته، درصد کاربران بدون خرابی شما 0٪ است (0 نفر از 3 کاربر بدون خرابی بودند).
سه نفر از کاربران شما در سه روز گذشته با برنامه شما تعامل داشتند، اما هیچ کدام از آنها هیچ خرابی نداشتند.
ادغام ها
اگر پروژه شما از 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 مشکل را پسرفته می‌داند و دوباره آن را باز می‌کند.
این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما همچنان کاربرانی در نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر تصادفاً، یکی از آن نسخه‌های قدیمی‌تر، هیچ‌گاه گزارش خرابی ارسال نکرده باشد، و آن کاربران شروع به مواجهه با باگ کنند، آن گزارش‌های خرابی باعث ایجاد یک مشکل پسرفته می‌شوند.
اگر به دلیل الگوریتم رگرسیون ما نمی‌خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.