Android 15 适配之16K Page Size ：为什么它会是最坑的一个适配点
首先什么是 Page Size ？一般意义上，页面(Page)指的就是 Linux 假造内存管理中使用的最小数据单元，页面大小(Page Size)就是假造地址空间中的页面大小， Linux 中进程的假造地址空间是由固定大小的页面组成。https://img-blog.csdnimg.cn/img_convert/720dc6fa828081600924b69898402fad.png
Page Size
对于假造内存， CPU 的内存管理单元（MMU）会将假造地址转换为物理地址，以是假造内存最终也会映射到物理内存页面。
而为了实现假造内存到物理的映射，两个地址空间都会被分别为多个固定页面，而假造空间和物理空间中的页面需要大小雷同，通常长度为 4K，为了区分假造页面和物理页面，后者一般会被称为页框（page frames ）。
就是每个应用都有自己独特的假造地址空间，而且它永远也不要关心其他应用在做什么，占据了哪些真实地址，实际物理地址映射，是由 Linux 内核去管理和分配，假造内存也是为什么体系支持多应用同时运行的基础。
剩下的就很简单了，由于 Android 用的是 Linux 内核，以是在这部分逻辑一直以来都是遵循 Linux 的实现，只是 Android 由于「历史因素」限制，一直只支持 4 KB 内存页面大小，而现在为了优化体系内存性能，提高内存麋集型工作负载的性能，Android 15 开始将采用 16KB 页面大小的要求。
https://img-blog.csdnimg.cn/img_convert/1857fc3e49359e264ee1f352102a1c87.png
那前面说了那么多「无用的知识」，核心还是 Android 15 要启动 16K Page Size 了，对于我们来说有什么影响？
先说理论上的正面影响：
[*]体系面临内存压力时缩短应用启动时间：平均缩短 3.16%，某些应用的改进甚至高达 30%
[*]降低应用启动时的耗电量：平均淘汰 4.56%
[*]相机启动速度更快：热启动速度平均加快 4.48%，冷启动速度平均加快 6.60%
[*]改善体系启动时间：平均改善1.5%（约0.8秒）
那么负面影响是什么？你带有 .so 的 android 项目，很可能需要重新编译带有全新的动态库(.so) 才能正常运行对应功能，不然大概率会 crash 。
至于你的项目里有没有动态库，信任你应该很清晰，如果不清晰，直接把 apk 拖到 Android Studio ，看看 lib 下是否有 so 文件即可。
https://img-blog.csdnimg.cn/img_convert/1ec3c93ced154f169d4e1b628b076ffc.png
那为什么说用 Android 15 启动 16K Page Size 后，以往使用了 C/C++（native）代码的基本都会 crash 呢？这就是前面说到的 Linux 下 Page Size 的实现。
可能各人会以为，为什么不能有兼容层，将 4k 页面大小转换为 16k 页面大小？
理论上这是可行的，比如你可以使用假造化技术让 4K 的应用跑在 16K 主机上，但是想要体系直接混搭 Page Size 支持，是一个比力困难的事故。
前面我们知道，假造内存和物理内存之间存在映射，那么如果 CPU 处于 16K 模式，那么其实所有内容都会处于 16K 模式，简单不严谨的理解，这会是一个 CPU 全局寄存器设置的概念。
以是对于所有空间页面而言，在恣意时刻要么是 4K，要么是 16K ，页表结构在 4K 模式和 16K 模式下完全不同（每级页面、级数、屏蔽）。
这里扯一段额外的东西， Apple Silicon 的 MacOS 其实是有混淆 16K/4K 支持，事实上 macOS 本身始终以 16K 页面运行，只有 Rosetta 模式下应用会以 4K 模式运行：
我大概记得好像是，在 macOS 上，Rosetta 模式用户空间和内核空间的页面大小可以不同，不同的用户空间程序可以使用不同的页面大小运行。
由于 Linux 不支持混淆 Page Size，默认上 android 也不支持，除非 Android OS 层后续也做雷同 Rosetta 等处理。
如何检测
前面讲了那么多废话，各人肯定还是很关心，如何知道我的 App 是否支持 16K Page Size 运行。
固然带有陈年 .so 的很大概率不行，但是大概呢？
最简单且最实用的做法就是通过模拟器 VanillaIceCream 的 APIs Experimental 16k Page Size ARM 64 v8a System Image 进行测试。
https://img-blog.csdnimg.cn/img_convert/e4e4b68123254e7ffdb2d07326d8089a.png
根据自己的设备，如上图选择下载一个 VanillaIceCream 的 16k Page Size 的模拟器镜像，然后在 Other Images 选择下载的镜像创建模拟器。
https://img-blog.csdnimg.cn/img_convert/c09c485aaef142f7c301df79c05ff390.png
留意，这里干货来咯，由于老板本 AS 在 LLDB 调试 16 KB 模拟器体系映像会存在问题，以是至少需要下载一个 Android Studio Koala Feature Drop | 2024.1.2 Canary 5 ，就是如下图所示这个，带 Drop 版本的才能成功运行 16K Page Size 模拟器。
什么是 Drop 版本？可以参考：https://juejin.cn/post/7379816515551723546
https://img-blog.csdnimg.cn/img_convert/36a8f2b6b5086e1173a1d8c190ce3ab0.png
运行模拟器之后，通过 adb shell getconf PAGE_SIZE 可以获取到一个 16384 的值，说明体系现在已经是 16K 的模式。
https://img-blog.csdnimg.cn/img_convert/5402aa7a0f9dece02e8905a34c3497da.png
那么，我把 GSYVideoPlayer 运行到 16K 模拟器后，不出所料 IJK 内核无法正常播放。
https://img-blog.csdnimg.cn/img_convert/3ec9fe45171bad4477ae3423dedcbf97.png
另外，官方提供了一个 16 KB ELF 对齐脚原来验证共享库的 ELF 段是否正确对齐，如下脚本针对 GSYVideoPlayer 里的动态库进行校验后，输出却是比力不测。
#!/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
可以看到此时动态库是 ALIGNED 的，而且是 2**16 ，也就是 armv68a 的动态库此时的 ELF 对齐。
https://img-blog.csdnimg.cn/img_convert/b82b7599300a163464958a2cdf1996ca.png
另外，通过 sdk 的 build-tools/35.0.0 下的 zipalign 命令运行：
./zipalign -c -P 16 -v 4 /Users/guoshuyu/workspace/android/GSYVideoPlayer/app/build/outputs/apk/release/app-release.apk
可以看到此时的 apk 对齐也是没有问题的，以是此时的运行问题可能更多在于 C++ 代码里的 mmap 或者 sysconf 等代码存在问题，例如写死了 4096 等硬编码。
https://img-blog.csdnimg.cn/img_convert/ff234afad02b92353b3e55466cca29de.png
兼容
对于 LLDB 调试 16 KB 模拟器，需要 NDK r27 RC 1 的支持， 如果使用 r27 及以上的版本，那么只需要在 Application.mk 设置：
APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true
如果是 Android NDK r26 及更低版本 ，则需要在 Android.mk 启用 16 KB ELF 对齐 ：
LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
另外，构建支持 16 KB 设备的应用还需要 AGP 8.3 + 的支持，16 K 设备会要求附带未压缩共享库的应用将它们对齐到 16 KB 压缩对齐，为此升级到 Android Gradle 插件 (AGP) 版本 8.3+ 会是一个比力好的选择。
如果使用 AGP 版本 8.2或更低的版本，那么另一种选择是切换到使用压缩共享库
如果无法将 AGP 升级到 8.3 或更高版本，那么另一种选择是切换到使用压缩共享库：
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
也就是什么？适配的基础是重新编译 .so ，重新编译的基础是：
[*]NDK r27 推荐，NDK r26 及更低版本可以修改 max-page-size，固然太低是真不行，反正目前测试我的 NDK r10e 是有问额····
[*]AGP 8.3 + 推荐，低版本可以用 useLegacyPackaging
固然，重新编译只是基础，代码里使用了例如 mmap 或者硬编码 4096 的地方，都需要修改适配。
那么问题来了，老旧 .so 连源码都没有的环境下，是不是没救了？ 答案是肯定的，确实没救了，更糟心的是：谷歌筹划来岁将对 16k 设备的支持作为 Google Play 应用程序提交的必要条件。
本质上你的 .so可能已经是 16K 对齐，但是还存在逻辑适配问题。
以是逃是逃不开了，好消息是目前这是一个实验性的阶段，另一个好消息，那就是 Flutter 本身已经支持了 16k ，在测试里 Flutter 3.22 是可以在 16K 模拟器上正常运行，这一定程度也算不幸中的万幸了。
https://img-blog.csdnimg.cn/img_convert/f378393cd516441043f4d3081239f568.png
https://img-blog.csdnimg.cn/img_convert/71547aff48706f652db81a867fbc1707.png
https://img-blog.csdnimg.cn/img_convert/031022d4fbaafebd402198975b6c7ce8.png
末了
以是心凉了没？从目前看，基于 Linux 内核下的 16K Page Size 很大可能不支持 4K Page Size 的 C/C++ native 代码，以是可以遇见的环境有这么几种：
[*]Android OS 最终落地了混淆 Page Size 支持
[*]重新编译和修改 .so 支持 16K
以是各人以为会是怎么样的一个结果？
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]