این صفحه راهنمایی عیبیابی و پاسخ به سؤالات متداول در مورد استفاده از 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 ).
مطمئن شوید که از آخرین نسخهها برای همه کیتهای توسعه نرمافزار Firebase ( iOS+ | Android ) استفاده میکنید.
به خصوص بررسی کنید که حداقل از نسخه های زیر Firebase SDK برای Google Analytics استفاده می کنید:iOS+ — نسخه 6.3.1+ (نسخه 8.9.0+ برای macOS و tvOS) | Android — نسخه 17.2.3+ (BoM v24.7.1+) .
ممکن است متوجه دو قالب مختلف برای مشکلات فهرست شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است در برخی از مشکلات خود متوجه ویژگی به نام "Variants" شوید. در اینجا دلیل آن است!
در اوایل سال 2023، موتور تجزیه و تحلیل بهبود یافته ای را برای گروه بندی رویدادها و همچنین طراحی به روز شده و برخی ویژگی های پیشرفته برای مسائل جدید (مانند انواع!) ارائه کردیم. برای همه جزئیات، پست اخیر وبلاگ ما را بررسی کنید، اما می توانید برای نکات مهم در زیر بخوانید.
Crashlytics همه رویدادهای برنامه شما (مانند خرابیها، موارد غیرمرگبار و ANR) را تجزیه و تحلیل میکند و گروههایی از رویدادها به نام مسائل ایجاد میکند — همه رویدادها در یک شماره یک نقطه شکست مشترک دارند.
برای گروهبندی رویدادها در این مسائل، موتور تجزیه و تحلیل بهبودیافته اکنون به بسیاری از جنبههای رویداد، از جمله فریمهای موجود در ردیابی پشته، پیام استثنا، کد خطا و سایر ویژگیهای پلتفرم یا نوع خطا نگاه میکند.
با این حال، در این گروه از رویدادها، ردیابی پشته منجر به شکست ممکن است متفاوت باشد. ردیابی پشتهای متفاوت میتواند به معنای ریشهای متفاوت باشد. برای نشان دادن این تفاوت احتمالی در یک شماره، اکنون انواع مختلفی را در شماره ایجاد می کنیم - هر گونه یک زیرگروه از رویدادها در یک شماره است که دارای نقطه شکست یکسان و ردیابی پشته مشابه است. با انواع مختلف، میتوانید رایجترین ردیابیهای پشته را در یک موضوع اشکال زدایی کنید و تعیین کنید که آیا دلایل اصلی مختلف منجر به شکست میشوند یا خیر.
در اینجا چیزی است که با این بهبودها تجربه خواهید کرد:
ابرداده اصلاح شده در ردیف شماره نمایش داده می شود
اکنون درک و تریاژ مسائل در برنامه شما آسان تر شده است.مسائل تکراری کمتر
تغییر شماره خط منجر به مشکل جدیدی نمی شود.اشکال زدایی آسانتر مسائل پیچیده با دلایل ریشه ای مختلف
از انواع برای اشکال زدایی رایج ترین ردیابی پشته در یک شماره استفاده کنید.هشدارها و سیگنال های معنی دار تر
یک شماره جدید در واقع نشان دهنده یک باگ جدید است.جستجوی قدرتمندتر
هر شماره حاوی فراداده قابل جستجوی بیشتری است، مانند نوع استثنا و نام بسته.
در اینجا نحوه اجرای این بهبودها آمده است:
وقتی رویدادهای جدیدی را از برنامه شما دریافت میکنیم، بررسی میکنیم که آیا آنها با مشکل موجود مطابقت دارند یا خیر.
اگر مطابقت وجود نداشته باشد، به طور خودکار الگوریتم گروهبندی رویداد هوشمندانهتر خود را در رویداد اعمال میکنیم و یک مشکل جدید با طراحی ابرداده اصلاحشده ایجاد میکنیم.
این اولین بهروزرسانی بزرگی است که ما در حال ایجاد گروهبندی رویداد خود هستیم. اگر بازخوردی دارید یا با مشکلی مواجه شدید، لطفاً با ارسال گزارش به ما اطلاع دهید.
Crashlytics از گزارش ANR برای برنامههای Android از دستگاههایی که Android 11 و بالاتر را اجرا میکنند، پشتیبانی میکند. API اصلی که برای جمعآوری ANR استفاده میکنیم ( getHistoricalProcessExitReasons ) قابل اعتمادتر از SIGQUIT یا رویکردهای مبتنی بر نظارت است. این API فقط در دستگاههای Android 11 و بالاتر در دسترس است.
اگر برخی از ANR های شما BuildId
خود را ندارند، به شرح زیر عیب یابی کنید:
مطمئن شوید که از نسخه بهروز Crashlytics Android SDK و Crashlytics Gradle استفاده میکنید.
اگر
BuildId
s برای اندروید 11 و برخی از ANR های اندروید 12 را ندارید، احتمالاً از یک SDK، پلاگین Gradle یا هر دو قدیمی استفاده می کنید. برای جمع آوری صحیحBuildId
برای این ANR ها، باید از نسخه های زیر استفاده کنید:- Crashlytics Android SDK نسخه 18.3.5+ (Firebase BoM v31.2.2+)
- پلاگین Crashlytics Gradle نسخه 2.9.4+
بررسی کنید که آیا از یک مکان غیر استاندارد برای کتابخانه های مشترک خود استفاده می کنید.
اگر فقط
BuildId
را برای کتابخانههای مشترک برنامهتان از دست دادهاید، احتمالاً از مکان استاندارد و پیشفرض برای کتابخانههای مشترک استفاده نمیکنید. اگر اینطور باشد، ممکن است Crashlytics نتواندBuildId
مرتبط را پیدا کند. توصیه می کنیم از مکان استاندارد برای کتابخانه های مشترک استفاده کنید.مطمئن شوید که
BuildId
ها را در طول فرآیند ساخت حذف نمی کنید.توجه داشته باشید که نکات عیبیابی زیر هم برای خرابیهای ANR و هم برای خرابیهای بومی اعمال میشود.
با اجرای
readelf -n
روی باینری های خود بررسی کنید که آیاBuildId
وجود دارد یا خیر. اگرBuildId
وجود ندارد، سپس-Wl,--build-id
به پرچمهای سیستم ساخت خود اضافه کنید.بررسی کنید که در تلاش برای کاهش اندازه APK خود،
BuildId
ها را ناخواسته حذف نکنید.اگر نسخههای stripped و unstripped یک کتابخانه را نگه میدارید، حتماً به نسخه صحیح در کد خود اشاره کنید.
ممکن است بین تعداد ANR بین Google Play و Crashlytics ناهماهنگی وجود داشته باشد. این به دلیل تفاوت در مکانیسم جمع آوری و گزارش داده های ANR انتظار می رود. Crashlytics هنگام راهاندازی بعدی برنامه، ANR را گزارش میکند، در حالی که Android Vitals دادههای ANR را پس از وقوع ANR ارسال میکند.
علاوه بر این، Crashlytics فقط ANRهایی را که در دستگاههای دارای Android نسخه ۱۱ و بالاتر رخ میدهند، در مقایسه با Google Play که ANRهای دستگاههای دارای سرویسهای Google Play و رضایت جمعآوری دادهها را نشان میدهد، نمایش میدهد.
زنجیرههای ابزار LLVM و GNU پیشفرضها و درمانهای متمایزی برای بخش فقط خواندنی باینریهای برنامه شما دارند، که ممکن است ردیابی پشتهای ناسازگار در کنسول Firebase ایجاد کند. برای کاهش این موضوع، پرچمهای پیوند دهنده زیر را به فرآیند ساخت خود اضافه کنید:
اگر از پیوند دهنده
lld
از زنجیره ابزار LLVM استفاده می کنید، اضافه کنید:-Wl,--no-rosegment
اگر از پیوند دهنده
ld.gold
از زنجیره ابزار گنو استفاده می کنید، اضافه کنید:-Wl,--rosegment
اگر همچنان ناهماهنگی های stack trace را مشاهده می کنید (یا اگر هیچ کدام از پرچم ها مربوط به زنجیره ابزار شما نیست)، به جای آن موارد زیر را به فرآیند ساخت خود اضافه کنید:
-fno-omit-frame-pointer
پلاگین Crashlytics یک تولید کننده فایل نماد Breakpad سفارشی را بسته بندی می کند. اگر ترجیح میدهید از باینری خود برای تولید فایلهای نماد Breakpad استفاده کنید (به عنوان مثال، اگر ترجیح میدهید همه فایلهای اجرایی بومی در زنجیره ساخت خود را از منبع بسازید)، از ویژگی انتخابی پسوند symbolGeneratorBinary
برای تعیین مسیر فایل اجرایی استفاده کنید.
می توانید مسیر دودویی تولید کننده فایل نماد Breakpad را به یکی از دو روش مشخص کنید:
گزینه 1 : مسیر را از طریق پسوند
firebaseCrashlytics
در فایلbuild.gradle
خود مشخص کنید.موارد زیر را به فایل
build.gradle
در سطح برنامه خود اضافه کنید: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") } } } } }
گزینه 2 : مسیر را از طریق یک خط ویژگی در فایل ویژگی های Gradle خود مشخص کنید
می توانید از ویژگی
com.google.firebase.crashlytics.symbolGeneratorBinary
برای تعیین مسیر فایل اجرایی استفاده کنید.شما می توانید به صورت دستی فایل ویژگی های Gradle خود را به روز کنید یا فایل را از طریق خط فرمان به روز کنید. به عنوان مثال، برای تعیین مسیر از طریق خط فرمان، از دستوری مانند زیر استفاده کنید:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
اگر استثنای زیر را مشاهده کردید، احتمالاً از نسخهای از DexGuard استفاده میکنید که با Firebase Crashlytics SDK ناسازگار است:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
این استثنا برنامه شما را خراب نمیکند، اما از ارسال گزارشهای خرابی جلوگیری میکند. برای رفع این مشکل:
مطمئن شوید که از آخرین نسخه DexGuard 8.x استفاده می کنید. آخرین نسخه حاوی قوانینی است که توسط Firebase Crashlytics SDK مورد نیاز است.
اگر نمی خواهید نسخه DexGuard خود را تغییر دهید، سعی کنید خط زیر را به قوانین مبهم سازی خود (در فایل پیکربندی DexGuard خود) اضافه کنید:
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
هنگامی که یک برنامه از یک مبهم کننده استفاده می کند که پسوند فایل را نشان نمی دهد، Crashlytics به طور پیش فرض هر مشکل را با پسوند فایل .java
ایجاد می کند.
برای اینکه Crashlytics بتواند مشکلاتی با پسوند فایل درست ایجاد کند، مطمئن شوید که برنامه شما از تنظیمات زیر استفاده میکند:
- از اندروید Gradle 4.2.0 یا بالاتر استفاده می کند
- از R8 با مبهم سازی روشن استفاده می کند. برای به روز رسانی برنامه خود به R8، این مستندات را دنبال کنید.
توجه داشته باشید که پس از بهروزرسانی به تنظیماتی که در بالا توضیح داده شد، ممکن است مشکلات .kt
جدید را مشاهده کنید که تکراری از مشکلات .java
موجود هستند. برای کسب اطلاعات بیشتر در مورد آن شرایط ، پرسشهای متداول را ببینید.
از اواسط دسامبر 2021، Crashlytics پشتیبانی از برنامههایی را که از Kotlin استفاده میکنند، بهبود بخشید.
تا همین اواخر، مبهمکنندههای موجود پسوند فایل را آشکار نمیکردند، بنابراین Crashlytics به طور پیشفرض هر مشکل را با پسوند فایل .java
ایجاد میکرد. با این حال، از اندروید Gradle 4.2.0، R8 از پسوندهای فایل پشتیبانی می کند.
با این بهروزرسانی، Crashlytics اکنون میتواند تعیین کند که آیا هر کلاسی که در برنامه استفاده میشود در Kotlin نوشته شده است یا خیر و نام فایل صحیح را در امضای شماره قرار دهد. اگر برنامه شما دارای تنظیمات زیر باشد، خرابیها اکنون به درستی به فایلهای .kt
نسبت داده میشوند (در صورت لزوم):
- برنامه شما از Android Gradle 4.2.0 یا بالاتر استفاده می کند.
- برنامه شما از R8 با مبهم سازی روشن استفاده می کند.
از آنجایی که خرابیهای جدید اکنون شامل پسوند فایل صحیح در امضای مشکل خود میشوند، ممکن است مشکلات .kt
جدیدی را مشاهده کنید که در واقع فقط تکراری از مشکلات موجود با برچسب .java
هستند. در کنسول Firebase، ما سعی میکنیم اگر یک مشکل .kt
جدید تکراری احتمالی یک مشکل با برچسب .java
موجود باشد، شناسایی کنیم و با شما در میان بگذاریم.
مقدار بدون خرابی نشاندهنده درصد کاربرانی است که با برنامه شما درگیر بودهاند اما در یک بازه زمانی خاص دچار خرابی نشدهاند .
در اینجا فرمول محاسبه درصد کاربران بدون خرابی وجود دارد. مقادیر ورودی آن توسط 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
ادغام ها
اگر پروژه شما از Crashlytics در کنار Google Mobile Ads SDK استفاده می کند، احتمالاً گزارشگران خرابی هنگام ثبت کنترل کننده های استثنا دخالت می کنند. برای رفع مشکل، با تماس با disableSDKCrashReporting
گزارش خرابی را در SDK تبلیغات موبایل خاموش کنید.
پس از اینکه Crashlytics را به BigQuery پیوند دادید، مجموعه دادههای جدیدی که ایجاد میکنید بهطور خودکار در ایالات متحده قرار میگیرند، بدون در نظر گرفتن مکان پروژه Firebase شما.
پشتیبانی از پلتفرم
Firebase Crashlytics NDK از ARMv5 (armeabi) پشتیبانی نمی کند. پشتیبانی از این ABI از NDK r17 حذف شد.
مسائل پسرفته
زمانی که شما قبلاً آن را بسته اید، یک مشکل پسرفت داشته است، اما Crashlytics گزارش جدیدی دریافت می کند مبنی بر اینکه مشکل دوباره رخ داده است. Crashlytics به طور خودکار این مشکلات پسرفته را مجدداً باز می کند تا بتوانید آنها را مطابق با برنامه خود برطرف کنید.
در اینجا یک سناریوی مثال آمده است که توضیح می دهد چگونه Crashlytics یک موضوع را به عنوان یک رگرسیون طبقه بندی می کند:
- برای اولین بار، Crashlytics یک گزارش خرابی در مورد Crash "A" دریافت می کند. Crashlytics یک مشکل مربوط به آن خرابی را باز می کند (مساله "A").
- شما این اشکال را به سرعت برطرف میکنید، شماره A را میبندید و سپس نسخه جدیدی از برنامه خود را منتشر میکنید.
- Crashlytics پس از بسته شدن این موضوع، گزارش دیگری در مورد مشکل "A" دریافت می کند.
- اگر گزارش مربوط به نسخه برنامهای است که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که نسخه اصلاً گزارش خرابی را برای هر خرابی ارسال کرده است)، Crashlytics این مشکل را پسرفته در نظر نخواهد گرفت. موضوع بسته خواهد ماند.
- اگر گزارش مربوط به نسخه برنامهای است که Crashlytics از آن اطلاعی نداشته است (به این معنی که نسخه هرگز گزارش خرابی برای هر خرابی ارسال نکرده است)، Crashlytics مشکل را پسرفتشده در نظر میگیرد و دوباره آن را باز میکند. .
وقتی مشکلی پسرفت میکند، یک هشدار تشخیص رگرسیون ارسال میکنیم و یک سیگنال رگرسیون به مشکل اضافه میکنیم تا به شما اطلاع دهیم که Crashlytics دوباره مشکل را باز کرده است. اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.
اگر گزارشی از یک نسخه برنامه قدیمی است که در هنگام بسته شدن مشکل، هیچ گزارش خرابی ارسال نکرده است، Crashlytics مشکل را پسرفته میداند و دوباره آن را باز میکند.
این وضعیت میتواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کردهاید و نسخه جدیدی از برنامه خود را منتشر کردهاید، اما همچنان کاربرانی در نسخههای قدیمیتر بدون رفع اشکال دارید. اگر بهطور تصادفی، یکی از آن نسخههای قدیمیتر هیچوقت هیچ گزارش خرابی ارسال نکرده بود، و آن کاربران شروع به مواجهه با باگ کردند، آن گزارشهای خرابی باعث ایجاد یک مشکل پسرفته میشوند.
اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.