پشتیبانی از اندازه صفحه 16 کیلوبایت

از لحاظ تاریخی، اندروید تنها از اندازه صفحات حافظه 4 کیلوبایتی پشتیبانی می‌کند که عملکرد حافظه سیستم را برای میانگین کل حافظه‌ای که دستگاه‌های اندرویدی معمولا دارند بهینه می‌کند. با شروع Android 15، AOSP از دستگاه هایی پشتیبانی می کند که برای استفاده از اندازه صفحه 16 کیلوبایت (دستگاه های 16 کیلوبایت) پیکربندی شده اند. اگر برنامه شما از کتابخانه های NDK استفاده می کند، چه به طور مستقیم یا غیرمستقیم از طریق یک SDK، باید برنامه خود را بازسازی کنید تا بتواند روی این دستگاه های 16 کیلوبایتی کار کند.

از آنجایی که سازندگان دستگاه‌ها به ساخت دستگاه‌هایی با حافظه فیزیکی (RAM) بیشتر ادامه می‌دهند، بسیاری از این دستگاه‌ها از اندازه صفحه ۱۶ کیلوبایت (و در نهایت بیشتر) برای بهینه‌سازی عملکرد دستگاه استفاده می‌کنند. افزودن پشتیبانی برای دستگاه‌های اندازه صفحه 16 کیلوبایت، برنامه شما را قادر می‌سازد تا در این دستگاه‌ها اجرا شود و به برنامه شما کمک می‌کند از بهبودهای عملکرد مرتبط بهره مند شود. بدون کامپایل مجدد، برنامه‌ها ممکن است در دستگاه‌های 16 کیلوبایتی در نسخه‌های بعدی اندروید تولید نشوند.

برای کمک به اضافه کردن پشتیبانی از برنامه خود، راهنمایی هایی در مورد نحوه بررسی اینکه آیا برنامه شما تحت تأثیر قرار گرفته است ، نحوه بازسازی برنامه خود (در صورت وجود) و نحوه آزمایش برنامه خود در یک محیط 16 کیلوبایتی با استفاده از شبیه سازها (از جمله Android) ارائه کرده ایم. 15 تصویر سیستم برای شبیه ساز اندروید).

مزایا و دستاوردهای عملکرد

دستگاه هایی که با اندازه صفحه 16 کیلوبایت پیکربندی شده اند به طور متوسط ​​کمی از حافظه بیشتری استفاده می کنند، اما بهبودهای عملکردی مختلفی را برای سیستم و برنامه ها نیز به دست می آورند:

• زمان‌های راه‌اندازی برنامه کمتر زمانی که سیستم تحت فشار حافظه است: به طور متوسط ​​3.16٪ کمتر، با بهبودهای قابل توجه (تا 30٪) برای برخی از برنامه‌هایی که آزمایش کردیم.
• کاهش مصرف انرژی در حین راه اندازی برنامه: به طور متوسط ​​4.56٪ کاهش
• راه‌اندازی سریع‌تر دوربین: به طور متوسط ​​4.48٪ سریع‌تر استارت‌های گرم و 6.60٪ سریع‌تر شروع سرد.
• بهبود زمان بوت سیستم: به طور متوسط ​​8٪ (تقریباً 950 میلی ثانیه) بهبود یافته است.

این پیشرفت‌ها بر اساس آزمایش اولیه ما هستند و نتایج روی دستگاه‌های واقعی احتمالاً متفاوت خواهد بود. در ادامه آزمایش خود، تجزیه و تحلیل بیشتری از دستاوردهای بالقوه برای برنامه ها ارائه خواهیم کرد.

بررسی کنید که آیا برنامه شما تحت تأثیر قرار گرفته است

اگر برنامه شما از هر کد بومی استفاده می کند ، باید برنامه خود را با پشتیبانی از دستگاه های 16 کیلوبایتی بازسازی کنید . اگر مطمئن نیستید که برنامه شما از کد بومی استفاده می‌کند، می‌توانید از APK Analyzer برای شناسایی وجود کد بومی استفاده کنید و سپس تراز بخش‌های ELF را برای کتابخانه‌های مشترکی که پیدا کردید بررسی کنید .

اگر برنامه شما فقط از کدهای نوشته شده به زبان برنامه نویسی جاوا یا کاتلین استفاده می کند که شامل همه کتابخانه ها یا SDK می شود، برنامه شما از قبل از دستگاه های 16 کیلوبایتی پشتیبانی می کند. با این وجود، توصیه می کنیم برنامه خود را در یک محیط 16 کیلوبایتی آزمایش کنید تا مطمئن شوید که هیچ رگرسیون غیرمنتظره ای در رفتار برنامه وجود ندارد.

آیا برنامه شما از کد بومی استفاده می کند؟

اگر یکی از موارد زیر اعمال شود، برنامه شما از کد بومی استفاده می کند:

• برنامه شما از هر کد C/C++ (بومی) استفاده می کند. اگر برنامه شما از Android NDK استفاده می کند، برنامه شما از کد بومی استفاده می کند.
• برنامه شما به کتابخانه های بومی شخص ثالث یا وابستگی هایی که از آنها استفاده می کنند پیوند می دهد.
• برنامه شما توسط یک برنامه ساز شخص ثالث ساخته شده است که از کتابخانه های بومی در دستگاه استفاده می کند.

کتابخانه های بومی را با استفاده از APK Analyzer شناسایی کنید

APK Analyzer ابزاری است که به شما امکان می دهد جنبه های مختلف یک APK ساخته شده را ارزیابی کنید. برای تشخیص اینکه آیا برنامه شما از کد بومی یا کتابخانه‌ها استفاده می‌کند، این مراحل را دنبال کنید:

1. Android Studio را باز کنید، سپس روی File > Open کلیک کنید و هر پروژه را انتخاب کنید.

2. از نوار منو، روی Build > Analyze APK کلیک کنید...

   

3. APK مورد نظر برای تجزیه و تحلیل را انتخاب کنید.

4. به داخل پوشه lib نگاه کنید، که در صورت وجود فایل‌های شی اشتراک‌گذاری شده ( .so ) را میزبانی می‌کند. اگر هر فایل شی مشترکی وجود دارد، برنامه شما از کد بومی استفاده می کند. اگر هیچ فایل شی مشترکی وجود ندارد یا پوشه lib وجود ندارد، برنامه شما از کد بومی استفاده نمی کند.

   

برنامه خود را با پشتیبانی از دستگاه های 16 کیلوبایتی بسازید

برای پشتیبانی از دستگاه‌های 16 کیلوبایتی، برنامه‌هایی که از کد بومی استفاده می‌کنند باید مراحلی را که در بخش‌های زیر توضیح داده شده است انجام دهند.

بسته بندی کتابخانه های مشترک خود را به روز کنید

توصیه می کنیم AGP نسخه 8.5.1 یا بالاتر را ارتقا دهید و از کتابخانه های مشترک غیرفشرده استفاده کنید.

AGP نسخه 8.5.1 یا بالاتر

دستگاه‌های 16 کیلوبایتی به برنامه‌هایی نیاز دارند که با کتابخانه‌های اشتراک‌گذاری‌شده فشرده‌نشده ارسال شوند تا آن‌ها را روی یک مرز زیپ تراز شده 16 کیلوبایتی تراز کنند. برای انجام این کار، باید به Android Gradle Plugin (AGP) نسخه 8.5.1 یا بالاتر ارتقا دهید. برای جزئیات بیشتر در مورد فرآیند ارتقا، به بخش ارتقاء پلاگین Android Gradle مراجعه کنید.

AGP نسخه 8.5 یا پایین تر

توجه: در AGP نسخه 8.3 تا 8.5، برنامه ها به طور پیش فرض 16 کیلوبایت تراز شده اند. با این حال، bundletool به طور پیش‌فرض فایل‌های APK را زیپال نمی‌کند. بنابراین، ممکن است به نظر برسد که برنامه کار می کند، اما وقتی از یک بسته در Play ساخته شود، نصب نمی شود.

اگر نمی توانید AGP را به نسخه 8.5.1 یا بالاتر ارتقا دهید، گزینه جایگزین استفاده از کتابخانه های اشتراکی فشرده شده است. پیکربندی Gradle خود را به‌روزرسانی کنید تا Gradle کتابخانه‌های مشترک شما را هنگام بسته‌بندی برنامه‌تان فشرده کند تا از مشکلات نصب برنامه با کتابخانه‌های به اشتراک‌گذاشته‌نشده اجتناب شود.

شیار

در فایل build.gradle خود گزینه زیر را اضافه کنید:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

کاتلین

در فایل build.gradle.kts خود گزینه زیر را اضافه کنید:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

برنامه خود را با استفاده از تراز ELF 16 کیلوبایتی کامپایل کنید

دستگاه‌های 16 کیلوبایتی نیاز دارند که بخش‌های ELF کتابخانه‌های مشترک با استفاده از ترازبندی ELF 16 کیلوبایتی به درستی تراز شوند تا برنامه شما اجرا شود.

توجه: اگر برنامه شما کتابخانه های بومی را در سیستم فایل استخراج نکند ( extractNativeLibs روی false تنظیم شده است)، احتمالاً بعد از کامپایل با استفاده از تراز ELF 16 کیلوبایتی، متوجه افزایش جزئی در اندازه باینری برنامه خود خواهید شد. بهینه سازی های مدیریت بسته در اندروید 15 هزینه های زمان اجرا را از این افزایش خنثی می کند.

برای کامپایل برنامه خود با استفاده از تراز 16 کیلوبایتی ELF، بسته به نسخه Android NDK که استفاده می‌کنید، مراحل یکی از بخش‌های زیر را تکمیل کنید.

مهم: اگر برنامه شما از کتابخانه‌های مشترک از پیش ساخته شده استفاده می‌کند، باید آن‌ها را نیز به همین روش کامپایل کنید و کتابخانه‌های تراز شده با ۱۶ کیلوبایت را دوباره به برنامه خود وارد کنید.

اندروید NDK r26 و پایین تر

برای پشتیبانی از کامپایل کتابخانه های اشتراکی تراز شده با ۱۶ کیلوبایت با Android NDK نسخه r26 یا پایین تر، باید پیکربندی ndk-build یا cmake خود را به صورت زیر به روز کنید:

ndk-build

Android.mk خود را برای فعال کردن تراز ELF 16 کیلوبایتی به روز کنید:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

CMake

CMakeLists.txt خود را برای فعال کردن تراز ELF 16 کیلوبایتی به روز کنید:

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

مهم: حتی اگر برنامه شما به صورت پویا به کتابخانه استاندارد C++ ( libc++_shared.so ) از NDK های r26 و پایین تر، که برخی از آنها 16 کیلوبایت تراز نیستند، پیوند می دهد، همچنان باید تراز همه کتابخانه های دیگر را در اینجا به روز کنید، و شما باید کد خود را به روز کند تا بسته به PAGE_SIZE اجتناب شود. به منظور آزمایش بر روی آن نسخه‌های پایین‌تر NDK در دستگاه‌های 16 کیلوبایتی، نسخه‌های قناری LTS NDK نسخه‌های r21 (فقط برای ویندوز و لینوکس)، r23 و r25 در Android CI با 16 کیلوبایت تراز libc++_shared.so موجود است. کتابخانه ها صرف نظر از این، توصیه می‌شود برای به‌روزرسانی به نسخه 16 کیلوبایتی ELF کتابخانه استاندارد C++ به Android NDK r27 یا بالاتر بروید. در غیر این صورت، برنامه شما امروز روی دستگاه‌های 16 کیلوبایتی نصب نمی‌شود.

اگر نمی توانید به Android NDK جدیدتر بروید، ممکن است بتوانید برنامه خود را به روز کنید تا کتابخانه استاندارد C++ را به صورت ایستا در کتابخانه مشترک خود کامپایل کنید. برای جزئیات بیشتر در مورد پیوند استاتیک به کتابخانه استاندارد C++ به بخش پشتیبانی کتابخانه C++ مراجعه کنید و حتماً بخش ملاحظات مهم را بخوانید.

اندروید NDK r27 و بالاتر

برای پشتیبانی از کامپایل کتابخانه های اشتراکی تراز شده با ۱۶ کیلوبایت با 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"
      }
    }
  }
}

کاتلین

در فایل 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")
      }
    }
  }
}

سایر سیستم های ساخت

پرچم های پیوند دهنده زیر را مشخص کنید:

-Wl,-z,max-page-size=16384

برای نمونه کدهایی که به اندازه صفحه خاصی اشاره می کنند، بررسی کنید

حتی اگر برنامه شما 16 کیلوبایت تراز باشد، اگر مکان‌هایی در کد شما فرض کنند که دستگاه از اندازه صفحه خاصی استفاده می‌کند، برنامه شما می‌تواند با خطا مواجه شود. برای جلوگیری از این، مراحل زیر را انجام دهید:

1. هر گونه وابستگی کدگذاری سختی که به ثابت PAGE_SIZE اشاره می کند یا نمونه هایی در منطق کد شما که اندازه صفحه دستگاه را 4 کیلوبایت فرض می کند ( 4096 ) را حذف کنید.

   به جای آن از getpagesize() یا sysconf(_SC_PAGESIZE) استفاده کنید.

2. به دنبال موارد استفاده از mmap() و سایر API هایی باشید که به آرگومان های صفحه تراز شده نیاز دارند و در صورت لزوم با جایگزین ها جایگزین کنید.

در برخی موارد، اگر برنامه شما از PAGE_SIZE به‌عنوان یک مقدار مناسب استفاده می‌کند که به اندازه صفحه اصلی مرتبط نیست، این امر باعث نمی‌شود که برنامه شما هنگام استفاده در حالت 16 کیلوبایتی خراب شود. با این حال، اگر این مقدار با mmap بدون MAP_FIXED به هسته ارسال شود، هسته همچنان از یک صفحه کامل استفاده می‌کند که مقداری از حافظه را هدر می‌دهد. به این دلایل، وقتی حالت 16 کیلوبایتی در NDK r27 و بالاتر فعال باشد، PAGE_SIZE تعریف نشده است.

اگر برنامه شما از PAGE_SIZE به این روش استفاده می‌کند و هرگز مستقیماً این مقدار را به هسته منتقل نمی‌کند، به جای استفاده از PAGE_SIZE ، یک متغیر جدید با نام جدید ایجاد کنید تا نشان دهد که برای مقاصد دیگر استفاده می‌شود و صفحه حافظه واقعی را منعکس نمی‌کند.

برنامه خود را در یک محیط 16 کیلوبایتی تست کنید

بعد از اینکه برنامه خود را با پشتیبانی از دستگاه های 16 کیلوبایتی ساختید، می خواهید برنامه خود را در یک محیط 16 کیلوبایتی آزمایش کنید تا ببینید آیا برنامه شما دچار رگرسیون می شود یا خیر. برای این کار مراحل زیر را دنبال کنید:

1. Android 15 SDK را تنظیم کنید .

2. یکی از محیط های تست زیر را تنظیم کنید:

   • شبیه ساز Android را با یک تصویر سیستم Android 15 مبتنی بر 16 کیلوبایت تنظیم کنید
   • با استفاده از گزینه های توسعه دهنده، حالت 16 کیلوبایتی را در دستگاهی فعال کنید
   • از Cuttlefish با اندازه صفحه 16 کیلوبایت در ARM64 استفاده کنید
   • شبیه سازی Cuttlefish با اندازه صفحه 16 کیلوبایت در x86-64

3. دستگاه تست خود را راه اندازی کنید، سپس دستور زیر را اجرا کنید تا مطمئن شوید که از یک محیط 16 کیلوبایتی استفاده می کند:

   adb shell getconf PAGE_SIZE
   

   دستور باید مقدار 16384 را برگرداند.

4. برای هر کتابخانه مشترک، بررسی کنید که بخش‌های ELF کتابخانه‌های مشترک با استفاده از تراز ELF 16 کیلوبایتی به درستی تراز شده باشند. برای کمک به این فرآیند می توانید از این اسکریپت استفاده کنید:

   #!/bin/bash
   
   # usage: alignment.sh path to search for *.so files
   
   dir="$1"
   
   RED="\e[31m"
   GREEN="\e[32m"
   ENDCOLOR="\e[0m"
   
   matches="$(find $dir -name "*.so" -type f)"
   IFS=$'\n'
   for match in $matches; do
     res="$(objdump -p ${match} | grep LOAD | awk '{ print $NF }' | head -1)"
     if [[ $res =~ "2**14" ]] || [[ $res =~ "2**16" ]]; then
       echo -e "${match}: ${GREEN}ALIGNED${ENDCOLOR} ($res)"
     else
       echo -e "${match}: ${RED}UNALIGNED${ENDCOLOR} ($res)"
     fi
   done
   

   1. اسکریپت را در فایلی مانند alignment.sh ذخیره کنید.

   2. فایل APK برنامه خود را استخراج کنید:

       unzip APK_NAME.apk -d /tmp/my_apk_out
       ```
   
   1.  Run the script on the extracted files in the `/tmp/my_apk_out`
       directory:
   
   ```none {: .devsite-terminal .devsite-click-to-copy }
       alignment.sh /tmp/my_apk_out | grep "arm64-v8a"
       ```
   
   The script outputs either `ALIGNED` or `UNALIGNED` for all the `arm64-v8a`
       shared libraries.
   
   1.  If any `arm64-v8a` shared libraries are `UNALIGNED`, you'll need to
       [update the packaging for those libraries][20], then [recompile your
       app][21] and retest by following the steps in this section.
   

5. دستور zipalign زیر را اجرا کنید تا مطمئن شوید برنامه شما 16 کیلوبایت تراز شده است، جایی که APK_NAME نام فایل APK برنامه شما است:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

6. برنامه خود را به طور کامل آزمایش کنید و بر روی مناطقی تمرکز کنید که ممکن است با تغییر نمونه کدهایی که به اندازه های صفحه خاصی اشاره می کنند تحت تأثیر قرار گیرند.

شبیه ساز Android را با یک تصویر سیستم Android 15 مبتنی بر 16 کیلوبایت تنظیم کنید

مهم: یک مشکل شناخته شده وجود دارد که از اشکال زدایی با LLDB با تصاویر سیستم شبیه ساز 16 کیلوبایتی جلوگیری می کند. رفع این مشکل در NDK r27 RC 1 و Android Studio Koala Feature Drop | 2024.1.2 قناری 5.

برای راه اندازی یک محیط 16 کیلوبایتی با استفاده از شبیه ساز اندروید، مراحل زیر را دنبال کنید:

1. تصاویر سیستم شبیه ساز اندروید 15 مبتنی بر 16 کیلوبایت با اندروید استودیو Jellyfish سازگار است | 2023.3.1 یا بالاتر. با این حال، برای بهترین تجربه هنگام کار با اندروید 15 بتا، آخرین نسخه پیش نمایش اندروید استودیو را دانلود کنید.

   به یاد داشته باشید که می‌توانید نسخه موجود Android Studio خود را نصب کنید، زیرا می‌توانید چندین نسخه را در کنار هم نصب کنید .

2. در Android Studio، روی Tools > SDK Manager کلیک کنید.

3. در برگه پلتفرم‌های SDK ، Show Package Details را علامت بزنید، سپس بخش Android VanillaIceCream Preview را باز کنید و بسته به دستگاه‌های مجازی که می‌خواهید ایجاد کنید، یکی یا هر دو تصویر سیستم شبیه‌ساز زیر را انتخاب کنید:

   • Google APIs Experimental 16k Size Page Size ARM 64 v8a System Image
   • Google APIs Experimental 16k Page Size Intel x86_64 Atom System Image
   توجه: اگر می‌خواهید از دستگاه Google Pixel پشتیبانی‌شده شبیه‌سازی کنید ، فقط به تصویر سیستم ARM 64 v8a نیاز دارید.

   

4. روی Apply > OK کلیک کنید تا هر کدام از تصاویر سیستمی را که انتخاب کرده اید دانلود کنید.

5. مراحل راه اندازی یک دستگاه مجازی برای Android 15 را دنبال کنید و هنگامی که از شما خواسته شد یک تصویر سیستم را انتخاب کنید، تصویر سیستمی 16 کیلوبایتی را که دانلود کرده اید انتخاب کنید. اگر به طور خودکار توصیه نمی شود، می توانید تصویر سیستم 16 کیلوبایتی را در برگه سایر تصاویر پیدا کنید.

   

هشدار: برای شبیه سازی یک محیط 16 کیلوبایتی در سیستم های x86_64 نیز باید مراحل زیر را انجام دهید. این مراحل موقتی هستند و در آینده حذف خواهند شد.

1. در Device manager، روی 3 نقطه کنار تصویر 16 کیلوبایتی کلیک کنید، سپس روی Show on Disk کلیک کنید.
2. در این پوشه فایل config.ini را پیدا کنید.

3. خط زیر را به فایل config.ini اضافه کنید و تغییرات خود را ذخیره کنید:

   kernel.parameters = androidboot.page_shift=14
   

4. برای تأیید تغییرات خود، دستور زیر را اجرا کنید که باید 16384 را برگرداند:

   adb shell getconf PAGE_SIZE
   

با استفاده از گزینه های توسعه دهنده، حالت 16 کیلوبایتی را در دستگاهی فعال کنید

گزینه Boot with 16KB page size developer را تغییر دهید تا دستگاه به حالت 16 کیلوبایت راه اندازی شود.

با شروع اندروید 15 QPR1، می‌توانید از گزینه توسعه‌دهنده موجود در دستگاه‌های خاص برای راه‌اندازی دستگاه در حالت 16 کیلوبایتی و انجام تست روی دستگاه استفاده کنید .

این گزینه توسعه دهنده در دستگاه های زیر موجود است:

• Pixel 8 و 8 Pro (با Android 15 QPR1 Beta 1 یا بالاتر)
• Pixel 8a (با Android 15 QPR1 Beta 2 یا بالاتر)

توجه: اندروید 15 QPR1 در نسخه بتا است. برای اطلاعات بیشتر در مورد دریافت QPR1 در دستگاه واجد شرایط، به دریافت نسخه‌های بتای Android 15 QPR مراجعه کنید.