高效使用Bitmaps（一） 大Bitmap的加载

转载：http://my.oschina.net/rengwuxian/blog/182885

高效使用Bitmaps有什么好处？

我们常常提到的“Android程序优化”，通常指的是性能和内存的优化，即：更快的响应速度，更低的内存占用。Android程序的性能和内存问题，大部分都和图片紧密相关，而图片的加载在很多情况下很用到Bitmap（位图）这个类。而由于Bitmap自身的特性（将每个像素的属性全部保存在内存中），导致稍有不慎就会创建出一个占用内存非常大的Bitmap对象，从而导致加载过慢，还会有内存溢出的风险。所以，Android程序要做优化，Bitmap的优化是必不可少的一步。

需要对Bitmap进行优化的情形

首先请看一行代码：

?


1

mImageView.setImageResource(R.drawable.my_image);

这是一行从资源文件中加载图片到ImageView的代码。通常这段代码没什么问题，但有些情况下，你需要对这段代码进行优化。例如当图片的尺寸远远大于ImageView的尺寸时，或者当你要在一个ListView或GridView中批量加载一些大小未知的图片时。实际上，以上这行代码会在运行时使用BitmapFactory.decodeStream()方法将资源图片生成一个Bitmap，然后由这个Bitmap生成一个Drawable，最后再将这个Drawable设置到ImageView。由于在过程中生成了Bitmap，因此如果你使用的图片过大，就会导致性能和内存占用的问题。另外，需要优化的情形不止这一种，这里就不再列举。

下面分步说明使用代码来减小Bitmap的尺寸从而达到减小内存占用的方法：

1. 获取原图片尺寸

通常，我们使用BitmapFactory.decodeResource()方法来从资源文件中读取一张图片并生成一个Bitmap。但如果使用一个BitmapFactory.Options对象，并把该对象的inJustDecodeBounds属性设置为true，decodeResource()方法就不会生成Bitmap对象，而仅仅是读取该图片的尺寸和类型信息：

?


1

2

3

4

5

6

BitmapFactory.Options options = new BitmapFactory.Options();

options.inJustDecodeBounds = true;

BitmapFactory.decodeResource(getResources(), R.id.myimage, options);

int imageHeight = options.outHeight;

int imageWidth = options.outWidth;

String imageType = options.outMimeType;

2. 根据原图尺寸和目标区域的尺寸计算出合适的Bitmap尺寸

BitmapFactory.Options类有一个参数inSampleSize，该参数为int型，他的值指示了在解析图片为Bitmap时在长宽两个方向上像素缩小的倍数。inSampleSize的默认值和最小值为1（当小于1时，解码器将该值当做1来处理），且在大于1时，该值只能为2的幂（当不为2的幂时，解码器会取与该值最接近的2的幂）。例如，当inSampleSize为2时，一个2000*1000的图片，将被缩小为1000*500，相应地，它的像素数和内存占用都被缩小为了原来的1/4：

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

public static int calculateInSampleSize(

            BitmapFactory.Options options, int reqWidth, int reqHeight) {

    // 原始图片的宽高

    final int height = options.outHeight;

    final int width = options.outWidth;

    int inSampleSize = 1;

    if (height > reqHeight || width > reqWidth) {

        final int halfHeight = height / 2;

        final int halfWidth = width / 2;

        // 在保证解析出的bitmap宽高分别大于目标尺寸宽高的前提下，取可能的inSampleSize的最大值

        while ((halfHeight / inSampleSize) > reqHeight

                && (halfWidth / inSampleSize) > reqWidth) {

            inSampleSize *= 2;

        }

    }

    return inSampleSize;

}

3. 根据计算出的inSampleSize生成Bitmap

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,

        int reqWidth, int reqHeight) {

    // 首先设置 inJustDecodeBounds=true 来获取图片尺寸

    final BitmapFactory.Options options = new BitmapFactory.Options();

    options.inJustDecodeBounds = true;

    BitmapFactory.decodeResource(res, resId, options);

    // 计算 inSampleSize 的值

    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);

    // 根据计算出的 inSampleSize 来解码图片生成Bitmap

    options.inJustDecodeBounds = false;

    return BitmapFactory.decodeResource(res, resId, options);

}

这里有一点要注意，就是要在第二遍decode之前把inJustDecodeBounds设置回false。

4. 调用以上的decodeSampledBitmapFromResource方法，使用自定尺寸的Bitmap。

如果你要将一张大图设置为一个100*100的缩略图，执行以下代码：

?


1

mImageView.setImageBitmap(decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));

到此，使用decodeResource()方法将一个大图解析为小尺寸bitmap的应用就完成了。同理，还可以使用decodeStream()，decodeFile()等方法做相同的事，原理是一样的。

延伸：一个Bitmap到底占用多大内存？系统给每个应用程序分配多大内存？

· Bitmap占用的内存为：像素总数 * 每个像素占用的内存。在Android中，Bitmap有四种像素类型：ARGB_8888、ARGB_4444、ARGB_565、ALPHA_8，他们每个像素占用的字节数分别为4、2、2、1。因此，一个2000*1000的ARGB_8888类型的Bitmap占用的内存为2000*1000*4=8000000B=8MB。

· Android根据设备屏幕尺寸和dpi的不同，给系统分配的单应用程序内存大小也不同，具体如下表（表格取自Android 4.4 Compatibility Definition Document (CDD)）：

 屏幕尺寸  DPI  应用内存
 small / normal / large  ldpi / mdpi  16MB
 small / normal / large  tvdpi / hdpi  32MB
 small / normal / large  xhdpi  64MB
 small / normal / large  400dpi  96MB
 small / normal / large  xxhdpi  128MB
 xlarge  mdpi  32MB
 xlarge  tvdpi / hdpi  64MB
 xlarge  xhdpi  128MB
 xlarge  400dpi  192MB
 xlarge  xxhdpi  256MB
时间： 2024-11-11 08:14:55

高效使用Bitmaps（一） 大Bitmap的加载的相关文章

Android 基础 十二 Bitmap的加载和Cache

本章的主题是Bitmap的加载和Cache,主要包含三个方面的内容.首先讲述如何有效地加载一个Bitmap,这是一个很有意义的话题,由于Bitmap的特殊性以及Android对单个应用所施加的内存限制,比如16MB,这导致Bitmap加载的时候很容易出现内存溢出.下面这个异常信息在开发中应该经常遇到: 因此如何高效的加载Bitmap是一个很重要也很容易被开发者或忽视的问题. 接着介绍Android中常用的缓存策略,缓存策略是一种通用的思想,可以用在很多场景中,但是实际开发中经常需要用Bitmap

Bitmap 的加载和 Cache

Android 中如何高效地加载 Bitmap 是一个很重要也很容易被我们忽视的问题. Bitmap 的高效加载 BitmapFactory 类提供了:decodeFile.decodeResource.decodeStream.decodeByteArray 以及 decodeFileDescriptor 等几类方法来加载一个 Bitmap 对象. 高效加载 Bitmap 的核心思想就是设置 BitmapFactory.Options 的 inSampleSize 采样率属性来加载所需尺寸的图

关于Bitmap的加载（一）

Android中的Bitmap的加载,为了更好的用户体验,有非常多的奇巧淫技.要达到的目的是,一边加载一边看,不卡屏.图片根据布局大小显示.如果图片大了,要合理的缩小,防止内存溢出. 于是,我把Android training的讲解记录下来. 首先,是单一图片的加载. 单一图片,加载最首要的问题是判断图片的大小.如果图片过大,我们需要对图片进行一定比例的压缩. 先通过图片本身的宽高和要求的宽高,计算图片的缩放比例. public static int calculateInSampleSize(

关于Bitmap的加载（二）

接上节,上节记录了Bitmap的加载,用上节的方法,我们可以方便地压缩图片,进行加载. 然而,有时候,当出来大量的图片或者是一张大图要加载时,这一过程所花的时间就会显得很长.甚至长到用户可以感觉出来,即UI的卡顿.因此,我们需要一个方法让图片自己加载去吧,不能干扰用户的操作.所以,我们需要用一个新的线程来完成图片加载的操作.其中最简单便捷的方法,就是Use an AsyncTask. 首先创建一个AsyncTask的子类: class BitmapWorkerTask extends Async

Bitmap的加载与Cache(一)

如何有效的加载一个bitmap,由于Bitmap的特殊性以及Android对单个应用所施加的内存限制,比如16MB,这就导致加载Bitmap的时候很容易出现内存溢出. 因此,如何高效的加载bitmap是一个很重要也很容易被开发者忽略的问题. Bitmap的高效加载: 如何加载一张图片呢?BitmapFactory类提供了四类方法:decodedFile,decodedResource,decodedStream和decodedByteArray,分别用于支持文件系统,资源,输入流以及字节数组中加

第12章 Bitmap的加载和Cache

高效加载 BitmapFactory类提供四种方法: decodeFile:从文件,间接调用decodeStream decodeResource:从资源,间接调用decodeStream decodeStream:输入流 decodeByteArray:字节数组中 使用BitmapFactory.options按一定采样率来加载缩小后图片来避免OOM. public class ImageResizer { private static final String TAG = "ImageRes

Bitmap的加载和Cache

前提:由于Bitmap的特殊性以及Android对单个应用所施加的内存限制,导致加载Bitmap的时候很容易出现内存溢出. 下面这个一场信息在开发中应该市场遇到: java.lang.OutofMemoryError: bitmap size exceeds VM budget Android实际开发中经常需要用Bitmap做缓存,通过换粗策略,我们不需要每次都从网络上请求图片或者从存储设备中加载图片,这样就极大地提高了图片的加载效率以及产品的用户体验. 目前比较常用的缓存策略是LruCache

easyUI之datagrid大数据量加载慢的原因之我见

最近项目中使用了easyUI这个js展现层,说实话,展示效果还算不错,使用上也比较方便,但是让我头疼的就是datagrid的这个控件. 它的使用起始非常简单方便,而且提供的功能也比较全面,但是美中不足的就是,该控件在加载比较大的数据量时,渲染速度有点难以承受. 网上找了相关的解决方案,无外乎就是使用view. view这个东西说实话的确能起到改善datagrid的加载速度的问题,但是缺陷也比较多,网上有该缺陷描述,本人不在此说了. 还有一个提到的方案,就是修改 jquery-easyui-min

高效抽取loading，再多的加载页面也不怕

当今的app基本上有两个操作,一个是加载数据 ,一个就是把数据显示到页面上.但如果页面特别的多.就每个页面都要加载数据,就要写 loading 页面.我之前就是用dialog写,抽取出来一个类.哪里需要了就在那里添加以下代码.我发现我大多数时间都在 重复的 添加 loading代码.为此总加班. 请无限参考此文章:http://blog.csdn.net/wanghao200906/article/details/46805085 下面是页面多的时候状态 这要再多点儿 一个一个的写不但代码不好看