از آنجایی که بهینه‌سازی‌های R8 کد برنامه شما را به‌روزرسانی می‌کند، آزمایش دقیق رفتار برنامه برای اطمینان از عملکرد مورد انتظار آن بسیار مهم است. در صورت بروز رفتار غیرمنتظره، از این صفحه به عنوان راهنما برای عیب‌یابی مشکلات احتمالی پس از بهینه‌سازی استفاده کنید.
هنگام عیب‌یابی، روی موقعیت‌های زیر تمرکز کنید:
- بهینه‌سازی بیش از حد منجر به از کار افتادن برنامه می‌شود : برنامه شما به دلیل بهینه‌سازی بیش از حد کد در R8 از کار می‌افتد.
- بهینه‌سازی نامشخص یا ناکافی : R8 برنامه شما را آنطور که انتظار داشتید بهینه نکرده است یا برای بهینه‌سازی‌ها به توضیحات بیشتری نیاز دارید.
خرابی برنامه
اگر برنامه شما پس از بهینه‌سازی با R8 از کار افتاد، معمولاً به دلیل بازتاب خراب است. برای شناسایی بازتاب خراب، از دستورالعمل‌های زیر استفاده کنید:
- شما با یک استثنا مواجه می‌شوید که معمولاً به این معنی است که کلاس، متد یا فیلد مشخص شده از طریق reflection استفاده می‌شود. این استثناها معمولاً یکی از موارد زیر هستند:
ClassNotFoundException،NoSuchMethodException،NoSuchFieldException،NoClassDefFoundError،NoSuchMethodError،NoSuchFieldError. - کدی را می‌بینید که با
import kotlin.reflect.*یاimport java.lang.reflect.*به reflection اشاره می‌کند. - مشاهده می‌کنید که یک سازنده کلاس به صورت زیر استفاده می‌شود:
Something::class.constructors. - شما
Class.forName(...)را می‌بینید.
راه حل : یک قانون نگه داشتن اضافه کنید.
بهینه‌سازی نامشخص یا ناکافی
از آنجایی که قوانین از برنامه شما و همچنین کتابخانه‌های موجود اعمال می‌شوند، ممکن است به شفافیت بیشتری در مورد قوانین اعمال شده نیاز داشته باشید، یا به توضیحی در مورد اینکه چرا R8 بخش‌های خاصی از کد را که انتظار داشتید بهینه شوند، حفظ کرده است، نیاز داشته باشید.
ابهام در مورد قوانین اعمال شده : از آنجا که قوانین کتابخانه‌های گنجانده شده در برنامه شما نیز اعمال می‌شوند و گزینه‌های سراسری این کتابخانه‌ها نیز به برنامه شما منتقل می‌شوند، ممکن است در مورد اینکه کدام قوانین اعمال می‌شوند، مطمئن نباشید.
راه حل : با مشاهده گزارش تمام قوانینی که R8 هنگام ساخت پروژه شما اعمال می‌کند، بررسی کنید که کدام قوانین اعمال می‌شوند. می‌توانید این گزارش را در
./app/build/outputs/mapping/configuration.txtپیدا کنید. این گزارش شامل تمام قوانین ادغام شده از هر کتابخانه و ماژولی است که برای پیکربندی R8 استفاده شده است و می‌تواند برای شناسایی قوانین ناکارآمد مورد استفاده قرار گیرد.کد زیادی نگه داشته می‌شود : بهینه‌سازی R8 ممکن است کدی را که انتظار داشتید حذف شود، حفظ کند.
راه حل : از گزینه پیکربندی
-whyareyoukeepingبرای فهمیدن دلیل نگه‌داری کد استفاده کنید. خروجی شامل مسیری از کد نگه‌داری شده به یکی از نقاط ورودی برنامه شما است. برای اطلاعات بیشتر، به-whyareyoukeepingمراجعه کنید.دشواری در درک ردپای پشته اصلی : R8 کد را به روش‌های مختلف تغییر می‌دهد و باعث می‌شود ردپای پشته دیگر به کد اصلی اشاره نکند. برای مثال، شماره خطوط و نام کلاس‌ها و متدها می‌توانند تغییر کنند.
راه حل : با شروع از Android Studio Otter 3 Feature Drop و AGP 9.0، Logcat به طور خودکار ردیابی‌های پشته را از حالت مبهم خارج می‌کند. با این حال، اگر از نسخه‌های قبلی اندروید استودیو استفاده می‌کنید، باید ردیابی پشته اصلی را به صورت دستی بازیابی کنید. برای بازیابی ردیابی پشته اصلی، از ابزار خط فرمان
retraceاستفاده کنید که همراه با بسته ابزارهای خط فرمان ارائه می‌شود.برای استفاده از
retrace، مسیر یک فایل نگاشت و یک فایل ردیابی پشته را به دستور ارائه دهید. فایل نگاشت کهmapping.txtنام دارد، به طور خودکار با Android App Bundle (AAB) شما همراه می‌شود. برای جزئیات بیشتر، به مستندات retrace و مقاله مرکز راهنمای Play Console در مورد نحوه‌ی رمزگشایی ردیابی‌های پشته خرابی مراجعه کنید. هنگام استفاده از Play و Firebase Crashlytics، از فایلmapping.txtبا خرابی‌هایی که سرویس از کاربران برنامه جمع‌آوری می‌کند، استفاده کنید. دستور زیر نشان می‌دهد که چگونه می‌توانیدretraceاز ریشه پروژه خود اجرا کنید:$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt
گزارش اشکالات
اگر نمی‌توانید مشکلی را با R8 حل کنید، یک اشکال (bug) ثبت کنید .