认证0级讲师
用glide等图片框架呢?会自动压缩图片的 可能会好一点
我也碰到过,没有完全避免,但是可以尽量1.本地图片加载适量压缩
InputStream is = this.getResources().openRawResource(R.drawable.pic1); BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = false; options.inSampleSize = 10; // width,hight设为原来的十分一 Bitmap btp = BitmapFactory.decodeStream(is, null, options);
2.在application中加上:
android:largeHeap="true" android:hardwareAccelerated="true" 这样可以使用更大的内存,而不会报错
当然最根本的解决方法是在适当的时候回收内存。比如你说的滑动界面,可以在适配器中做判断,不显示的界面就让图片回收,滑动显示的时候重新加载
单图一般不会OOM吧,多图的话不需要高清的。大量的高清图不好处理,尽量用异步加载、压缩(压缩以后也就不算高清了)、多回收、滑动暂停加载。
没必要在同一个界面用大量高清图片, 最好不要超过 View 的大小了, 不然也没什么意义,
然后可以选择降低一些质量来减少占用...
然后再做其他操作的时候有选择得回收一下内存吧...
glide略优于Picasso(glide根据Picasso改进的),如果是大量使用图片的APP,可是用是Fresco,FaceBook的黑科技,图片缓存另外自己开辟的内存空间,吊炸天。(还有一些预加载模糊图片之类的,不过用起来稍微有点麻烦,个人感觉,因为要给图片至少一个明确的高度或宽度值,不然两个wrap_content不显示)
简单的做法,把图片格式转成webp,图片的质量没多少下降,但是图片的体积大大变小
用glide等图片框架呢?会自动压缩图片的 可能会好一点
我也碰到过,没有完全避免,但是可以尽量
1.本地图片加载适量压缩
2.在application中加上:
当然最根本的解决方法是在适当的时候回收内存。比如你说的滑动界面,可以在适配器中做判断,不显示的界面就让图片回收,滑动显示的时候重新加载
单图一般不会OOM吧,多图的话不需要高清的。大量的高清图不好处理,尽量用异步加载、压缩(压缩以后也就不算高清了)、多回收、滑动暂停加载。
没必要在同一个界面用大量高清图片, 最好不要超过 View 的大小了, 不然也没什么意义,
然后可以选择降低一些质量来减少占用...
然后再做其他操作的时候有选择得回收一下内存吧...
glide略优于Picasso(glide根据Picasso改进的),如果是大量使用图片的APP,可是用是Fresco,FaceBook的黑科技,图片缓存另外自己开辟的内存空间,吊炸天。(还有一些预加载模糊图片之类的,不过用起来稍微有点麻烦,个人感觉,因为要给图片至少一个明确的高度或宽度值,不然两个wrap_content不显示)
简单的做法,把图片格式转成webp,图片的质量没多少下降,但是图片的体积大大变小