android加载大图片列表，内存管理问题

这图得多大才能经常发生OOM。

试试这个？ https://github.com/davemorrissey/subsampling-scale-image-view

类似开眼的主界面那种,满屏大图,如果长时间浏览,查看大量内容一些手机好像会崩溃,虽然我没遇到过,不过有用户反映了.... 【 在 sollian 的大作中提到: 】 : 这图得多大才能经常发生OOM。

finish之后图片对象仍然被引用了？ 在finish之前显示的调用recycle试试。

试试fresco，再优化一下，应该可以的。

图片可以主动回收的，recycle()

【 在 cdls 的大作中提到: 】 : 是用了Glide和RecyclerView了进行优化了，为了追求图片质量，导致经常发生OOM，尤其是列表每一项点击进入的页面也有很多大图，但是详情界面finish之后发现内存并没有减少，求各位大神支招，如何内存优化和在Activity finish之后尽快释放资源 我谈谈个人的看法。 首先我想吐槽这个“为了追求图片质量，导致经常发生OOM”，即便你们想追求图片质量，但跟OOM并没有必然的联系吧，手机屏幕就这么小，一张大图原图比手机屏幕还大你硬要生成全尺寸bitmap没有意义啊，屏幕又放不下，所以这个不是OOM的锅是程序员的锅。 回到正题吧，最容易出现OOM的地方在从二进制文件变成bitmap对象的时候，因为bitmap对象的大小完全根据尺寸和RGB色值数据决定，最关键的是去做自适应，不要生成超过控件大小的图片bitmapFactory里面有方法这么干的，网上主要说的也都是这个。 google有专门讲这个的你可以去看看 https://developer.android.com/training/displaying-bitmaps/index.html? 其次就是释放资源的问题，都知道java的gc是不可控的，如果虚拟机认为这个资源还没到释放的时候它保持着也没关系，并不急着一定要finish就马上释放，但是如果虚拟机宁可OOM也不让内存降下来，就应该考虑并不是它不去释放，而是释放不了，这样你就该去考虑是不是内存泄露的问题了，你应该反复进出列表页和详情页，如果内存一直在升从来不下降，那肯定就是内存泄漏了，要从代码去找原因。 然后同意ls那些观点去使用那些优秀的图片加载控件，因为他们对bitmap生成和内存泄漏问题都做好了处理，这比你自己维护要好得多。 最后上面这些都是我编的