Android Bitmap优化 android bitmap内存

转载

时光机3号 2023-09-14 20:10:52

文章标签 Android Bitmap优化 android 缓存加载 Android 文章分类 Android 移动开发

在Android应用中加载Bitmaps的操作是需要特别小心处理的，有下面几个方面的原因:

移动设备的系统资源有限。Android设备对于单个程序至少需要16MB的内存。Android Compatibility Definition Document (CDD), Section 3.7. Virtual Machine Compatibility 中给出了对于不同大小与密度的屏幕的最低内存需求。应用应该在这个最低内存限制下去优化程序的效率。当然，大多数设备的都有更高的限制需求。
Bitmap会消耗很多内存，特别是对于类似照片等内容更加丰富的图片。例如，Galaxy Nexus的照相机能够拍摄2592x1936 pixels (5 MB)的图片。如果bitmap的图像配置是使用ARGB_8888 (从Android 2.3开始的默认配置) ，那么加载这张照片到内存大约需要19MB(

2592*1936*4

Android应用的UI通常会在一次操作中立即加载许多张bitmaps。例如在ListView, GridView 与ViewPager 等控件中通常会需要一次加载许多张bitmaps，而且需要预先加载一些没有在屏幕上显示的内容，为用户滑动的显示做准备。

一、高效加载大图

对于大图片而言，通常的做法是进行压缩。我们可以参考android 比较靠谱的图片压缩和官网中关于bitmap的加载。一般加载一个按比例缩小的版本到内存中。具体做法是先获取图片的尺寸，并拿来跟我们希望显示的大小进行计算获取缩放比例，根据这个比例生成指定大小的bitmap。

有下面一些因素需要考虑：

评估加载完整图片所需要耗费的内存。
程序在加载这张图片时可能涉及到的其他内存需求。
呈现这张图片的控件的尺寸大小。
屏幕大小与当前设备的屏幕密度。

例如，如果把一个大小为1024x768像素的图片显示到大小为128x96像素的ImageView上吗，就没有必要把整张原图都加载到内存中。

为了告诉解码器去加载一个缩小版本的图片到内存中，需要在BitmapFactory.Options 中设置 inSampleSize 的值。例如, 一个分辨率为2048x1536的图片，如果设置 inSampleSize 为4，那么会产出一个大约512x384大小的Bitmap。加载这张缩小的图片仅仅使用大概0.75MB的内存，如果是加载完整尺寸的图片，那么大概需要花费12MB（前提都是Bitmap的配置是 ARGB_8888）。

下面有一段根据目标图片大小来计算Sample图片大小的代码示例：

public static int calculateInSampleSize(
            BitmapFactory.Options options, int reqWidth, int reqHeight) {
    // Raw height and width of image
    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;

        // Calculate the largest inSampleSize value that is a power of 2 and keeps both
        // height and width larger than the requested height and width.
        while ((halfHeight / inSampleSize) > reqHeight
                && (halfWidth / inSampleSize) > reqWidth) {
            inSampleSize *= 2;
        }
    }

    return inSampleSize;
}

Note: 设置inSampleSize为2的幂是因为解码器最终还是会对非2的幂的数进行向下处理，获取到最靠近2的幂的数。详情参考inSampleSize的文档。

二、非UI线程处理Bitmap

当图片来源是网络或者是存储卡时（或者是任何不在内存中的形式），这些方法都不应该在UI 线程中执行。因为在上述情况下加载数据时，其执行时间是不可估计的，它依赖于许多因素（从网络或者存储卡读取数据的速度，图片的大小，CPU的速度等）。如果其中任何一个子操作阻塞了UI线程，系统都会容易出现应用无响应的错误。

你可以自己写一个thread来处理，但更方便的是使用AsyncTask，其封装了与主线程的交互。对于ListView，GridView这些复用view的控件，处理图片错位乱序。而官网推荐使用的是使用弱引用关联。

三、缓存Bitmap

内存缓存LruCache

内存缓存以花费宝贵的程序内存为前提来快速访问位图。LruCache类（在API Level 4的Support Library中也可以找到）特别适合用来缓存Bitmaps，它使用一个强引用（strong referenced）的LinkedHashMap保存最近引用的对象，并且在缓存超出设置大小的时候剔除（evict）最近最少使用到的对象。

Note:

为了给LruCache选择一个合适的大小，需要考虑到下面一些因素：

应用剩下了多少可用的内存?
多少张图片会同时呈现到屏幕上？有多少图片需要准备好以便马上显示到屏幕？
设备的屏幕大小与密度是多少？一个具有特别高密度屏幕（xhdpi）的设备，像Galaxy Nexus会比Nexus S（hdpi）需要一个更大的缓存空间来缓存同样数量的图片。
Bitmap的尺寸与配置是多少，会花费多少内存？
图片被访问的频率如何？是其中一些比另外的访问更加频繁吗？如果是，那么我们可能希望在内存中保存那些最常访问的图片，或者根据访问频率给Bitmap分组，为不同的Bitmap组设置多个LruCache对象。
是否可以在缓存图片的质量与数量之间寻找平衡点？某些时候保存大量低质量的Bitmap会非常有用，加载更高质量图片的任务可以交给另外一个后台线程。

通常没有指定的大小或者公式能够适用于所有的情形，我们需要分析实际的使用情况后，提出一个合适的解决方案。缓存太小会导致额外的花销却没有明显的好处，缓存太大同样会导致java.lang.OutOfMemory的异常，并且使得你的程序只留下小部分的内存用来工作（缓存占用太多内存，导致其他操作会因为内存不够而抛出异常）。

下面是一个为Bitmap建立LruCache的示例：

private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Get max available VM memory, exceeding this amount will throw an
    // OutOfMemory exception. Stored in kilobytes as LruCache takes an
    // int in its constructor.
    final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);

    // Use 1/8th of the available memory for this memory cache.
    final int cacheSize = maxMemory / 8;

    mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
        @Override
        protected int sizeOf(String key, Bitmap bitmap) {
            // The cache size will be measured in kilobytes rather than
            // number of items.
            return bitmap.getByteCount() / 1024;
        }
    };
    ...
}

public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }
}

public Bitmap getBitmapFromMemCache(String key) {
    return mMemoryCache.get(key);
}

Note:在上面的例子中, 有1/8的内存空间被用作缓存。这意味着在常见的设备上（hdpi），最少大概有4MB的缓存空间（32/8）。如果一个填满图片的GridView控件放置在800x480像素的手机屏幕上，大概会花费1.5MB的缓存空间（800x480x4 bytes），因此缓存的容量大概可以缓存2.5页的图片内容。

使用磁盘缓存DiskLruCache

内存缓存能够提高访问最近用过的Bitmap的速度，但是我们无法保证最近访问过的Bitmap都能够保存在缓存中。像类似GridView等需要大量数据填充的控件很容易就会用尽整个内存缓存。另外，我们的应用可能会被类似打电话等行为而暂停并退到后台，因为后台应用可能会被杀死，那么内存缓存就会被销毁，里面的Bitmap也就不存在了。一旦用户恢复应用的状态，那么应用就需要重新处理那些图片。

磁盘缓存可以用来保存那些已经处理过的Bitmap，它还可以减少那些不再内存缓存中的Bitmap的加载次数。当然从磁盘读取图片会比从内存要慢，而且由于磁盘读取操作时间是不可预期的，读取操作需要在后台线程中处理。

Note:如果图片会被更频繁的访问，使用ContentProvider或许会更加合适，比如在图库应用中。

Note :因为初始化磁盘缓存涉及到I/O操作，所以它不应该在主线程中进行。但是这也意味着在初始化完成之前缓存可以被访问。为了解决这个问题，在上面的实现中，有一个锁对象（lock object）来确保在磁盘缓存完成初始化之前，应用无法对它进行读取。

四、管理Bitmap的内存使用

我们首先要知道Android管理Bitmap内存使用的演变进程:

在Android 2.2 (API level 8)以及之前，当垃圾回收发生时，应用的线程是会被暂停的，这会导致一个延迟滞后，并降低系统效率。从Android 2.3开始，添加了并发垃圾回收的机制，这意味着在一个Bitmap不再被引用之后，它所占用的内存会被立即回收。
在Android 2.3.3 (API level 10)以及之前, 一个Bitmap的像素级数据（pixel data）是存放在Native内存空间中的。这些数据与Bitmap本身是隔离的，Bitmap本身被存放在Dalvik堆中。我们无法预测在Native内存中的像素级数据何时会被释放，这意味着程序容易超过它的内存限制并且崩溃。自Android 3.0 (API Level 11)开始，像素级数据则是与Bitmap本身一起存放在Dalvik堆中。

而在Android3.0(API 11)之后，Bitmap的像素数据和Bitmap对象一起存储在Dalvik heap中，所以我们不用手动调用recycle()来释放Bitmap对象，内存的释放都交给垃圾回收器来做。

Caution：只有当我们确定这个Bitmap不再需要用到的时候才应该使用recycle()。在执行recycle()方法之后，如果尝试绘制这个Bitmap，我们将得到"Canvas: trying to use a recycled bitmap"的错误提示。

在2.3版本及之前的版本，使用引用计数的方式来决定是否recycle掉bitmap，新创建的bitmap加入LruCache时计数加一，从LruCache移除时减一，imageView显示该bitmap时加一，不显示时减一。

本文大部分文字来源于胡凯这位大牛的开源翻译项目，这里只是集合起来做下总结。

参考胡凯开源项目对应部分。

本人研究缩写的源码：http://yunpan.cn/cHUwsEFW7bBfg （提取码：2e6b）

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。