深入 Glide 源码探究解决加载图片超时问题

What happened

我们的项目是一个图片浏览的 App，为了用户有良好的体验效果，会定时在后台下载壁纸数据，且同时会将对应的图片提前下载到本地，等到用户打开App时，不需要再等待图片下载，就可以立即看到图片。但在开发和测试的过程中，会出现下载图片超时错误的情况，而且在最近一次需求中，出现的概率大大增加，所以决心深入 Glide 源码探究。

下载超时 log：

GlideHelper: img download error. url = https://xxxx/wbp,q_auto,h_2276,w_1080,c_fill/https%3A%2F%2Fcdn.xxx.com%2Fstatic%2Fwallpaper%2F3518313389605031946_GETTY_996206592.jpg%3Fut%3D1624552936 
    java.util.concurrent.ExecutionException: java.net.SocketTimeoutException : Read timed out
        at com.bumptech.glide.request.RequestFutureTarget.doGet(RequestFutureTarget.java:189)
        at com.bumptech.glide.request.RequestFutureTarget.get(RequestFutureTarget.java:100)
        at com.xxx.common.glide.GlideHelper.download(GlideHelper.java:61)
        at com.xxx.manager.KSyncStrategyManager.downloadWallpapers(KSyncStrategyManager.java:239)
        at com.xxx.manager.KSyncStrategyManager.startDownloadWallpaperJobs(KSyncStrategyManager.java:60)
        at com.xxx.manager.KSyncStrategyManager.startSyncWallpaperListByUserLikeTag(KSyncStrategyManager.java:117)
        ...

源码分析

先附上我总结的整个源码分析的逻辑图，以下是分析的过程，可能会有冗长，如果想知道如何设置超时时间，可以直接跳到解决方案。

由于我们对 Glide 进行了升级，我对旧版本（3.7.0）和新版本（4.13.0）都进行了分析，两个版本区别不是特别大，以下主要以 4.13.0 来做分析的，最后会把有区别的地方标记在逻辑图中。

我们项目中调用 Glide 的 downloadOnly() 去下载图片：

public static File download(Context context, String url, int timeout) {
   
    ...

    File file = null;

    try {
   
        file = Glide.with(context)
                .load(glideUrl)
                .downloadOnly(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL)
                .get();

    } catch (Exception e) {
   
        LogUtils.e(TAG, "img download error. url = " + url, e);
    }
    return file;
}

首先，我的方式是从 Glide.xxx.get() 开始分析，接下来会调用到 RequestFutureTarget 中的 doGet(xxx)，其中是获取 resource，没有涉及到 SocketTimeoutException 相关超时异常，所以我们还得往上一层去追。

public class RequestFutureTarget<R> implements FutureTarget<R>, RequestListener<R> {
   
  ...

  @Override
  public R get() throws InterruptedException, ExecutionException {
   
    try {
   
      return doGet(null);
    } catch (TimeoutException e) {
   
      throw new AssertionError(e);
    }
  }

  ...

  private synchronized R doGet(Long timeoutMillis) throws ExecutionException, InterruptedException, TimeoutException {
   

    if (assertBackgroundThread && !isDone()) {
   
      Util.assertBackgroundThread();
    }

    if (isCancelled) {
   
      throw new CancellationException();
    } else if (loadFailed) {
   
      throw new ExecutionException(exception);
    } else if (resultReceived) {
   
      return resource;
    }

    // 省略了异常判断
    ...

    return resource;
  }
}

紧接着就开始分析 submit(xxx)，它会调用到 RequestBuilder 中 submit(xxx)，最终调用到 4 个参数的 into(xxx)，通过一步一步分析，其中调用另一个类 RequestManager.track(xxx)，最终会调用到 RequestTracker.runRequest(xxx)，从方法名看感觉像是开始执行请求操作了。

public class RequestBuilder<TranscodeType> extends BaseRequestOptions<RequestBuilder<TranscodeType>> implements Cloneable, ModelTypes<RequestBuilder<TranscodeType>> {
   
    ...
    
    public FutureTarget<TranscodeType> submit(int width, int height) {
   
        final RequestFutureTarget<TranscodeType> target = new RequestFutureTarget<>(width, height);
        return into(target, target, Executors.directExecutor());
    }

    private <Y extends Target<TranscodeType>> Y into(
            @NonNull Y target,
            @Nullable RequestListener<