ok，这样我们就把glide中的http通讯组件成功替换成okhttp了。

实现下载进度监听

那么，将http通讯组件替换成okhttp之后，我们又该如何去实现监听下载进度的功能呢？这就要依靠okhttp强大的拦截器机制了。

我们只要向okhttp中添加一个自定义的拦截器，就可以在拦截器中捕获到整个http的通讯过程，然后加入一些自己的逻辑来计算下载进度，这样就可以实现下载进度监听的功能了。

拦截器属于okhttp的高级功能，不过即使你之前并没有接触过拦截器，我相信你也能轻松看懂本篇文章的，因为它本身并不难。

确定了实现思路之后，那我们就开始动手吧。首先创建一个没有任何逻辑的空拦截器，新建progressinterceptor类并实现interceptor接口，代码如下所示：

public class progressinterceptor implements interceptor { 

 @override 
 public response intercept(chain chain) throws ioexception {
  request request = chain.request(); 
  response response = chain.proceed(request); 
  return response; 
 } 

}

这个拦截器中我们可以说是什么都没有做。就是拦截到了okhttp的请求，然后调用proceed()方法去处理这个请求，最终将服务器响应的response返回。

接下来我们需要启用这个拦截器，修改myglidemodule中的代码，如下所示：

public class myglidemodule implements glidemodule { 
 @override 
 public void applyoptions(context context, glidebuilder builder) { 
 } 

 @override 
 public void registercomponents(context context, glide glide) { 
  okhttpclient.builder builder = new okhttpclient.builder(); 
  builder.addinterceptor(new progressinterceptor()); 
  okhttpclient okhttpclient = builder.build(); 
  glide.register(glideurl.class, inputstream.class, new okhttpglideurlloader.factory(okhttpclient));
 } 
}

这里我们创建了一个okhttpclient.builder，然后调用addinterceptor()方法将刚才创建的progressinterceptor添加进去，最后将构建出来的新okhttpclient对象传入到okhttpglideurlloader.factory中即可。

好的，现在自定义的拦截器已经启用了，接下来就可以开始去实现下载进度监听的具体逻辑了。首先新建一个progresslistener接口，用于作为进度监听回调的工具，如下所示：

public interface progresslistener {

 void onprogress(int progress);

}

然后我们在progressinterceptor中加入注册下载监听和取消注册下载监听的方法。修改progressinterceptor中的代码，如下所示：

public class progressinterceptor implements interceptor { 

 static final map listener_map = new hashmap<>();

 public static void addlistener(string url, progresslistener listener) {
  listener_map.put(url, listener); 
 } 

 public static void removelistener(string url) { 
  listener_map.remove(url); 
 } 

 @override 
 public response intercept(chain chain) throws ioexception { 
  request request = chain.request(); 
  response response = chain.proceed(request); 
  return response; 
 } 

}

可以看到，这里使用了一个map来保存注册的监听器，map的键是一个url地址。之所以要这么做，是因为你可能会使用glide同时加载很多张图片，而这种情况下，必须要能区分出来每个下载进度的回调到底是对应哪个图片url地址的。

接下来就要到今天最复杂的部分了，也就是下载进度的具体计算。我们需要新建一个progressresponsebody类，并让它继承自okhttp的responsebody，然后在这个类当中去编写具体的监听下载进度的逻辑，代码如下所示：

public class progressresponsebody extends responsebody {

 private static final string tag = "progressresponsebody";

 private bufferedsource bufferedsource;

 private responsebody responsebody;

 private progresslistener listener;

 public progressresponsebody(string url, responsebody responsebody) {
  this.responsebody = responsebody;
  listener = progressinterceptor.listener_map.get(url);
 }

 @override
 public mediatype contenttype() {
  return responsebody.contenttype();
 }

 @override
 public long contentlength() {
  return responsebody.contentlength();
 }

 @override 
 public bufferedsource source() {
  if (bufferedsource == null) {
bufferedsource = okio.buffer(new progresssource(responsebody.source()));
  }
  return bufferedsource;
 }

 private class progresssource extends forwardingsource {

  long totalbytesread = 0;

  int currentprogress;

  progresssource(source source) {
super(source);
  }

  @override 
  public long read(buffer sink, long bytecount) throws ioexception {
long bytesread = super.read(sink, bytecount);
long fulllength = responsebody.contentlength();
if (bytesread == -1) {
 totalbytesread = fulllength;
} else {
 totalbytesread += bytesread;
}
int progress = (int) (100f * totalbytesread / fulllength);
log.d(tag, "download progress is " + progress);
if (listener != null && progress != currentprogress) {
 listener.onprogress(progress);
}
if (listener != null && totalbytesread == fulllength) {
 listener = null;
}
currentprogress = progress;
return bytesread;
  }
 }

}

其实这段代码也不是很难，下面我来简单解释一下。首先，我们定义了一个progressresponsebody的构造方法，该构造方法中要求传入一个url参数和一个responsebody参数。那么很显然，url参数就是图片的url地址了，而responsebody参数则是okhttp拦截到的原始的responsebody对象。然后在构造方法中，我们调用了progressinterceptor中的listener_map来去获取该url对应的监听器回调对象，有了这个对象，待会就可以回调计算出来的下载进度了。

由于继承了responsebody类之后一定要重写contenttype()、contentlength()和source()这三个方法，我们在contenttype()和contentlength()方法中直接就调用传入的原始responsebody的contenttype()和contentlength()方法即可，这相当于一种委托模式。但是在source()方法中，我们就必须加入点自己的逻辑了，因为这里要涉及到具体的下载进度计算。

那么我们具体看一下source()方法，这里先是调用了原始responsebody的source()方法来去获取source对象，接下来将这个source对象封装到了一个progresssource对象当中，最终再用okio的buffer()方法封装成bufferedsource对象返回。

那么这个progresssource是什么呢？它是一个我们自定义的继承自forwardingsource的实现类。forwardingsource也是一个使用委托模式的工具，它不处理任何具体的逻辑，只是负责将传入的原始source对象进行中转。但是，我们使用progresssource继承自forwardingsource，那么就可以在中转的过程中加入自己的逻辑了。

可以看到，在progresssource中我们重写了read()方法，然后在read()方法中获取该次读取到的字节数以及下载文件的总字节数，并进行一些简单的数学计算就能算出当前的下载进度了。这里我先使用log工具将算出的结果打印了一下，再通过前面获取到的回调监听器对象将结果进行回调。

好的，现在计算下载进度的逻辑已经完成了，那么我们快点在拦截器当中使用它吧。修改progressinterceptor中的代码，如下所示：

public class progressinterceptor implements interceptor { 

 ... 

 @override 
 public response intercept(chain chain) throws ioexception { 
  request request = chain.request(); 
  response response = chain.proceed(request); 
  string url = request.url().tostring(); 
  responsebody body = response.body(); 
  response newresponse = response.newbuilder().body(new progressresponsebody(url, body)).build();
  return newresponse; 
 } 

}

这里也都是一些okhttp的简单用法。我们通过response的newbuilder()方法来创建一个新的response对象，并把它的body替换成刚才实现的progressresponsebody，最终将新的response对象进行返回，这样计算下载进度的逻辑就能生效了。

代码写到这里，我们就可以来运行一下程序了。现在无论是加载任何网络上的图片，都应该是可以监听到它的下载进度的。

修改activity_main.xml中的代码，如下所示：

很简单，这里使用了一个button按钮来加载图片，使用了一个imageview来展示图片。

然后修改mainactivity中的代码，如下所示：

public class mainactivity extends appcompatactivity { 

 string url = "https://guolin.tech/book.png"; 

 imageview image; 

 @override 
 protected void oncreate(bundle savedinstancestate) { 
  super.oncreate(savedinstancestate); 
  setcontentview(r.layout.activity_main); 
  image = (imageview) findviewbyid(r.id.image); 
 } 

 public void loadimage(view view) { 
  glide.with(this) 
 .load(url) 
 .diskcachestrategy(diskcachestrategy.none)
 .override(target.size_original, target.size_original)
 .into(image); 
 } 
}

现在就可以运行一下程序了，效果如下图所示。

ok，图片已经加载出来了。那么怎么验证有没有成功监听到图片的下载进度呢？还记得我们刚才在progressresponsebody中加的打印日志吗？现在只要去logcat中观察一下就知道了，如下图所示：

由此可见，下载进度监听功能已经成功实现了。

进度显示

虽然现在我们已经能够监听到图片的下载进度了，但是这个进度目前还只能显示在控制台打印当中，这对于用户来说是没有任何意义的，因此我们下一步就是要想办法将下载进度显示到界面上。

现在修改mainactivity中的代码，如下所示：

public class mainactivity extends appcompatactivity {

 string url = "https://guolin.tech/book.png";

 imageview image;

 progressdialog progressdialog;

 @override
 protected void oncreate(bundle savedinstancestate) {
  super.oncreate(savedinstancestate);
  setcontentview(r.layout.activity_main);
  image = (imageview) findviewbyid(r.id.image);
  progressdialog = new progressdialog(this);
  progressdialog.setprogressstyle(progressdialog.style_horizontal);
  progressdialog.setmessage("加载中"); 
 }

 public void loadimage(view view) {
  progressinterceptor.addlistener(url, new progresslistener() {
@override
public void onprogress(int progress) {
 progressdialog.setprogress(progress);
}
  });
  glide.with(this)
 .load(url)
 .diskcachestrategy(diskcachestrategy.none)
 .override(target.size_original, target.size_original)
 .into(new glidedrawableimageviewtarget(image) {
  @override
  public void onloadstarted(drawable placeholder) {
super.onloadstarted(placeholder);
progressdialog.show();
  }

  @override 
  public void onresourceready(glidedrawable resource, glideanimation animation) {
super.onresourceready(resource, animation);
progressdialog.dismiss();
progressinterceptor.removelistener(url);
  }
 });
 }

代码并不复杂。这里我们新增了一个progressdialog用来显示下载进度，然后在loadimage()方法中，调用了progressinterceptor.addlistener()方法来去注册一个下载监听器，并在onprogress()回调方法中更新当前的下载进度。

最后，glide的into()方法也做了修改，这次是into到了一个glidedrawableimageviewtarget当中。我们重写了它的onloadstarted()方法和onresourceready()方法，从而实现当图片开始加载的时候显示进度对话框，当图片加载完成时关闭进度对话框的功能。

现在重新运行一下程序，效果如下图所示。

当然，不仅仅是静态图片，体积比较大的gif图也是可以成功监听到下载进度的。比如我们把图片的url地址换成https://guolin.tech/test.gif，重新运行程序，效果如下图所示。

好了，这样我们就把带进度的glide图片加载功能完整地实现了一遍。虽然这个例子当中的界面都比较粗糙，下载进度框也是使用的最简陋的，不过只要将功能学会了，界面那都不是事，大家后期可以自己进行各种界面优化。

最后，如果你想要下载完整的demo，请点击这里。

写了大半年的一个系列就这么要结束了，突然还有一点点小不舍。如果大家能将整个系列的七篇文章都很好地掌握了，那么现在自称为glide高手应该不算过分。

其实在刚打算写这个系列的时候，我是准备写八篇文章，结果最后满打满算就只写出了七篇。那么为了兑现自己当初八篇的承诺，我准备最后一篇写一下关于glide 4.0版本的用法，顺便让我自己也找个契机去研究一下新版本。当然，这并不是说glide 3.7版本就已经淘汰了，事实上，glide 3.7版本十分稳定，而且还能几乎完全满足我平时开发的所有需求，是可以长期使用下去的一个版本。