前言
Glide 这个三方库使用起来非常简单
Glide.with(this).load("").into(imageView)。便可以将资源图片加载到对应的控件上面
而且 Glide 还有以下的优点：
- Glide 具有生命周期，可以更加合理的管理图片的加载和释放
- 加载速度比较快，默认采用 RGB565 的加载方式，当然也可以自定义 config
- 可以加载 GIF 图
- 可以自定义加载的网络框架(Glide默认采用 URLHttpConnection )
...
如此强大的功能竟然只要一行代码就可以实现，接下来我们就一起去探讨 Glide 的奥秘吧。
with
首先从 with 方法开始看起
@NonNull
public static RequestManager with(@NonNull FragmentActivity activity) {
return getRetriever(activity).get(activity);
}
@NonNull
private static RequestManagerRetriever getRetriever(@Nullable Context context) {
// Context could be null for other reasons (ie the user passes in null), but in practice it will
// only occur due to errors with the Fragment lifecycle.
Preconditions.checkNotNull(
context,
"You cannot start a load on a not yet attached View or a Fragment where getActivity() "
+ "returns null (which usually occurs when getActivity() is called before the Fragment "
+ "is attached or after the Fragment is destroyed).");
return Glide.get(context).getRequestManagerRetriever();
}
with 方法有很多，就只挑其中一个讲讲。我们可以看到 with 将 activity 传了进来，然后获取了 RequestManagerRetriever 对象，这个对象主要作用就是用来管理 Fragment 的。
然后执行了 RequestManagerRetriever#get 方法
@NonNull
public RequestManager get(@NonNull FragmentActivity activity) {
if (Util.isOnBackgroundThread()) {
return get(activity.getApplicationContext());
} else {
assertNotDestroyed(activity);
FragmentManager fm = activity.getSupportFragmentManager();
return supportFragmentGet(activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
}
}
主要是判断当前如果是子线程那么就采用 Application 的 context ，如果是主线程，那么就调用 supportFragmentGet 的方法生成一个 Fragment，从而让整个 Glide 具有生命周期，然后返回了RequestManager 对象用于后续的 load 调用
load
/**
* Equivalent to calling {@link #asDrawable()} and then {@link RequestBuilder#load(String)}.
*
* @return A new request builder for loading a {@link Drawable} using the given model.
*/
@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable String string) {
return asDrawable().load(string);
}
@NonNull
@Override
@CheckResult
public RequestBuilder<TranscodeType> load(@Nullable String string) {
return loadGeneric(string);
}
@NonNull
private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
this.model = model;
isModelSet = true;
return this;
}
如果传入的是 String，那么默认就将资源转化成 drawable 对象，当然 Glide 也可以配置成 Bitmap 即调用 asBitmap() 方法(不是本文重点，这里不做赘述)。然后执行 load 方法，就是简单的将 model 传入, isModelSet 设置为 true (这个 isModelSet 主要是为了让开发者先调用 load 方法，再调用 into ，不然直接抛异常)，并且返回了一个 RequestBuilder 对象
into
接下来就是本文的重点 into()， into 这个方法里面就是 Glide 的核心功能所在，由于 into 里面的逻辑太多，这里先列出几个核心类
- RequestBuilder
主要用于获取 SingleRequest 和创建 ViewTarget 对象 - SingleRequest
加载图片由 SingleRequest 发起，并且在 SingleRequest 处接收回调设置最终的图片 - Engine
用于加载缓存（活动缓存，内存缓存） - EngineJob
内部维护了一个线程池，用来管理加载图片的任务 - DecodeJob
实现了 Runnable 的接口，用来加载图片的任务 - DataFetcherGenerator
这个接口由三个子类实现分别: DataCacheGenerator,用于加载磁盘缓存,主要针对包含原始未修改源数据的缓存文件；ResourceCacheGenerator,用于加载磁盘缓存,主要针对降采样/转换后的资源缓存文件，用于加载；SourceGenerator,用于加载图片，将图片写入磁盘，然后在从磁盘中读取数据显示到对应的控件上， - ModelLoader
主要是用来加载数据源Model 中的数据 - DataFetcher
这里主要讲 HttpUrlFetcher 和 OkHttpStreamFetcher 用于加载网络图片的类 - ViewTarget
可以显示的 View 目标，可以指控件，也可以指的是一个回调
那么就可以从 RequestBuilder 开始了
@NonNull
public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
Util.assertMainThread();
Preconditions.checkNotNull(view);
BaseRequestOptions<?> requestOptions = this;
if (!requestOptions.isTransformationSet()
&& requestOptions.isTransformationAllowed()
&& view.getScaleType() != null) {
// Clone in this method so that if we use this RequestBuilder to load into a View and then
// into a different target, we don't retain the transformation applied based on the previous
// View's scale type.
switch (view.getScaleType()) {
case CENTER_CROP:
requestOptions = requestOptions.clone().optionalCenterCrop();
break;
case CENTER_INSIDE:
requestOptions = requestOptions.clone().optionalCenterInside();
break;
case FIT_CENTER:
case FIT_START:
case FIT_END:
requestOptions = requestOptions.clone().optionalFitCenter();
break;
case FIT_XY:
requestOptions = requestOptions.clone().optionalCenterInside();
break;
case CENTER:
case MATRIX:
default:
// Do nothing.
}
}
return into(
glideContext.buildImageViewTarget(view, transcodeClass),
/*targetListener=*/ null,
requestOptions,
Executors.mainThreadExecutor());
}
这段代码主要是通过 ImageView 的 ScaleType 设置对应的属性，然后执行后续的 into 方法
private <Y extends Target<TranscodeType>> Y into(
@NonNull Y target,
@Nullable RequestListener<TranscodeType> targetListener,
BaseRequestOptions<?> options,
Executor callbackExecutor) {
Preconditions.checkNotNull(target);
//判断之前是否执行过 load 方法，如果执行过 load 方法，那么 isModeSet 则是 true
if (!isModelSet) {
throw new IllegalArgumentException("You must call #load() before calling #into()");
}
//这个方法最后就会调用 SingleRequest.obtain 方法实例化 SingleRequest
Request request = buildRequest(target, targetListener, options, callbackExecutor);
...代码省略...
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);
return target;
}
首先判断是否执行过 load，然后初始化 SingleRequest (也就是 Glide 加载图片的发起者),然后执行 RequestManager 的 track 方法。
synchronized void track(@NonNull Target<?> target, @NonNull Request request) {
targetTracker.track(target);
requestTracker.runRequest(request);
}
/** Starts tracking the given request. */
public void runRequest(@NonNull Request request) {
requests.add(request);
if (!isPaused) {
request.begin();
} else {
request.clear();
if (Log.isLoggable(TAG, Log.VERBOSE)) {
Log.v(TAG, "Paused, delaying request");
}
pendingRequests.add(request);
}
}
接下来就开始执行 request (即 SingleRequest )的 begin 方法
@Override
public void begin() {
synchronized (requestLock) {
...代码省略...
status = Status.WAITING_FOR_SIZE;
if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
onSizeReady(overrideWidth, overrideHeight);
} else {
target.getSize(this);
}
...代码省略...
}
}
先判断用户是否设置了有效的宽高，如果没有的话框架自己去获取 View 的宽高作为图片的宽高值，当然最后都会调用到 onSizeReady 方法
@Override
public void onSizeReady(int width, int height) {
...代码省略...
loadStatus =
engine.load(
glideContext,
model,
requestOptions.getSignature(),
this.width,
this.height,
requestOptions.getResourceClass(),
transcodeClass,
priority,
requestOptions.getDiskCacheStrategy(),
requestOptions.getTransformations(),
requestOptions.isTransformationRequired(),
requestOptions.isScaleOnlyOrNoTransform(),
requestOptions.getOptions(),
requestOptions.isMemoryCacheable(),
requestOptions.getUseUnlimitedSourceGeneratorsPool(),
requestOptions.getUseAnimationPool(),
requestOptions.getOnlyRetrieveFromCache(),
this,
callbackExecutor);
...代码省略...
}
}
然后就调用 engine 的 load 方法，所以就开始了执行三级缓存策略的前两级缓存(即活动缓存，内存缓存)
public <R> LoadStatus load(
GlideContext glideContext,
Object model,
Key signature,
int width,
int height,
Class<?> resourceClass,
Class<R> transcodeClass,
Priority priority,
DiskCacheStrategy diskCacheStrategy,
Map<Class<?>, Transformation<?>> transformations,
boolean isTransformationRequired,
boolean isScaleOnlyOrNoTransform,
Options options,
boolean isMemoryCacheable,
boolean useUnlimitedSourceExecutorPool,
boolean useAnimationPool,
boolean onlyRetrieveFromCache,
ResourceCallback cb,
Executor callbackExecutor) {
long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
//创建获取缓存所对应的 key
EngineKey key =
keyFactory.buildKey(
model,
signature,
width,
height,
transformations,
resourceClass,
transcodeClass,
options);
EngineResource<?> memoryResource;
synchronized (this) {
//加载缓存
memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);
if (memoryResource == null) {
//如果缓存没有，那么就开始任务
return waitForExistingOrStartNewJob(
glideContext,
model,
signature,
width,
height,
resourceClass,
transcodeClass,
priority,
diskCacheStrategy,
transformations,
isTransformationRequired,
isScaleOnlyOrNoTransform,
options,
isMemoryCacheable,
useUnlimitedSourceExecutorPool,
useAnimationPool,
onlyRetrieveFromCache,
cb,
callbackExecutor,
key,
startTime);
}
}
// Avoid calling back while holding the engine lock, doing so makes it easier for callers to
// deadlock.
cb.onResourceReady(memoryResource, DataSource.MEMORY_CACHE);
return null;
}
首先创建对应的 key，然后通过 key 去获取指定的缓存，如果没找到缓存，那么就开始执行 waitForExistingOrStartNewJob 方法(看名字就知道是在等待存在的任务或者是新启动一个任务，本文只讲新启动的任务)。那么我们先看看如果获取缓存的吧
@Nullable
private EngineResource<?> loadFromMemory(
EngineKey key, boolean isMemoryCacheable, long startTime) {
if (!isMemoryCacheable) {
return null;
}
//加载活动缓存
EngineResource<?> active = loadFromActiveResources(key);
if (active != null) {
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Loaded resource from active resources", startTime, key);
}
return active;
}
//如果活动缓存不存在，那么就加载内存缓存
EngineResource<?> cached = loadFromCache(key);
if (cached != null) {
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Loaded resource from cache", startTime, key);
}
return cached;
}
return null;
}
活动缓存:
@Nullable
private EngineResource<?> loadFromActiveResources(Key key) {
EngineResource<?> active = activeResources.get(key);
if (active != null) {
active.acquire();
}
return active;
}
//活动缓存是存放在一个 HashMap 中，每次获取出来就会自增1，每次再停止加载或者对应的控件被销毁的时候自减1。
//这样就可以知道对应的 resource 被使用的情况。一旦计数为0，就会进入 lrucache 对象，后面会讲到
@VisibleForTesting final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();
@Nullable
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;
}
内存缓存:
//memoryCache 是一个接口，这里其实是 LruResourceCache 的实现类
private final MemoryCache cache;
private EngineResource<?> loadFromCache(Key key) {
EngineResource<?> cached = getEngineResourceFromCache(key);
if (cached != null) {
cached.acquire();
activeResources.activate(key, cached);
}
return cached;
}
private EngineResource<?> getEngineResourceFromCache(Key key) {
Resource<?> cached = cache.remove(key);
final EngineResource<?> result;
if (cached == null) {
result = null;
} else if (cached instanceof EngineResource) {
// Save an object allocation if we've cached an EngineResource (the typical case).
result = (EngineResource<?>) cached;
} else {
result =
new EngineResource<>(
cached, /*isMemoryCacheable=*/ true, /*isRecyclable=*/ true, key, /*listener=*/ this);
}
return result;
}
可以看到活动缓存其实是一个 HashMap，将活动的资源保存起来。而内存缓存是一个 LruRecourseCache (本质是 LinkedHashMap )，将没有使用的缓存保存起来。
看到这里有些人会疑惑活动缓存存在的价值是什么，毕竟严格意义来说也是内存缓存。
其实可以试想一下因为内存缓存采用的是 LRU 算法(即最近最少使用算法)，会将最近不常使用的资源销毁掉。但是毕竟 LinkedHashMap 存入的资源有限，一旦加载图片有很多，如果不设置活动缓存这一级，那么会发现，最早加载的图片可以就有可能被销毁了(这也是 LRU 算法的弊端，当然为了节省空间，LRU 算法也是必须的)
好了。活动缓存和内存缓存介绍完毕，如果此时没有得到对应的资源，那么就会启动一个任务
private <R> LoadStatus waitForExistingOrStartNewJob(
GlideContext glideContext,
Object model,
Key signature,
int width,
int height,
Class<?> resourceClass,
Class<R> transcodeClass,
Priority priority,
DiskCacheStrategy diskCacheStrategy,
Map<Class<?>, Transformation<?>> transformations,
boolean isTransformationRequired,
boolean isScaleOnlyOrNoTransform,
Options options,
boolean isMemoryCacheable,
boolean useUnlimitedSourceExecutorPool,
boolean useAnimationPool,
boolean onlyRetrieveFromCache,
ResourceCallback cb,
Executor callbackExecutor,
EngineKey key,
long startTime) {
//获取是否有对应 key 的任务存在，不详细展开
EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
if (current != null) {
current.addCallback(cb, callbackExecutor);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Added to existing load", startTime, key);
}
return new LoadStatus(cb, current);
}
//新建线程池
EngineJob<R> engineJob =
engineJobFactory.build(
key,
isMemoryCacheable,
useUnlimitedSourceExecutorPool,
useAnimationPool,
onlyRetrieveFromCache);
//新建对应的任务
DecodeJob<R> decodeJob =
decodeJobFactory.build(
glideContext,
model,
key,
signature,
width,
height,
resourceClass,
transcodeClass,
priority,
diskCacheStrategy,
transformations,
isTransformationRequired,
isScaleOnlyOrNoTransform,
onlyRetrieveFromCache,
options,
engineJob);
//将线程池缓存起来，下次可以复用
jobs.put(key, engineJob);
engineJob.addCallback(cb, callbackExecutor);
//启动任务
engineJob.start(decodeJob);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Started new load", startTime, key);
}
return new LoadStatus(cb, engineJob);
}
这里主要就是初始化 engineJob 和 DecodeJob ，EnginJob 内部维护了一个线程池，主要是为了管理 DecodeJob 的，DecodeJob 实现了 Runnable 接口，可以理解为一个任务。所以主要操作就在 DecodeJob 中。
@Override
public void run() {
...代码省略...
try {
if (isCancelled) {
notifyFailed();
return;
}
runWrapped();
} catch (CallbackException e) {
// If a callback not controlled by Glide throws an exception, we should avoid the Glide
// specific debug logic below.
throw e;
} catch (Throwable t) {
...代码省略...
if (!isCancelled) {
throw t;
}
throw t;
} finally {
...代码省略...
}
}
private void runWrapped() {
switch (runReason) {
case INITIALIZE:
stage = getNextStage(Stage.INITIALIZE);
currentGenerator = getNextGenerator();
runGenerators();
break;
case SWITCH_TO_SOURCE_SERVICE:
runGenerators();
break;
case DECODE_DATA:
decodeFromRetrievedData();
break;
default:
throw new IllegalStateException("Unrecognized run reason: " + runReason);
}
}
主要是执行了 runWrapped 方法，当然这个方法理解起来稍微复杂一点，稍微有点绕。
一开始会根据缓存策略判断是否需要加载转化过的图片资源，如果需要则在调用 getNextGenerator 的时候获取指定的 ResourceCacheGenerator (这里我们就直接跳过进入 nextStage )，
然后获取不到的时候就会再次执行 getNextStage ，根据缓存策略判断是否需要加载原图资源。如果需要则调用 getNextGenerator 获取 DataCacheGenerator ，然后调用 Generator 的 startNext 方法
@Override
public boolean startNext() {
while (modelLoaders == null || !hasNextModelLoader()) {
sourceIdIndex++;
if (sourceIdIndex >= cacheKeys.size()) {
return false;
}
Key sourceId = cacheKeys.get(sourceIdIndex);
// PMD.AvoidInstantiatingObjectsInLoops The loop iterates a limited number of times
// and the actions it performs are much more expensive than a single allocation.
@SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")
Key originalKey = new DataCacheKey(sourceId, helper.getSignature());
cacheFile = helper.getDiskCache().get(originalKey);
if (cacheFile != null) {
this.sourceKey = sourceId;
modelLoaders = helper.getModelLoaders(cacheFile);
modelLoaderIndex = 0;
}
}
loadData = null;
boolean started = false;
while (!started && hasNextModelLoader()) {
ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);
//这里获取的 loadData 就是 ByteBufferFileLoader
loadData =
modelLoader.buildLoadData(
cacheFile, helper.getWidth(), helper.getHeight(), helper.getOptions());
if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {
started = true;
loadData.fetcher.loadData(helper.getPriority(), this);
}
}
return started;
}
然后调用 ByteBufferFileLoader 的内部对象 ByteBufferFetcher 的 loadData 方法
@Override
public void loadData(
@NonNull Priority priority, @NonNull DataCallback<? super ByteBuffer> callback) {
ByteBuffer result;
try {
result = ByteBufferUtil.fromFile(file);
} catch (IOException e) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "Failed to obtain ByteBuffer for file", e);
}
callback.onLoadFailed(e);
return;
}
callback.onDataReady(result);
}
开始读取本地磁盘的缓存资源，也就是三级缓存策略中的最后一级。如果仍然没有获取到资源，那么继续调用 getNextStage 方法，然后调用 getNextGenerator ，获取 SourceGenerator 对象。执行 startNext 方法（PS:字打到这里，越来越觉得这个设计很像责任链的设计模式）
@Override
public boolean startNext() {
if (dataToCache != null) {
Object data = dataToCache;
dataToCache = null;
cacheData(data);
}
if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
return true;
}
sourceCacheGenerator = null;
loadData = null;
boolean started = false;
while (!started && hasNextModelLoader()) {
loadData = helper.getLoadData().get(loadDataListIndex++);
if (loadData != null
&& (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
|| helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
started = true;
loadData.fetcher.loadData(helper.getPriority(), this);
}
}
return started;
}
如果我们没有设置网络框架的时候，默认 loadData.fetcher 就是 HttpUrlFetcher ，我们进去看下操作:
@Override
public void loadData(
@NonNull Priority priority, @NonNull DataCallback<? super InputStream> callback) {
long startTime = LogTime.getLogTime();
try {
InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
callback.onDataReady(result);
} catch (IOException e) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "Failed to load data for url", e);
}
callback.onLoadFailed(e);
} finally {
if (Log.isLoggable(TAG, Log.VERBOSE)) {
Log.v(TAG, "Finished http url fetcher fetch in " + LogTime.getElapsedMillis(startTime));
}
}
}
private InputStream loadDataWithRedirects(
URL url, int redirects, URL lastUrl, Map<String, String> headers) throws IOException {
if (redirects >= MAXIMUM_REDIRECTS) {
throw new HttpException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");
} else {
// Comparing the URLs using .equals performs additional network I/O and is generally broken.
// See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html.
try {
if (lastUrl != null && url.toURI().equals(lastUrl.toURI())) {
throw new HttpException("In re-direct loop");
}
} catch (URISyntaxException e) {
// Do nothing, this is best effort.
}
}
urlConnection = connectionFactory.build(url);
for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
}
urlConnection.setConnectTimeout(timeout);
urlConnection.setReadTimeout(timeout);
urlConnection.setUseCaches(false);
urlConnection.setDoInput(true);
// Stop the urlConnection instance of HttpUrlConnection from following redirects so that
// redirects will be handled by recursive calls to this method, loadDataWithRedirects.
urlConnection.setInstanceFollowRedirects(false);
// Connect explicitly to avoid errors in decoders if connection fails.
urlConnection.connect();
// Set the stream so that it's closed in cleanup to avoid resource leaks. See #2352.
stream = urlConnection.getInputStream();
if (isCancelled) {
return null;
}
final int statusCode = urlConnection.getResponseCode();
if (isHttpOk(statusCode)) {
return getStreamForSuccessfulRequest(urlConnection);
} else if (isHttpRedirect(statusCode)) {
String redirectUrlString = urlConnection.getHeaderField("Location");
if (TextUtils.isEmpty(redirectUrlString)) {
throw new HttpException("Received empty or null redirect url");
}
URL redirectUrl = new URL(url, redirectUrlString);
// Closing the stream specifically is required to avoid leaking ResponseBodys in addition
// to disconnecting the url connection below. See #2352.
cleanup();
return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
} else if (statusCode == INVALID_STATUS_CODE) {
throw new HttpException(statusCode);
} else {
throw new HttpException(urlConnection.getResponseMessage(), statusCode);
}
}
很明显采用的是 HttpURLConnection 的类来加载图片资源，我们都知道 HttpURLConnection 其实都已经快要被废弃了，那么 Glide 团队自然也会考虑到这一点，所以这个地方可以支持用户改成 OKHttp 加载(使用方式可以查看Glide自定义模块这篇文章，此处不做介绍)。那么这个时候的 fetcher 就会变成 OkHttpStreamFetcher ：
@Override
public void loadData(
@NonNull Priority priority, @NonNull final DataCallback<? super InputStream> callback) {
Request.Builder requestBuilder = new Request.Builder().url(url.toStringUrl());
for (Map.Entry<String, String> headerEntry : url.getHeaders().entrySet()) {
String key = headerEntry.getKey();
requestBuilder.addHeader(key, headerEntry.getValue());
}
Request request = requestBuilder.build();
this.callback = callback;
call = client.newCall(request);
call.enqueue(this);
}
@Override
public void onResponse(@NonNull Call call, @NonNull Response response) {
responseBody = response.body();
if (response.isSuccessful()) {
long contentLength = Preconditions.checkNotNull(responseBody).contentLength();
stream = ContentLengthInputStream.obtain(responseBody.byteStream(), contentLength);
callback.onDataReady(stream);
} else {
callback.onLoadFailed(new HttpException(response.message(), response.code()));
}
}
调用的时候会执行 OKHttp 的加载方式，然后通过 onResponse 返回,此处的 onDataReady 会调用到 SourceGenerator 的 onDataReady 方法
@Override
public void onDataReady(Object data) {
DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
dataToCache = data;
// We might be being called back on someone else's thread. Before doing anything, we should
// reschedule to get back onto Glide's thread.
cb.reschedule();
} else {
cb.onDataFetcherReady(
loadData.sourceKey,
data,
loadData.fetcher,
loadData.fetcher.getDataSource(),
originalKey);
}
}
然后执行 DecodeJob 的 reschedule 方法
@Override
public void reschedule() {
runReason = RunReason.SWITCH_TO_SOURCE_SERVICE;
callback.reschedule(this);
}
@Override
public void reschedule(DecodeJob<?> job) {
// Even if the job is cancelled here, it still needs to be scheduled so that it can clean itself
// up.
getActiveSourceExecutor().execute(job);
}
执行 execute 之后会再次指定到 DecodeJob 的 run 方法，这次在 DecodeJob 的 runWrapper 方法里面 runReason 已经变成了 DECODE_DATA 了
private void decodeFromRetrievedData() {
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey(
"Retrieved data",
startFetchTime,
"data: "
+ currentData
+ ", cache key: "
+ currentSourceKey
+ ", fetcher: "
+ currentFetcher);
}
Resource<R> resource = null;
try {
resource = decodeFromData(currentFetcher, currentData, currentDataSource);
} catch (GlideException e) {
e.setLoggingDetails(currentAttemptingKey, currentDataSource);
throwables.add(e);
}
if (resource != null) {
notifyEncodeAndRelease(resource, currentDataSource);
} else {
runGenerators();
}
}
private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {
if (resource instanceof Initializable) {
((Initializable) resource).initialize();
}
Resource<R> result = resource;
LockedResource<R> lockedResource = null;
if (deferredEncodeManager.hasResourceToEncode()) {
lockedResource = LockedResource.obtain(resource);
result = lockedResource;
}
notifyComplete(result, dataSource);
stage = Stage.ENCODE;
try {
if (deferredEncodeManager.hasResourceToEncode()) {
deferredEncodeManager.encode(diskCacheProvider, options);
}
} finally {
if (lockedResource != null) {
lockedResource.unlock();
}
}
// Call onEncodeComplete outside the finally block so that it's not called if the encode process
// throws.
onEncodeComplete();
}
private void notifyComplete(Resource<R> resource, DataSource dataSource) {
setNotifiedOrThrow();
callback.onResourceReady(resource, dataSource);
}
然后就开始解码，然后将资源通过 callback 的 onRecourseRead 方法加载到控件上面(这里的 callback 指的是 SingleRequest ,然后调用到指定的target上面)。
在获取到数据源以后，还有一个重要的操作，就是将 bitmap 存入到 LruBitmapPool 里面可以复用,因为 Bitmap 内存占用很多，此举也是为了减少应用频繁申请和释放内存从而减少了内存抖动。
总结
为了方便理解 into 的主要逻辑，这里提供一幅简单的流程图供参考
Glide流程图.jpg
当然 Glide 的精髓远不在此，这里只是简单的梳理了一下 Glide 的主要工作流程。 Glide 还需要多花费时间深入研究才行
