最佳使用BitmapFactory.Options.inSampleSize来提高速度

感谢Schermvlieger在anddev.org上提出这个问题，

我只是将他的问题复制到SO，因为没有人在其他网站上回复，我也面临同样的问题。

我想知道BitmapFactory.Options.inSampleSize在显示图像的速度方面会有什么最佳用途。
文档提到使用2的幂的值，所以我正在使用2,4,8,16等。

我想知道的是：

我应该重新采样到仍然大于屏幕分辨率的最小尺寸，还是应该采样到足以避免OutOfMemoryError的尺寸？
如何在不耗尽内存的情况下计算仍可显示的图像的最大尺寸？图像的颜色深度是否也起作用，显示的深度是什么？
通过两种机制显示图像是否有效（大文件的BitmapFactory ，较小的文件的setImageURI() ）我顺便使用ImageSwitcher 。
它是否有助于在应用程序开始时创建Bitmap ， BitmapFactory.Options和inTempStorage ，或者只在需要时动态创建它们？

Solutions Collecting From Web of "最佳使用BitmapFactory.Options.inSampleSize来提高速度"

您应该始终尝试加载和预缩放图像，使它们尽可能接近最终显示的大小。在绘图时缩放图像非常昂贵，应该不惜一切代价避免。

考虑到图像的内存成本，是的，颜色 – deptch起着非常重要的作用。 ALPHA_8格式的图像每像素使用1个字节，RGB_565或ARGB_4444中的图像使用每个像素2个字节，ARGB_8888中的图像使用每个像素4个字节。显示器的深度根本不重要。你应该总是尝试使用ARGB_8888来获得最好的质量，但如果你的图像是不透明的，那么565就足够了。

你提出了很好的问题，但这一切都取决于你的需求和你使用的内存量。我建议您查看此链接以获取有关位图的许多提示： http ： //developer.android.com/training/displaying-bitmaps/index.html 。

简而言之，您应该考虑缓存，下采样，并尽可能使用足够好的位图格式。

这是我对你的问题的回答：

为什么不兼得？如果您认为可能有OOM，请尝试回收旧的未使用的位图，然后再次检查。
你可以计算位图的（估计）大小：

宽度×高度×bytesPerPixel

其中bytesPerPixel通常为4或2（取决于位图格式）。
从未使用过setImageURI，所以我无法帮助你。我建议在后台线程中下载图像（使用asyncTask是一种方法）并在它准备好时显示它们。
如果只有少数你知道不会占用大量内存，我想这没关系。我仍然认为缓存可能会更好。

在这里你可以调用用户定义的方法shrinkmehtod实际发送字符串文件路径和高度和宽度为reduce image to method。

  Bitmap bit=shrinkmethod(arrpath1[position], 100, 100); //iv.setImageURI(Uri.parse(arrpath1[position])); iv.setImageBitmap(bit);

这是用户定义的方法，以编程方式减小图像的大小。

 Bitmap shrinkmethod(String file,int width,int height){ BitmapFactory.Options bitopt=new BitmapFactory.Options(); bitopt.inJustDecodeBounds=true; Bitmap bit=BitmapFactory.decodeFile(file, bitopt); int h=(int) Math.ceil(bitopt.outHeight/(float)height); int w=(int) Math.ceil(bitopt.outWidth/(float)width); if(h>1 || w>1){ if(h>w){ bitopt.inSampleSize=h; }else{ bitopt.inSampleSize=w; } } bitopt.inJustDecodeBounds=false; bit=BitmapFactory.decodeFile(file, bitopt); return bit; }

我希望这会帮助你减小尺寸。