java - 哪种方式更好地从 http 获取响应？为什么？

Question

我想知道这两种从 http 调用获取响应的方法的一般区别在哪里。

以下是 Android 示例，但在 Java 中是完全相同的。

仅使用org.apache.http库的第一个示例:

String s = "";

try {

    HttpPost httppost = new HttpPost(url);
    HttpClient httpclient = new DefaultHttpClient();
    HttpResponse response = httpclient.execute(httppost);
    HttpEntity entity = response.getEntity();

    s = EntityUtils.toString(entity, HTTP.UTF_8);

    // do something with s      
} catch (Exception e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}

使用 BufferedReader 获取响应的第二个示例:

HttpClient httpclient = new DefaultHttpClient();
HttpGet httpget = new HttpGet(url);
HttpResponse response = httpclient.execute(httpget);
HttpEntity entity = response.getEntity();

InputStream instream = entity.getContent();
BufferedReader bufferedreader = new BufferedReader(new InputStreamReader(
                instream));

try {
    String line;
    StringBuilder sb = new StringBuilder();
    while((line = bufferedreader.readLine()) != null)
            sb.append(line);

        // do something with the stringbuilder

} catch (Exception e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}

在哪些情况下我应该更喜欢使用 Stream 和 Reader 的第二个示例而不是第一个示例，反之亦然？我问这个问题有一些主要的想法。如果有重要的内容未包含，请告诉我:

1. Reader 方法需要更多的空间和时间。
2. 响应数据的大小对第一个或第二个示例没有影响。
3. 第二个示例中的代码更复杂(开销更大)。
4. 由于库中存在大量不同的 Reader，Reader 方法更加灵活。

这一点让我更喜欢第一个例子。

Answer 1

两个版本的性能差异可能不会对应用程序的整体性能产生重大影响。 (如果响应正文非常大，可能很重要，但即使如此，性能也可能由网络延迟和带宽考虑因素主导。)

假设性能差异不太可能很大，另一件事要考虑的是代码的可维护性；即阅读和修改有多容易。我的感觉是第一个版本更简单，因此更容易正确且更易于维护。

---

1) The Reader approach takes way more space and time.

不一定。差异(如果有)在于创建结果字符串之前累积数据的方式。如果 HTTP 响应包含 Content-length header ，则第一个版本可能可以预分配正确大小的byte[]。相比之下，第二个版本在 StringBuilder 中累积数据，这可能需要对构建器的支持数组进行多轮重新分配/复制。 (额外的工作是O(N)，因此它不会改变计算复杂性的总体衡量标准。但它仍然会影响性能......和内存使用。)

2) The size of the response data has no effect on the first or second example.

不正确。它在两种情况下都有影响。 (显然......在这两种情况下，长响应比短响应需要更长的时间来阅读!)

3) The code in the second example is more complicated (has more overhead).

它更复杂，但这并不意味着有更多的开销。在第一种情况下，也很复杂，但它不是您必须编写的代码。但无论如何，简单并不一定意味着更高的效率/更低的开销。这不是性能的运作方式......

4) The Reader approach is way more flexible, because of the amount of different Readers in the library.

无关紧要。在本例中，您已经对 Reader 类做出了很好的选择。灵活性在这里没有任何区别。

---

还有其他问题:

• 两个版本都假设响应正文是文本。
• 第一个版本假设响应正文采用 UTF-8 编码。
• 第二个版本假设响应正文使用(本地)平台的默认编码进行编码。
• 第二个版本吞噬了换行符。这是一个错误。

---

错误说明:readLine() 方法读取一行并返回不带行分隔符的行。然后，您的代码将其添加到 StringBuilder ...而不添加行分隔符。最终结果是 StringBuilder 包含删除了所有行分隔符的数据。哎呀!