Android复盘OkHttp HttpLoggingInterceptor造成的OOM

转载请标明出处：http://blog.csdn.net/zhaoyanjun6/article/details/121903763
本文出自【赵彦军的博客】

前言

最近项目中发生了很多 oom，通过 oom 日志分析来看，都跟 okhttp 有关。经过艰难的分析定位，终于发现了造成 oom 的凶手HttpLoggingInterceptor 。

原因是 HttpLoggingInterceptor 作为 okhttp 请求的过程的日志输出工具, 会把 ResponseBody 里面内容全部读出来，放在内存里。对于普通的网络请求，影响并不大。但是对于下载来说，它会把整个文件读出来，放在内存，就非常容易造成 oom

HttpLoggingInterceptor 简介

该拦截器用于记录应用中的网络请求的信息。

使用：

val okHttpClientBuilder: OkHttpClient.Builder = OkHttpClient.Builder()
        
//创建日志拦截器
val logging = HttpLoggingInterceptor { message -> UtilLog.v("OkHttp", message) }
logging.level = HttpLoggingInterceptor.Level.BODY

//添加日志拦截器
okHttpClientBuilder.addInterceptor(logging)

日志包含4个等级，含四个级别：NONE、BASIC、HEADER、BODY

NONE 不记录

BASIC 请求/响应行
--> POST /greeting HTTP/1.1 (3-byte body)
<-- HTTP/1.1 200 OK (22ms, 6-byte body)

HEADER 请求/响应行 + 头
--> Host: example.com
Content-Type: plain/text
Content-Length: 3
<-- HTTP/1.1 200 OK (22ms)
Content-Type: plain/text
Content-Length: 6

BODY 请求/响应行 + 头 + 体

下载文件请求阶段需要等很久以及OOM

正常请求没什么问题，但是当我使用这个 okhttp 实例去下载文件的时候出现了问题，请求很久才能拿到正文开始下载。

开始我以为是链接的问题，换了之后发现还是这样，经过一番定位（一行行注释），把问题定位到了HttpLoggingInterceptor拦截器上，发现添加了这个拦截器，并且把level设置为Body的时候就会出现这种情况（由于android不允许在主线程请求网络，所以UI没卡），之后经过调试，发现当代码走到以下位置时，就会卡住。

大致原因应该是这里需要将内容全部请求出来。

然而在你下载东西的时候，内容是很多的，那么这里的卡住的时长和文件大小成正比，如果文件太大，内存不够，那么系统会不停地GC去获取更多内存，但是总内存就那么点大，所以这就是个死结，甚至会OOM

当然，这里设置level < Body就好了，但是有些时候会有特殊需求，比如说新加一个拦截器，需要根据服务端返回的数据做不同的处理，这里就要参照 HttpLoggingInterceptor 自定义一个拦截器，buffer复制的地方必定会经过，那么上面的问题就会出现。

解决办法：

• 方法一：就是定义两个 okhttp（retrofit也是两个）实例，一个专门用来下载文件，不加这个拦截器。另外一个专门添加这个拦截器去处理服务器返回数据。

• 方法二：设置 level < Body