Recently, I was studying the source code of the Volley framework and found that its use of HTTP requests is quite interesting. In Android 2.3 and above, HttpURLConnection is used, while in Android 2.2 and below, HttpClient is used. I was also curious about the reason for using it this way, so I found a blog written by a Google engineer. The article compared HttpURLConnection and HttpClient. I will briefly translate it for you below.
Original address: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
Most Android applications use the HTTP protocol to send and receive network data, and Android mainly provides two There are three ways to perform HTTP operations, HttpURLConnection and HttpClient. Both methods support HTTPS protocol, upload and download in the form of streams, configure timeout, IPv6, and connection pooling.
HttpClientDefaultHttpClient and its brother AndroidHttpClient are both specific implementation classes of HttpClient. They both have many APIs, and their implementation is relatively stable and has few bugs.
But at the same time, due to the large number of HttpClient APIs, it is difficult for us to upgrade and expand it without destroying compatibility. Therefore, the current Android team is not active in improving and optimizing HttpClient.
HttpURLConnectionHttpURLConnection is a multi-purpose, lightweight HTTP client that can be used to perform HTTP operations and is suitable for most applications. Although the API provided by HttpURLConnection is relatively simple, it also makes it easier for us to use and extend it.
However, before Android version 2.2, HttpURLConnection always had some annoying bugs. For example, when the close() method is called on a readable InputStream, it may cause the connection pool to fail. Then our usual solution is to directly disable the connection pool function:
[java] view plaincopy
private void disableConnectionReuseIfNecessary() {
// This is a bug before version 2.2
if (Integer.parseInt(Build.VERSION.SDK) < Build.VERSION_CODES.FROYO) {
System.setProperty("http.keepAlive" , "false");
}
}
In Android 2.3, we added more transparent response compression. HttpURLConnection will automatically add the following header to each request made and process the corresponding return result: Accept-Encoding: gzip
configure your web server to support the function of compressing the client's response, so that you can build on this improvement. Get maximum benefits. If you have problems compressing responses, this document will tell you how to disable this feature.
However, if the response compression function is enabled, the Content-Length in the HTTP response header will represent the compressed length. At this time, it is wrong to use the getContentLength() method to retrieve the decompressed data. The correct approach should be to keep calling the InputStream.read() method to read the response data until -1 appears.
We have also added some HTTPS improvements in Android 2.3. Now HttpsURLConnection will use SNI (Server Name Indication) to connect, so that multiple HTTPS hosts can share the same IP address. In addition, some compression and session mechanisms have been added. If the connection fails, it will automatically try to reconnect. This allows HttpsURLConnection to connect to the latest servers more efficiently without destroying compatibility with older versions.
In Android 4.0 version, we have added some response caching mechanisms. When the cache is installed (calling the install() method of HttpResponseCache), all HTTP requests will meet the following three conditions:
All cached responses are provided by local storage. Because there is no need to initiate a network connection request for the task, all responses are available immediately.
Contingent cached responses must be checked by the server for updates. For example, if the client initiates a request similar to "If the picture /foo.png changes, send it to me", the server needs to return the updated data, or return a 304 Not Modified status. . If the requested content does not occur, the client will not download any data.
Uncached responses are served directly from the server. This part of the response is later stored in the response cache.
Since this function is only available in versions after 4.0, we can usually use reflection to start the response caching function. The following sample code shows how to enable response caching in Android 4.0 and later versions without affecting previous versions: [java]
view plaincopy
private void enableHttpResponseCache() {
try {
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
File httpCacheDir = new File(getCacheDir(), "http");
Class.forName("android.net.http.HttpResponseCache")
.getMethod("install", File.class, long.class)
.invoke(null, httpCacheDir, httpCacheSize);
} catch (Exception httpResponseCacheNotAvailable) {
}
}
You should also configure your web server and add it to the HTTP response Cached headers. Which one is the best? Prior to Android 2.2, HttpClient had fewer bugs, so using it was the best option.
In Android version 2.3 and later, HttpURLConnection is the best choice. Its API is simple and its size is small, making it very suitable for Android projects. Compression and caching mechanisms can effectively reduce network access traffic and also play a major role in improving speed and saving power. For new applications, we should be more inclined to use HttpURLConnection, because we will also spend more time optimizing HttpURLConnection in future work.