来源：映维网 作者
现在Oculus Quest APK必须兼容ARM64，而Oculus开发者关系工程师Gabor Szauer日前撰文概述了64位之于32位的优势。下面是映维网的具体整理：
这篇博文探讨了切换到64位版本时的内存相关优势。尽管64位无法帮助你获得更多的物理内存，但改为64位有助于缓解内存压力，并使得应用程序的运行更加稳定。下面我们通过Android物理内存和虚拟内存之间的关系来解释原因。
Android操作系统为每个应用程序提供自己的内存视图，这就是所谓的虚拟内存。内存的虚拟视图与最大可寻址空间一样大。对于32位应用，这恰好是4GiB，物理内存量不会改变这一事实。
对于Quest，内存不分页到磁盘。这意味着可用的物理内存正用于备份当前运行应用的所有虚拟内存。所述物理内存恒定不变，不会因为切换到64位版本而有所不同。改变的是虚拟内存地址空间的大小。
接下来我们来谈谈共享代码。Android加载共享库一次，然后将它们链接到使用共享库的任何应用程序的虚拟地址空间中。例如，Quest视觉系统驻留在内存中一次，但会映射到使用所述视觉系统的每个应用程序的虚拟地址空间中。
示例场景
下面我们来看一个示例场景。假设我们有1GB的共享库代码映射到应用程序的虚拟地址空间中。这时，我们需要考虑三个重要事项。首先，我们假设有2.5GiB的物理内存可用；其次，应用程序具有4GiB虚拟地址空间，但映射到虚拟地址空间的共享代码已经用完了其中的1GiB；最后，虚拟地址空间视图与可用物理内存之间存在关系。这一示例开始的状态是3GiB可用虚拟内存视图，其中2.5GiB内存用于物理备份。
一个明显的问题是，应用程序认为存在3GiB的可用内存，但实际只有2.5GiB的可用物理内存。如果应用程序尝试分配超过2.5GiB的内存，届时将因为物理内存不足而崩溃。
假设应用程序最多分配2.5GiB，这时不会耗尽物理内存。如果应用程序可以线性分配与物理可用内存一样多的内存，这没有问题。但如果应用程序尝试大量分配（并且正在主动释放），则虚拟地址空间将变得碎片化。大多数应用程序会由于内存压力而崩溃，这是因为虚拟地址空间碎片化，而非因为缺少物理内存。
例如，假设有500MiB的虚拟地址范围可用，但分成100个不连续块（每块50MiB）。如果应用程序尝试分配75MiB，即便存在足够的物理内存来支持所述分配，并且虚拟地址空间具有500MiB的可用总内存，应用同样会崩溃。
对于64位版本，虚拟地址空间为18.4EB。这（几乎）消除了虚拟地址空间中的内存压力（内存碎片）。它简化了我们考虑内存的方式，因为最大的考量是用于支持18.4 EB虚拟地址空间的物理内存量。对于变成64位版本，这是一个非常重要的因素，因为你不再遇到虚拟地址空间碎片所带来的内存压力。
当然，上面只是简化的示例解释。碎片的数量不仅取决于应用程序的分配，而且涉及Android维护的各种堆。另一个问题是何时物理内存必须备份虚拟分配。但是，上面这个示例概述了64位版本在内存方面的优势（即使可用物理内存没有增加）。
若存在疑问，请在下方评论栏留下你的问题。
原文链接：https://yivian.com/news/70219.html
