בעבר הייתה ב-Android תמיכה רק בגודלי דפי זיכרון בגודל של 4KB, ביצוע אופטימיזציה של ביצועי זיכרון המערכת עבור הכמות הממוצעת של הזיכרון הכוללת בדרך כלל יש במכשירי Android. החל מ-Android 15, מערכת AOSP תומכת מכשירים שמוגדרים להשתמש בגודל דף של 16KB (16KB) מכשירים). אם באפליקציה נעשה שימוש בספריות NDK, ישירות או בעקיפין דרך SDK, תצטרכו לבנות את האפליקציה מחדש כדי פועלים במכשירים האלה בגודל 16KB.
יצרני מכשירים ממשיכים לפתח מכשירים עם כמויות גדולות יותר של זיכרון פיזי (RAM), רבים מהמכשירים האלה ישתמשו ב- 16KB בסופו של דבר, הם יהיו גדולים יותר) כדי לבצע אופטימיזציה של ביצועי המכשיר. ההוספה מתבצעת תמיכה במכשירים בגודל דף של 16KB תאפשר לאפליקציה לפעול מכשירים ועוזרים לאפליקציה להפיק תועלת מהביצועים המשויכים ושיפורים. בלי הידור מחדש, יכול להיות שאפליקציות לא יפעלו במכשירים עם נפח אחסון של 16KB כשהם יופקו בגרסאות עתידיות של Android.
כדי לעזור לך להוסיף תמיכה עבור האפליקציה, הכנו הנחיות בנושא בדיקה אם האפליקציה שלכם הושפעה, איך ליצור מחדש את האפליקציה (אם רלוונטי), ואיך לבדוק את האפליקציה סביבה של 16KB באמצעות אמולטורים (כולל Android 15) תמונות מערכת עבור אמולטור Android).
יתרונות ושיפור בביצועים
Devices configured with 16 KB page sizes use slightly more memory on average, but also gain various performance improvements for both the system and apps:
- Lower app launch times while the system is under memory pressure: 3.16% lower on average, with more significant improvements (up to 30%) for some apps that we tested
- Reduced power draw during app launch: 4.56% reduction on average
- Faster camera launch: 4.48% faster hot starts on average, and 6.60% faster cold starts on average
- Improved system boot time: improved by 8% (approximately 950 milliseconds) on average
These improvements are based on our initial testing, and results on actual devices will likely differ. We'll provide additional analysis of potential gains for apps as we continue our testing.
איך בודקים אם האפליקציה שלכם מושפעת
אם האפליקציה משתמשת בקוד מקורי, צריך ליצור מחדש את האפליקציה עם תמיכה במכשירים בנפח 16 KB. אם אתם לא בטוחים שהאפליקציה שלכם משתמשת בקוד נייטיב, תוכלו להשתמש בכלי הניתוח ל-APK כדי לזהות אם קיים קוד נייטיב כלשהו, ואז לבדוק את ההתאמה של פלחי ELF לכל ספריות משותפות שתמצאו.
אם האפליקציה שלכם משתמשת רק בקוד שנכתב בשפת התכנות Java או ב-Kotlin, כולל כל הספריות או ערכות ה-SDK, האפליקציה כבר תומכת במכשירים בנפח 16KB. עם זאת, מומלץ לבדוק את האפליקציה בסביבה של 16 KB כדי לוודא שאין נסיגה לא צפויה בהתנהגות האפליקציה.
האם באפליקציה שלכם נעשה שימוש בקוד מקורי?
האפליקציה שלך משתמשת בקוד נייטיב אם אחד מהמצבים הבאים רלוונטי:
- האפליקציה שלך משתמשת בכל קוד C/C++ (מותאם). אם האפליקציה שלכם משתמשת ב-Android NDK, היא משתמשת בקוד מקורי.
- האפליקציה מקשרת לספריות מותאמות או ליחסי תלות של צד שלישי (כמו ערכות SDK) שמשתמשים בהן.
- האפליקציה שלכם נוצרה על ידי כלי לפיתוח אפליקציות של צד שלישי שמשתמש בספריות מקומיות במכשיר.
זיהוי ספריות נייטיב באמצעות כלי הניתוח של APK
כלי הניתוח ל-APK הוא כלי שמאפשר לבחון היבטים שונים של חבילת APK מובנית. כדי לבדוק אם האפליקציה משתמשת בקוד או בספריות מקומיים, פועלים לפי השלבים הבאים:
- פותחים את Android Studio, לוחצים על קובץ > פתיחה ובוחרים פרויקט כלשהו.
בסרגל התפריטים, לוחצים על Build > Analyze APK…
בוחרים את קובץ ה-APK שרוצים לנתח.
בודקים בתוך התיקייה
lib
, שמארחת קבצים של אובייקטים משותפים (.so
), אם קיימים. אם יש קבצים של אובייקטים משותפים, האפליקציה משתמשת בקוד מקורי. אם אין קובצי אובייקטים משותפים או שאין תיקייהlib
, האפליקציה לא משתמשת בקוד מקורי.
בדיקת ההתאמה של פלחי ELF בספריות משותפות
בכל ספרייה משותפת, צריך לוודא שהפלחים של ה-ELF בספריות המשותפות מותאמים בצורה נכונה באמצעות התאמה של 16 KB ELF. אם אתם מפתחים ב-Linux או ב-macOS, תוכלו להשתמש בסקריפט check_elf_alignment.sh
כפי שמתואר בקטע הבא. אפשר גם להשתמש ישירות בכלי שורת הפקודה.
שימוש בסקריפט check_elf_alignment.sh (Linux או macOS)
כדי לבדוק את ההתאמה של פלחים של ELF באמצעות הסקריפט check_elf_alignment.sh
:
שומרים את הסקריפט
check_elf_alignment.sh
בקובץ.מריצים את הסקריפט בקובץ ה-APK של האפליקציה:
check_elf_alignment.sh APK_NAME.apk
הפלט של הסקריפט הוא
ALIGNED
אוUNALIGNED
לכלarm64-v8a
הספריות המשותפות.אם ספריות משותפות מסוג
arm64-v8a
אוx86_64
הן בגרסהUNALIGNED
, תצטרכו לעדכן את האריזה של הספריות האלה, ואז לערוך קומפילציה מחדש של האפליקציה ולבדוק אותה מחדש לפי השלבים שמפורטים בקטע הזה.
שימוש בכלי שורת הפקודה ישירות
כדי לבדוק את ההתאמה של פלחי ELF באמצעות כלים ישירות בשורת הפקודה:
- מוודאים שכלי ה-build-Tools של Android SDK בגרסה 35.0.0 ואילך ושה-NDK של Android מותקנים באמצעות מנהל ה-SDK ב-Android Studio או כלי שורת הפקודה
sdkmanager
. לחלץ את קובץ ה-APK של האפליקציה:
Linux או macOS
unzip APK_NAME.apk -d /tmp/my_apk_out
Windows (PowerShell)
Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
בספרייה הזמנית שאליה חילוץ את קובץ ה-APK, בודקים את התוכן של הספרייה
lib
כדי למצוא קבצים של אובייקטים משותפים (.so
). אלה אותם קובצי אובייקטים משותפים שהייתם רואים כשמזהים ספריות מקוריות באמצעות APK Analyzer. מריצים את הפקודה הבאה בכל קובץ אובייקט משותף:Linux או macOS
SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
Windows (PowerShell)
SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
כאשר
SDK_ROOT_LOCATION
הוא הנתיב לספרייה שבה התקנתם את Android SDK,SHARED_OBJECT_FILE
הוא השם של קובץ האובייקט המשותף שבודקים, ו-NDK_VERSION
הוא גרסת ה-NDK של Android שהתקנתם (לדוגמה,28.0.12433566
). הפלט ייראה בערך כך בכל קובץ שאתם בודקים:LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14 LOAD off 0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14 LOAD off 0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
בודקים את שורות הפלט כדי לוודא שבקטעי העומס אין ערכים קטנים מ-
2**14
. אם יש קטעי עומס עם הערכים2**13
,2**12
או ערכים נמוכים יותר, תצטרכו לעדכן את האריזה של הספריות האלה, ואז לעבד מחדש את האפליקציה ולבדוק אותה שוב לפי השלבים שמפורטים בקטע הזה.בשלב הבא, מריצים את כלי שורת הפקודה
zipalign
בקובץ ה-APK של האפליקציה:Linux או macOS
SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
Windows (PowerShell)
SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
כאשר
SDK_ROOT_LOCATION
הוא הנתיב לספרייה שבה התקנתם את Android SDK, ו-APK_NAME
הוא שם קובץ ה-APK של האפליקציה. אם כל הספריות המשותפות מותאמות בצורה נכונה, בשורה האחרונה של הפלט יופיע הכיתוב 'Verification successful'.אם האימות נכשל, צריך להתאים מחדש חלק מהספריות המשותפות, כך שתצטרכו לעדכן את האריזה של הספריות האלה, ואז להדר מחדש את האפליקציה ולבדוק שוב על ידי ביצוע השלבים שמפורטים בקטע הזה.
בניית האפליקציה עם תמיכה במכשירים עם 16KB
כדי לתמוך במכשירים עם נפח של 16KB, אפליקציות שמשתמשות בקוד נייטיב צריכות להשלים את השלבים שמתוארים בקטעים הבאים. אם מעדכנים לגרסה 8.5.1 ואילך של AGP מגרסה r28 ואילך של NDK ומשתמשים ביחסי תלות מוכנים מראש שתואמים ל-16KB, האפליקציות תואמות ל-16KB כברירת מחדל.
עדכון האריזה של הספריות המשותפות
מומלץ לשדרג ל-AGP לגרסה 8.5.1 ואילך ולהשתמש בספריות משותפות לא דחוסות.
AGP מגרסה 8.5.1 ואילך
במכשירים עם 16 KB נדרשים אפליקציות שנשלחות עם ספריות משותפות לא דחוסות כדי ליישר אותן על תחום ממורכז בגודל 16 KB. לשם כך, צריך לשדרג את Android Gradle Plugin (AGP) לגרסה 8.5.1 ואילך. פרטים על תהליך השדרוג מופיעים בקטע Android Plugin Upgrade Assistant.
AGP מגרסה 8.5 ומטה
אם אתם לא יכולים לשדרג את AGP לגרסה 8.5.1 ואילך, האפשרות החלופית היא לעבור לשימוש בספריות משותפות דחוסות. כדי למנוע בעיות בהתקנת האפליקציה עם ספריות משותפות לא מותאמות, צריך לעדכן את ההגדרות של Gradle כך ש-Gradle ידחוס את הספריות המשותפות בזמן האריזה של האפליקציה.
Groovy
בקובץ build.gradle
, מוסיפים את האפשרות הבאה:
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Kotlin
מוסיפים את האפשרות הבאה לקובץ build.gradle.kts
:
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging = true
}
}
}
איך מקמפלים את האפליקציה באמצעות התאמה של ELF ל-16KB
כדי שהאפליקציה תפעל במכשירים עם 16KB, צריך לבצע התאמה נכונה של קטעי ה-ELF בספריות המשותפות באמצעות התאמה של 16KB ELF.
כדי לקמפל את האפליקציה באמצעות התאמה של ELF בגודל 16 KB, צריך לבצע את השלבים שמפורטים באחד מהקטעים הבאים, בהתאם לגרסה של Android NDK שבה אתם משתמשים.
Android NDK r28 ואילך
בגרסה r28 ואילך של NDK, הידור מתבצע כברירת מחדל עם התאמה ל-16KB.
Android NDK r27
כדי לתמוך בתכנות של ספריות משותפות בגודל 16KB עם Android NDK בגרסה r27 ואילך, צריך לעדכן את הדגלים ndk-build
, build.gradle
, build.gradle.kts
או את הדגלים של הקישור באופן הבא:
ndk-build
בתוך Application.mk
:
APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true
מגניב
בקובץ build.gradle
, מגדירים את הארגומנט -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON
:
android {
...
defaultConfig {
...
// This block is different from the one you use to link Gradle
// to your CMake or ndk-build script.
externalNativeBuild {
// For ndk-build, instead use the ndkBuild block.
cmake {
// Passes optional arguments to CMake.
arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
}
}
}
}
Kotlin
בקובץ build.gradle.kts
, מגדירים את הארגומנט -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON
:
android {
...
defaultConfig {
...
// This block is different from the one you use to link Gradle
// to your CMake or ndk-build script.
externalNativeBuild {
// For ndk-build, instead use the ndkBuild block.
cmake {
// Passes optional arguments to CMake.
arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
}
}
}
}
מערכות build אחרות
מציינים את הדגלים הבאים של הקישור:
-Wl,-z,max-page-size=16384
Android NDK r26 וגרסאות קודמות
כדי לתמוך בהידור של ספריות משותפות שמותאמות ל-16KB עם Android NDK מגרסה r26 ומטה, צריך לעדכן את ההגדרות של ndk-build
או cmake
באופן הבא:
ndk-build
מעדכנים את Android.mk
כדי לאפשר התאמה של ELF בגודל 16KB:
LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
CMake
מעדכנים את CMakeLists.txt
כדי להפעיל התאמה של ELF בנפח 16KB:
target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")
בדיקת מופעי קוד שמפנים לגדלי דפים ספציפיים
גם אם האפליקציה מותאמת ל-16 KB, יכול להיות שתופיעו בה שגיאות אם בחלקים מסוימים בקוד מוגדרת הנחה שהמכשיר משתמש בגודל דף ספציפי. כדי למנוע זאת, צריך לבצע את השלבים הבאים:
מסירים יחסי תלות בתוך הקוד שמפנים הקבוע
PAGE_SIZE
או למופעים בלוגיקת הקוד, שמניחים שגודל הדף של המכשיר הוא 4KB (4096
).במקום זאת, צריך להשתמש ב-
getpagesize()
או ב-sysconf(_SC_PAGESIZE)
.כדאי לחפש שימושים ב-
mmap()
ובממשקי API אחרים שמחייבים ארגומנטים תואמים לדפים, ולהחליף אותם בחלופות במקרה הצורך.
במקרים מסוימים, אם באפליקציה נעשה שימוש ב-PAGE_SIZE
כערך נוח שלא קשור לגודל הדף הבסיסי, הדבר לא יגרום לשגיאות באפליקציה כשמשתמשים בה במצב 16KB. עם זאת, אם הערך הזה מועבר לליבה עם mmap
בלי MAP_FIXED
, הליבה עדיין משתמשת בדף שלם, מה שמבזבז חלק מהזיכרון. לכן, הערך של PAGE_SIZE
לא מוגדר כשמפעילים את המצב של 16KB ב-NDK בגרסה 27 ואילך.
אם האפליקציה משתמשת ב-PAGE_SIZE
באופן הזה ואף פעם לא מעבירה את הערך הזה ישירות לליבה, במקום להשתמש ב-PAGE_SIZE
, צריך ליצור משתנה חדש עם שם חדש כדי לשקף את העובדה שהוא משמש למטרות אחרות ולא משקף דף זיכרון אמיתי.
בדיקת ערכות ה-SDK לתמיכה ב-16KB
הרבה ערכות SDK תואמות לדפים בגודל 16KB, במיוחד אם אתם מפתחים אותן בעצמכם או מקבלים ערכות מוכנות מראש מהזמן האחרון. עם זאת, חלק מה-SDK שנוצרו מראש או גרסאות של SDK לא תואמות ל-16 KB, לכן צריך לבדוק באתר של כל ספק SDK באיזו גרסה כדאי להשתמש עם 16 KB.
בדיקת האפליקציה בסביבה של 16 KB
אחרי שתיצרו את האפליקציה עם תמיכה במכשירים בנפח 16 KB, כדאי לבדוק אותה בסביבה בנפח 16 KB כדי לראות אם יש בה נסיגה לאחור. לשם כך, בצע את הצעדים הבאים:
מגדירים אחת מסביבות הבדיקה הבאות:
מפעילים את מכשיר הבדיקה ומריצים את הפקודה הבאה כדי לוודא שהוא משתמש בסביבה של 16 KB:
adb shell getconf PAGE_SIZE
הפקודה אמורה להחזיר את הערך
16384
.מריצים את הפקודה הבאה
zipalign
כדי לוודא שהאפליקציה תואמת ל-16KB, כאשר APK_NAME הוא השם של קובץ ה-APK של האפליקציה:zipalign -c -P 16 -v 4 APK_NAME.apk
בודקים היטב את האפליקציה, ומתמקדים באזורים שעשויים להיות מושפעים משינוי של מופעי קוד שמפנים לגדלים ספציפיים של דפים.
הגדרת Android Emulator באמצעות קובץ אימג' של מערכת Android 15 בגודל 16KB
כדי להגדיר סביבה של 16 KB באמצעות Android Emulator:
קובצי אימג' של מערכת של אמולטור Android 15 בגודל 16KB תואמים ל-Android Studio Jellyfish | 2023.3.1 ואילך. עם זאת, כדי ליהנות מחוויית השימוש הטובה ביותר כשעובדים עם גרסת הבטא של Android 15, צריך להוריד את גרסת התצוגה המקדימה העדכנית של Android Studio.
חשוב לזכור שאפשר להשאיר את הגרסה הקיימת של Android Studio מותקנת, כי אפשר להתקין כמה גרסאות במקביל.
ב-Android Studio, לוחצים על 'כלים' > 'מנהל SDK'.
בכרטיסייה SDK Platforms, מסמנים את התיבה Show Package Details, מרחיבים את הקטע Android VanillaIceCream Preview ובוחרים אחת או את שתי קובצי האימג' הבאים של מערכת האמולטור, בהתאם למכשירים הווירטואליים שרוצים ליצור:
- Google APIs Experimental 16k Page Size ARM 64 v8a System Image
- Google APIs Experimental 16k Page Size Intel x86_64 Atom System Image
לוחצים על אישור > בסדר כדי להוריד את קובצי האימג' של המערכת שבחרתם.
פועלים לפי השלבים להגדרת מכשיר וירטואלי ל-Android 15, וכשמופיעה בקשה לבחור קובץ אימג' של מערכת, בוחרים את קובץ האימג' בגודל 16KB שהורדתם. אם לא מוצגת המלצה אוטומטית, אפשר למצוא את תמונת המערכת בגודל 16KB בכרטיסייה Other Images.
- במנהל המכשירים, לוחצים על 3 הנקודות לצד התמונה בגודל 16KB ואז על הצגה בדיסק.
- מאתרים את הקובץ
config.ini
בתיקייה הזו. מוסיפים את השורה הבאה לקובץ
config.ini
ושומרים את השינויים:kernel.parameters = androidboot.page_shift=14
כדי לאמת את השינויים, מריצים את הפקודה הבאה, והיא אמורה להחזיר את הערך
16384
:adb shell getconf PAGE_SIZE
הפעלה של מצב 16KB במכשיר באמצעות האפשרויות למפתחים
החל מ-Android 15 QPR1, להשתמש באפשרות למפתחים שזמינה מכשירים לאתחול המכשיר במצב 16 KB ולביצוע בדיקות במכשיר.
האפשרות הזו למפתחים זמינה במכשירים הבאים:
- Pixel 8 ו-Pixel 8 Pro (עם Android 15 QPR1 Beta 1 ואילך)