אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור ולהעלות קובץ Android App Bundle. כשעושים זאת, 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 מספק חומר עזר שימושי של כמה מהטקסטורות הנתמכות הנפוצות טקסטורת מסוג support-gl . הדף הזה כולל גם כמה רמזים לגבי הטלפונים (או משפחות של טלפונים) שתומכים בפורמטים מסוימים של טקסטורה. לתשומת ליבך: בדרך כלל מומלץ שאחת מחבילות ה-APK שלך תתמוך ETC1, מאחר שפורמט הטקסטורה הזה נתמך בכל המכשירים מבוססי Android שתומכים ב-OpenGL ES מפרט 2.0
מאחר שרוב המכשירים מבוססי Android תומכים ביותר מפורמט טקסטורה אחד, צריך ליצור לפי סדר העדפה. יוצרים תרשים שכולל את כל הפורמטים שהאפליקציה עומדת בהם תמיכה. התא הימני ביותר יהיה בעדיפות הנמוכה ביותר (הוא יהיה כנראה ETC1, ברירת מחדל יציבה מבחינת ביצועים ותאימות). ואז צבעים בתרשים, כך שכל אחד מהם התא מייצג APK.
| ETC1 | ATI | PowerVR |
הצבעים בתרשים עושים יותר מאשר רק הופך את המדריך לפחות למונוכרומטי - יש בו גם דרך תקשורת קלה יותר בתוך הצוות – עכשיו אפשר פשוט להתייחס לכל APK בתור "כחול", "ירוק" או 'red', במקום 'זה שתומך בפורמטים של טקסטורה ETC1', וכו'.
הקצאת כל הקוד והמשאבים הנפוצים בפרויקט ספרייה
לא משנה אם אתם משנים אפליקציה קיימת ל-Android או יוצרים אפליקציה מאפס, הדבר הראשון שצריך לעשות ל-codebase, ולרוב הדבר הכי חשוב. הכול שנכנסים לפרויקט הספרייה, צריך לעדכן אותם רק פעם אחת (למשל, מחרוזות שמתאימות לשפה מסוימת, עיצובים של צבעים, באגים שתוקנו בקוד משותף), שמשפרים את זמן הפיתוח ומפחיתים את לטעויות שניתן היה להימנע בקלות.
הערה: בעוד פרטים על ההטמעה כוללים פרויקטים של ספריות שלא נכללים בשיעור הזה, תוכלו להשיג אפשר לקרוא את המאמר יצירת ספריית Android.
אם אתם ממירים אפליקציה קיימת לשימוש בתמיכה ב-APK מרובים, לסרוק את ה-codebase לכל קובץ מחרוזת, רשימת ערכים ועיצוב שהותאמו לשוק המקומי. צבעים, סמלי תפריטים ופריסה שלא עומדים להשתנות ב-APKs, ולהוסיף בפרויקט הספרייה. קוד שלא עומד להשתנות הרבה גם בפרויקט הספרייה. סביר להניח שתצטרכו להרחיב מחלקות כדי להוסיף שיטה או שניים מ-APK ל-APK.
מצד שני, אם אתם יוצרים את האפליקציה מאפס, נסו לכתוב קוד בפרויקט הספרייה קודם, ואז להעביר אותו למטה APK נפרד, אם יש צורך. הרבה יותר קל לנהל את זה בטווח הארוך מאשר להוסיף אותם לדף אינטרנט ואז עוד משהו, ואז עוד חודשים לאחר מכן, בניסיון להבין אם אפשר להזיז את ה-blob הזה למקטע הספרייה בלי להזיז שום דבר.
יצירת פרויקטים חדשים של APK
צריך להיות פרויקט Android נפרד לכל APK שמפרסמים. קל ונוח לארגון, יש למקם את פרויקט הספרייה ואת כל הפרויקטים הקשורים של ה-APK באותה תיקיית הורה. זכרו גם שלכל APK צריך להיות אותו שם חבילה, אבל לא בטוח צריך לשתף את שם החבילה עם הספרייה. אם היו לכם 3 חבילות APK בהתאם לסכימה שתואר קודם לכן, תיקיית השורש עשויה להיראות כך:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
לאחר יצירת הפרויקטים, מוסיפים את פרויקט הספרייה כהפניה לכל פרויקט APK. אם המיקום אפשרית, להגדיר את הפעילות ההתחלתית שלך בפרויקט הספרייה ולהרחיב את הפעילות הזו ב-APK. פרויקט. לאחר הגדרת פעילות התחלתית בפרויקט הספרייה, יש לכם הזדמנות להתחיל באתחול האפליקציה במקום אחד, כך שכל חבילת APK בנפרד לא ליישם מחדש את "Universalversal" משימות כמו אתחול Analytics, הרצת בדיקות רישוי וכל פעולה אחרת הליכי אתחול שלא משתנים הרבה מ-APK ל-APK.
שינוי המניפסטים
כשמשתמש מוריד אפליקציה שמשתמשת בכמה חבילות APK דרך Google Play, בחירת ה-APK לשימוש מתבצעת לפי כמה כללים פשוטים:
- במניפסט צריך להראות שחבילת APK מסוימת עומדת בדרישות
- מתוך חבילות ה-APK שעומדות בדרישות, מספר הגרסה הגבוה ביותר זוכה
- אם אחד מהפורמטים האלה של טקסטורה ב-APK נתמך במכשיר בשוק, המכשיר הזה נחשב ככשיר
לגבי הטקסטורות של GL, הכלל האחרון חשוב. המשמעות היא שצריך, להקפיד מאוד על השימוש בפורמטים שונים של GL באותה אפליקציה. אם היו משתמשים ב-PowerVR ב-99% מהמקרים, אבל ב-ETC1, למשל, במסך הפתיחה... לאחר מכן המניפסט יציין בהכרח תמיכה בשני הפורמטים. מכשיר שרק תומך ב-ETC1 ייחשב כתואם, תתבצע הורדה של האפליקציה שלך והמשתמש יראה קריסת מחשבה מרגשת הודעות. המקרה הנפוץ הוא שאם משתמשים במספר חבילות APK באופן ספציפי כדי לטרגט במכשירים שונים בהתאם לתמיכה במרקם של GL, זה יהיה פורמט טקסטורה אחד לכל APK.
למעשה, התמיכה בטקסטורה מעט שונה מזו של שני ה-APK האחרים מאפיינים, רמת API וגודל מסך. לכל מכשיר יש רק רמת API אחת ומסך אחד גודל, וה-APK יכול לתמוך במגוון שלהם. עם טקסטורות, ה-APK בדרך כלל תומכים במרקם אחד, והמכשיר יתמוך בהרבה טקסטורה. תהיה חפיפה בדרך כלל המכשיר תומך בחבילות APK רבות, אבל הפתרון זהה: קודי גרסאות.
לדוגמה, אפשר לקחת כמה מכשירים ולבדוק כמה מחבילות ה-APK שהוגדרו קודם מתאימות לכל אחד במכשיר.
| FooPhone | Nexus S | אבו |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC (TC) |
בהנחה ששני הפורמטים PowerVR ו-ATI עדיפים על פני ETC1 כשהם זמינים, בהתאם ל"זכיות במספר הגרסה הגבוהה ביותר" כלל, אם מגדירים את המאפיין versionCode בכל APK למשל, אדום ≥ ירוק ≥ כחול, ואז גם 'אדום' וגם 'ירוק' ייבחרו תמיד מעל ל'כחול' במכשירים שתומכים בהם, ואם מכשיר כלשהו יתמוך בעתיד גם באדום וגם בירוק, ייבחר בצבע אדום.
כדי להשאיר את כל חבילות ה-APK ב"טראקים" נפרדים, חשוב שתהיה לכם קוד גרסה טוב scheme. הגרסה המומלצת מופיעה בקטע 'קודי גרסאות' במדריך למפתחים. מאז קבוצת ה-APK לדוגמה עוסקת רק באחד מ-3 מאפיינים אפשריים, והיא אמורה להספיק הפריד כל חבילת APK ב-1000 ואז הגדיל את מספר ה-APKs משם. הדוגמה הזו יכולה להיראות כך:
כחול: 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 שתומך רק ב-APK אף אחד לא יראה את הקאפקייק במסכי XLARGE)
- מניפסט של כל APK חייב להיות ייחודי לפחות לאחד מסך נתמך, מרקם OpenGL או גרסת פלטפורמה
- מומלץ לבדוק כל חבילת APK במכשיר אחד לפחות. מלבד זאת, יש לכם אחד אמולטורים של מכשירים שניתן להתאים אישית בעסק, שממוקמים במכונת הפיתוח שלכם. השתגע!
כדאי גם לבדוק את ה-APK המורכב לפני שדוחפים אותו לשוק, כדי לוודא שאין בו הפתעות שעלולות להסתיר את האפליקציה ב-Google Play. זה בעצם די פשוט באמצעות 'aapt' של Google. Aapt (הכלי לאריזת נכסים של Android) הוא חלק מתהליך ה-build ליצירה לארוז את אפליקציות 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, חשוב לוודא שאין לך ערכים מתנגשים תומך במסכים ובמסכים תואמים, ושאין לך מכשיר שמתכוון ל-'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 מטרגטות את המכשירים הרצויים. מזל טוב, סיימת!