这是一个创建于 443 天前的主题，其中的信息可能已经有所发展或是发生改变。
虽说目的是提升性能，但感觉为了这个提升(Google 自己的数据都没 10%)修改的代价有点大啊：
- 原生库需要重新编译，可能需要修改代码以支持动态页大小，代码段需要 16K 对齐
- 16K 页表只能全局启用，不允许 4K 页应用与 16K 页应用混合运行，因为 Linux 不支持
- 只有高版本 NDK 和 AGP 支持，版 NDK 不一定能通过改链接选项实现兼容
考虑下收益，感觉完全看不到能推下去的可能性，哪怕有是 Play 市场来推，要求升级 NDK 可比升级 Target 难多了。
 | 1 seers 2024-09-16 01:54:13 +08:00 应该是为了匹配越来越大的 ram ，不然怎么看都像是小马拉大车，只能说战未来了 |
 | 2 kenvix 2024-09-16 02:08:15 +08:00 via Android  2 难评，x86 高性能计算这么多年来了还是 4K 页，不知道为什么嵌入式反而这么积极 |
 | 3 billccn 2024-09-16 02:45:16 +08:00 3 @seers 应该和内存大小无关，服务器是手机几十倍内存还不都是 4k page 。因为 page table 是多层的，所以可容纳的页面数量一般超过 CPU 的硬件寻址限制。 Android 推这个应该是处于功耗的考虑，因为页面变成 4 倍大，那 page fault 可能就会变成原来的 1/4 概率。另外大多数 Android 设备的 swap 不是硬盘，而是 zRAM ，压缩解压也挺费电的，操作次数越少越好咯。我想 16K 的压缩比可能也比 4K 好一点 |
 | 4 ziseyinzi 2024-09-16 06:07:44 +08:00 就是实验性支持一下吧，为 Android 25 做铺垫。 |
 | 5 ysc3839 2024-09-16 06:42:17 +08:00 via Android 感觉是跟苹果的风 |
 | 6 imluvian 2024-09-16 08:41:35 +08:00 via Android 1 这是给汽车用的。汽车上要开 inline ecc ，能差很多。 |
 | 7 lumyx 2024-09-16 12:47:48 +08:00 面向未来，15 也不是强制打开的。开发者模式才能打开，估计至少得 5 年-8 年才能慢慢强制。可以参考 32 位- 64 位 app 的过度时间 |
 | 8 Flyfish233 2024-09-16 18:04:20 +08:00 via Android 我有个应用虽然东西多，但是用的都是开源库，自己扒拉扒拉已经可以正常使用 16k page ，有个开发者问我怎么搞不了，我让他发 Libchecker ，一看用了一个华为闭源库。我认为国内会很难推广，而且这个不一定像 64 位这么好推了 |
 | 9 jim9606 OP 2 |
 | 10 V28a19cc 2024-09-17 00:29:19 +08:00 1 目前是零收益，因为目前切换 4K/16K 需要格式化 data 。 |
 | 11 Metre 2024-09-17 10:12:12 +08:00 1 这几年 arm 的 linux 的 64K page_size 已经把我适配吐了 |
 | 12 R4rvZ6agNVWr56V0 2024-09-17 15:43:13 +08:00 一方面为了匹配更大的内存需求，另一方面提升内存管理效率：16KB 页面大小比 4KB 大 4 倍， 意味着内存管理单元(MMU)需要处理的页面表项减少了 4 倍，Android 性能和效率方面将会获得显著提升。 |
|
Select Language