عیب‌یابی و پرسشگان Crashlytics

دیدن قالب‌های مختلف (و گاهی اوقات «گونه‌ها») برای برخی‌از مشکلات در جدول مشکلات

ممکن است متوجه دو قالب متفاوت برای مشکلات فهرست‌شده در جدول مشکلات در کنسول Firebase شوید. همچنین ممکن است در برخی‌از مشکلات خود متوجه ویژگی‌ای به نام «گونه‌ها» شوید. دلیلش این است!

در اوایل سال ۲۰۲۳، موتور تجزیه‌وتحلیل بهبودیافته‌ای برای گروه‌بندی رویدادها و همچنین طراحی به‌روزشده و برخی‌از ویژگی‌های پیشرفته برای مشکلات جدید (مثل گونه‌ها!) عرضه کردیم. برای اطلاع از جزئیات کامل، پست وبلاگ اخیر ما را بررسی کنید، اما می‌توانید نکات مهم را در زیر بخوانید.

‫Crashlytics همه رویدادهای برنامه شما (مثل خرابی‌ها، خطاهای غیرمهلک، و خطاهای ANR) را تجزیه‌وتحلیل می‌کند و گروه‌هایی از رویدادها به نام مشکلات ایجاد می‌کند — همه رویدادهای یک مشکل نقطه مشترک خرابی دارند.

برای گروه‌بندی رویدادها در این مسائل، موتور تجزیه‌وتحلیل بهبودیافته اکنون به جنبه‌های زیادی از رویداد، ازجمله قاب‌های ردیابی پشته‌ای، پیام استثنا، کد خطا، و دیگر ویژگی‌های نوع خطا یا پلاتفرم نگاه می‌کند.

بااین‌حال، در این گروه از رویدادها، ردیابی‌های پشته‌ای که به خرابی منجر می‌شوند ممکن است متفاوت باشند. ردیابی پشته متفاوت می‌تواند به معنای علت ریشه‌ای متفاوت باشد. برای نشان دادن این تفاوت احتمالی در یک مشکل، اکنون در مشکلات گونه‌هایی ایجاد می‌کنیم - هر گونه زیرگروهی از رویدادها در یک مشکل است که نقطه خرابی یکسان و رد پشته مشابهی دارد. با انواع، می‌توانید رایج‌ترین ردیابی‌های پشته را در یک مشکل اشکال‌زدایی کنید و تعیین کنید که آیا علل ریشه‌ای مختلف منجر به خرابی می‌شوند یا خیر.

در اینجا با آنچه با این بهبودها تجربه خواهید کرد آشنا می‌شوید:

• فراداده بازطراحی‌شده در ردیف مشکل نمایش داده می‌شود
  اکنون درک و اولویت‌بندی مشکلات در برنامه‌تان آسان‌تر است.

• مشکلات تکراری کمتر
  تغییر شماره خط منجر به مشکل جدیدی نمی‌شود.

• عیب‌یابی آسان‌تر مشکلات پیچیده با دلایل ریشه‌ای مختلف
  از گونه‌ها برای عیب‌یابی رایج‌ترین ردیابی پشته در یک مشکل استفاده کنید.

• هشدارها و نشان‌های معنادارتر
  مشکل جدید درواقع نشان‌دهنده اشکال جدید است.

• جستجوی قدرتمندتر
  هر مشکل حاوی فراداده‌های قابل‌جستجوی بیشتری است، مثل نوع استثنا و نام بسته.

نحوه عرضه این بهبودها به این صورت است:

• وقتی رویدادهای جدیدی از برنامه‌تان دریافت می‌کنیم، بررسی می‌کنیم که آیا با مشکل موجودی مطابقت دارند یا نه.

• اگر مطابقت وجود نداشته باشد، به‌طور خودکار الگوریتم گروه‌بندی رویداد هوشمندتر خود را روی رویداد اعمال می‌کنیم و مشکل جدیدی با طراحی فراداده بازسازی‌شده ایجاد می‌کنیم.

این اولین به‌روزرسانی بزرگی است که در گروه‌بندی رویدادهایمان انجام می‌دهیم. اگر بازخوردی دارید یا با مشکلی مواجه شدید، ازطریق ثبت گزارش به ما اطلاع دهید.

گزارش‌های ردپای رخدادها را نمی‌بینید

اگر گزارش‌های ردیابی نمی‌بینید (iOS+‎ | Android | Flutter | Unity)، توصیه می‌کنیم پیکربندی برنامه‌تان را برای Google Analytics بررسی کنید. مطمئن شوید الزامات زیر را برآورده می‌کنید:

• Google Analytics را در پروژه Firebase خود فعال کرده‌اید.

• هم‌رسانی داده را برای Google Analytics فعال کرده‌اید. درباره این تنظیم در مدیریت تنظیمات هم‌رسانی داده‌های Analytics بیشتر بدانید

• «کیت توسعه نرم‌افزار Firebase» را برای Google Analytics به برنامه‌تان اضافه کرده‌اید: iOS+ | Android | Flutter | Unity.
  این کیت توسعه نرم‌افزار باید علاوه‌بر کیت توسعه نرم‌افزار Crashlytics اضافه شود.

• از جدیدترین نسخه‌های «کیت توسعه نرم‌افزار Firebase» برای همه محصولاتی که در برنامه‌تان استفاده می‌کنید (iOS+ | Android | Flutter | Unity) استفاده می‌کنید.

  برای پلاتفرم‌های Apple و برنامه‌های Android، به‌ویژه بررسی کنید که از حداقل نسخه زیر از «کیت توسعه نرم‌افزار Firebase برای Google Analytics» استفاده می‌کنید: iOS+‎ — نسخه ۶.۳.۱+‎ (نسخه ۸.۹.۰+‎ برای macOS و tvOS) | Android — نسخه ۱۷.۲.۳+‎ (BoM نسخه ۲۴.۷.۱+).

عدم مشاهده هشدارهای سرعت

اگر هشدارهای سرعت را نمی‌بینید، مطمئن شوید که از

سنجه‌های بدون خرابی را نمی‌بینید (یا سنجه‌های غیرقابل‌اعتماد می‌بینید)

اگر سنجه‌های بدون خرابی (مثل کاربران و جلسه‌های بدون خرابی) را نمی‌بینید یا سنجه‌های غیرقابل‌اعتماد می‌بینید، موارد زیر را بررسی کنید:

• مطمئن شوید که از استفاده می‌کنید.

• مطمئن شوید که تنظیمات جمع‌آوری داده‌های شما بر کیفیت سنجه‌های بدون خرابی شما تأثیر نمی‌گذارد:

  • اگر با غیرفعال کردن گزارش خرابی خودکار، گزارش موافقت را فعال کنید، اطلاعات خرابی فقط از کاربرانی که صریحاً با جمع‌آوری داده‌ها موافقت کرده‌اند به Crashlytics ارسال می‌شود. بنابراین، دقت سنجه‌های بدون خرابی تحت تأثیر قرار خواهد گرفت زیرا ‫Crashlytics فقط اطلاعات خرابی این کاربران موافقت‌کننده را دارد (به‌جای همه کاربران شما). این یعنی سنجه‌های بدون خرابی شما ممکن است قابل‌اعتماد نباشد و کمتر نشان‌دهنده پایداری کلی برنامه شما باشد.

  • اگر جمع‌آوری خودکار داده‌ها را غیرفعال کرده‌اید، می‌توانید از sendUnsentReports برای ارسال گزارش‌های ذخیره‌شده در حافظه نهان دستگاه به Crashlytics استفاده کنید. استفاده از این روش داده‌های خرابی را به Crashlytics ارسال می‌کند، اما داده‌های جلسه را ارسال نمی‌کند که باعث می‌شود نمودارهای کنسول مقادیر پایین یا صفر را برای سنجه‌های بدون خرابی نشان دهند.

کاربران بدون خرابی چگونه محاسبه می‌شوند؟

درک سنجه‌های بدون خرابی را ببینید.

چه کسی می‌تواند یادداشت‌های مربوط به یک مسئله را مشاهده، بنویسد، و حذف کند؟

یادداشت‌ها به اعضای پروژه اجازه می‌دهد درباره مسائل خاص با سؤالات، به‌روزرسانی‌های وضعیت، و غیره نظر دهند.

وقتی یکی از اعضای پروژه یادداشتی پست می‌کند، با ایمیل «حساب Google» او برچسب‌گذاری می‌شود. این نشانی ایمیل به‌همراه یادداشت برای همه اعضای پروژه که دسترسی به مشاهده یادداشت دارند نمایان است.

در زیر دسترسی‌های لازم برای مشاهده، نوشتن، و حذف کردن یادداشت‌ها توضیح داده شده است:

• اعضای پروژه با هریک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی برای یک مشکل بنویسند.

  • مالک یا ویرایشگر پروژه، سرپرست Firebase، سرپرست کیفیت، یا سرپرست Crashlytics

• اعضای پروژه با هریک از نقش‌های زیر می‌توانند یادداشت‌های پست‌شده در مسئله را ببینند، اما نمی‌توانند یادداشت‌ها را حذف یا یادداشت جدیدی بنویسند.

  • بیننده پروژه، بیننده Firebase، بیننده کیفیت، یا بیننده Crashlytics

مشکل پس‌رفت چیست؟

وقتی قبلاً مشکلی را بسته‌اید اما Crashlytics گزارش جدیدی دریافت می‌کند که مشکل دوباره رخ داده است، مشکل دچار پسرفت شده است. ‫Crashlytics به‌طور خودکار این مشکلات پس‌رفت را دوباره باز می‌کند تا بتوانید آن‌ها را به‌صورت مناسب برای برنامه‌تان برطرف کنید.

در اینجا سناریو مثالی آورده شده است که توضیح می‌دهد Crashlytics چگونه مشکلی را به‌عنوان پسرفت دسته‌بندی می‌کند:

1. برای اولین‌بار، Crashlytics گزارش خرابی درباره «خرابی A» دریافت می‌کند. ‫Crashlytics یک مشکل مربوط به آن خرابی باز می‌کند (مشکل «الف»).
2. این اشکال را به‌سرعت برطرف می‌کنید، «مسئله A» را می‌بندید، و سپس نسخه جدیدی از برنامه‌تان را منتشر می‌کنید.
3. ‫Crashlytics گزارش دیگری درباره «مشکل A» پس‌از اینکه مشکل را بسته‌اید دریافت می‌کند.
   • اگر گزارش مربوط به نسخه برنامه‌ای باشد که Crashlytics از آن مطلع بوده است وقتی مشکل را بستید (یعنی نسخه گزارش خرابی برای هر خرابی ارسال کرده است)، در این صورت Crashlytics مشکل را به‌عنوان پس‌رفت درنظر نخواهد گرفت. مشکل بسته باقی خواهد ماند.
   • اگر گزارش مربوط به نسخه برنامه‌ای باشد که Crashlytics وقتی مشکل را بستید از آن اطلاعی نداشت (یعنی نسخه هرگز گزارش خرابی برای هیچ خرابی‌ای ارسال نکرده بود)، در این صورت Crashlytics مشکل را بازگشت‌یافته درنظر می‌گیرد و مشکل را دوباره باز می‌کند.

وقتی مشکلی بازگشت می‌کند، هشدار تشخیص بازگشت ارسال می‌کنیم و نشان بازگشتی به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics مشکل را دوباره باز کرده است. اگر نمی‌خواهید مشکلی به‌دلیل الگوریتم پس‌رفت ما دوباره باز شود، به‌جای بستن مشکل، آن را «بی‌صدا» کنید.

چرا برای نسخه‌های قدیمی‌تر برنامه با مشکلات پس‌رفت مواجه می‌شوم؟

اگر گزارش مربوط به نسخه قدیمی برنامه‌ای باشد که هنگام بستن مشکل هیچ گزارش خرابی ارسال نکرده است، Crashlytics مشکل را پس‌رفت درنظر می‌گیرد و مشکل را دوباره باز می‌کند.

این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: اشکالی را برطرف کرده‌اید و نسخه جدیدی از برنامه‌تان منتشر کرده‌اید، اما هنوز کاربرانی دارید که از نسخه‌های قبلی بدون رفع اشکال استفاده می‌کنند. اگر به‌طور اتفاقی یکی از آن نسخه‌های قبلی هنگام بستن مشکل، گزارش خرابی ارسال نکرده باشد و آن کاربران با اشکال مواجه شوند، آن گزارش‌های خرابی باعث ایجاد مشکل پس‌رفت خواهد شد.

اگر نمی‌خواهید مشکلی به‌دلیل الگوریتم پس‌رفت ما دوباره باز شود، به‌جای بستن مشکل، آن را «بی‌صدا» کنید.

‫dSYM وجود ندارد/بارگذاری نمی‌شود

برای بارگذاری dSYM پروژه و دریافت برونداد پرحرف، موارد زیر را بررسی کنید:

1. مطمئن شوید که مرحله ساخت پروژه شما حاوی Crashlytics اجرای دستورگان باشد، که به Xcode اجازه می‌دهد dSYMهای پروژه شما را در زمان ساخت بارگذاری کند (برای دستورالعمل‌های افزودن دستورگان، Initializing Crashlytics را بخوانید). پس‌از به‌روزرسانی پروژه، خرابی اجباری ایجاد کنید و تأیید کنید که خرابی در داشبورد Crashlytics نشان داده می‌شود.

2. اگر هشدار «dSYM وجود ندارد» را در کنسول Firebase مشاهده کردید، Xcode را بررسی کنید تا مطمئن شوید dSYM را به‌درستی تولید می‌کند برای ساخت.

3. اگر Xcode به‌درستی dSYM تولید می‌کند و همچنان dSYM ازدست‌رفته می‌بینید، احتمالاً ابزار اجرای دستور درحین بارگذاری dSYM گیر می‌کند. در این حالت، هریک از موارد زیر را امتحان کنید:

   • مطمئن شوید که از جدیدترین نسخه Crashlytics استفاده می‌کنید.

   • فایل‌های dSYM ناموجود را به‌صورت دستی بارگذاری کنید:

     • گزینه ۱: از گزینه مبتنی بر کنسول «کشیدن و رها کردن» در برگه dSYMs برای بارگذاری بایگانی zip حاوی فایل‌های dSYM مفقودشده استفاده کنید.
     • گزینه ۲: از upload-symbols نوشتار برای بارگذاری فایل‌های dSYM ازدست‌رفته، برای شناسه‌های UUID ارائه‌شده در برگه dSYMs استفاده کنید.

4. اگر همچنان dSYMهای ازدست‌رفته را می‌بینید یا بارگذاری‌ها همچنان ناموفق هستند، با پشتیبانی Firebase تماس بگیرید و حتماً گزارش‌هایتان را ارسال کنید.

ازکارافتادگی‌ها به‌درستی نمادسازی نشده‌اند

اگر پشته‌های ردیابی شما به‌نظر می‌رسد که نمادگذاری ضعیفی دارند، موارد زیر را بررسی کنید:

• اگر چارچوب‌های کتابخانه برنامه‌تان به کد برنامه شما ارجاع نمی‌دهند، مطمئن شوید که -fomit-frame-pointer به‌عنوان پرچم تدوین تنظیم نشده باشد.

• اگر چند قاب (Missing) برای کتابخانه برنامه‌تان می‌بینید، بررسی کنید آیا dSYM اختیاری به‌عنوان مفقود (برای نسخه برنامه تحت‌تأثیر قرارگرفته) در برگه Crashlytics dSYMs کنسول Firebase فهرست شده است یا نه. اگر این‌طور است، مرحله عیب‌یابی «هشدار dSYM ازدست‌رفته» را در پرسشگان dSYM ازدست‌رفته/بارگذاری نمی‌شود در این صفحه دنبال کنید. توجه داشته باشید که بارگذاری این dSYMها باعث نمادگذاری خرابی‌هایی که قبلاً رخ داده‌اند نمی‌شود، اما این کار به اطمینان از نمادگذاری خرابی‌های آینده کمک می‌کند.

آیا می‌توانم از Crashlytics برای macOS یا tvOS استفاده کنم؟

بله، می‌توانید Crashlytics را در پروژه‌های macOS و tvOS پیاده‌سازی کنید. حتماً نسخه ۸.۹.۰ یا بالاتر از «کیت توسعه نرم‌افزار Firebase» را برای Google Analytics اضافه کنید تا خرابی‌ها به سنجه‌های جمع‌آوری‌شده توسط Google Analytics (کاربران بدون خرابی، جدیدترین نسخه، هشدارهای سرعت، و گزارش‌های ردپا) دسترسی داشته باشند.

آیا می‌توانم از Crashlytics در پروژه Firebase با چندین برنامه در پلاتفرم‌های مختلف Apple استفاده کنم؟

اکنون می‌توانید خرابی‌های چند برنامه را در یک پروژه Firebase گزارش کنید، حتی اگر برنامه‌ها برای پلاتفرم‌های مختلف Apple ساخته شده باشند (برای مثال، iOS،‏ tvOS، و Mac Catalyst). قبلاً، اگر برنامه‌ها شناسه دسته‌ای یکسانی داشتند، باید آن‌ها را در پروژه‌های Firebase جداگانه قرار می‌دادید.

چرا خطاهای ANR فقط برای Android 11 و نسخه‌های بالاتر گزارش می‌شود؟

‫Crashlytics از گزارش خطای ANR برای برنامه‌های Android در دستگاه‌هایی که از Android 11 و بالاتر استفاده می‌کنند پشتیبانی می‌کند. میانای برنامه‌سازی کاربردی زیربنایی که برای جمع‌آوری ANR استفاده می‌کنیم (getHistoricalProcessExitReasons) از رویکردهای مبتنی بر SIGQUIT یا watchdog قابل‌اعتمادتر است. این «میانای برنامه‌سازی کاربردی» فقط در دستگاه‌های Android 11 و بالاتر دردسترس است.

چرا برخی‌از خطاهای ANR BuildId ندارند؟

اگر برخی‌از ANRهای شما BuildId ندارند، به روش زیر عیب‌یابی کنید:

• مطمئن شوید که از نسخه به‌روز Crashlytics کیت توسعه نرم‌افزار Android و Crashlytics افزایه Gradle استفاده می‌کنید.

  اگر BuildId مربوط به Android 11 و برخی‌از خطاهای ANR مربوط به Android 12 را ندارید، احتمالاً از کیت توسعه نرم‌افزار یا افزایه Gradle قدیمی یا هر دو استفاده می‌کنید. برای جمع‌آوری صحیح BuildId برای این ANRها، باید از نسخه‌های زیر استفاده کنید:

  • ‫Crashlytics Android SDK v18.3.5+‎‏ (Firebase BoM v31.2.2+)‎
  • Crashlytics افزایه Gradle نسخه ۲.۹.۴ و بالاتر

• بررسی کنید که آیا از مکان غیرمعمولی برای کتابخانه‌های مشترک خود استفاده می‌کنید یا خیر.

  اگر فقطBuildIds برای کتابخانه‌های مشترک برنامه‌تان ندارید، احتمالاً از مکان استاندارد و پیش‌فرض برای کتابخانه‌های مشترک استفاده نمی‌کنید. اگر این‌طور باشد، Crashlytics ممکن است نتواند BuildIdهای مرتبط را پیدا کند. توصیه می‌کنیم که از مکان استاندارد برای کتابخانه‌های مشترک استفاده کنید.

• مطمئن شوید که درطول فرایند ساخت، BuildIdها را حذف نمی‌کنید.

  توجه داشته باشید که نکات عیب‌یابی زیر هم برای خطاهای ANR و هم برای خرابی‌های بومی اعمال می‌شود.

  • با اجرای readelf -n روی فایل‌های باینری، بررسی کنید که BuildId وجود دارد یا نه. اگر BuildId وجود ندارد، -Wl,--build-id را به پرچم‌های سیستم ساخت اضافه کنید.

  • بررسی کنید که به‌طور ناخواسته BuildId را در تلاش برای کاهش اندازه APK حذف نکرده باشید.

  • اگر نسخه‌های حذف‌شده و حذف‌نشده کتابخانه‌ای را نگه می‌دارید، مطمئن شوید که در کد خود به نسخه صحیح اشاره می‌کنید.

تفاوت‌های بین گزارش‌های ANR در داشبورد Crashlytics و «کنسول Google Play»

ممکن است بین تعداد خطاهای ANR در Google Play و Crashlytics عدم تطابق وجود داشته باشد. این امر به‌دلیل تفاوت در سازوکار جمع‌آوری و گزارش داده‌های ANR قابل‌انتظار است. ‫Crashlytics هنگام راه‌اندازی بعدی برنامه خطاهای ANR را گزارش می‌کند، درحالی‌که «معیارهای کلیدی Android» داده‌های خطای ANR را پس‌از وقوع آن ارسال می‌کند.

علاوه‌براین، Crashlytics فقط خطاهای ANR را که در دستگاه‌های دارای Android 11 به بالا رخ می‌دهد نمایش می‌دهد، درحالی‌که Google Play خطاهای ANR را از دستگاه‌های دارای «خدمات Google Play» و موافقت با جمع‌آوری داده‌ها نمایش می‌دهد.

چرا خرابی‌هایی از .kt فایل برچسب‌گذاری‌شده به‌عنوان .java مشکل می‌بینم؟

وقتی برنامه‌ای از مبهم‌سازی استفاده می‌کند که پسوند فایل را آشکار نمی‌کند، Crashlytics هر مشکل را به‌طور پیش‌فرض با پسوند فایل .java تولید می‌کند.

برای اینکه Crashlytics بتواند مشکلات را با افزونه فایل صحیح تولید کند، مطمئن شوید که برنامه‌تان از تنظیمات زیر استفاده می‌کند:

• از Android Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند
• از R8 با روشن بودن مبهم‌سازی استفاده می‌کند. برای به‌روزرسانی برنامه‌تان به R8، این مستندات را دنبال کنید.

توجه داشته باشید که پس‌از به‌روزرسانی به تنظیمات شرح‌داده‌شده در بالا، ممکن است مشکلات جدید .kt را ببینید که تکراری از مشکلات موجود .java هستند. برای کسب اطلاعات بیشتر درباره این شرایط، به پرسشگان مراجعه کنید.

چرا .kt مشکل را می‌بینم که تکراری از مشکلات .java موجود است؟

از اواسط دسامبر ۲۰۲۱، Crashlytics پشتیبانی از برنامه‌هایی که از Kotlin استفاده می‌کنند را بهبود بخشید.

تا همین اواخر، درهم‌سازهای دردسترس افزونه فایل را آشکار نمی‌کردند، بنابراین Crashlytics هر مشکل را به‌طور پیش‌فرض با افزونه فایل .java تولید می‌کرد. بااین‌حال، از Android Gradle 4.2.0،‏ R8 از پسوندهای فایل پشتیبانی می‌کند.

با این به‌روزرسانی، Crashlytics اکنون می‌تواند تشخیص دهد که آیا هر کلاس استفاده‌شده در برنامه به زبان Kotlin نوشته شده است یا نه و نام فایل صحیح را در امضای مشکل اضافه کند. اکنون خرابی‌ها به‌درستی به .kt فایل (درصورت لزوم) نسبت داده می‌شود اگر برنامه شما تنظیمات زیر را داشته باشد:

• برنامه‌تان از Android Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند.
• برنامه شما از R8 با فعال بودن مبهم‌سازی استفاده می‌کند.

ازآنجایی‌که خرابی‌های جدید اکنون پسوند فایل صحیح را در امضای مشکل خود دارند، ممکن است مشکلات جدید .kt را ببینید که درواقع فقط تکراری از مشکلات موجود با برچسب .java هستند. در کنسول Firebase، تلاش می‌کنیم اگر مشکل جدید .kt احتمالاً تکراری از مشکل موجود با برچسب .java باشد، آن را شناسایی کنیم و به شما اطلاع دهیم.

با Dexguard ازکارافتادگی دریافت نمی‌کنید

اگر استثنای زیر را می‌بینید، احتمالاً از نسخه DexGuard استفاده می‌کنید که با کیت توسعه نرم‌افزار Firebase Crashlytics سازگار نیست:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

این استثنا باعث ازکارافتادن برنامه شما نمی‌شود اما مانع از ارسال گزارش‌های خرابی می‌شود. برای رفع این مشکل:

1. مطمئن شوید که از جدیدترین نسخه DexGuard 8.x استفاده می‌کنید. جدیدترین نسخه حاوی قوانینی است که کیت توسعه نرم‌افزار Firebase Crashlytics به آن‌ها نیاز دارد.

2. اگر نمی‌خواهید نسخه DexGuard خود را تغییر دهید، خط زیر را به قوانین مبهم‌سازی خود (در فایل پیکربندی DexGuard) اضافه کنید:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

چگونه به افزایه Crashlytics Gradle نسخه ۳ ارتقا دهیم؟

جدیدترین نسخه افزایه Gradle Crashlytics نسخه اصلی (v3.0.0) است و با حذف پشتیبانی از نسخه‌های پایین‌تر Gradle و افزایه Android Gradle، کیت توسعه نرم‌افزار را مدرن‌سازی می‌کند. علاوه‌براین، تغییرات این نسخه مشکلات مربوط به AGP نسخه ۸.۱ و بالاتر را برطرف می‌کند و پشتیبانی از برنامه‌های بومی و ساختمان‌های سفارشی‌سازی‌شده را بهبود می‌بخشد.

حداقل الزامات

افزایه Crashlytics Gradle نسخه ۳ حداقل ملزومات زیر را دارد:

• افزایه Android Gradle نسخه ۸.۱ و بالاتر
  این افزایه را بااستفاده از دستیار ارتقا افزایه Android Gradle در جدیدترین نسخه Android Studio ارتقا دهید.

• افزایه Gradle در Firebase google-services نسخه 4.4.1 یا بالاتر
  این افزایه را با مشخص کردن جدیدترین نسخه در فایل ساخت Gradle پروژه خود به‌روز کنید، مانند این:

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

تغییرات در افزونه Crashlytics

با افزایه Gradle نسخه ۳ Crashlytics، افزونه Crashlytics تغییرات زیر را دارد که باعث ازکار افتادن می‌شود:

• افزونه از بلوک Android defaultConfig برداشته شد. درعوض، باید هر گونه را پیکربندی کنید.

• فیلد منسوخ‌شده mappingFile برداشته شد. به‌جای آن، فایل ادغام‌شده نقشه اکنون به‌طور خودکار ارائه می‌شود.

• فیلد منسوخ‌شده strippedNativeLibsDir برداشته شد. درعوض، باید از unstrippedNativeLibsDir برای همه کتابخانه‌های بومی استفاده کنید.

• فیلد unstrippedNativeLibsDir را به حالت تجمعی تغییر داد.

  مشاهده نمونه‌ای با چند فهرست راهنما

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  تکلیف uploadCrashlyticsSymbolFilesBasicRelease فقط نمادهای موجود در MY/NATIVE/LIBS را بارگذاری می‌کند، اما uploadCrashlyticsSymbolFilesFeatureXRelease نمادهای موجود در MY/NATIVE/LIBS و MY/FEATURE_X/LIBS را بارگذاری می‌کند.

• فیلد بسته شدن symbolGenerator با دو فیلد سطح بالای جدید جایگزین شد:

  • ‫symbolGeneratorType، رشته‌ای از "breakpad" (پیش‌فرض) یا "csym".
  • ‫breakpadBinary، فایل لغو باینری محلی dump_syms.

نمونه‌ای از نحوه ارتقا دادن افزونه

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

تفاوت‌های بین ردیابی پشته NDK در داشبورد Crashlytics و logcat

زنجیره‌های ابزار LLVM و GNU پیش‌فرض‌ها و پردازش‌های متمایزی برای بخش فقط‌خواندنی باینری‌های برنامه شما دارند که ممکن است باعث تولید ردیابی پشته ناسازگار در کنسول Firebase شود. برای کاهش این مشکل، پرچم‌های پیونددهنده زیر را به فرایند ساخت اضافه کنید:

• اگر از پیونددهنده lld از زنجیره ابزار LLVM استفاده می‌کنید، این موارد را اضافه کنید:

  -Wl,--no-rosegment

• اگر از پیونددهنده ld.gold از زنجیره ابزار GNU استفاده می‌کنید، این موارد را اضافه کنید:

  -Wl,--rosegment

اگر همچنان ناسازگاری‌های ردیابی پشته را می‌بینید (یا اگر هیچ‌کدام از پرچم‌ها مربوط به زنجیره ابزار شما نیست)، به‌جای آن، موارد زیر را به فرایند ساخت خود اضافه کنید:

-fno-omit-frame-pointer

چگونه از برنامه تولیدکننده فایل نماد Breakpad خودم برای NDK استفاده کنم؟

افزایه Crashlytics شامل تولیدکننده فایل نماد Breakpad سفارشی‌سازی‌شده است. اگر ترجیح می‌دهید از باینری خودتان برای تولید فایل‌های نماد Breakpad استفاده کنید (برای مثال، اگر ترجیح می‌دهید همه فایل‌های اجرایی بومی را در زنجیره ساخت خود از منبع بسازید)، از دارایی اختیاری افزونه symbolGeneratorBinary برای مشخص کردن مسیر فایل اجرایی استفاده کنید.

می‌توانید مسیر فایل اجرایی تولیدکننده فایل نماد Breakpad را به یکی از دو روش زیر مشخص کنید:

• گزینه ۱: مسیر را ازطریق firebaseCrashlytics افزونه در فایل build.gradle مشخص کنید

  مورد زیر را به فایل build.gradle.kts سطح برنامه اضافه کنید:

  افزایه Gradle نسخه ۳.۰.۰ و بالاتر

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  نسخه‌های پایین‌تر افزایه

  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")
            }
          }
        }
     }
  }

• گزینه ۲: مسیر را ازطریق خط دارایی در فایل Gradle properties مشخص کنید

  می‌توانید از دارایی com.google.firebase.crashlytics.breakpadBinary برای مشخص کردن مسیر فایل اجرایی استفاده کنید.

  می‌توانید فایل دارایی‌های Gradle را به‌صورت دستی به‌روز کنید یا فایل را ازطریق خط فرمان به‌روز کنید. برای مثال، برای مشخص کردن مسیر ازطریق خط فرمان، از فرمانی مانند فرمان زیر استفاده کنید:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

آیا Crashlytics از armeabi پشتیبانی می‌کند؟

‫NDK Firebase Crashlytics از ARMv5 (armeabi) پشتیبانی نمی‌کند. پشتیبانی از این ABI از NDK r17 برداشته شد.

مشاهده پشته‌های ردیابی غیرنمادین برای برنامه‌های Android در داشبورد Crashlytics

اگر از Unity IL2CPP استفاده می‌کنید و ردیابی پشته بدون نماد می‌بینید، موارد زیر را امتحان کنید:

1. مطمئن شوید که از نسخه ۸.۶.۱ یا بالاتر از Crashlytics Unity SDK استفاده می‌کنید.

2. مطمئن شوید که برای اجرای دستور Firebase CLI crashlytics:symbols:upload برای تولید و بارگذاری فایل نماد راه‌اندازی شده‌اید.

   هر بار که نسخه ساخت یا هر ساخت دیگری را که می‌خواهید ردیابی پشته نمادین‌شده آن را در کنسول Firebase ببینید ایجاد می‌کنید، باید این دستور CLI را اجرا کنید. در دریافت گزارش‌های خرابی خوانا بیشتر بدانید.

آیا می‌توان از Crashlytics با برنامه‌هایی که از IL2CPP استفاده می‌کنند استفاده کرد؟

بله، Crashlytics می‌تواند ردیابی پشته نمادین‌شده را برای برنامه‌هایی که از IL2CPP استفاده می‌کنند نمایش دهد. این قابلیت برای برنامه‌هایی که در پلاتفرم‌های Android یا Apple منتشر شده‌اند دردسترس است. آنچه باید انجام دهید در اینجا آورده شده است:

1. مطمئن شوید که از نسخه ۸.۶.۰ یا بالاتر از Crashlytics Unity SDK استفاده می‌کنید.

2. تکالیف لازم برای پلاتفرم خود را تکمیل کنید:

   • برای برنامه‌های پلاتفرم Apple: هیچ اقدام ویژه‌ای لازم نیست. برای برنامه‌های پلاتفرم Apple، افزایه Firebase Unity Editor به‌طور خودکار پروژه Xcode شما را برای بارگذاری نمادها پیکربندی می‌کند.

   • برای برنامه‌های Android: مطمئن شوید که برای اجرای فرمان Firebase CLI crashlytics:symbols:upload برای تولید و بارگذاری فایل نماد آماده‌اید.

     هر بار که نسخه ساخت یا هر ساخت دیگری را که می‌خواهید ردیابی پشته نمادگذاری‌شده آن را در کنسول Firebase ببینید ایجاد می‌کنید، باید این دستور CLI را اجرا کنید. در دریافت گزارش‌های خرابی خوانا بیشتر بدانید.

چرا یک برنامه باید استثناهای مدیریت‌نشده را به‌عنوان خطاهای مهلک گزارش کند؟

با گزارش کردن استثناهای غیرقابل‌درک به‌عنوان خطاهای مهلک، نشانگر واقع‌گرایانه‌تری از استثناهایی که ممکن است باعث غیرقابل‌بازی شدن بازی شود دریافت می‌کنید – حتی اگر برنامه همچنان اجرا شود.

توجه داشته باشید که اگر گزارش خطاهای مهلک را شروع کنید، درصد کاربران بدون خرابی (CFU) شما احتمالاً کاهش خواهد یافت، اما سنجه CFU نماینده بهتری از تجربه کاربران نهایی با برنامه شما خواهد بود.

کدام استثناها به‌عنوان خطاهای مهلک گزارش خواهند شد؟

برای اینکه Crashlytics استثنای غیرقابل‌مهار را به‌عنوان مهلک گزارش کند، هر دو شرط زیر باید برقرار باشد:

• درطول مقداردهی اولیه در برنامه‌تان، دارایی ReportUncaughtExceptionsAsFatal باید روی true تنظیم شود.

• برنامه شما (یا کتابخانه گنجانده‌شده) استثنایی را ایجاد می‌کند که دریافت نمی‌شود. استثنایی که ایجاد شده است، اما پرتاب نشده است، به‌عنوان استثنای مدیریت‌نشده درنظر گرفته نمی‌شود.

پس‌از فعال کردن گزارش استثناهای غیرقابل‌کنترل به‌عنوان خطاهای مهلک، اکنون خطاهای مهلک جدید زیادی دارم. چگونه این استثناها را به‌درستی مدیریت کنم؟

وقتی گزارش‌های استثناهای مدیریت‌نشده‌تان را به‌عنوان خطاهای مهلک دریافت می‌کنید، در اینجا چند گزینه برای مدیریت این استثناهای مدیریت‌نشده ارائه شده است:

• به این فکر کنید که چگونه می‌توانید این استثناهای مدیریت‌نشده را دریافت و مدیریت کنید.
• گزینه‌های مختلفی را برای ثبت استثناها در کنسول اشکال‌زدایی Unity و در Crashlytics درنظر بگیرید.

استثناهای پرتاب‌شده را دریافت و مدیریت کنید

استثناها برای انعکاس وضعیت‌های غیرمنتظره یا استثنایی ایجاد و پرتاب می‌شوند. حل‌وفصل مشکلات منعکس‌شده توسط استثنای پرتاب‌شده شامل برگرداندن برنامه به وضعیت شناخته‌شده (فرایندی که به‌عنوان مدیریت استثنا شناخته می‌شود) است.

بهترین روال این است که همه استثناهای پیش‌بینی‌شده را دریافت و مدیریت کنید، مگر اینکه برنامه نتواند به وضعیت شناخته‌شده برگردد.

برای کنترل اینکه کدام نوع استثناها توسط کدام کد دریافت و مدیریت شوند، کدی را که ممکن است استثنا تولید کند در بلوک try-catch قرار دهید. مطمئن شوید که شرایط در catch بیانیه‌ها تا حد امکان محدود باشد تا استثناهای خاص به‌درستی مدیریت شوند.

ثبت استثناها در Unity یا Crashlytics

چندین روش برای ثبت استثناها در Unity یا Crashlytics وجود دارد تا به عیب‌یابی مشکل کمک کند.

هنگام استفاده از Crashlytics، در اینجا دو گزینه رایج و توصیه‌شده را می‌بینید:

• گزینه ۱: در کنسول Unity چاپ کنید، اما درطول توسعه یا عیب‌یابی به Crashlytics گزارش نکنید

  • بااستفاده از Debug.Log(exception)، Debug.LogWarning(exception)، و Debug.LogError(exception) در کنسول Unity چاپ کنید که محتوای استثنا را در کنسول Unity چاپ می‌کنند و استثنا را دوباره پرتاب نمی‌کنند.

• گزینه ۲: برای گزارش‌دهی یکپارچه در داشبورد Crashlytics در موقعیت‌های زیر، در Crashlytics بارگذاری کنید:

  • اگر استثنایی ارزش ثبت شدن برای اشکال‌زدایی رویداد احتمالی بعدی Crashlytics را دارد، از Crashlytics.Log(exception.ToString()) استفاده کنید.
  • اگر استثنایی باید همچنان به Crashlytics گزارش شود، با وجود اینکه گرفته و مدیریت شده است، از Crashlytics.LogException(exception) برای ثبت آن به‌عنوان رویداد غیرمهلک استفاده کنید.

بااین‌حال، اگر می‌خواهید رویداد مهلکی را به‌صورت دستی به «تشخیص خرابی Unity Cloud» گزارش کنید، می‌توانید از Debug.LogException استفاده کنید. این گزینه استثنا را مانند «گزینه ۱» در کنسول Unity چاپ می‌کند، اما استثنا را نیز پرتاب می‌کند (چه قبلاً پرتاب یا دریافت شده باشد چه نشده باشد). خطا را به‌صورت غیرمحلی ایجاد می‌کند. این یعنی حتی یک Debug.LogException(exception) با try-catch بلوک اطراف هم همچنان منجر به استثنای مدیریت‌نشده می‌شود.

بنابراین، فقط و فقط درصورتی با Debug.LogException تماس بگیرید که بخواهید همه موارد زیر را انجام دهید:

• برای چاپ استثنا در کنسول Unity.
• برای بارگذاری استثنا در Crashlytics به‌عنوان رویداد مهلک.
• برای پرتاب استثنا، آن را به‌عنوان استثنای جاافتاده درنظر بگیرید و آن را به «تشخیص خرابی ابری Unity» گزارش کنید.

توجه داشته باشید که اگر می‌خواهید استثنای گرفته‌شده را در کنسول Unity چاپ کنید و آن را به‌عنوان رویداد غیرمهلک در 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
    //
}

برنامه از کیت توسعه نرم‌افزار Google Mobile Ads نیز استفاده می‌کند اما خرابی دریافت نمی‌کند

اگر پروژه شما از Crashlytics در کنار کیت توسعه نرم‌افزار Google Mobile Ads استفاده می‌کند، احتمالاً گزارشگران خرابی هنگام ثبت کردن مدیریت‌کننده‌های استثنا تداخل ایجاد می‌کنند. برای برطرف کردن مشکل، گزارش خرابی را در کیت توسعه نرم‌افزار Mobile Ads با فراخوانی disableSDKCrashReporting خاموش کنید.

مجموعه‌داده BigQuery من کجا قرار دارد؟

‫Firebase داده‌ها را به مکان مجموعه داده‌ای که هنگام راه‌اندازی صادر کردن داده‌ها به BigQuery انتخاب کردید صادر می‌کند.

• این مکان هم بر مجموعه داده Crashlytics و هم بر مجموعه داده جلسه‌های Firebase اعمال می‌شود (اگر داده‌های جلسه برای صادر کردن فعال شده باشد).

• این مکان فقط برای داده‌هایی که به BigQuery صادر می‌شود کاربرد دارد و بر مکان داده‌های ذخیره‌شده برای استفاده در داشبورد Crashlytics کنسول Firebase یا در Android Studio تأثیری ندارد.

• پس‌از ایجاد مجموعه داده، مکان آن را نمی‌توان تغییر داد، اما می‌توانید مجموعه داده را در مکان دیگری کپی کنید یا مجموعه داده را به‌صورت دستی در مکان دیگری منتقل (بازسازی) کنید. برای کسب اطلاعات بیشتر، تغییر مکان برای برون‌برد‌های موجود را ببینید.

پس‌از ارتقا به زیرساخت جدید برون‌برد برای BigQuery مشکلی دارید؟

در اواسط اکتبر ۲۰۲۴، Crashlytics زیرساخت جدیدی برای صادر کردن دسته‌ای داده‌های Crashlytics به BigQuery راه‌اندازی کرد.

همه پروژه‌های Firebase از تاریخ ۲ مارس ۲۰۲۶ به‌طور خودکار به زیرساخت جدید صادر کردن دسته‌ای ارتقا یافته‌اند.

تفاوت‌های مهم بین زیرساخت قدیمی صادرات و زیرساخت جدید صادرات

• زیرساخت جدید از Crashlytics مکان مجموعه داده در خارج از ایالات متحده پشتیبانی می‌کند.

  • صادرات قبل‌از اواسط اکتبر ۲۰۲۴ فعال شده باشد و به زیرساخت صادرات جدید ارتقا یافته باشد — اکنون می‌توانید به‌صورت اختیاری مکان صادرات داده‌ها را تغییر دهید.

  • صادر کردن در اواسط اکتبر ۲۰۲۴ یا بعداز آن فعال شده باشد — درطول راه‌اندازی از شما خواسته شده باشد مکانی را برای صادر کردن داده‌ها انتخاب کنید.

• زیرساخت جدید از داده‌های جای‌خالی از قبل‌از فعال کردن برون‌برد پشتیبانی نمی‌کند.

  • زیرساخت قدیمی از داده‌های جای‌گزین تا ۳۰ روز قبل‌از تاریخی که صادر کردن را فعال کردید پشتیبانی می‌کرد.

  • زیرساخت جدید از پر کردن شکاف‌های داده تا ۳۰ روز گذشته یا برای جدیدترین تاریخی که صادر کردن را به BigQuery فعال کرده‌اید پشتیبانی می‌کند (هرکدام جدیدتر باشد).

• زیرساخت جدید BigQuery جدول دسته‌ای را بااستفاده از شناسه‌های تنظیم‌شده برای «برنامه‌های Firebase» در پروژه Firebase شما نام‌گذاری می‌کند.

  • زیرساخت قدیمی داده‌ها را در جدول‌های دسته‌ای با نام‌هایی براساس شناسه‌های بسته یا نام‌های بسته در باینری برنامه شما می‌نوشت.

  • زیرساخت جدید داده‌ها را در جدول‌های دسته‌ای با نام‌هایی براساس شناسه‌های دسته‌ای یا نام‌های بسته تنظیم‌شده برای «برنامه‌های Firebase» ثبت‌شده در پروژه Firebase شما می‌نویسد.

اگر نام جدول دسته‌ای قدیمی شما با شناسه برنامه Firebase شما مطابقت نداشت

اگر نام جدول دسته‌ای قدیمی شما با شناسه بسته یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما مطابقت ندارد، یکی از این گزینه‌ها را پیاده‌سازی کنید تا از اختلالات بیشتر در داده‌های دسته‌ای برون‌بردشده جلوگیری کنید.

درک نحوه استفاده زیرساخت برون‌برد از شناسه‌ها برای نوشتن داده‌ها در BigQuery جدول

در اینجا نحوه نوشتن داده‌های Crashlytics در BigQuery جدول دسته‌ای توسط دو زیرساخت برون‌برد توضیح داده شده است:

• زیرساخت برون‌برد قدیمی: داده‌ها را در جدولی با نامی که براساس شناسه دسته یا نام بسته در باینری برنامه شما است می‌نوشت.

• زیرساخت جدید برون‌برد: داده‌ها را در جدولی با نامی که براساس شناسه دسته یا نام بسته برای «برنامه Firebase» ثبت‌شده در پروژه Firebase شما تنظیم شده است می‌نویسد.

متأسفانه، گاهی اوقات شناسه بسته یا نام بسته در باینری برنامه شما با شناسه بسته یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده در پروژه Firebase شما مطابقت ندارد. این اتفاق معمولاً زمانی می‌افتد که فردی شناسه واقعی را درطول ثبت برنامه وارد نکرده باشد.

اگر این مشکل قبل‌از ارتقا برطرف نشود چه اتفاقی می‌افتد؟

اگر شناسه‌های این دو مکان مطابقت نداشته باشند، موارد زیر اتفاق افتاده است:

• داده‌های Crashlytics شما اکنون در جدول دسته‌ای جدید BigQuery نوشته می‌شود — یعنی جدول جدیدی با نامی براساس شناسه بسته یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما در پروژه Firebase شما.

• هر جدول «قدیمی» موجود با نامی براساس شناسه در باینری برنامه‌تان دیگر داده‌ای در آن نوشته نمی‌شود.

سناریوهای نمونه از شناسه‌های نامنطبق

توجه داشته باشید که نام‌های جدول دسته‌ای BigQuery به‌طور خودکار با _IOS یا _ANDROID برای نشان دادن پلاتفرم برنامه اضافه می‌شوند.

^{* اگر شناسه در باینری برنامه شما با یکی از شناسه‌های تنظیم‌شده برای «برنامه Firebase» مطابقت داشته باشد، زیرساخت برون‌برد جدید جدول جدیدی برای آن شناسه ایجاد نمی‌کند. درعوض، همچنان به نوشتن داده‌ها برای آن برنامه خاص در آن ادامه خواهد داد. همه برنامه‌های دیگر در جدول‌های جدید نوشته خواهند شد.}

^{** اگر یکی از شناسه‌های موجود در باینری برنامه شما با مجموعه شناسه‌های برنامه Firebase مطابقت داشته باشد، زیرساخت برون‌برد جدید جدول جدیدی ایجاد نمی‌کند. درعوض، آن جدول را حفظ می‌کند و شروع به نوشتن داده‌های همه برنامه‌ها در آن می‌کند.}

گزینه‌های کاهش اختلال

• گزینه ۱:
  از جدول جدیدی که توسط زیرساخت جدید برون‌برد ایجاد شده است استفاده کنید. داده‌ها را از جدول قدیمی‌تان به جدول جدید کپی خواهید کرد.

  1. در کنسول Google Cloud، همه داده‌ها را از جدول قدیمی‌تان به جدول جدیدی که درطول ارتقای زیرساخت ایجاد شده است کپی کنید.

  2. اگر وابستگی‌های پایین‌دستی دارید که به جدول دسته‌ای شما وابسته هستند، آن‌ها را تغییر دهید تا از جدول جدید استفاده کنند.

• گزینه ۲:
  برای نوشتن دوباره در جدول قدیمی، پیکربندی مجدد کنید. برای رسیدن به این هدف، باید برخی‌از پیش‌فرض‌ها را در پیکربندی BigQuery ملغی کنید.

  1. در کنسول Firebase، «شناسه برنامه Firebase» (برای نمونه، 1:1234567890:ios:321abc456def7890) برنامه با نام و شناسه جدول دسته‌ای نامنطبق را پیدا کنید و یادداشت کنید:
     به settings تنظیمات پروژه بروید، سپس به کارت برنامه‌های شما بروید تا همه «برنامه‌های Firebase» و اطلاعات آن‌ها را ببینید.

  2. در کنسول Google Cloud، «پیکربندی انتقال داده» جدیدی را که با ارتقای زیرساخت ایجاد شده است تغییر دهید تا داده‌ها در جدول قدیمی شما نوشته شود:

     1. برای مشاهده «پیکربندی انتقال داده»، به BigQuery > انتقال داده بروید.

     2. پیکربندی‌ای را که منبع Firebase Crashlytics with Multi-Region Support دارد انتخاب کنید.

     3. روی ویرایش در گوشه بالا سمت چپ کلیک کنید.

     4. در بخش جزئیات منبع داده، فهرستی برای gmp_app_id و فهرستی برای client_namespace پیدا کنید.

        در BigQuery، شناسه برنامه Firebase را gmp_app_id می‌نامند. به‌طور پیش‌فرض، مقدار client_namespace در BigQuery شناسه بسته نرم‌افزاری / نام بسته متمایز مربوط به برنامه است، اما این پیکربندی پیش‌فرض را ملغی خواهید کرد.

        ‫BigQuery از مقدار client_namespace برای نام جدول دسته‌ای که هر «برنامه Firebase» پیوندشده در آن می‌نویسد استفاده می‌کند.

     5. gmp_app_id برنامه Firebase را که می‌خواهید تنظیمات پیش‌فرض آن را ملغی کنید پیدا کنید. مقدار client_namespace آن را به نام جدولی که می‌خواهید «برنامه Firebase» به‌جای آن بنویسد تغییر دهید (معمولاً این نام جدول قدیمی است که برنامه با زیرساخت صادر کردن قدیمی در آن می‌نوشت).

     6. تغییر پیکربندی را ذخیره کنید.

  3. برای روزهایی که جدول قدیمی شما داده ندارد، جای‌گذاری پس‌از تکمیل زمان‌بندی کنید.

  4. پس‌از تکمیل جای‌گذاری، جدول جدیدی را که زیرساخت جدید صادر کردن به‌طور خودکار ایجاد کرده است حذف کنید.