به عنوان یک نویسنده کتابخانه، باید مطمئن شوید که توسعه دهندگان برنامه می توانند به راحتی کتابخانه شما را در برنامه خود بگنجانند و در عین حال تجربه کاربر نهایی با کیفیت بالا را حفظ کنند. باید مطمئن شوید که کتابخانه شما بدون راهاندازی اضافی با بهینهسازی Android سازگار است - یا سندی مبنی بر اینکه کتابخانه ممکن است برای استفاده در Android نامناسب باشد.
این مستندات برای توسعه دهندگان کتابخانه های منتشر شده هدف قرار می گیرد، اما ممکن است برای توسعه دهندگان ماژول های کتابخانه داخلی در یک برنامه بزرگ و مدولار شده نیز مفید باشد.
اگر توسعهدهنده برنامه هستید و میخواهید درباره بهینهسازی برنامه Android خود بیاموزید، به فعال کردن بهینهسازی برنامه مراجعه کنید. برای اطلاع از اینکه کدام کتابخانه ها برای استفاده مناسب هستند، به انتخاب عاقلانه کتابخانه ها مراجعه کنید.
از کدژن بر روی بازتاب استفاده کنید
در صورت امکان، از تولید کد ( کدژن ) بر روی بازتاب استفاده کنید. کدژن و انعکاس هر دو رویکردهای رایج برای جلوگیری از کد دیگ بخار در هنگام برنامه نویسی هستند، اما کدژن با بهینه ساز برنامه مانند R8 سازگارتر است:
- با کدژن، کد در طول فرآیند ساخت، تجزیه و تحلیل و اصلاح می شود. از آنجایی که پس از زمان کامپایل هیچ تغییر عمدهای وجود ندارد، بهینهساز میداند که در نهایت به چه کدی نیاز است و چه چیزی را میتوان با خیال راحت حذف کرد.
- با بازتاب، کد در زمان اجرا تجزیه و تحلیل و دستکاری می شود. از آنجایی که کد تا زمانی که اجرا نشود واقعاً نهایی نمی شود، بهینه ساز نمی داند چه کدی را می توان با خیال راحت حذف کرد. احتمالاً کدهایی را که به صورت پویا از طریق بازتاب در زمان اجرا استفاده میشوند، حذف میکند، که باعث خرابی برنامه برای کاربران میشود.
بسیاری از کتابخانه های مدرن به جای بازتاب از کدژن استفاده می کنند. KSP را برای یک ورودی مشترک که توسط Room ، Dagger2 و بسیاری دیگر استفاده میشود، ببینید.
وقتی بازتاب مشکلی ندارد
اگر باید از بازتاب استفاده کنید، فقط باید به یکی از موارد زیر فکر کنید:
- انواع هدفمند خاص (پیادهکنندههای رابط یا زیر کلاسهای خاص)
- کد با استفاده از یک حاشیه نویسی زمان اجرا خاص
استفاده از بازتاب در این روش هزینه زمان اجرا را محدود می کند و نوشتن قوانین حفظ مشتری هدفمند را امکان پذیر می کند.
این شکل خاص و هدفمند انعکاس، الگویی است که میتوانید هم در چارچوب Android (مثلاً هنگام افزایش فعالیتها، نماها و نقشهها) و هم در کتابخانههای AndroidX (به عنوان مثال هنگام ساخت WorkManager ListenableWorkers یا RoomDatabases) مشاهده کنید. در مقابل، بازتاب باز Gson برای استفاده در برنامههای Android مناسب نیست .
قوانین حفظ مصرف کننده را بنویسید
کتابخانهها باید قوانین نگهداری «مصرفکننده» را بستهبندی کنند، که از همان قالب قوانین نگهداری برنامه استفاده میکنند. این قوانین در مصنوعات کتابخانه (AAR یا JAR) قرار میگیرند و در هنگام بهینهسازی برنامه Android در هنگام استفاده از کتابخانه، بهطور خودکار مصرف میشوند.
کتابخانه های AAR
برای افزودن قوانین مصرف کننده برای یک کتابخانه AAR، از گزینه consumerProguardFiles
در اسکریپت ساخت ماژول کتابخانه Android استفاده کنید. برای اطلاعات بیشتر، به راهنمای ما در مورد ایجاد ماژول های کتابخانه مراجعه کنید.
کاتلین
android { defaultConfig { consumerProguardFiles("consumer-proguard-rules.pro") } ... }
شیار
android { defaultConfig { consumerProguardFiles 'consumer-proguard-rules.pro' } ... }
کتابخانه های JAR
برای بستهبندی قوانین با کتابخانه Kotlin/Java خود که به صورت JAR ارسال میشود، فایل قوانین خود را با هر نام فایلی در فهرست نهایی META-INF/proguard/
JAR قرار دهید. به عنوان مثال، اگر کد شما در <libraryroot>/src/main/kotlin
، یک فایل قوانین مصرف کننده را در <libraryroot>/src/main/resources/META-INF/proguard/consumer-proguard-rules.pro
قرار دهید و قوانین در مکان صحیح در JAR خروجی شما قرار می گیرند.
با بررسی اینکه قوانین در دایرکتوری META-INF/proguard
قرار دارند، بررسی کنید که قوانین بستهبندی نهایی JAR به درستی انجام میشود.
پشتیبانی از کوچک کننده های مختلف (پیشرفته)
میتوانید قوانینی را برای کوچککنندههای خاص (R8 یا ProGuard) و همچنین نسخههای کوچککننده خاص تنظیم کنید. این کار کتابخانه شما را قادر میسازد تا در پروژههایی که از نسخههای کوچککننده جدید استفاده میکنند، بهینه کار کند، در حالی که اجازه میدهد از قوانین موجود در پروژههایی با نسخههای کوچککننده قدیمیتر استفاده شود.
برای تعیین قوانین کوچک کردن هدفمند، باید آنها را در مکانهای خاصی در داخل یک کتابخانه AAR یا JAR قرار دهید، همانطور که در زیر توضیح داده شده است.
In an AAR library:
consumer-proguard-rules.pro (legacy location)
classes.jar
└── META-INF
└── com.android.tools (targeted shrink rules location)
├── r8-from-<X>-upto-<Y>/<R8-rules-file>
└── proguard-from-<X>-upto-<Y>/<ProGuard-rules-file>
In a JAR library:
META-INF
├── proguard/<ProGuard-rules-file> (legacy location)
└── com.android.tools (targeted shrink rules location)
├── r8-from-<X>-upto-<Y>/<R8-rules-file>
└── proguard-from-<X>-upto-<Y>/<ProGuard-rules-file>
این بدان معناست که قوانین کوچک کردن هدفمند در فهرست META-INF/com.android.tools
یک JAR یا در فهرست META-INF/com.android.tools
داخل classes.jar
یک AAR ذخیره میشوند.
در زیر آن دایرکتوری، میتوان چندین دایرکتوری با نامهایی به شکل r8-from-<X>-upto-<Y>
یا proguard-from-<X>-upto-<Y>
وجود داشته باشد تا مشخص شود قوانین داخل دایرکتوریها برای کدام نسخه کوچککننده نوشته شدهاند. توجه داشته باشید که قسمت های - from-<X>
و - upto-<Y>
اختیاری هستند، نسخه <Y>
انحصاری است و محدوده های نسخه باید پیوسته باشند.
برای مثال، r8-upto-8.0.0, r8-from-8.0.0-upto-8.2.0
و r8-from-8.2.0
مجموعه معتبری از قوانین کوچک کردن هدفمند را تشکیل می دهند. قوانین تحت پوشه r8-from-8.0.0-upto-8.2.0
توسط R8 از نسخه 8.0.0 تا نسخه 8.0.0 استفاده می شود، اما شامل نسخه 8.2.0 نمی شود .
با توجه به این اطلاعات، افزونه Android Gradle قوانین را از فهرست های R8 منطبق انتخاب می کند. اگر یک کتابخانه قوانین کوچک کردن هدفمند را مشخص نکند، افزونه Android Gradle قوانین را از مکانهای قدیمی انتخاب میکند ( proguard.txt
برای AAR یا META-INF/proguard/<ProGuard-rules-file>
برای JAR).