考虑到内存有限，我该如何优雅地降低我的表现？

Question

我花了最近几天试图去除我游戏中的内存泄漏，导致许多内存不足错误。我即将添加大量的图形，虽然不是非常复杂，但会显着增加我系统的处理需求，而且我有点担心我的内存使用情况，并且我希望有人可能拥有给我一些提示。我不想低于Android 2.1，所以请为此定制任何答案。

首先，我的游戏包括：

1. 2个活动，13个XML文件（有些涉及到布局，一些对话的一小部分，和2个直接相关的活动
2. 一在Adobe Illustrator中制作并转换为PNG的绘图数量可能很大，但并不特别大，在大多数情况下，在任何给定的时间内，只有少量的内存在内存中。
3. 相当多的对话框。
4. 针对Android 1.6及以上版本
5. 我使用了最新的Admob，因此我必须针对3.2构建。
6. 我的模拟器默认堆大小约为24 MB。

从我的游戏范例图片：

我学到的东西：

1. 尽管我的总应用程序大小只有大约500K，我以某种方式占用了24 Megs，按adb shell procrank计算。
2. 我做了相当多的优化，但没有看到内存的大幅增加。
3. 使用工具来查找堆中的内容通常只显示大约7 MB的可用空间，使用大约3 MB。有时，在打开新的对话框之类的时候，我看到了一个增加，但我不能说我看到它全是那么大......
4. MAT表明我的任何类都没有使用异常大的内存。

因此，考虑到所有这些，我的问题。

1. 是24 Mb的发展到（1.6 + Android）的实际要求？
2. 假设它是这样的，我怎么能够为可以处理它的系统提供更好的图形，但是不会为较老的系统崩溃和烧毁？
3. 什么是我可以用来改善我的记忆使用率的一些常见陷阱？

Answer 1

没有看到您的实际代码，我不能说以下将与您是否相关。但是，这是值得一试的。

如果你还没有这样做，你可以考虑使用一种叫做LruCache的东西。http://developer.android.com/reference/android/util/LruCache.html

使用此工具，您可以确定您的缓存对象（例如Bitmaps）将在什么时间点符合垃圾回收的条件。所以，如果你想将它设置为4mb（例如），操作系统会在它试图超越它时处理它。 （请参阅文档中的实现细节和一个很好的例子）。

唯一的缺点是，那只小宝石只能与3.2一起出现，因此您必须在AndroidManifest中创建您的最小SDK，或者在运行时以api级别进行编程检查，以确定您是否可以使用它。 Pre 3.2我会说你需要在你使用的任何Bitmap上调用recycle（），但是如果你已经优化了，我会认为你已经在做这件事了。

这是关于堆和本机内存之间区别的一个很好的小片段。 http://code-gotcha.blogspot.com/2011/09/android-bitmap-heap.html它可能（取决于你在做什么）帮助你理解为什么你没有看到你期待的记忆力下降。

最后又用堆大小打交道时，以及这个职位从SO应该有所帮助： Detect application heap size in Android

希望有所帮助。