blocks|key|999528|text|在位图创建过程中避免OOM的最佳方法，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|999529|http://developer.android.com/training/displaying-bitmaps/index.html|offset|length|999530|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1V|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Best way to avoid OOM during Bitmap creation,

<a href="http://developer.android.com/training/displaying-bitmaps/index.html" rel="nofollow">http://developer.android.com/training/displaying-bitmaps/index.html</a>

blocks|key|999576|text|一般来说，您不应该使用System.gc()显式调用GC。甚至还有IO讲座(http://www.youtube.com/watch?v=_CruQY55HOk)，在那里他们解释了GC暂停日志的含义，并且还声明永远不要调用System.gc()，因为Dalvik比您更清楚何时调用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|999577|另一方面，正如在上面的回答中提到的，Android中的GC过程(就像其他任何东西一样)有时会有buggy。这意味着Dalvik+GC算法无法与Hotspot或JRockit+JVM相提并论，在某些情况下可能会出错。其中一种情况是分配位图对象。这是一个棘手的问题，因为它使用堆和非堆内存，而且在内存受限的设备上，一个松散的位图对象实例就足以给出一个OutOfMemory异常。因此，在不再需要这个位图之后调用它通常是许多开发人员的建议，甚至被一些人认为是很好的做法。|999578|一种更好的做法是在位图上使用.recycle()，因为它就是这个方法的用途，因为它将位图的本机内存标记为可以安全删除。请记住，这非常依赖于版本，这意味着在较早的Android版本(我认为是3.0之前)上通常会需要它，但在以后的版本中不会需要。此外，在较新的版本上使用它也不会有太大影响(只是不要在循环或类似的东西中这样做)。新的艺术运行时在这里改变了很多，因为他们为大对象引入了一个特殊的堆“分区”，但我认为用艺术以太做这件事不会有太大伤害。|999579|关于System.gc()还有一个非常重要的注意事项。此方法不是Dalvik+(或JVM)必须响应的命令。考虑一下，这更像是对虚拟机说：“如果不麻烦的话，你可以做垃圾收集吗？”|999580|entityMap|0|LINK|mutability|MUTABLE|url|http://www.youtube.com/watch?v=_CruQY55HOk^0|12|16|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Generally speaking, you should not call GC explicitly with System.gc(). There is even the IO lecture (<a href="http://www.youtube.com/watch?v=_CruQY55HOk" rel="nofollow noreferrer">http://www.youtube.com/watch?v=_CruQY55HOk</a>) where they explain what the GC pauses log mean and in which they also state to never call System.gc() because Dalvik knows better than you when to do so.
On the other hand, as mentioned in the above answers already GC process in Android (like everything else) is sometimes buggy. This means Dalvik GC algorithms are not on par with Hotspot or JRockit JVMs and might get things wrong on some occasions. One of those occasions is when allocating bitmap objects. This is a tricky one because it uses Heap and Non-Heap memory and because one loose instance of bitmap object on the memory-constrained device is enough to give you an OutOfMemory exception. So calling it after you don't need this bitmap any more is generally suggested by many developers and is even considered good practice by some people.
A better practice is using .recycle() on a bitmap as it is what this method is made for, as it marks native memory of the bitmap as safe to delete.
Keep in mind that this is very version dependent, meaning it will generally be required on older Android versions (Pre 3.0 I think) but will not be required on later ones. Also, it won't hurt much using it on newer versions either (just don't do this in a loop or something like that). New ART runtime changed a lot here because they introduced a special Heap &quot;partition&quot; for big objects but I think it will not hurt much to do this with ART ether.
Also one very important note about System.gc(). This method is not a command that Dalvik (or JVMs) are obligated to respond to. Consider it more like saying to Virtual machine &quot;Could you please do garbage collection if it's not a hassle&quot;.

blocks|key|999603|text|我的应用程序管理了很多图片，但它死于OutOfMemoryError。这对我很有帮助。在Manifest.xml中添加|type|unstyled|depth|inlineStyleRanges|entityRanges|data|999604|<application
....
+++android:largeHeap="true">+|code-block|syntax|javascript|999605|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

My app manage a lot of images and it died with a OutOfMemoryError.
This helped me.
In the Manifest.xml
Add 

<pre><code>&lt;application
....
 android:largeHeap="true"&gt; 
</code></pre>

blocks|key|1213866|text|似乎System.gc()不能在Art+Android6.0.1Nexus5x上工作，所以我用Runtime.getRuntime().gc();代替。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1213867|entityMap^0|2|B|1B|Q|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

It seems <code>System.gc()</code> do not work on Art Android 6.0.1 Nexus 5x, So I use <code>Runtime.getRuntime().gc();</code> instead.

I have seen many Android answers that suggest calling the garbage collector in some situations.

Is it a good practice to request the garbage collector in Android before doing a memory-hungry operation? If not, should I only call it if I get an <code>OutOfMemory</code> error?

Are there other things I should use before resorting to the garbage collector?

Garbage collector in Android

虚拟机

Android

我看过很多Android回答，建议在某些情况下调用垃圾收集器。在执行耗用内存的操作之前，在Android中请求垃圾收集器是一种好的做法吗？如果不是，我应该只在收到OutOfMemory错误时才调用它吗？在求助于垃圾收集器之前，有没有其他我应该使用的东西？

问Android中的垃圾收集器
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android中的垃圾收集器EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android中的垃圾收集器
EN