اگر برنامه خود را در Google Play منتشر میکنید، باید یک Android App Bundle بسازید و آپلود کنید. وقتی این کار را انجام میدهید، Google Play بهطور خودکار فایلهای APK بهینهشده را برای پیکربندی دستگاه هر کاربر تولید و ارائه میکند، بنابراین آنها فقط کد و منابعی را که برای اجرای برنامه شما نیاز دارند دانلود میکنند. اگر در Google Play منتشر نمی کنید، انتشار چندین APK مفید است، اما باید خودتان هر APK را بسازید، امضا کنید و مدیریت کنید.
هنگامی که برنامه اندروید خود را برای استفاده از چندین APK در Google Play توسعه میدهید، مهم است که برخی از روشهای خوب را از همان ابتدا اتخاذ کنید و از سردردهای غیرضروری بیشتر در فرآیند توسعه جلوگیری کنید. این درس به شما نشان میدهد که چگونه چندین APK از برنامه خود ایجاد کنید که هر کدام از زیرمجموعههای متفاوتی از فرمتهای بافت OpenGL پشتیبانی میکنند. همچنین برخی از ابزارهای لازم برای حفظ یک پایگاه کد APK چندگانه را تا حد امکان بدون دردسر به دست خواهید آورد.
تأیید کنید که به چندین APK نیاز دارید
وقتی سعی میکنید برنامهای ایجاد کنید که در همه دستگاههای مجهز به Android موجود کار کند، طبیعتاً میخواهید برنامهتان در هر دستگاه به بهترین شکل ظاهر شود، صرفنظر از این که همه آنها از یک مجموعه از بافتهای GL پشتیبانی نمیکنند. ممکن است در ابتدا به نظر برسد که پشتیبانی از چندین APK بهترین راه حل است، اما اغلب اینطور نیست. بخش استفاده از یک APK به جای راهنمای برنامهنویس چندگانه APK حاوی اطلاعات مفیدی درباره نحوه انجام این کار با یک APK منفرد است، از جمله نحوه شناسایی قالبهای بافت پشتیبانی شده در زمان اجرا . بسته به موقعیت شما، ممکن است ساده تر باشد که همه فرمت ها را با برنامه خود ترکیب کنید و به سادگی انتخاب کنید که در زمان اجرا از کدام یک استفاده کنید.
اگر بتوانید آن را مدیریت کنید، محدود کردن برنامه خود به یک APK دارای چندین مزیت است، از جمله:
- انتشار و تست آسان تر است
- تنها یک پایگاه کد برای نگهداری وجود دارد
- برنامه شما می تواند با تغییرات پیکربندی دستگاه سازگار شود
- بازیابی برنامه در همه دستگاه ها فقط کار می کند
- لازم نیست نگران ترجیحات بازار، رفتار «ارتقای» از یک APK به دیگری، یا اینکه کدام APK با کدام دسته از دستگاه ها می رود، باشید.
بقیه این درس فرض میکند که درباره موضوع تحقیق کردهاید، مطالب موجود در منابع مرتبط را با دقت جذب کردهاید و تشخیص دادهاید که چندین APK مسیر مناسبی برای برنامه شما هستند.
خواسته های خود را نمودار کنید
راهنمای برنامهنویس Android یک مرجع مفید از برخی از بافتهای رایج پشتیبانی شده در صفحه supports-gl-texture ارائه میکند. این صفحه همچنین حاوی نکاتی در مورد اینکه کدام تلفن ها (یا خانواده تلفن ها) از فرمت های بافت خاصی پشتیبانی می کنند، است. توجه داشته باشید که به طور کلی ایده خوبی است که یکی از APK های شما از ETC1 پشتیبانی کند، زیرا این فرمت بافت توسط همه دستگاه های مجهز به Android که از مشخصات OpenGL ES 2.0 پشتیبانی می کنند پشتیبانی می شود.
از آنجایی که اکثر دستگاههای مجهز به اندروید از بیش از یک قالب بافت پشتیبانی میکنند، باید ترتیب اولویت را تعیین کنید. نموداری ایجاد کنید که شامل تمام فرمت هایی است که برنامه شما قرار است از آنها پشتیبانی کند. سلول سمت چپ کمترین اولویت را خواهد داشت (احتمالاً ETC1 خواهد بود، یک پیش فرض واقعاً محکم از نظر عملکرد و سازگاری). سپس در نمودار طوری رنگ کنید که هر سلول نشان دهنده یک APK باشد.
ETC1 | ATI | PowerVR |
رنگآمیزی در نمودار چیزی بیش از این است که این راهنما را کمتر تک رنگ میکند - همچنین راهی برای آسانتر کردن ارتباطات درون تیمی دارد - اکنون میتوانید به سادگی به هر APK به عنوان "آبی"، "سبز" یا "قرمز" اشاره کنید. از "یکی که از فرمت های بافت ETC1 پشتیبانی می کند" و غیره.
همه کدها و منابع رایج را در یک پروژه کتابخانه قرار دهید
چه در حال تغییر یک برنامه اندرویدی موجود باشید و چه از ابتدا شروع کنید، این اولین کاری است که باید با پایگاه کد انجام دهید و تا حد زیادی مهمترین آن است. هر چیزی که وارد پروژه کتابخانه می شود فقط باید یک بار به روز شود (به رشته های محلی سازی شده با زبان، تم های رنگی، اشکالات رفع شده در کد مشترک فکر کنید)، که زمان توسعه شما را بهبود می بخشد و احتمال اشتباهاتی را کاهش می دهد که به راحتی می توان از آنها اجتناب کرد.
توجه: در حالی که جزئیات پیادهسازی نحوه ایجاد و گنجاندن پروژههای کتابخانه فراتر از محدوده این درس است، میتوانید با خواندن «ایجاد کتابخانه Android» سرعت خود را افزایش دهید.
اگر در حال تبدیل یک برنامه موجود برای استفاده از پشتیبانی APK چندگانه هستید، پایگاه کد خود را برای هر فایل رشته محلی، فهرست مقادیر، رنگهای تم، نمادهای منو و طرحبندی که قرار نیست در APK تغییر کند، جستجو کنید و همه آنها را در پروژه کتابخانه کدی که قرار نیست تغییر زیادی کند باید در پروژه کتابخانه نیز قرار گیرد. احتمالاً متوجه خواهید شد که این کلاس ها را برای اضافه کردن یک یا دو روش از APK به APK گسترش می دهید.
از سوی دیگر، اگر برنامه را از ابتدا ایجاد میکنید، تا حد امکان سعی کنید ابتدا کد را در پروژه کتابخانه بنویسید، سپس در صورت لزوم آن را به یک APK جداگانه منتقل کنید. مدیریت این کار در درازمدت بسیار سادهتر از اضافه کردن آن به یکی، سپس دیگری، سپس دیگری، سپس ماهها بعد تلاش برای کشف این موضوع است که آیا میتوان این لکه را به بخش کتابخانه منتقل کرد، بدون اینکه چیزی خراب شود.
پروژه های جدید APK ایجاد کنید
برای هر APK که میخواهید منتشر کنید، باید یک پروژه اندروید جداگانه وجود داشته باشد. برای سازماندهی آسان، پروژه کتابخانه و تمام پروژه های APK مرتبط را در یک پوشه والد قرار دهید. همچنین به یاد داشته باشید که هر APK باید نام بسته یکسانی داشته باشد، اگرچه آنها لزوماً نیازی به اشتراک گذاری نام بسته با کتابخانه ندارند. اگر قرار بود 3 APK داشته باشید که طبق طرحی که قبلا توضیح داده شد، دایرکتوری ریشه شما ممکن است به شکل زیر باشد:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
پس از ایجاد پروژه ها، پروژه کتابخانه را به عنوان مرجع به هر پروژه APK اضافه کنید. در صورت امکان، شروع فعالیت خود را در پروژه کتابخانه تعریف کنید و آن فعالیت را در پروژه APK خود گسترش دهید. داشتن یک فعالیت شروع که در پروژه کتابخانه تعریف شده است به شما این فرصت را می دهد که تمام مقداردهی اولیه برنامه خود را در یک مکان قرار دهید، به طوری که هر APK جداگانه مجبور به اجرای مجدد وظایف "جهانی" مانند شروع به تجزیه و تحلیل، اجرای بررسی های مجوز، و سایر موارد نیست. سایر مراحل اولیه سازی که از APK به APK تغییر چندانی نمی کنند.
مانیفست ها را تنظیم کنید
وقتی کاربر برنامهای را دانلود میکند که از چندین APK استفاده میکند، APK صحیح برای استفاده با استفاده از چند قانون ساده انتخاب میشود:
- مانیفست باید نشان دهد که APK خاص واجد شرایط است
- از بین فایلهای APK واجد شرایط، بیشترین تعداد نسخه برنده میشود
- اگر هر یک از قالبهای بافت فهرستشده در APK شما توسط دستگاه موجود در بازار پشتیبانی میشود، آن دستگاه واجد شرایط در نظر گرفته میشود.
با توجه به GL Textures، آخرین قانون مهم است. این بدان معناست که برای مثال باید در مورد استفاده از فرمت های مختلف GL در یک برنامه بسیار مراقب باشید. اگر قرار بود 99 درصد مواقع از PowerVR استفاده کنید، اما از ETC1 مثلاً برای صفحه نمایش خود استفاده کنید... پس مانیفست شما لزوماً پشتیبانی از هر دو فرمت را نشان می دهد. دستگاهی که فقط از ETC1 پشتیبانی میکند سازگار تلقی میشود، برنامه شما دانلود میشود و کاربر پیامهای خرابی هیجانانگیزی را میبیند. مورد رایج این است که اگر از چندین APK به طور خاص برای هدف قرار دادن دستگاههای مختلف بر اساس پشتیبانی از بافت GL استفاده میکنید، یک قالب بافت در هر APK خواهد بود.
این در واقع باعث می شود که پشتیبانی از بافت کمی متفاوت از دو بعد چندگانه APK دیگر، سطح API و اندازه صفحه نمایش باشد. هر دستگاه معینی فقط یک سطح API و یک اندازه صفحه دارد و پشتیبانی از طیف وسیعی از آنها به عهده APK است. با بافت ها، APK به طور کلی از یک بافت پشتیبانی می کند و دستگاه از بسیاری از بافت ها پشتیبانی می کند. اغلب از نظر یک دستگاه که از بسیاری از APK ها پشتیبانی می کند همپوشانی وجود دارد، اما راه حل یکسان است: کدهای نسخه.
به عنوان مثال، چند دستگاه را بردارید و ببینید چه تعداد از APKهای تعریف شده قبلی برای هر دستگاه مناسب است.
FooPhone | Nexus S | اوو |
ETC1 | ETC1 | ETC1 |
PowerVR | ATI TC |
با فرض اینکه فرمتهای PowerVR و ATI هر دو نسبت به ETC1 ترجیح داده میشوند، نسبت به قانون «بیشترین تعداد نسخه برنده»، اگر ویژگی versionCode را در هر APK به گونهای تنظیم کنیم که قرمز ≥ سبز ≥ آبی باشد، قرمز و سبز همیشه خواهند بود. در دستگاههایی که از آنها پشتیبانی میکنند، بیش از آبی انتخاب شوند، و اگر دستگاهی بیاید که از قرمز و سبز پشتیبانی میکند، قرمز انتخاب میشود.
برای اینکه همه فایلهای APK خود را در «تراکهای» جداگانه نگه دارید، داشتن یک طرح کد نسخه خوب مهم است. مورد توصیه شده را می توان در قسمت کدهای نسخه راهنمای توسعه دهنده ما یافت. از آنجایی که مجموعه نمونه APK فقط با یکی از 3 بعد ممکن سروکار دارد، کافی است هر APK را با 1000 و افزایش از آنجا جدا کنید. این ممکن است به نظر برسد:
آبی: 1001، 1002، 1003، 1004...
سبز: 2001، 2002، 2003، 2004...
قرمز: 3001، 3002، 3003، 3004...
با کنار هم گذاشتن همه اینها، مانیفست های Android شما احتمالاً چیزی شبیه به زیر است:
آبی:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" /> ...
سبز:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" /> ...
قرمز:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="3001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" /> ...
چک لیست قبل از راه اندازی خود را مرور کنید
قبل از آپلود در Google Play، موارد زیر را دوباره بررسی کنید. به یاد داشته باشید که این موارد به طور خاص به چندین APK مرتبط هستند و به هیچ وجه یک چک لیست کامل برای همه برنامههایی که در Google Play آپلود میشوند را نشان نمیدهند.
- همه APK ها باید یک نام بسته داشته باشند
- همه فایلهای APK باید با یک گواهی امضا شوند
- فیلترهای مانیفست خود را برای اطلاعات متناقض بررسی کنید (یک APK که فقط از کیک کوچک در صفحههای XLARGE پشتیبانی میکند توسط کسی دیده نمیشود)
- مانیفست هر APK باید حداقل در یکی از صفحات پشتیبانی شده، بافت OpenGL یا نسخه پلت فرم منحصر به فرد باشد
- سعی کنید هر APK را حداقل در یک دستگاه آزمایش کنید. به غیر از آن، شما یکی از قابل تنظیم ترین شبیه سازهای دستگاه را در کسب و کار دارید که روی دستگاه توسعه خود نشسته است. دیوانه شوید!
همچنین ارزش آن را دارد که APK کامپایل شده را قبل از ورود به بازار بررسی کنید تا مطمئن شوید که هیچ شگفتی وجود ندارد که بتواند برنامه شما را در Google Play پنهان کند. این در واقع با استفاده از ابزار "aapt" بسیار ساده است. Aapt (ابزار بسته بندی دارایی اندروید) بخشی از فرآیند ساخت برای ایجاد و بسته بندی برنامه های اندرویدی شما است و همچنین ابزار بسیار مفیدی برای بازرسی آنها است.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
وقتی خروجی aapt را بررسی میکنید، مطمئن شوید که مقادیر متناقضی برای صفحههای پشتیبانی و صفحههای سازگار نداشته باشید، و مقادیر «مصرف-ویژگی» ناخواستهای که در نتیجه مجوزهای شما اضافه شدهاند نداشته باشید. تنظیم در مانیفست در مثال بالا، APK برای اکثر دستگاهها نامرئی خواهد بود.
چرا؟ با افزودن مجوز مورد نیاز SEND_SMS، ویژگی مورد نیاز android.hardware.telephony به طور ضمنی اضافه شد. از آنجایی که اکثر (اگر نه همه) دستگاههای xlarge تبلتهایی هستند که سختافزار تلفن در آنها وجود ندارد، Google Play در این موارد این APK را فیلتر میکند، تا زمانی که دستگاههای آینده عرضه شوند که هم به اندازه کافی بزرگ باشند که اندازه صفحه نمایش xlarge را گزارش کنند و هم دارای سختافزار تلفن باشند.
خوشبختانه این مشکل با افزودن موارد زیر به مانیفست خود به راحتی برطرف می شود:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
الزامات android.hardware.touchscreen
نیز به طور ضمنی اضافه شده است. اگر میخواهید APK شما در تلویزیونهایی که دستگاههای غیر لمسی هستند قابل مشاهده باشد، باید موارد زیر را به مانیفست خود اضافه کنید:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
پس از تکمیل چک لیست قبل از راه اندازی، فایل های APK خود را در Google Play آپلود کنید. ممکن است کمی طول بکشد تا برنامه هنگام مرور Google Play نمایش داده شود، اما زمانی که ظاهر شد، آخرین بررسی را انجام دهید. برای اطمینان از اینکه APK ها دستگاه های مورد نظر را هدف قرار می دهند، برنامه را در هر دستگاه آزمایشی دانلود کنید. تبریک می گویم، کار شما تمام شد!