一、踩坑速记

1. 未添加header指定服务器采用何种压缩方式导致下载进度异常

描述：使用OkHttp3执行文件下载（服务端有nginx反向代理服务器进行压缩），获取回调中文件总大小为0或负值，导致显示下载进度异常。

1.1 前端解决方案

添加请求头addHeader("Accept-Encoding", "application/octet-stream")或者addHeader("Accept-Encoding", "*") 即可；

addHeader("Accept-Encoding", "application/octet-stream");
addHeader("Accept-Encoding", "*");

1.2 后端解决方案

服务端需要下载的文件更改为.bin后缀（nginx未对bin文件进行压缩，此时返回的数据格式默认是二进制流），当然这样的前提是前端知道要下载的文件是个什么文件，下载完成要自行命名修改后缀为正常后缀，如.apk文件。

2. okhttp请求设置了log拦截器导致下载异常

描述：如果在初始化OkHttpClient 时设置了log拦截器，而且呢设置了HttpLoggingInterceptor.Level = Level.BODY时，会发现监听不到下载的进度了。（文件明明已经在开始下载，但没有进度回调，或者文件下载很长一段时间后才有进度回调）。

2.1 去掉HttpLoggingInterceptor拦截

注释掉HttpLoggingInterceptor的log拦截即可。

//.addInterceptor(mInterceptor);

2.2 设置log级别比BODY级别更低

mInterceptor.setLevel(HttpLoggingInterceptor.Level.BASIC);
mInterceptor.setLevel(HttpLoggingInterceptor.Level.HEADERS);
mInterceptor.setLevel(HttpLoggingInterceptor.Level.NONE);

3. 不继续踩坑的下载库

https://github.com/lingochamp/okdownload/

二、踩坑记录

1. 坑一 Header详细解析

1.1 OkHttp下载文件-Header坑的产生

很久很久以前，具体多久已经记不太清楚了，只记得那是第一次把项目中的请求换成OkHttp，发版之后突然接到客服反馈说用户升级app一直失败，然后抓紧调试以下，发现真的是执行app更新时，发现一直不显示文件大小和进度，已下载文件大小一直是负的，最终下载完成的文件执行安装还会是失败报错；一下子就慌了。

1.2 问题分析

由于过去的时间过于“久远”，分析问题的具体步骤就不可能详细描述了，只记得是用fiddler监控下载过程;尝试下载别的文件如百度/应用宝上的apk文件；分析返回的文件内容和格式。网络管理员、运维、经理、技术总监都参与到了问题的分析讨论和解决方案的制订。

这里说下最后敲定的问题原因：

1. 由于前端升级后不久，nginx也针对网络优化做了一次升级，那么nginx会默认对文件进行压缩以节省网络宽带，并减少网络延迟；而且呢我们的okhttp下载请求没有设置Accept-Encoding指定返回的数据格式，所以此时nginx默认gzip格式压缩返回的Content-Type是text/plain；charset=utf-8即当成文本了;
2. 那么现在okhttp下载器接到的是text文本，相当于把本是apk的文件流转成了text文本传输，这边把文本当文件流再写入到了一个文件里，最后这个文件还能安装吗？哈哈，不能！

1.3 解决方案

上面分析了是nginx把apk文件流当成text文件进行了压缩传输，那么前端请求时主动告诉后台我要的是个什么文件，这样可以吗？

答案是肯定的：通过设置addHeader("Accept-Encoding", "application/octet-stream")，可以指定返回的数据格式是二进制流文件，此时再去执行下载，已经可以正常执行了。后面又尝试了设置支持所有类型("Accept-Encoding", "*")，也是可以的。

本地的代码可以该，那么已经上线的版本怎么处理呢？最后是经理去分析了nginx反向代理的一些配置和流程，发现可以在某个目录下的bin文件不被压缩，于是尝试了将apk文件后缀修改成bin文件，升级到服务器上，将旧版本升级的路径指向了新配置的bin文件，完美的解决了旧版本的更新问题。

2. 坑二HttpLoggingInterceptor详细解析

2.1 OkHttp下载文件-log坑的产生

前几天，网约车的部门经理找我说他手机上司机端升级一直下不下来，因为很久没有提过下载的问题，也没有动下载的代码，没有怀疑是代码问题，所以怀疑是网的问题（ps：公司的公网的网速一直不怎么样）。然后我去拿我手机上模拟器跑一下，发现也好久没见进度往前走，啧啧~想到之前的坑，不会老坑重踩了把。。。赶紧拉代码看了一遍，还好，没有改动记录，header也都设置了，所以不是之前的问题。那么这次又是什么问题呢？

2.2 问题分析

前面简单说了肯定不是header的问题了，于是开始从别的方面找原因。

2.2.1 服务端配置导致文件获取不到文件大小，所以进度无法获取

由于上次跟服务端的nginx反向代理有关，所以这次也优先想到了先排查后端的问题。先咨询了负责运维的同事，表示最近没有升级，但是呢我对比了两个文件在浏览器（360和chrome）的下载过程,如下图所示，BUS365.apk和BUS365.bin是同样大的都是25.1M，但是bin文件可以看到正常的进度和文件总大小，apk文件下载进度异常而且无法获取文件总大小。（从百度手机助手链接下载apk文件同下图中bin文件表现一致，可以显示文件总大小和下载进度）

https://www.bus365.com/public/images/BUS365.bin

https://www.bus365.com/public/phoneClient/BUS365.apk

image.png image.png image.png

2.2.2 不是nginx的原因，是主站服务器告诉nginx要返回的什么数据格式，nginx只是代理转发

网络运维的同事也非常辛苦地配合着自己研究了一上午的时间，最后给我的结果是：“nginx是中间做了转发代理，并不决定返回的数据格式，还得看主站服务，咱们一起去找主站看看把。”(下图中的ContentType是返回结果中的文件格式)。

https://www.bus365.com/public/phoneClient/BUS365.apk

image.png

https://www.bus365.com/public/images/BUS365.bin

image.png

2.2.3 主站只负责业务处理，具体的返回规则是play框架决定的

这次负责主站服务的同事倒是很快给出了结论：“主站只负责业务处理，具体的哪个目录下的文件压缩，支持哪个格式的文件（apk,bin等）不压缩，这些返回规则是play框架决定的，得找技术总监决定修改play框架！”好吧，我们越来越接近业务的“核心”了。。。。。。但是，我只是想，在下载安装包时，能够获取到文件大小和进度的显示啊，我感觉已经越走越远了，有木有？！！！

2.2.4 突发奇想，不上传主站，上传到专门的文件服务器

万分感谢辛苦的运维同事和主站后台服务同事的配合，回去边写邮件想着怎么去说动技术总监去改play框架来满足咱们的需求，边跟经理交流下这个问题，经理提出来可以先把安装包传文件服务器试一下，这简单啊，又不费啥事儿，马上传上去，得到文件服务器上的下载路径。https://mraw.bus365.cn/files/group1/M00/00/F8/wKgDEl-X5nGAQMxkAe7MXjwMMyU347.apk,嘿，在浏览器下载真的有进度和总大小了。

image.png

2.2.5 以为找到了钥匙，却打不开“紧锁的大门”

满心欢喜以为，安装包上传文件服务器就可以圆满解决问题了，跟运维沟通后得知：1，文件服务器没有做cdn缓存，所以下载速度并不快；2，文件服务器每次上传都是新地址，旧的不会自动删除，不建议放大文件，更何况需要大批量的下载的升级类文件；3，更重要的时，当我把文件服务器的下载链接放到司机端中执行下载时，依然很久没有进度回调。。。

2.2.6 柳暗花明又一村，找到真正的原因

搜okhttp下载进度关键词时，看到了这篇浏览量极小的文章：okHttp3 下载进度监听 踩坑https://blog.csdn.net/boxing012/article/details/105316216，文中提到了

如果在初始化OkHttpClient 时设置了log拦截器，不管拦截器的级别是什么，监听到的进度都不正常（文件已经在开始下载，但没有进度回调，文件下载一段时间后才有进度）

当然这段话还是有一定问题的，后面分析会说明，不过有一点时对的，就是okHttpClient设置了log拦截器后，会导致进度回调失败。回头看司机端的初始化代码中，确实发现有设置HttpLoggingInterceptor，当注释掉.addInterceptor(logging)后，下载更新的进度就正常了。

HttpLoggingInterceptor logging = new HttpLoggingInterceptor();
        logging.setLevel(HttpLoggingInterceptor.Level.BODY);
        OkHttpClient okHttpClient = new OkHttpClient.Builder()
                .connectTimeout(GlobalUrlConfig.HTTP_TIMEOUT, TimeUnit.MILLISECONDS)
                .readTimeout(GlobalUrlConfig.HTTP_TIMEOUT, TimeUnit.MILLISECONDS)
                .addInterceptor(logging)
                .hostnameVerifier(new HostnameVerifier() {
                    @Override
                    public boolean verify(String hostname, SSLSession session) {
                        return true;
                    }
                })
                .build();
        OkHttpUtils.initClient(okHttpClient);

2.2.7 问题原因找到了，分析下HttpLoggingInterceptor为什么会导致下载进度失败呢？

既然问题出现在HttpLoggingInterceptor身上，肯定需要分析HttpLoggingInterceptor的源码，其它地方就先不用看了，直接看intercept();

  @Override
  public Response intercept(Chain chain) throws IOException {
    Level level = this.level;

    Request request = chain.request();
    if (level == Level.NONE) {
      return chain.proceed(request);
    }

    boolean logBody = level == Level.BODY;
    boolean logHeaders = logBody || level == Level.HEADERS;

    RequestBody requestBody = request.body();
    boolean hasRequestBody = requestBody != null;

    Connection connection = chain.connection();
    String requestStartMessage = "--> "
            + request.method()
            + ' ' + request.url()
            + (connection != null ? " " + connection.protocol() : "");
    if (!logHeaders && hasRequestBody) {
      requestStartMessage += " (" + requestBody.contentLength() + "-byte body)";
    }
    logger.log(requestStartMessage);

    if (logHeaders) {
      if (hasRequestBody) {
        // Request body headers are only present when installed as a network interceptor. Force
        // them to be included (when available) so there values are known.
        if (requestBody.contentType() != null) {
          logger.log("Content-Type: " + requestBody.contentType());
        }
        if (requestBody.contentLength() != -1) {
          logger.log("Content-Length: " + requestBody.contentLength());
        }
      }

      Headers headers = request.headers();
      for (int i = 0, count = headers.size(); i < count; i++) {
        String name = headers.name(i);
        // Skip headers from the request body as they are explicitly logged above.
        if (!"Content-Type".equalsIgnoreCase(name) && !"Content-Length".equalsIgnoreCase(name)) {
          logHeader(headers, i);
        }
      }

      if (!logBody || !hasRequestBody) {
        logger.log("--> END " + request.method());
      } else if (bodyHasUnknownEncoding(request.headers())) {
        logger.log("--> END " + request.method() + " (encoded body omitted)");
      } else {
        Buffer buffer = new Buffer();
        requestBody.writeTo(buffer);

        Charset charset = UTF8;
        MediaType contentType = requestBody.contentType();
        if (contentType != null) {
          charset = contentType.charset(UTF8);
        }

        logger.log("");
        if (isPlaintext(buffer)) {
          logger.log(buffer.readString(charset));
          logger.log("--> END " + request.method()
                  + " (" + requestBody.contentLength() + "-byte body)");
        } else {
          logger.log("--> END " + request.method() + " (binary "
                  + requestBody.contentLength() + "-byte body omitted)");
        }
      }
    }

    long startNs = System.nanoTime();
    Response response;
    try {
      response = chain.proceed(request);
    } catch (Exception e) {
      logger.log("<-- HTTP FAILED: " + e);
      throw e;
    }
    long tookMs = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNs);

    ResponseBody responseBody = response.body();
    long contentLength = responseBody.contentLength();
    String bodySize = contentLength != -1 ? contentLength + "-byte" : "unknown-length";
    logger.log("<-- "
            + response.code()
            + (response.message().isEmpty() ? "" : ' ' + response.message())
            + ' ' + response.request().url()
            + " (" + tookMs + "ms" + (!logHeaders ? ", " + bodySize + " body" : "") + ')');

    if (logHeaders) {
      Headers headers = response.headers();
      for (int i = 0, count = headers.size(); i < count; i++) {
        logHeader(headers, i);
      }

      if (!logBody || !HttpHeaders.hasBody(response)) {
        logger.log("<-- END HTTP");
      } else if (bodyHasUnknownEncoding(response.headers())) {
        logger.log("<-- END HTTP (encoded body omitted)");
      } else {
        BufferedSource source = responseBody.source();
        source.request(Long.MAX_VALUE); // Buffer the entire body.
        Buffer buffer = source.buffer();

        Long gzippedLength = null;
        if ("gzip".equalsIgnoreCase(headers.get("Content-Encoding"))) {
          gzippedLength = buffer.size();
          GzipSource gzippedResponseBody = null;
          try {
            gzippedResponseBody = new GzipSource(buffer.clone());
            buffer = new Buffer();
            buffer.writeAll(gzippedResponseBody);
          } finally {
            if (gzippedResponseBody != null) {
              gzippedResponseBody.close();
            }
          }
        }

        Charset charset = UTF8;
        MediaType contentType = responseBody.contentType();
        if (contentType != null) {
          charset = contentType.charset(UTF8);
        }

        if (!isPlaintext(buffer)) {
          logger.log("");
          logger.log("<-- END HTTP (binary " + buffer.size() + "-byte body omitted)");
          return response;
        }

        if (contentLength != 0) {
          logger.log("");
          logger.log(buffer.clone().readString(charset));
        }

        if (gzippedLength != null) {
          logger.log("<-- END HTTP (" + buffer.size() + "-byte, "
                  + gzippedLength + "-gzipped-byte body)");
        } else {
          logger.log("<-- END HTTP (" + buffer.size() + "-byte body)");
        }
      }
    }

    return response;
  }

我们注意到

requestBody.writeTo(buffer);

source.request(Long.MAX_VALUE); // Buffer the entire body.

这两行，一个是操作请求的body，一个是操作结果的body，后一行操作结果的地方还给了一个最大值。这会有什么问题呢，如果你在这里打断点会发现，下载文件的请求，走到这里竟然“不执行了”，其实是卡在这里了（至于为什么没有卡死UI，因为是开启了线程执行的）。这里需要将内容全部请求出来，然后方便后面的复制buffer，然而在你下载东西的时候，内容是很多的（几M,几十M，甚至几百M），那么这里的卡住的时长和文件大小成正比，如果文件太大，内存不够，那么系统会不停地GC去获取更多内存，甚至可能会发生OOM。这就是为什么一直没有进度回调的原因了，因为：这里日志还没打印完成，而日志打印完成的前提是文件下载完成，所以直到文件完成下载，你才有可能接收到进度的回调（同理：打印requestbody会影响上传进度回调）。

image.png image.png

再往上看logBody是何许人也？logBody是判断打印的level是否是Level.BODY,所以，当你设置级别为header、basic、none时，代码执行到上面的条件ogger.log("<-- END HTTP");就不会执行body的复制和打印了，进而不会产生下载进度条不变的问题了。

image.png

2.3 解决方案

上面分析了是HttpLoggingInterceptor拦截了body去执行打印去了，影响了进度的回调，所以解决方案也很简单：1，取消log拦截器(addInterceptor)；2，设置更低级别的拦截（HttpLoggingInterceptor.Level.BASIC）。两个方案都可以很好的解决这个问题。

HttpLoggingInterceptor logging = new HttpLoggingInterceptor();
        logging.setLevel(HttpLoggingInterceptor.Level.BASIC);
        OkHttpClient okHttpClient = new OkHttpClient.Builder()
                .connectTimeout(GlobalUrlConfig.HTTP_TIMEOUT, TimeUnit.MILLISECONDS)
                .readTimeout(GlobalUrlConfig.HTTP_TIMEOUT, TimeUnit.MILLISECONDS)
                //.addInterceptor(logging)
                .hostnameVerifier(new HostnameVerifier() {
                    @Override
                    public boolean verify(String hostname, SSLSession session) {
                        return true;
                    }
                })
                .build();
        OkHttpUtils.initClient(okHttpClient);

但是某个人就会问了：HttpLoggingInterceptor这么方便的拦截器，我用来打印后台返回的结果多方便啊，这body都不让拦截了，不行我就想要用！呵呵，没遭遇过社会的毒打💪💪💪。

那么能不能满足某个人的需求呢，当然可以：就是定义两个OkHttpClient实例对象，一个专门用来下载文件，这个不加拦截器，或者HttpLoggingInterceptor的level < Body就好了；另外一个专门处理网络请求的添加BODY级别的拦截器去处理服务器返回的数据，这样就没有问题了。

三、脱坑推荐

下载文件作为APP中最常用的功能之一，在github上已经有非常成熟的开源框架，不喜欢踩坑的可以尝试站在“巨人”的肩膀上去鸟瞰整个世界。这里推荐一个稳定、高效、灵活、简单易用的Android 文件下载引擎。单一个下载功能的安卓库，星星数都能破万，已经无需再去介绍它的魅力，直接移步github去试用即可。

1代地址：https://github.com/lingochamp/FileDownloader

2代地址：https://github.com/lingochamp/okdownload/

特点：

• 简单易用
• 单任务多线程/多连接/分块下载(并支持通过ConnectionCountAdapter定制)
• 高并发
• 灵活
• 可选择性支持: 独立/非独立进程
• 自动断点续传

参考

https://blog.csdn.net/sese12138/article/details/106019355

https://blog.csdn.net/boxing012/article/details/105316216