UniversalImageLoader的一个小问题

最新推荐文章于 2020-12-19 12:19:52 发布

转载最新推荐文章于 2020-12-19 12:19:52 发布 · 217 阅读

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/angeldevil/p/4351203.html

本文深入探讨了UniversalImageLoader在加载图片时遇到的问题，分析了其内部机制，特别是针对多线程环境下同一图片的加载过程，揭示了部分场景下图片加载不全的原因。文章详细解释了内存缓存、磁盘缓存以及View重用机制如何影响图片的加载效率。

最近在使用UniversalImageLoader时遇到了一个小问题，多个地方同时通过ImageLoader.getInstance().loadImage(url, new ImageSize(dp72, dp72)...加载图像时，有一定机率只有部分地方能正确地加载到图片，其他地方是什么结果呢？从Log看是这个样子：

1 03-19 15:41:44.167 1500-1541/xxx D/ImageLoader﹕ Start display image task [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
2 03-19 15:41:44.167 1500-1541/xxx D/ImageLoader﹕ Load image from network [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
3 03-19 15:41:44.167 1500-1541/xxx D/ImageLoader﹕ Cache image on disk [cxxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
4 03-19 15:41:44.187 1500-1538/xxx D/ImageLoader﹕ Start display image task [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
5 03-19 15:41:44.187 1500-1538/xxx D/ImageLoader﹕ Image already is loading. Waiting... [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
6 03-19 15:41:44.199 1500-1541/xxx D/ImageLoader﹕ Cache image in memory [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
7 03-19 15:41:44.199 1500-1538/xxx D/ImageLoader﹕ ...Get cached bitmap from memory after waiting. [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
8 03-19 15:41:44.219 1500-1500/xxx D/ImageLoader﹕ Display image in ImageAware (loaded from NETWORK) [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]
9 03-19 15:41:44.219 1500-1500/xxx D/ImageLoader﹕ ImageAware is reused for another image. Task is cancelled. [xxxxxxx/group1/M00/00/04/wKgKklUKfS-AGTJRAAAV5nnd6hE739.jpg_144x144]

有了Log，再结合源码，看下到底是什么原因，从上面的Log可以看到，两个地方加载同一张图片，都发现缓存中没有，所以都从网络上加载（通过分析可以知道，第1，2，3，6，8是第一个加载的地方的Log，4，5，7，9是第二个加载的地方的Log）。

UniversalImageLoader实际加载图片的类叫LoadAndDisplayImageTask，这是一个Runnable，所以我们从它的run方法开始看。首先要强调一点，由于这两个地方加载的是相同的Url，并且ImageSize相同，所以它们的memoryCacheKey是相同的，接下来就看run方法，首先是第一部分代码。

ReentrantLock loadFromUriLock = imageLoadingInfo.loadFromUriLock;
L.d(LOG_START_DISPLAY_IMAGE_TASK, memoryCacheKey);
if (loadFromUriLock.isLocked()) { // 注意这里
    L.d(LOG_WAITING_FOR_IMAGE_LOADED, memoryCacheKey);
}

loadFromUriLock.lock();

由于memoryCacheKey相同，所以这里获得的是同一个锁，结果就是第一个线程锁住这个锁进行图片加载，所以打印出了前3行Log。

接着轮到第二个线程执行，它发现另一个线程锁住了loadFromUriLock，所以它打印出了第4和第5行Log。

然后又换第一个线程执行。

try {
    checkTaskNotActual();
    bmp = configuration.memoryCache.get(memoryCacheKey);
    if (bmp == null || bmp.isRecycled()) {
        bmp = tryLoadBitmap();
        if (bmp == null) {
            return;
        }

        checkTaskNotActual();
        checkTaskInterrupted();

        if (bmp != null && options.isCacheInMemory()) {
            L.d(LOG_CACHE_IMAGE_IN_MEMORY, memoryCacheKey); // 1
            configuration.memoryCache.put(memoryCacheKey, bmp);
        }
    } else {
        loadedFrom = LoadedFrom.MEMORY_CACHE;
        L.d(LOG_GET_IMAGE_FROM_MEMORY_CACHE_AFTER_WAITING, memoryCacheKey); // 2
    }

    checkTaskNotActual();
    checkTaskInterrupted();
} catch (TaskCancelledException e) {
    fireCancelEvent();
    return;
} finally {
    // 释放锁
    loadFromUriLock.unlock();
}

// 显示图片
DisplayBitmapTask displayBitmapTask = new DisplayBitmapTask(bmp, imageLoadingInfo, engine, loadedFrom);
runTask(displayBitmapTask, syncLoading, handler, engine);

第一个线程加载完图片后，在finally中释放了锁，然后通过DisplayBitmapTask进行图片的显示，从Log中可以分析出，线程中加载完图片后打印了注释1处的Log，然后释放了锁，轮到线程2执行。

由于线程一已经加载完图片并存入了缓存了，所以线程二会进入代码注释2的代码块，打印出第7行Log。

然后线程一线程二再依次运行分别打印第8，9行Log，两个线程都取到了Bitmap，为何会一个正确加载完图片，而另一个有一定机率加载不到呢？这要看UniversalImageLoader的缓存与判断View重用的机制。

ImageLoader在加载图片前会调用ImageLoaderEngine.prepareDisplayTaskFor方法来记录一些东西，具体就是记录一个ImageAware在加载哪一个Url，以判断当图片加载完成后，这个ImageAware是否被重用来加载其他的Url了。

private final Map<Integer, String> cacheKeysForImageAwares = Collections.synchronizedMap(new HashMap<Integer, String>());

void prepareDisplayTaskFor(ImageAware imageAware, String memoryCacheKey) {
    cacheKeysForImageAwares.put(imageAware.getId(), memoryCacheKey);
}

可以看到就是通过一个Map记录的，以ImageAware的id为键，对于LoadImage方法，使用的是NonViewAware，它的id是Url.hasCode，所以两个地方加载同一个图片，在cacheKeysForImageAwares中只有一条记录。

当加载完图片后是通过DisplayBitmapTask来显示图片并回调我们的Listener的。

public void run() {
    if (imageAware.isCollected()) {
        L.d(LOG_TASK_CANCELLED_IMAGEAWARE_COLLECTED, memoryCacheKey);
        listener.onLoadingCancelled(imageUri, imageAware.getWrappedView());
    } else if (isViewWasReused()) {
        L.d(LOG_TASK_CANCELLED_IMAGEAWARE_REUSED, memoryCacheKey);
        listener.onLoadingCancelled(imageUri, imageAware.getWrappedView());
    } else {
        L.d(LOG_DISPLAY_IMAGE_IN_IMAGEAWARE, loadedFrom, memoryCacheKey);
        displayer.display(bitmap, imageAware, loadedFrom);
        engine.cancelDisplayTaskFor(imageAware);
        listener.onLoadingComplete(imageUri, imageAware.getWrappedView(), bitmap);
    }
}

void cancelDisplayTaskFor(ImageAware imageAware) {
    cacheKeysForImageAwares.remove(imageAware.getId());
}

private boolean isViewWasReused() {
    String currentCacheKey = engine.getLoadingUriForView(imageAware);
    return !memoryCacheKey.equals(currentCacheKey);
}

当第一个地方执行到这个run方法时，会走到else分支里，打印出第8行的Log，然后调用ImageLoaderEngine.cancelDisplayTaskFor方法，移除在Map中的记录，并回调我们的Listener。

然后第二个地方执行到run中的isViewWasReused方法时，由于Map中的记录已经被第一个线程移除了，所以取得的currentCacheKey是null，就会判定为View被重用了，所以不能得到正确的结果。

那么为什么有时两个地方能同时得到正确的结果呢？那是因为如果当第一个线程进入到else代码块但在执行cancelDisplayTaskFor之前进行了线程调度，另一个线程还是有机会同时进入else代码块的。

其实对于NonViewAware，基本是不可能被重用的，所以感觉在这里可以做下特殊处理，或者对其生成 id的方法进行下修改（但这样会多次从网络取同一张图片）。或者像Volley一样，当执行一个请求时，如果发现这个图片正在Loading，就将其加入一个列表，当加载完后统一向这个列表里的请求发送消息，但这个修改就比较麻烦了，所以还是对NonViewAware做下特殊处理比较好，毕竟这个基本是不可能被重用的。

转载于:https://www.cnblogs.com/angeldevil/p/4351203.html