项目经验,如需转载,请注明作者:Yuloran (t.cn/EGU6c76)
前言
这个 bug 本不应该定位这么久,只是最近状态实在是太差了,无论是心理上还是身体上,都感觉非常的疲惫。
Bug 现象
使用 RxDownload2
下载文件时,要等很久(平均6s以上),才开始刷新进度。
定位分析
从理论上看,使用 @Streaming
的方式下载文件,在与服务器建立连接后应当立即返回,只有从输入流开始读数据时才会阻塞。但是,现在下载进度刷新需要等待这么久,看起来像是已经下完了才开始刷新。从 okhttp
的日志看,这段时间确实是发起 GET请求
到 End Http
的时间,那么这期间肯定出了什么问题。okhttp
框架应该不会有问题,那只能是我们的拦截器有问题,如果拦截器中调用了读取数据的方法,就会导致阻塞。
Bug 原因
嗯,加解密拦截器、日志拦截器中都调用了 response.body() 方法,所以导致了阻塞。
Bug 修复
分析业务,下载文件时无需对报文进行加解密,所以删掉即可。同时重写一个针对下载的日志拦截器,不调用 response.body() 方法,就解决了。
其它
哈哈,定位这个问题哪有上面说的这么简单,项目原因就不多说了。
附
RxDownload2 系列文章: