إذا كنت تنشر تطبيقك على Google Play، عليك إنشاء مجموعة حزمات تطبيق Android وتحميلها. عند إجراء ذلك، ينشئ Google Play تلقائيًا حِزم APK محسّنة ويعرضها لكل إعداد جهاز مستخدم، ما يسمح له بتنزيل الرمز والموارد التي يحتاجها فقط لتشغيل تطبيقك. ويكون نشر حِزم APK متعددة مفيدًا في حال عدم النشر على Google Play، ولكن عليك إنشاء كل حِزمة APK وتوقيعها وإدارتها بنفسك.
عند تطوير تطبيق Android للاستفادة من حِزم 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.
بما أنّ معظم الأجهزة التي تعمل بنظام التشغيل Android متوافقة مع أكثر من تنسيق واحد للنسيج، عليك تحديد الترتيب المفضّل. أنشئ رسمًا بيانيًا يتضمّن جميع التنسيقات التي سيتيح تطبيقك استخدامها. ستكون الخلية على يمين الصفحة ذات الأولوية الأدنى (من المحتمل أن تكون ETC1، وهي ملف افتراضي جيد جدًا من حيث الأداء والتوافق). بعد ذلك، أضِف الألوان إلى الرسم البياني بحيث تمثّل كل خلية حزمة APK.
| ETC1 | ATI | PowerVR |
إنّ تلوين الرسم البياني لا يؤدي فقط إلى جعل هذا الدليل أقلّ أحادية اللون، بل يساعد أيضًا في تسهيل التواصل داخل الفريق. يمكنك الآن الإشارة إلى كل APK باسم "الأزرق" أو "الأخضر" أو "الأحمر" بدلاً من "الملف الذي يتيح تنسيقات النسيج ETC1" وما إلى ذلك.
وضع كل الرموز والموارد الشائعة في مشروع مكتبة
سواء كنت تعدّل تطبيق Android حاليًا أو تبدأ تطبيقًا من الصفر، فهذا هو أول إجراء يجب اتّخاذه في قاعدة الرموز البرمجية، وهو أهم إجراء على الإطلاق. لا يتطلّب كل المحتوى المضمّن في مشروع المكتبة سوى تعديله مرة واحدة (مثل سلاسل النصوص المترجَمة بلغات مختلفة، وموضوعات الألوان، والأخطاء التي تم إصلاحها في الرمز البرمجي المشترَك)، ما يُحسِّن من وقت التطوير ويقلل من احتمالية حدوث أخطاء كان من الممكن تجنُّبها بسهولة.
ملاحظة: على الرغم من أنّ تفاصيل التنفيذ حول كيفية إنشاء مشاريع المكتبات ودمجها تتجاوز نطاق هذا الدرس، يمكنك الاطّلاع على إنشاء مكتبة Android للتعرّف على هذه التفاصيل.
إذا كنت بصدد تحويل تطبيق حالي لاستخدام حِزم APK متعددة، ابحث في قاعدة بياناتك عن كل ملف سلاسل مُترجَمة وقائمة القيم وألوان المظهر ورمز التموين والتنسيق الذي لن يتغيّر في حِزم APK، ثم ضع كل ذلك في مشروع المكتبة. يجب أيضًا وضع الرموز البرمجية التي لن تتغيّر كثيرًا في مشروع المكتبة. من المحتمل أن تحتاج إلى توسيع نطاق هذين الصنفين لإضافة طريقة أو طريقتَين من حزمة APK إلى أخرى.
من ناحية أخرى، إذا كنت تنشئ التطبيق من الصفر، حاوِل كتابة الرمز قدر الإمكان في مشروع المكتبة أولاً، ثم نقله إلى ملف APK individual (فردي) فقط إذا لزم الأمر. من الأسهل بكثير إدارة هذا الإجراء على المدى الطويل مقارنةً بإضافته إلى ملف واحد، ثم إلى ملف آخر، ثم إلى ملف آخر، ثم بعد بضعة أشهر محاولة معرفة ما إذا كان يمكن نقل هذه الكتلة إلى الأعلى إلى قسم المكتبة بدون إفساد أي شيء.
إنشاء مشاريع APK جديدة
يجب أن يكون هناك مشروع Android منفصل لكل حزمة APK ستصدرها. لتسهيل عملية التنظيم، ضَع مشروع المكتبة وجميع مشاريع APK ذات الصلة ضمن المجلد الرئيسي نفسه. تذكَّر أيضًا أنّه يجب أن يكون لكل ملف APK اسم الحزمة نفسه، على الرغم من أنّه ليس من الضروري مشاركة اسم الحزمة مع المكتبة. إذا كان لديك 3 ملفات APK تتبع المخطط الموضح سابقًا، قد يظهر الدليل الجذري على النحو التالي:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
بعد إنشاء المشاريع، أضِف مشروع المكتبة كمرجع لكل مشروع APK. وإذا أمكن، حدِّد نشاط البدء في مشروع المكتبة، ووسِّع هذا النشاط في مشروع APK. من خلال تحديد نشاط بدء في مشروع المكتبة، يمكنك وضع كل عمليات إعداد تطبيقك في مكان واحد، لكي لا يضطر كل ملف APK فردي إلى إعادة تنفيذ المهام "العادية"، مثل إعداد "إحصاءات Google" وإجراء عمليات التحقّق من الترخيص وأي إجراءات إعداد أخرى لا تتغيّر كثيرًا من ملف APK إلى آخر.
تعديل البيانات
عندما ينزِّل مستخدم تطبيقًا يستخدم حِزم APK متعددة من خلال Google Play، يتم اختيار ملف APK الصحيح لاستخدامه من خلال بعض القواعد البسيطة:
- يجب أن يوضّح البيان أنّ حزمة APK هذه مؤهّلة.
- من بين ملفات APK المؤهَّلة، يتم اختيار الملف الذي يحمل أعلى رقم إصدار.
- إذا كان أي من تنسيقات اللمسات المُدرجة في حزمة APK متوافقًا مع الجهاز المتوفّر في السوق، يعتبر هذا الجهاز مؤهَّلاً.
في ما يتعلق بـ GL Textures، تكون هذه القاعدة الأخيرة مهمة. وهذا يعني أنّه يجب، مثلاً، أن تكون مهتمًا جدًا باستخدام تنسيقات GL مختلفة في التطبيق نفسه. إذا كنت ستستخدم PowerVR بنسبة% 99 من الوقت، ولكنك تستخدم ETC1 مثلاً لشاشة البداية... بعد ذلك، يجب أن يشير بيان التطبيق إلى توافقه مع كلا التنسيقَين. سيتم اعتبار الجهاز متوافقًا إذا كان فقط يتوافق مع ETC1، وسيتم تنزيل تطبيقك وسيظهر للمستخدم بعض رسائل الأعطال المثيرة. في العادة، إذا كنت تستخدم حِزم APK متعددة لاستهداف أجهزة مختلفة استنادًا إلى توافقها مع بنية GL، سيكون هناك تنسيق بنية واحد لكل حزمة APK.
ويؤدي ذلك إلى اختلاف طفيف في توافق النسيج عن السمتَين الأخريتَين المتعدّدتَين لملفات APK، وهما مستوى واجهة برمجة التطبيقات وحجم الشاشة. يتضمّن أي جهاز مستوى واحدًا فقط لواجهة برمجة التطبيقات وحجم شاشة واحدًا، ويعود الأمر إلى حزمة APK في توفير توافق مع مجموعة من هذه المستويات والأحجام. باستخدام الزخارف، ستدعم حزمة APK بشكل عام زخرفة واحدة، وسيدعم الجهاز الكثير. غالبًا ما يكون هناك تداخل في ما يتعلّق بجهاز واحد يتوافق مع العديد من حِزم APK، ولكن الحلّ هو نفسه: رموز الإصدارات.
على سبيل المثال، يمكنك اختيار بعض الأجهزة ومعرفة عدد حِزم APK المحدّدة سابقًا التي تتوافق مع كل جهاز.
| FooPhone | Nexus S | إيفو |
| ETC1 | ETC1 | ETC1 |
| منفذ PowerVR | ATI TC |
بافتراض أنّه من الأفضل استخدام تنسيقَي PowerVR وATI بدلاً من ETC1 عند توفّره، مقارنةً بقاعدة "أعلى رقم إصدار يفوز به رقم الإصدار". في حال ضبط سمة رمز الإصدار في كل حزمة APK باللون الأحمر ≥ الأخضر ≥ الأزرق، سيتم دائمًا اختيار كل من اللونَين الأحمر والأخضر بدلاً من اللون الأزرق على الأجهزة المتوافقة معه، وفي حال توفّر جهاز متوافق مع كلٍّ من اللونَين الأحمر والأخضر، سيتم اختيار أي جهاز متوافق مع كلا التنسيقَين الأحمر والأخضر.
لإبقاء جميع حزم APK على "مسارات" منفصلة، يجب أن يكون لديك مخطّط رمز إصدار جيد. يمكن العثور على الرمز المقترَح في قسم "رموز الإصدارات" من دليل المطوّرين. بما أنّ المجموعة النموذجية من حِزم APK تتعامل فقط مع سمة واحدة من 3 سمات محتمَلة، سيكون من الكافي لفصل كل حِزمة APK بمقدار 1, 000 وزيادة عددها من هناك. قد يبدو ذلك على النحو التالي:
الأزرق: 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 الذي يتيح استخدام cupcake على الشاشات الكبيرة جدًا إلا لعدد محدود من المستخدمين).
- يجب أن يكون ملف بيان كل حزمة 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، تأكَّد من عدم توفّر قيم متضاربة لسمتي supports-screens وcompatible-screens، ومن عدم توفّر قيم "uses-feature" غير المقصودة التي تمت إضافتها نتيجة الأذونات التي ضبطتها في البيان. في المثال أعلاه، لن يكون حِزمة 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 تستهدف الأجهزة المقصودة. تهانينا، لقد أكملت الخطوات المطلوبة.