Oculus简述64位Quest App的优势,相比32位可大大缓解内存压力

砍柴网  •  扫码分享
我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

来源:映维网  作者  广州客

现在Oculus Quest APK必须兼容ARM64,而Oculus开发者关系工程师Gabor Szauer日前撰文概述了64位之于32位的优势。下面是映维网的具体整理:

Oculus简述64位Quest App的优势,相比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

随意打赏

提交建议
微信扫一扫,分享给好友吧。