关于最大堆大小和Android的可用内存的两个问题 [英] Two questions about max heap sizes and available memory in android

问题描述

我认为这是应用程序需要它，到任何手机的最大堆大小是堆大小自动增加。我还看到，最大堆大小是根据不同的设备上。

I see that the Heap Size is automatically increased as the app needs it, up to whatever the phone's Max Heap Size is. I also see that the Max Heap Size is different depending on the device.

所以，我的第一个问题是，什么是典型的最大堆大小在Android设备上？我曾经在一个手机，能够使用堆了40MB，而另一个给出了在20年代MBS内存溢出错误测试的内存分配。什么是普遍使用的，什么是最高的是上常见的设备最低？有没有一个标准或平均？

So my first question is, what are the typical Max Heap Sizes on Android devices? I have tested memory allocation on one phone that was able to use a heap over 40mb while another gave out OutOfMemory errors in the 20's mbs. What are the lowest that are in common use and what are the highest that are on common devices? Is there a standard or average?

第二个问题，更重要的，是如何保证你能够使用每个器件的可用资源，但避免使用太多了？我知道有一些方法，如onLowMemory（），但这些似乎只对整个系统的内存，而不只是堆为特定应用程序。

The second question, and more important one, is how to ensure you are able to use the resources available per device but avoid using too much? I know there are methods such as onLowMemory() but those seem to be only for the entire system memory, not just the heap for your specific application.

有没有一种方法来检测最大堆大小的设备，也检测时，可用堆内存达到最低点为您的应用程序？

Is there a way to detect the max heap size for the device and also detect when the available heap memory is reaching a low point for your application?

例如，如果该设备只允许24MB的最大堆和应用程序已接近了极限配置，那么它可以检测并缩减。但是，如果该装置可以舒适地处理更多的，这将是能够利用什么是可用的优点

For example, if the device only allowed a max heap of 24mb and the app was nearing that limit in allocation, then it could detect and scale back. However, if the device could comfortably handle more, it would be able to take advantage of what is available.

感谢

推荐答案

早期的设备有每个应用程序上限为16MB。更高版本的设备增加，为24MB。未来的设备将可能有更多的可用。

Early devices had a per-app cap of 16MB. Later devices increased that to 24MB. Future devices will likely have even more available.

的值是物理存储器的可用的反射的设备上和在显示装置的性能（因为能够显示更多的颜色的屏幕更大，通常需要更大的位图）。

The value is a reflection of the physical memory available on the device and the properties of the display device (because a larger screen capable of displaying more colors will usually require larger bitmaps).

编辑：其他沉思...

我读到一篇文章不是不久前，指出垃圾收集分配器基本上是模拟一台具有无限怀念。只要你想，你可以分配尽可能多的，它会采取的细节。 Android的大多是这种方式工作;你把你所需要的东西硬引用，软/弱引用来的东西你可能没有，并丢弃提到你再也不需要再次东西。在GC排序这一切了。

I read an article not too long ago that pointed out that garbage-collecting allocators are essentially modeling a machine with infinite memory. You can allocate as much as you want and it'll take care of the details. Android mostly works this way; you keep hard references to the stuff you need, soft/weak references to stuff you might not, and discard references to the stuff you'll never need again. The GC sorts it all out.

在您的特定情况下，你会使用软引用来保持周围的东西，你不这样做的需要的有内存，但想保留，如果有足够的空间。

In your particular case, you'd use soft references to keep around the things that you don't need to have in memory, but would like to keep if there's enough room.

这开始与位图开回落，主要是因为，导致外部分配机制，一些早期的设计决策。此外，软引用机制需要一些调整 - 最初版本倾向于要么把一切都还是放弃一切

This starts to fall apart with bitmaps, largely because of some early design decisions that resulted in the "external allocation" mechanism. Further, the soft reference mechanism needs some tuning -- the initial version tended to either keep everything or discard everything.

在Dalvik的堆正在积极发展。（例如在Android 2.3的音符姜饼，它引入了一个并发GC），所以希望这些问题将在以后的版本中得到解决。

The Dalvik heap is under active development (see e.g. the notes on Android 2.3 "Gingerbread", which introduces a concurrent GC), so hopefully these issues will be addressed in a future release.

编辑：更新...

外部分配机制，走在4.0（冰淇淋三明治）。位图的像素数据现在被保存在Dalvik的堆，避免了早期的烦恼。

The "external allocation" mechanism went away in 4.0 (Ice Cream Sandwich). The pixel data for Bitmaps is now stored on the Dalvik heap, avoiding the earlier annoyances.

最近的设备（如Nexus的4）第堆大小在96MB以上。

Recent devices (e.g. the Nexus 4) cap the heap size at 96MB or more.

的应用程序的内存限制的一般意义上的存储类中获得，从 ActivityManager.getMemoryClass（）。更具体的值可以从 java.lang.Runtime中的函数可以了 maxMemory（）。

A general sense of the app's memory limits can be obtained as the "memory class", from ActivityManager.getMemoryClass(). A more specific value can be had from the java.lang.Runtime function maxMemory().

这篇关于关于最大堆大小和Android的可用内存的两个问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！