自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
16 KB 頁面大小
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
頁面大小是作業系統管理記憶體的細微程度。現今大多數 CPU 都支援 4 KB 分頁大小,因此 Android OS 和應用程式過去都是以 4 KB 分頁大小建構及最佳化。ARM CPU 支援較大的 16 KB 分頁大小,而從 Android 15 開始,AOSP 也支援建構採用 16 KB 分頁大小的 Android。這個選項會使用額外記憶體,但可提升系統效能。在 Android 15 中,這項選項預設為停用,但 OEM 和應用程式開發人員可以透過開發人員模式或開發人員選項啟用,為日後全面切換至 16 KB 模式做好準備。
Android 15 以上版本支援以 16 KB ELF 對齊方式建構 Android,可搭配 4 KB 和 16 KB 核心使用,從 android14-6.1
開始支援。搭配 16 KB 核心使用時,這項設定會使用額外記憶體,但可提升系統效能。
將 Android 設為 16 KB
16 KB 頁面僅適用於具有 16 KB 核心的 arm64
目標。
不過,您也可以選擇在 Cuttlefish 上模擬 16 KB 的使用者空間x86_64
。
核心空間
如果是 arm64
目標,如果您使用 Kleaf 建構核心,--page_size=16k
會以 16 KB 模式建構核心。如果您直接使用 Linux 核心設定,可以設定 CONFIG_ARM64_16K_PAGES
(而非 CONFIG_ARM64_4K_PAGES
) 來選取 16 KB 頁面。
使用者空間
如要在 Android 使用者空間中啟用 16 KB 分頁大小支援,請在產品上設定下列建構選項:
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
會移除 PAGE_SIZE
定義,並讓元件在執行階段決定網頁大小。
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384
,確保平台 ELF 檔案是以 16 KB 對齊方式建構。這個大小大於必要大小,是為了確保日後相容性。透過 16 KB ELF 對齊,核心可支援 4 KB/16 KB 頁面大小。
驗證建構旗標
選取 lunch
目標後,請確認環境中的建構標記設定正確無誤:
$ source build/envsetup.sh
$ lunch target
$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
true
如果前兩個指令分別傳回 16384
和 true
,表示您的建構標記設定正確,可搭配 16 KB 核心運作。不過,即使建構作業通過,16 KB 環境的差異仍可能導致執行階段問題。
16 KB 頁面大小系統程式設計
在任何 Android 裝置上,絕大多數的程式碼都不會直接處理頁面大小。不過,如果是處理網頁的程式碼,核心的記憶體配置行為會有所不同,因此您必須留意這一點,才能編寫出不僅相容,而且效能最高、資源用量最少的程式碼。
如果您在 4 KB 系統上對 1 KB、2 KB 或最多 4 KB 的區域呼叫 mmap
,系統會保留 4 KB 來實作這項作業。換句話說,向核心要求記憶體時,核心一律會將要求的記憶體向上取整至最接近的頁面大小。舉例來說,如果您在 4 KB 區域上配置 5 KB 區域,核心會配置 8 KB。
在 16 KB 的核心中,這些額外的頁面「尾端」較大。
舉例來說,如果使用 16 KB 的核心,從 1 KB 到 5 KB 的所有配置都會配置 16 KB。如果您要求 17 KB,系統會分配 32 KB。
舉例來說,在 4 KB 系統上,可以分配兩個 4 KB 的讀寫匿名區域。不過,在 16 KB 核心上,這會導致分配兩個頁面或 32 KB。在 16 KB 核心上,如果可以,這些區域可以合併為單一可讀取或可寫入的頁面,這樣就只會使用 16 KB,與 4 KB 核心的情況相比,會浪費 8 KB。如要進一步減少記憶體用量,可以合併更多頁面。事實上,在經過最佳化處理的 16 KB 系統中,16 KB 頁面所需的記憶體比 4 KB 系統更少,因為相同記憶體的分頁表大小只有四分之一。
使用 mmap
時,請務必將要求的大小向上取整至最接近的頁面大小。這樣一來,核心分配的記憶體總量就會直接顯示在執行階段值中,而不是隱含要求,或隱含或意外可存取。
建構共用程式庫,並調整為支援 16 KB ELF
如要建構屬於 Android 專案的共用程式庫,啟用 16 KB 分頁大小中的先前設定就已足夠:
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384
如要建構不屬於 android 專案的共用程式庫,您需要傳遞這個連結器標記:
-Wl,-z,max-page-size=16384
確認二進位檔和預先建構的項目是否支援 16 KB ELF 對齊
如要驗證對齊方式和執行階段行為,最佳做法是在 16 KB 編譯核心上測試及執行。不過,為了及早發現某些問題,建議採取下列做法:
從 Android 16 開始,您可以在建構時設定 PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true
。在 Android.bp
中使用 ignore_max_page_size: true
,以及在 Android.mk
中使用 LOCAL_IGNORE_MAX_PAGE_SIZE := true
,暫時忽略這些項目。這些設定會驗證所有預先建構的項目,並在項目更新但未與 16 KB 對齊時偵測到。
您可以執行 atest elf_alignment_test
,驗證在搭載 Android 15 以上版本的裝置上啟動時,裝置上 ELF 檔案的對齊方式。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-08-17 (世界標準時間)。
[null,null,["上次更新時間:2025-08-17 (世界標準時間)。"],[],[],null,["# 16 KB page size\n\nPage size is the granularity at which an OS manages memory. Most CPUs today\nsupport a 4 KB page size and so the Android OS and apps have\nhistorically been built and optimized to run with a 4 KB page size. ARM\nCPUs support the larger 16 KB page size, and starting in Android\n15, AOSP has support for building Android with a\n16 KB page size as well. This option uses additional memory but improves\nsystem performance. As of Android 15, this option isn't\nenabled by default, but it is available as a developer mode or a developer\noption for OEMs and app developers to prepare for switching to 16 KB mode\neverywhere in the future.\n\nAndroid 15 and higher have support for building\nAndroid with a 16 KB ELF alignment, which works with 4 KB and\n16 KB kernels starting with\n[`android14-6.1`](https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1).\nWhen used with a 16 KB kernel, this configuration uses additional memory\nbut improves system performance.\n\nSet Android to 16 KB\n--------------------\n\n16 KB pages are only supported on `arm64` targets with 16 KB kernels.\nHowever, there is also an option to\n[simulate 16 KB userspace on `x86_64`](/docs/core/architecture/16kb-page-size/getting-started-cf-x86-64-pgagnostic) for Cuttlefish.\n\n### Kernel space\n\nFor `arm64` targets, if you use\n[Kleaf](https://android.googlesource.com/kernel/build/+/refs/heads/main/kleaf/docs/kleaf.md)\nto build your kernel, `--page_size=16k` builds the kernel in 16 KB mode.\nIf you are directly using Linux kernel configuration, you can select 16 KB\npages by setting `CONFIG_ARM64_16K_PAGES` instead of `CONFIG_ARM64_4K_PAGES`.\n\n### User space\n\nTo enable 16 KB page size support in Android user space, set the following\nbuild options on your product:\n\n- `PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true` removes the `PAGE_SIZE` define, and it makes components determine page size at runtime.\n- `PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384` which ensures platform ELF files are built with 16 KB alignment. This larger-than-needed size is for future compatibility. With 16 KB ELF alignment, the kernel can support 4 KB/16 KB page sizes.\n\nVerify build flags\n------------------\n\nAfter selecting the `lunch` target, verify that the build flags are set up\ncorrectly in the environment: \n\n $ source build/envsetup.sh\n $ lunch \u003cvar translate=\"no\"\u003etarget\u003c/var\u003e\n\n $ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED\n 16384\n $ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO\n true\n\nIf the previous two commands return `16384` and `true` respectively, your build\nflags are set up correctly to work with a 16 KB kernel. However, even if\na build passes, there might still be runtime issues due to differences in a\n16 KB environment.\n\n16 KB page size system programming\n----------------------------------\n\nThe vast majority of code on any Android-powered device doesn't directly deal\nwith page size. However, for code that deals with pages, the kernel's memory\nallocation behavior changes, and you need to keep this in mind to write code\nthat is not only compatible but also maximally performant and minimally\nresource intensive.\n\nIf you call `mmap` on a 1 KB, 2 KB, or up to a 4 KB region on a\n4 KB system, the system reserves 4 KB to implement this. In other\nwords, when requesting memory from the kernel, the kernel must always round up\nthe requested memory to the nearest page size. For example, if you allocate a\n5 KB region on a 4 KB region, the kernel allocates 8 KB.\n\nOn a 16 KB kernel, these extra \"tail ends\" of pages are larger.\nFor example, all of these allocations, from 1 KB to 5 KB would\nallocate 16 KB when used with a 16 KB kernel. If you request\n17 KB, it allocates 32 KB.\n\nFor example, on a 4 KB system, it's okay to allocate two 4 KB\nread-write anonymous regions. However, on a 16 KB kernel, this would result\nin allocating two pages or 32 KB. On a 16 KB kernel, if possible,\nthese regions can be combined into a single read or writeable page so that only\n16 KB is used, wasting 8 KB compared to the 4 KB kernel case. To\nreduce even more memory usage, more pages can be combined. In fact, on a\n16 KB system that is maximally optimized, 16 KB pages require less\nmemory than 4 KB systems because the page table is one fourth the size\nfor the same memory.\n\nWhenever using `mmap`, ensure that you round the size you are requesting up to\nthe nearest page size. This ensures that the entire amount of memory the kernel\nallocates is directly visible to userspace in runtime values, instead of being\nimplicitly requested and implicitly or accidentally accessible.\n\nBuild shared libraries with 16 KB ELF alignment\n-----------------------------------------------\n\nTo build shared libraries that are part of the\n[android project](https://cs.android.com/android/platform/superproject/main),\nthe earlier settings in [Enable 16 KB page size](#enable-16kb) are sufficient:\n\n- `PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true`\n- `PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384`\n\nTo build shared libraries that aren't part of\n[android project](https://cs.android.com/android/platform/superproject/main),\nyou need to pass this linker flag: \n\n -Wl,-z,max-page-size=16384\n\nVerify binaries and prebuilts for 16 KB ELF alignment\n-----------------------------------------------------\n\nThe best way to verify alignment and runtime behavior is to test and run on a\n16 KB compiled kernel. However, in order to catch some issues earlier:\n\n- Starting in Android 16, you can set\n `PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true` at build time. Use\n `ignore_max_page_size: true` in `Android.bp` and\n `LOCAL_IGNORE_MAX_PAGE_SIZE := true` in `Android.mk` to temporarily ignore\n them. These settings verify all prebuilts and allow you to detect when one\n is updated but is not 16 KB aligned.\n\n- You can run `atest elf_alignment_test` which verifies the alignment of\n on-device ELF files on devices launching with\n Android 15 and later."]]