认证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,圖片的品質沒多少下降,但是圖片的體積大大變小