Glide源码解析之ActiveResources

前言

在之前我们看Glide获取数据的时候,第一个就是从ActiveResource中获取的,作为第一级缓存,那么它究竟是个什么东西,下面让我们来揭开它的神秘面纱。

第一级缓存

这里的代码很简单,从ActiveResource中根据key获取EngineResource,由此我们可以猜测ActiveResource很有可能是由Map来保存数据的。

    //Engine.load()
    EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
        cb.onResourceReady(active, DataSource.MEMORY_CACHE);
        return null;
    }
    
    private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) {
        if (!isMemoryCacheable) {
            return null;
        }
        EngineResource<?> active = activeResources.get(key);
        if (active != null) {
            active.acquire();
        }

        return active;
    }

ActiveResource源码

在构造函数中对变量isActiveResourceRetentionAllowed和monitorClearedResourcesExecutor赋值,在Engine中调用的是它的第一个构造函数,那么它实际使用的是一个只有一个线程的线程池,并且设置优先级为后台线程,然后就开始执行cleanReferenceQueue()。

其次用HashMap保存了ResourceWeakReference,也证实了上面的猜想。ResourceWeakReference这个类在下面会讲到。

final class ActiveResources {
    private final boolean isActiveResourceRetentionAllowed;
    private final Executor monitorClearedResourcesExecutor;
    @VisibleForTesting
    final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();
    private final ReferenceQueue<EngineResource<?>> resourceReferenceQueue = new ReferenceQueue<>();

    private ResourceListener listener;

    private volatile boolean isShutdown;
    
    ActiveResources(boolean isActiveResourceRetentionAllowed) {
        this(
                isActiveResourceRetentionAllowed,
                java.util.concurrent.Executors.newSingleThreadExecutor(
                        new ThreadFactory() {
                            @Override
                            public Thread newThread(@NonNull final Runnable r) {
                                return new Thread(
                                        new Runnable() {
                                            @Override
                                            public void run() {
                                                Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                                                r.run();
                                            }
                                        },
                                        "glide-active-resources");
                            }
                        }));
    }

    @VisibleForTesting
    ActiveResources(
            boolean isActiveResourceRetentionAllowed, Executor monitorClearedResourcesExecutor) {
        this.isActiveResourceRetentionAllowed = isActiveResourceRetentionAllowed;
        this.monitorClearedResourcesExecutor = monitorClearedResourcesExecutor;

        monitorClearedResourcesExecutor.execute(
                new Runnable() {
                    @Override
                    public void run() {
                        cleanReferenceQueue();
                    }
                });
    }
    
}

isActiveResourceRetentionAllowed代表是否保留活动资源,可以通过GlideBuilder赋值,默认为false。如果设置为true则Glide会持有底层的资源(比如Bitmap)的强引用用来做内存缓存。

    //GlideBuilder
    private boolean isActiveResourceRetentionAllowed;
    
    /**
     *  Defaults to {@code false}.
     */
    public GlideBuilder setIsActiveResourceRetentionAllowed(
            boolean isActiveResourceRetentionAllowed) {
        this.isActiveResourceRetentionAllowed = isActiveResourceRetentionAllowed;
        return this;
    }

在看cleanReferenceQueue()之前先来看下ActiveResource的静态内部类ResourceWeakReference,稍后会用到。

ResourceWeakReference

这里继承了WeakReference来持有EngineResource,这样当只有弱引用持有EngineResource的时候如果发生了gc则会回收掉EngineResource。

同时将ActiveResource的ReferenceQueue传入,这样当EngineResource被回收时就能知道了。

默认情况下变量resource的值为null,isCacheable的值为true。

    static final class ResourceWeakReference extends WeakReference<EngineResource<?>> {
        @Synthetic
        final Key key;
        @Synthetic
        final boolean isCacheable;

        @Nullable
        @Synthetic
        Resource<?> resource;

        @Synthetic
        @SuppressWarnings("WeakerAccess")
        ResourceWeakReference(
                @NonNull Key key,
                @NonNull EngineResource<?> referent,
                @NonNull ReferenceQueue<? super EngineResource<?>> queue,
                boolean isActiveResourceRetentionAllowed) {
            super(referent, queue);
            this.key = Preconditions.checkNotNull(key);
            this.resource =
                    referent.isCacheable() && isActiveResourceRetentionAllowed
                            ? Preconditions.checkNotNull(referent.getResource()) : null;
            isCacheable = referent.isCacheable();   //BaseRequestOptions中的值默认为true
        }
        
        //清除资源
        void reset() {
            resource = null;
            clear();
        }

看完ResourceWeakReference之后接下来开始看cleanReferenceQueue(),主要就是在while循环里面调用了resourceReferenceQueue的remove(),这个方法会一直阻塞当前线程,直到有返回值。当ResourceWeakReference里面的EngineResource被内存回收掉的时候才会有返回值,所以这里用线程池开了一个线程来处理。接着执行cleanupActiveReference(),把HashMap中保存的ResourceWeakReference删除。如果在GlideBuilder中设置了isActiveResourceRetentionAllowed为true则会接着执行下面的方法,把实际的资源重新生成一个EngineResource,并回调给Engin让它存入MemoryCache中。

    void cleanReferenceQueue() {
        while (!isShutdown) {
            try {
                ResourceWeakReference ref = (ResourceWeakReference) resourceReferenceQueue.remove();
                cleanupActiveReference(ref);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
    
    void cleanupActiveReference(@NonNull ResourceWeakReference ref) {
        synchronized (listener) {
            synchronized (this) {
                activeEngineResources.remove(ref.key);

                if (!ref.isCacheable || ref.resource == null) {
                    return;
                }
                EngineResource<?> newResource =
                        new EngineResource<>(ref.resource, /*isCacheable=*/ true, /*isRecyclable=*/ false);
                newResource.setResourceListener(ref.key, listener);
                listener.onResourceReleased(ref.key, newResource);
            }
        }
    }

    //Engine
    public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {
        activeResources.deactivate(cacheKey);
        if (resource.isCacheable()) {
            cache.put(cacheKey, resource);      //MemoryCache
        } else {
            resourceRecycler.recycle(resource);
        }
    }
    
    //ActiveResources
    synchronized void deactivate(Key key) {
        ResourceWeakReference removed = activeEngineResources.remove(key);
        if (removed != null) {
            removed.reset();
        }
    }

看完了监听内存回收的逻辑,接下来看下是如何从ActiveResource获取EngineResource的。直接从HashMap中根据key取ResourceWeakReference,如果没被回收则再取里面的EngineResource,如果已经被回收了则执行清除工作。

    synchronized EngineResource<?> get(Key key) {
        ResourceWeakReference activeRef = activeEngineResources.get(key);
        if (activeRef == null) {
            return null;
        }

        EngineResource<?> active = activeRef.get();
        if (active == null) {
            cleanupActiveReference(activeRef);
        }
        return active;
    }

ActiveResource并没有提供put()来保存数据,取而代之的是activate()。在Engine的load()中如果一开始在ActiveResource没有获取到EngineResource,则接下来会在MemoryCache中获取,如果获取到则会把EnginResource保存到ActiveResource。

    //Engine
    private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
        if (!isMemoryCacheable) {
            return null;
        }

        EngineResource<?> cached = getEngineResourceFromCache(key);
        if (cached != null) {
            cached.acquire();
            activeResources.activate(key, cached);
        }
        return cached;
    }
    
    synchronized void activate(Key key, EngineResource<?> resource) {
        ResourceWeakReference toPut =
                new ResourceWeakReference(
                        key, resource, resourceReferenceQueue, isActiveResourceRetentionAllowed);

        ResourceWeakReference removed = activeEngineResources.put(key, toPut);
        if (removed != null) {
            removed.reset();
        }
    }

总结

ActiveResource做为Glide的第一级缓存,保存的是那些活跃的EngineResource,即没有被内存回收的数据。这里对缓存的大小没有限制,防止因为同时加载的图片太多造成了MemoryCache因为大小限制而移出缓存,导致最终去使用磁盘缓存的问题。同时使用了弱引用,保证了当进行内存回收时能及时回收掉,避免一直占用内存。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,793评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,567评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,342评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,825评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,814评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,680评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,033评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,687评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,175评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,668评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,775评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,419评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,020评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,206评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,092评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,510评论 2 343

推荐阅读更多精彩内容