إذا نشرت تطبيقك على Google Play، عليك إنشاء مجموعة حزمات تطبيق Android: عند إجراء ذلك، ينشئ Google Play تلقائيًا حِزم APK محسّنة ويعرضها لإعدادات كل جهاز من أجهزة المستخدمين، كي لا يتم تنزيل سوى الرموز البرمجية والموارد التي يحتاجون إليها لتشغيل تطبيقك. يكون نشر حِزم APK متعددة مفيدًا إذا كنت لا تنشر على Google Play، ولكن عليك إنشاء كل حزمة APK وتوقيعها وإدارتها بنفسك.
عند تطوير تطبيق Android للاستفادة من عدة ملفات APK على Google Play، من المهم اتّباع بعض الممارسات الجيدة من البداية وتجنُّب المشاكل غير الضرورية المزيد في عملية التطوير. يشرح هذا الدرس كيفية إنشاء حزم APK متعددة ويغطي كل منها فئةً مختلفة من حجم الشاشة. ستحصل أيضًا على بعض الأدوات اللازمة لتسهيل عملية الحفاظ على قاعدة بيانات APK متعددة قدر الإمكان.
تأكيد الحاجة إلى حِزم APK متعددة
عند محاولة إنشاء تطبيق يعمل عبر مجموعة كبيرة من أنظمة التشغيل Android المتاحة الأجهزة، فإنك تريد بطبيعة الحال أن يظهر تطبيقك في أفضل حالاته على كل جهاز على حدة. عليك فعل ما يلي: الاستفادة من المساحة الكبيرة مع الاستمرار في العمل على الشاشات الصغيرة لاستخدام واجهة برمجة تطبيقات Android جديدة الميزات أو الزخارف المرئية المتوفرة على الأجهزة المتقدمة ولكن لا يتم التخلي عن الأجهزة القديمة. قد في البداية كما لو أن دعم حزم APK متعددة هو الحل الأفضل، ولكن هذا غالبًا الحالة. يعتمد استخدام يتضمّن قسم "حزمة APK بدلاً من ذلك" في دليل حِزم APK المتعددة بعض المعلومات المفيدة حول كيفية باستخدام ملف APK واحد، بما في ذلك استخدام مكتبة الدعم وروابط إلى الموارد عبر دليل مطوّري برامج Android.
إذا كان بإمكانك إدارته، فإن حصر تطبيقك بحزمة APK واحدة له العديد من المزايا، بما في ذلك:
- تسهيل النشر والاختبار
- يجب صيانة قاعدة رموز برمجية واحدة فقط
- يمكن للتطبيق التكيّف مع التغييرات التي تم إجراؤها على إعدادات الجهاز.
- استعادة التطبيقات على جميع الأجهزة
- لا داعي للقلق بشأن الإعدادات المفضّلة للسوق والسلوك الناتج عن "عمليات الترقية" من ملف APK واحد إلى بعد ذلك، أو حزمة APK التي تنطبق على أي فئة من الأجهزة
ويفترض باقي هذا الدرس أنك درست الموضوع واستيعابت بجديّة محددة في الموارد المرتبطة، وتحديد أن ملفات APK المتعددة هي المسار الصحيح التطبيق.
وضع رسم بياني للمتطلبات
ابدأ بإنشاء رسم بياني بسيط لتحديد عدد حِزم APK التي تحتاج إليها وشاشة استخدامها. الحجم الذي يغطيه كل ملف APK. لحسن الحظ، من السهل تخطيط متطلباتك بسرعة وسهولة على مرجع سهل لوقت لاحق. لنفترض أنّك تريد تقسيم حِزم APK على بُعدَين: واجهة برمجة التطبيقات وحجم الشاشة. إنشاء جدول يحتوي على صف وعمود لكل زوج ممكن من القيم واللون في بعض "الملفات الثنائية الكبيرة"، حيث يمثل كل لون حزمة APK واحدة.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| صغير | |||||||||||
| عادي | |||||||||||
| كبير | |||||||||||
| كبير جدًا |
في ما يلي مثال على أربعة حِزم APK. يُستخدم اللون الأزرق لجميع الأجهزة ذات الشاشات الصغيرة/العادية، بينما يُستخدم اللون الأخضر في الأجهزة الكبيرة لأجهزة الشاشة، واللون الأحمر مخصص للأجهزة ذات الشاشات الكبيرة للغاية، وكل ذلك بنطاق واجهة برمجة تطبيقات يتراوح من 3 إلى 10. يُعدّ اللون الأرجواني حالة خاصة، لأنّه مخصّص لجميع أحجام الشاشات، ولكن فقط لإصدار 11 من واجهة برمجة التطبيقات والإصدارات الأحدث. والأهم من ذلك، أنه من خلال بإلقاء نظرة على هذا الرسم البياني، ستتمكن فورًا من معرفة حزمة APK التي تغطي أي مزيج من واجهات برمجة التطبيقات وحجم الشاشة. إلى فلديك أيضًا أسماء رموز فخمة لكل منها، منذ "هل اختبرنا اللون الأحمر على ؟" هو كثير قد يكون توجيه أسئلة إلى العميل المكعّب أكثر سهولة من "هل اختبرنا حزمة APK الكبيرة التي يتراوح حجمها بين 3 إلى 10 ضد Xoom؟" طباعة هذه الصورة المخطط وتسليمه إلى كل شخص يعمل على قاعدة التعليمات البرمجية الخاصة بك. أصبحت الحياة أسهل كثيرًا.
وضع كل الرموز البرمجية والموارد الشائعة في مشروع مكتبة
سواء كنت تعدّل تطبيق Android حاليًا أو تبدأ تطبيقًا من الصفر، فهذا هو أول إجراء يجب اتّخاذه في قاعدة الرموز البرمجية، وهو أهم إجراء على الإطلاق. لا يتطلّب كل المحتوى المضمّن في مشروع المكتبة سوى تعديله مرة واحدة (مثل سلاسل النصوص المترجَمة بلغات مختلفة، وموضوعات الألوان، والأخطاء التي تم إصلاحها في الرمز البرمجي المشترَك)، ما يُحسِّن من وقت التطوير ويقلل من احتمالية حدوث أخطاء كان من الممكن تجنُّبها بسهولة.
ملاحظة: في حين أن تفاصيل تنفيذ كيفية إنشاء أن مشاريع المكتبة تقع خارج نطاق هذا الدرس، فيمكنك الحصول على من خلال قراءة إنشاء مكتبة Android.
إذا كنت بصدد تحويل تطبيق حالي ليستخدم دعم حِزم APK متعددة، وابحث في قاعدة التعليمات البرمجية لكل ملف سلسلة مترجَمة، وقائمة القيم، وموضوعات والألوان ورموز القوائم والتنسيق الذي لا يتغير عبر حزم APK، فضلاً عن وضع كل ذلك في مشروع المكتبة. التعليمات البرمجية التي لن تتغير كثيرًا ستذهب أيضًا في مشروع المكتبة. ستجد على الأرجح نفسك تقوم بتوسيع هذه إضافة طريقة أو اثنتين من APK إلى APK.
أما إذا كنت تنشئ التطبيق من البداية، فيمكنك تجربة قدر الإمكان لكتابة التعليمات البرمجية في مشروع المكتبة أولاً، ثم نقله فقط إلى APK بشكل فردي إذا لزم الأمر. فهذه العملية أسهل بكثير على المدى الطويل من إضافته إلى أداة ثم آخر، ثم آخر، ثم بعد أشهر محاولة معرفة ما إذا كان يمكن نقل هذا الكائن الثنائي الكبير إلى أعلى إلى قسم المكتبة دون إرباك أي شيء.
إنشاء مشاريع جديدة لحِزم APK
يجب أن يكون هناك مشروع Android منفصل لكل حزمة APK تريد إصدارها. للوصول إلى النتائج السهلة المؤسسة، ووضع مشروع المكتبة وجميع مشاريع حِزم APK ذات الصلة ضمن المجلد الرئيسي نفسه. تذكَّر أيضًا أنّه يجب أن يكون لكل ملف APK اسم الحزمة نفسه، على الرغم من أنّه ليس من الضروري مشاركة اسم الحزمة مع المكتبة. إذا توفرت لديك 3 ملفات APK تتبع المخطط كما هو موضح سابقًا، قد يبدو الدليل الجذري كما يلي:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
بعد إنشاء المشاريع، أضِف مشروع المكتبة كمرجع لكل مشروع APK. في حال حذف يمكنك تحديد نشاط البداية في مشروع المكتبة وتوسيع نطاق هذا النشاط في حزمة APK مشروعك. يمنحك تحديد نشاط البدء في مشروع المكتبة فرصة لوضع كل تهيئة تطبيقك في مكان واحد، كي لا يتعيّن على كل حزمة APK فردية إعادة تنفيذ "عام" مهام مثل تهيئة "إحصاءات Google" وإجراء عمليات التحقق من التراخيص وغير ذلك إجراءات الإعداد التي لا تغيّر كثيرًا من حزمة APK إلى حزمة APK.
تعديل البيانات
عندما يُنزِّل أحد المستخدمين تطبيقًا يستخدم ملفات APK متعددة من خلال Google Play، يتم اختيار حزمة APK المراد استخدامها باستخدام قاعدتَين بسيطتَين:
- يجب أن يُظهر البيان أنّ حِزمة APK معيَّنة مؤهَّلة
- من بين حِزم APK المؤهَّلة، يفوز أعلى رقم إصدار.
على سبيل المثال، لنأخذ مجموعة حزم APK المتعددة التي تم وصفها سابقًا، ونفترض أن كل تم ضبط حزمة APK على دعم كل أحجام الشاشات التي تزيد عن "الهدف" المحدد لها لحجم الشاشة. لنلقِ نظرة على نموذج المخطط من السابق:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| صغير | |||||||||||
| عادي | |||||||||||
| كبير | |||||||||||
| كبير جدًا |
بما أنّه لا بأس بتداخل التغطية، يمكننا وصف المنطقة التي يشملها كل APK على النحو التالي:
- يشمل اللون الأزرق جميع الشاشات، الإصدار minSDK 3.
- يشمل اللون الأخضر الشاشات الكبيرة والإصدارات الأحدث، والحد الأدنى لإصدار حزمة تطوير البرامج (SDK) هو 3.
- يغطي اللون الأحمر الشاشات الكبيرة جدًا (الأجهزة اللوحية بشكل عام)، والإصدار 9 من حزمة minSDK.
- يتوافق الإصدار Purple مع جميع الشاشات، ويجب أن يكون الحد الأدنى لإصدار حزمة تطوير البرامج (SDK) هو 11.
تجدر الإشارة إلى أن هناك الكثير من التداخل في هذه القواعد. على سبيل المثال، يمكن للجهاز الكبير جدًا الذي يتضمّن واجهة برمجة التطبيقات 11 تشغيل أي ملف من حِزم APK الأربعة المحدّدة. ومع ذلك، باستخدام قاعدة "يُمنَح الأولوية للإصدار الأعلى رقمًا"، يمكننا ضبط ترتيب الأفضلية على النحو التالي:
الأرجواني ≥ الأحمر ≥ الأخضر ≥ الأزرق
لماذا يُسمح بكل التداخل؟ لنتخيل أن حِزمة APK باللون البنفسجي بها بعض المتطلبات أن والاثنان الآخر لا يفعلان ذلك. تتضمّن صفحة الفلاتر على Google Play في دليل مطوّري تطبيقات Android قائمة كاملة بالعوامل المحتمَلة. على سبيل المثال، لنفترض أن اللون الأرجواني يتطلب كاميرا أمامية. في الواقع، يتمثل الهدف الكامل من اللون الأرجواني في استخدام أشياء ترفيهية باستخدام الكاميرا الأمامية! ولكن تبين أنه ليست جميع الأجهزة التي تعمل بالإصدار 11 من واجهة برمجة التطبيقات أو الإصدارات الأحدث حتى كاميرات أمامية! الأمر مرعب!
ولحسن الحظ، إذا كان هناك مستخدم يتصفح Google Play من أحد هذه الأجهزة، فسينظر Google Play في بيان، ورأي أن بنفسج يدرج الكاميرا الأمامية كشرط، ويتجاهلها بهدوء، بعد أن قرروا أن الأرجواني والجهاز ليسا متطابقين في السماء الرقمية. سيتبيّن للتطبيق بعد ذلك أنّ Red متوافق مع الأجهزة الكبيرة جدًا فقط، ولا يهتم أيضًا بما إذا كانت هناك كاميرا أمامية أم لا. سيظل بإمكان المستخدم تنزيل التطبيق من Google Play لأنه على الرغم من الحادث الذي وقع في الكاميرا الأمامية بالكامل، إلا أنه لا تزال هناك حزمة APK متوافقة مع هذا الحادث تحديدًا مستوى واجهة برمجة التطبيقات.
لإبقاء جميع حِزم APK على "مسارات" منفصلة، من المهم أن يكون لديك رمز إصدار جيد . يمكن العثور على الرمز الموصى به في قسم رموز الإصدار في دليل المطور لدينا. يستحق الأمر قراءة القسم بأكمله، لكن الملخص الأساسي لهذه المجموعة من لملفات APK، فسنستخدم رقمين لتمثيل minSDK، رقمين يمثلان الحد الأدنى/الأقصى لحجم الشاشة، و3 لتمثيل رقم الإصدار. بهذه الطريقة، عند ترقية الجهاز إلى إصدار جديد من Android، (على سبيل المثال، من 10 إلى 11)، أي ملفات APK مؤهّلة ومفضّلة الآن على الحزمة المثبَّتة حاليًا سيعتبره الجهاز "ترقية". نظام رقم الإصدار، عند تطبيقه على المثال حزمة APK، على النحو التالي:
الأزرق: 0304001، 0304002، 0304003...
الأخضر: 0334001 و0334002 و0334003
الأحمر: 0344001 و0344002 و0344003...
أرجواني: 1104001، 1104002، 1104003...
من خلال وضع كل ذلك معًا، من المحتمل أن تبدو بيانات Android مشابهة التالي:
أزرق:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
أخضر:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
أحمر:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
الأرجواني:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
يُرجى العلم أنّه من الناحية الفنية، ستتوافق حِزم APK المتعددة مع علامة supports-screens أو علامة compatible-screens. يُفضل استخدام الشاشات الداعمة بشكل عام، وهو أمر سيئ جدًا بشكل عام استخدام كليهما - يجعل الأمر الأمور معقدة بلا داعٍ، ويزيد من فرصة حدوث الأخطاء. لاحظ أيضًا أنه بدلاً من الاستفادة من القيم الافتراضية (الصغير والعادي صحيحان دائمًا بشكل افتراضي)، تحدد البيانات بشكل صريح القيمة لكل حجم شاشة. يمكن أن يجنّبك ذلك الصداع في المستقبل. على سبيل المثال، سيتم ضبط xlarge تلقائيًا على false في بيان التطبيق الذي يحتوي على حزمة تطوير برامج (SDK) مستهدَفة أصغر من 9، لأنّ هذا الحجم لم يكن متوفّرًا بعد. لذا، يجب أن تكون واضحًا.
مراجعة قائمة تحقق ما قبل الإطلاق
قبل التحميل إلى Google Play، يُرجى التحقّق جيدًا من العناصر التالية. تذكر أن هذه ذات صلة بشكل خاص بملفات APK متعددة، ولا يمثل بأي حال من الأحوال قائمة تحقق كاملة لجميع التطبيقات التي يتم تحميلها إلى Google Play.
- يجب أن يكون لجميع حِزم APK اسم الحزمة نفسه.
- يجب توقيع جميع حِزم APK باستخدام الشهادة نفسها.
- إذا تداخلت حِزم APK في إصدار النظام الأساسي، يجب أن يتضمّن الملف الذي يتضمّن إصدار minSdkVersion الأعلى رمز إصدار أعلى.
- يجب ضبط جميع أحجام الشاشة التي تريد أن تتيحها حزمة APK على "صحيح" في البيان. كل حجم شاشة الذي تريد تجنبه، اضبطه على false.
- تحقق مرة أخرى من فلاتر البيان بحثًا عن معلومات متضاربة (ملف APK يتوافق فقط مع الخَبز على شاشات XLARGE لأي شخص)
- يجب أن يكون بيان كل ملف APK فريدًا عبر شاشة واحدة على الأقل أو زخرفة OpenGL أو إصدار النظام الأساسي.
- جرِّب اختبار كل حزمة APK على جهاز واحد على الأقل. باستثناء ذلك، لديك واحدة من أكثر أجهزة محاكاة الأجهزة القابلة للتخصيص في الشركة على جهاز التطوير لديك. يا للعجب!
الأمر يستحق أيضًا فحص APK الذي تم تجميعه قبل طرحه إلى السوق، للتأكد من عدم وجود أي مفاجآت قد تخفي تطبيقك على Google Play. وهذا في الواقع بسيط جدًا باستخدام "aapt" . تُعد أداة Aapt (أداة تجميع مواد العرض في Android) جزءًا من عملية التصميم لإنشاء حزمة تطبيقات Android، وهي أداة مفيدة جدًا لفحصها.
>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 بشكل ضمني. بما أنّ معظم الأجهزة (إن لم تكن كلها) التي تستخدم شاشة بحجم كبير جدًا هي أجهزة لوحية لا تحتوي على أجهزة اتصال هاتفي، سيزيل Google Play حزمة APK هذه في هذه الحالات إلى أن تظهر أجهزة مستقبلية كبيرة بما يكفي لتسجيل حجم الشاشة على أنّه كبير جدًا، وتحتوي على أجهزة اتصال هاتفي.
يمكن حلّ هذه المشكلة بسهولة من خلال إضافة ما يلي إلى ملف البيان:
<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 تستهدف الأجهزة المقصودة. تهانينا، لقد انتهيت!