http://www.trinea.cn/android/mobile-performance-optimization/
A network request can be simply divided into two parts: connecting to the server -> getting data.
The process of DNS resolution is also included before connecting to the server; the data may be cached after the data is obtained.
1. Connection server optimization strategy
1. Use IP direct connection instead of domain name.
The DNS resolution process is omitted. The full name of DNS is Domain Name System, and resolution means obtaining the corresponding IP address according to the domain name. For example, the domain name resolution result of http://www.codekk.com is 104.236.147.76.
The first domain name resolution usually takes hundreds of milliseconds, but this time can be saved by directly requesting the IP instead of the domain name, and at the same time, it can prevent risks caused by domain name hijacking.
Of course, for the sake of security and expansion, this IP may be a dynamically updated IP list, and it can be accessed through the domain name when the IP is unavailable.
2. Reasonable deployment of servers.
Servers are deployed by multiple operators and in multiple locations. Generally, there are at least three major operators and three deployments in South, Central and North.
In conjunction with the dynamic IP list mentioned above, it supports priority, and selects the optimal server IP for connection each time according to the region and network type.
For the server side, you can also tune the server's TCP congestion window size, retransmission timeout (RTO), maximum transmission unit (MTU), etc.
2. Obtain data optimization strategy
1. Connection multiplexing
Save connection establishment time, such as enabling keep-alive.
Http 1.1 starts keep-alive by default. For Android, both HttpURLConnection and HttpClient enable keep-alive by default. It’s just that before 2.2, HttpURLConnection had a bug that affected the connection pool. For details, see: Android HttpURLConnection and HttpClient selection
2. Request merging
It is about merging multiple requests into one request, the more common one is CSS Image Sprites in web pages. If there are too many requests in a certain page, you can also consider doing some request merging.
3. Reduce the request data size
(1) For POST requests, the Body can be compressed by Gzip, such as logs.
(2) Compress the request header
This is not supported by Http 1.1, but supported by SPDY and Http 2.0. Http 1.1 can cache the request header of the previous request through the server, and the same request header can be represented by an id such as md5.
4. CDN caches static resources
Cache common static resources such as images, JS, and CSS.
5. Reduce the size of returned data
(1) Compression
Generally, API data is compressed using Gzip. The following figure is a comparison before and after Gzip compression in previous tests. 
(2) Simplified data formats
such as JSON instead of XML, and WebP instead of other image formats. Follow the official account codekk, reply 20 to view the introduction about WebP.
(3) For different devices and different networks, different content is returned, such as different resolution image sizes.
(4) 增量更新
需要数据更新时，可考虑增量更新。如常见的服务端进行 bsdiff，客户端进行 bspatch。
(5) 大文件下载
支持断点续传，并缓存 Http Resonse 的 ETag 标识，下次请求时带上，从而确定是否数据改变过，未改变则直接返回 304。
6. 数据缓存
缓存获取到的数据，在一定的有效时间内再次请求可以直接从缓存读取数据。
关于 Http 缓存规则 Grumoon 在 Volley 源码解析最后杂谈中有详细介绍。
三、其他优化手段
这类优化方式在性能优化系列总篇中已经有过完整介绍
1. 预取
包括预连接、预取数据。
2. 分优先级、延迟部分请求
将不重要的请求延迟，这样既可以削峰减少并发、又可以和后面类似的请求做合并。
3. 多连接
对于较大文件，如大图片、文件下载可考虑多连接。 需要控制请求的最大并发量，毕竟移动端网络受限。
四、监控
优化需要通过数据对比才能看出效果，所以监控系统必不可少，通过前后端的数据监控确定调优效果。