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