모두가 OkHttp를 사용했거나 접해본 적이 있을 것입니다. 최근 Okhttp를 사용하면서 함정에 빠졌습니다. 나중에 비슷한 문제가 발생하면 우회할 수 있도록 여기에 공유하겠습니다. 문제는 충분하지 않습니다. 이 기사는 소스 코드 관점에서 문제의 근원을 분석하는 데 중점을 두고 유용한 정보로 가득 차 있습니다.
1. 문제 발견개발 중에 OkHttpClient 개체를 구성하여 요청을 시작하고 이를 대기열에 추가했는데, 콜백 인터페이스가 onResponse() 메서드를 트리거한 후 전달되었습니다. 이 메서드의 응답 개체 처리는 결과를 반환하고 비즈니스 논리를 구현합니다. 코드는 대략 다음과 같습니다.
//注:为聚焦问题,删除了无关代码 getHttpClient().newCall(request).enqueue(new Callback() { @Override public void onFailure(Call call, IOException e) {} @Override public void onResponse(Call call, Response response) throws IOException { if (BuildConfig.DEBUG) { Log.d(TAG, "onResponse: " + response.body().toString()); } //解析请求体 parseResponseStr(response.body().string()); } });
onResponse()에서는 디버깅의 편의를 위해 반환 본문을 인쇄한 다음, 반환 본문을 parsResponseStr() 메서드를 통해 구문 분석했습니다(참고: response.body().string( ) 여기서는 두 번 호출됩니다) .
문제가 없을 것 같았던 이 코드는 실제로 실행 후 오류가 발생했습니다. 콘솔을 통해 반환 본문 데이터(json)가 성공적으로 인쇄된 것을 확인했지만 예외가 발생했습니다:
java.lang.IllegalStateException: closed
2. 문제를 해결해보세요코드를 확인해보니,parseResponseStr() 호출시 response.body().string()이 다시 파라미터로 사용되는 것이 문제인 것을 발견했습니다. 급해서 온라인으로 확인해 보니 response.body().string()은 한 번만 호출할 수 있다는 것을 알고 onResponse() 메서드의 로직을 수정하여 문제를 해결했습니다.
getHttpClient().newCall(request).enqueue(new Callback() { @Override public void onFailure(Call call, IOException e) {} @Override public void onResponse(Call call, Response response) throws IOException { //此处,先将响应体保存到内存中 String responseStr = response.body().string(); if (BuildConfig.DEBUG) { Log.d(TAG, "onResponse: " + responseStr); } //解析请求体 parseReponseStr(responseStr); } });
3 . 소스코드로 문제를 분석하세요 문제는 해결됐지만, 이후에도 분석이 필요합니다. 이전에 OkHttp에 대한 이해는 사용에 국한되어 있었고 내부 구현의 세부 사항을 주의 깊게 분석하지 않았기 때문에 주말 동안 시간을 내어 살펴보고 문제의 원인을 파악했습니다.
가장 직관적인 질문을 먼저 분석해 보겠습니다. 왜 response.body().string()은 한 번만 호출할 수 있나요?
디스어셈블리를 보면 먼저 response.body()를 통해 ResponseBody 객체(추상 클래스이므로 여기서는 특정 구현 클래스에 대해 신경 쓸 필요가 없습니다)를 가져온 다음 ResponseBody의 string() 메서드를 호출합니다. 응답 본문의 내용을 가져옵니다.
분석 후 body() 메서드에는 문제가 없습니다. string() 메서드를 살펴보겠습니다.
public final String string() throws IOException { return new String(bytes(), charset().name()); }
매우 간단합니다. byte() 메서드에서 반환된 byte[] 배열을 다음과 같이 변환합니다. 문자 집합(charset) 지정 및 구성 문제 없습니다. 계속해서 byte() 메서드를 살펴보세요.
public final byte[] bytes() throws IOException { //... BufferedSource source = source(); byte[] bytes; try { bytes = source.readByteArray(); } finally { Util.closeQuietly(source); } //... return bytes; } //... 表示删减了无关代码,下同。
byte() 메서드에서 BufferedSource 인터페이스 개체를 통해 byte[] 배열을 읽고 반환합니다. 위에서 언급한 예외와 결합하여 finally 코드 블록에서 Util.closeQuietly() 메서드를 발견했습니다. 실례합니다? 조용히 닫으시겠습니까? ? ?
이 메서드가 이상해 보이는데 맞나요? 후속 조치를 취하고 살펴보세요:
public static void closeQuietly(Closeable closeable) { if (closeable != null) { try { closeable.close(); } catch (RuntimeException rethrown) { throw rethrown; } catch (Exception ignored) { } } }
코드 문서 주석에 따르면 위에서 언급한 BufferedSource 인터페이스는 Closeable을 구현하는 리소스 버퍼로 이해될 수 있습니다. 리소스를 닫고 해제하기 위해 close() 메소드를 복사하여 인터페이스. 그런 다음 close() 메서드가 수행하는 작업을 살펴보세요(현재 시나리오에서 BufferedSource 구현 클래스는 RealBufferedSource입니다).
//持有的 Source 对象 public final Source source; @Override public void close() throws IOException { if (closed) return; closed = true; source.close(); buffer.clear(); }
분명히 리소스는 source.close()를 통해 닫히고 해제됩니다. 말하자면, closeQuietly() 메서드의 기능은 자명합니다. 이는 ResponseBody 하위 클래스가 보유하는 BufferedSource 인터페이스 객체를 닫는 것입니다.
분석의 이 시점에서 우리는 갑자기 response.body().string()을 호출할 때 OkHttp가 응답 본문의 버퍼 리소스를 반환하고 closeQuietly() 메서드를 호출하여 자동으로 해제한다는 사실을 깨달았습니다. 자원.
이런 식으로 string() 메서드를 다시 호출하면 여전히 위의 byte() 메서드로 돌아갑니다. 이번에는 bytes = source.readByteArray() 코드 줄에 문제가 있습니다. RealBufferedSource의 readByteArray() 메서드를 살펴보겠습니다.
@Override public byte[] readByteArray() throws IOException { buffer.writeAll(source); return buffer.readByteArray(); }
writeAll() 메서드를 계속 살펴보세요.
@Override public long writeAll(Source source) throws IOException { //... long totalBytesRead = 0; for (long readCount; (readCount = source.read(this, Segment.SIZE)) != -1; ) { totalBytesRead += readCount; } return totalBytesRead; }
문제는 for 루프의 source.read()에 있습니다. 위의 close() 메서드를 분석할 때 리소스를 닫고 해제하기 위해 source.close()를 호출했다는 사실을 기억하세요. 따라서 read() 메서드가 다시 호출되면 어떻게 될까요?
@Override public long read(Buffer sink, long byteCount) throws IOException { //... if (closed) throw new IllegalStateException("closed"); //... return buffer.read(sink, toRead); }
이 시점에서는 이전에 발생한 충돌과 일치합니다.
java.lang.IllegalStateException: closed
4 OkHttp는 왜 이렇게 설계되었나요? 소스 코드를 망쳐 문제의 근본 원인을 찾았지만 여전히 질문이 있습니다. OkHttp는 왜 이렇게 설계되었나요?
사실 이 문제를 이해하는 가장 좋은 방법은 JakeWharton이 문제에 대해 응답한 것처럼 ResponseBody의 주석 문서를 보는 것입니다.
reply of JakeWharton in okhttp issues
간단한 문장으로: ResponseBody에 문서화되어 있습니다. 그래서 저는 클래스 주석 문서를 읽기 위해 달려갔습니다. , 최종 요약은 다음과 같습니다.
在实际开发中,响应主体 RessponseBody 持有的资源可能会很大,所以 OkHttp 并不会将其直接保存到内存中,只是持有数据流连接。只有当我们需要时,才会从服务器获取数据并返回。同时,考虑到应用重复读取数据的可能性很小,所以将其设计为 一次性流(one-shot) ,读取后即 '关闭并释放资源'。
5.总结
最后,总结以下几点注意事项,划重点了:
1.响应体只能被使用一次;
2.响应体必须关闭:值得注意的是,在下载文件等场景下,当你以 response.body().byteStream() 形式获取输入流时,务必通过 Response.close() 来手动关闭响应体。
3.获取响应体数据的方法:使用 bytes() 或 string() 将整个响应读入内存;或者使用 source() , byteStream() , charStream() 方法以流的形式传输数据。
4.以下方法会触发关闭响应体:
Response.close() Response.body().close() Response.body().source().close() Response.body().charStream().close() Response.body().byteString().close() Response.body().bytes() Response.body().string()
上面是我整理给大家的,希望今后会对大家有帮助。
相关文章:
위 내용은 response.body().string()을 여러 번 호출할 수 없는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!