zoukankan      html  css  js  c++  java
  • Windows Phone内存管理的演变[E800]

    【e800编译】在这篇文章里,笔者从宏观的角度进行阐述,这样你就能了解使用指导背后的原因,并在Windows Phone内存管理方法演化的同时确保应用能正常使用。下面是参考表格:

    版本

    设备

    最小容量

    最大容量

    分页

    WP OS 7.1

    所有

    90M

    可变

    WP SDK 7.1.1更新

    256MB

    90M

    110M

    从55M开始

    WP SDK 7.1.1更新

    大于等于512MB

    90M

    可变

    历史

    WP OS 7.0和7.1, 应用仅限于90M内存。不过应该或许可以使用的容量会超过90M。90M是最小值。至于最大值,有些程序员认为WP应用没有内存限制,可用内存大于90M。事实上,应用经常会问鼎——因为极值不是恒定的。应用可消耗的内存可以一直处于90M以上,而且从某种程度上说,分配可能会失败。对于一个受托管的应用而言,是通过一个OutOfMemoryException(OOM)在表面实现。

    触发OutOfMemoryException又对其进行处理的应用就会终结。确切地说,应用何时达到这个可变值的顶部取决于系统内部的运行情况。手机里面的资源管理器组件管理着应用内存,但并不能管理OS本身,因此可供应用使用的内存量是变化的:一般最少是90M,有时会更多,有时则不会。这种可用量的不可预见性很难应付。我们在现有WP Store目录上的数据显示大部分应用都不会在90M之内。这就是说,有些应用会超出90M

    WP7.1.1发布后,应用内存顶峰值会更有意思。90M是唯一的保证。而WP7.1.1的分页也很有意思。现在,OS通常都可以分页,但是它此前并不在手机中。因为分页比较耗时,会影响UX,最终还可能降低闪存的作用。

    分页是台式机和服务器电脑中很普遍,但是在移动设备中不常见。分页可以让系统分配更多内存。它是通过使用闪存页面文件来实现。在WP 7.1.1上,应用可以分配到110M的虚拟内存。如果应用只使用5060M内存,那么所使用的内存都是物理内存。如果应用的内存消耗超过了所分配的值,那么可在页面文件中获得额外的虚拟内存。应用执行过程中,页面文件以外的代码和数据会根据需要分页或移出分页。

    移入移出分页很耗时间,而且页面写入会导致闪存设备的磨损。过量的页面写入最终会导致闪存损耗。设备的整体性能降级,应用的OOM会加剧。7.1.1中的一个挑战在于指出最佳分页值,这样我们就不会在设备的预计生命周期中出现闪存性能降低。

    7.1.1中引入分页的目的是满足低内存设备的需要。全球对能满足最低使用需要且可用内存低的手机的需求很大。即便没有详细了解详细信息,你也可以做下简单计算:

    物理内存总量

    256

    Modem

    30

    图像

    40

    OS

    50

    设备驱动,系统范围,页面池,系统缓存等

    40

    背景音频,各种缓冲

    40

    合计

    200

    剩余内存

    56

    如果在WP OS 7.1内存模式下所有程序员都坚守指导不超过90M,在

    没有分页的情况下,大部分现有应用在256M设备上运行时都会出现过多的OOM。注意这是基于应用使用图表,其中大部分应用都适合55M的物理内存,而且90%以上的都适合90M。此外,即便应用出现消耗90M的情况,也不会一直停留在此状态。这就是说,大多数时候应用没有分页。分页值让我们可以保留对现有WP Store目录的支持,与此同时还可以产生可预计的,平衡的整体UX

    7.1.1分页模式允许应用内存占用量达到110M,但是可用量是固定的。在256M设备上,超过110M通常会出现OOM。运行于高内存设备的相同应用或许可以超过110M,尽管现在这一点并没有保障。

    从大的角度来说,这意味着现有目录的大量应用可以在所有已知设备上顺利使用。最重要的是,应用在大于256M内存的设备上使用效果更佳,因为应用或许大多数情况下回有更多可用内存,而不局限于110M

    程序员的选择

    现在,你知道WP OS7.x 的内存管理的合理量,那么你能做的是什么呢?有两个选择:

    第一个选择是让应用适应90M,这样它就可以在所有设备上使用。有很多支持平台API的技术可供你调整应用。当然,你可以使用Visual Studio 缓存分析器来监控应用运行时的性能。如果你不适合90M,但是适合110M,那就可以在所有设备上使用。只是你的UX可能会因为分页而不能在256M设备上运行良好。API赋予了你足量的工具来调整应用,或许可以通过有条件地在有较高内存的设备上启用子集的功能来调节。

    如果在调节和有条件禁用某些性能后仍无法适应110M,还可以换另一个选择。首先,编辑应用找到导致内存消耗大于110M的代码路径。如果用户只是偶尔出现这一问题,那还处于可接受范围。如果经常发生,就要从较低内存设备给应用降级。记住:低内存设备尤为重要。如果你不能应用是否可用于低内存设备,就要将其清理出智能手机应用市场。

    关于未来

    分页是用来支持设备上的最大应用量。其代价是稍稍削弱性能。但即便如此,用户还是难以察觉的。

    那么此后的策略应该是什么呢?在WP 8中,OS不再是Windows CE,取而代之的是共享Windows 8的常用代码库。当然Window 8会使用分页。这是否意味着我们将在WP 8中使用分页呢?此策略从7x之后就没有改变过:OS可以分页,我们也愿意使用分页。目的只是支持所有设备上的应用,而不会对UX产生无法预料的副作用。

    如你最近能从诺基亚和HTC要推出的新型WP8 手机,包括720p1280*720)或WXGA1280*768)的广告中看到的。如果你想一想,就会发现更高的分辨率需要消耗更多内存。7x仅支持WVGA800*480),如果你升级7x系统的应用来获取更高分辨率的图像,现有的图像也可以扩展。现有的7x应用将在WP8上占用更多内存。此刻,虽然无法对WP8上应用的运行细节进行预测,但是由于对于7x过度到WP 8的思考已有时日,所以不用太担心。

    原文链接:http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/10/08/the-evolution-of-windows-phone-memory-management.aspx

  • 相关阅读:
    Ubuntu 16.04远程登录服务器--ssh的安装和配置
    设置淘宝源
    shell 循环 read line
    apt-get update 报错 W: Unknown Multi-Arch type 'no' for package 'compiz-core'
    expdp dblink
    ubuntu apt-update NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
    listener.log文件过大导致oracle假死
    rsync_ssh
    ssh多主机
    elk大纲
  • 原文地址:https://www.cnblogs.com/Yukang1989/p/2828138.html
Copyright © 2011-2022 走看看