Currently for the company's Android SDK for actual testing, reflecting the existence of slow network load resources, in the knowledge of the current CDN may be unstable, the SDK itself for the network module of the corresponding analysis, sorting out the relevant test records, to help the later optimization can be made.
A typical HTTP request Flow description:
Initiating a complete video ad request includes:
- Request ad content based on ad bit
- Download AD Videos
- Download logo Corner sign request
- Download Interstitial page Template Temp Resource
- Download video files for ad videos
- Download the source resource for the interstitial page HTML
As shown, the task of downloading an ad resource will not be performed until the ad request ad is returned successfully, this is synchronization. When the server returns AD data, it initiates a multi-threaded task of asynchronously downloading an ad resource. Only when all the resources required for a video ad are successfully downloaded will it enter the display process of the ad.
The simple understanding is that multiple download tasks are concurrent and the acquisition of content is asynchronous.
Data acquisition and content resolution
In general, the client requests data from the server, caches the content of the data, and finally renders it in different forms. So the loading of resources is simply divided into the following two links:
* Data acquisition: That is, sending a request to the server to return the corresponding data.
* Content parsing: The different data types returned by the server, the file forms cached on the device, correspond to their different parsing methods.
Network Task Analysis
Through the mobile phone terminal set proxy mode, with the help of Fiddler to the mobile phone network data capture packet analysis. The following is a demo program for the SDK project for data capture analysis:
As can be seen, for a complete video ad request, is the task of initiating 6 network requests, consistent with the content described above, the following for the actual implementation of these tasks and the corresponding data indicators for analysis.
Network task time-consuming analysis: (under the Company network environment according to AD bit request AD)
By analyzing the overall time-consuming distribution of the request ad task, it is found that the time-consuming is mainly two aspects of DNS resolution and TCP handshake connection.
the usual optimizations for the above two points are in the following ways:
1. Using IP direct connection, avoid the need to resolve the domain name through the DNS server to obtain the IP address this time-consuming process;
2. Considering the distributed deployment of CDN, the IP address that the domain name resolves to is not necessarily, increase the setting of DNS cache;
Save the domain name and the IP addresses that are resolved from the DNS server in the DNS cache. The next time you use this domain name, you get the required information directly from the DNS cache without having to access the DNS server again.
3. The establishment of a reliable TCP/IP connection is required three handshake protocol, each request is repeated the process of establishing a connection, is undoubtedly very time-consuming, consider the following way:
Request consolidation, small and fragmented data requests are centralized execution, similar requests are merged;
Sub-priority, delay part of the request, the non-important request delay, peak clipping reduce concurrency;
Connection multiplexing, do not need to pass the "three-time handshake every time: Establish a new connection, and then through the" four wave "to close the connection;
Timeline of the entire request
Network Task data Transfer analysis:
Request headers and Response headers
Content of the request and response:
Percentage of the total
Through the above data performance, consider the data transmitted over the network to do a bit of processing:
reduce request data size
1. For POST requests, the Body can do Gzip compression
2. Compression of the request header, HTTP 1.1 is not supported, can be modified after Spdy support, HTTP 2.0 native support.
Http 1.1 can be cached by the service-side request header for the previous request, and the same request header is represented by an ID such as MD5.
decrease the size of the returned data
Generally, the most common measures for network data optimization are:
(1) Use Gzip compression for returned content data
(2) Thin data formats such as JSON instead of XML,WEBP instead of other image formats
(3) for different devices different network return different content, such as different resolution picture
(4) When an incremental update requires data updates, consider incremental updates to the data. If the common service side is Bsdiff, the client is Bspatch.
(5) Large file download supports breakpoint continuation and multi-threaded download, and caches the ETag identifier of the Http Resonse, which is taken on the next request, to determine if the data has changed, and returns 304 if unchanged.
Compare JSON data using Gzip compression before and after comparison chart
Back to content before you turn on gzip compression
After gzip compression is turned on
The comparison found that by opening gzip, you can reduce the amount of data transferred by 57.3%
Network Task Optimization measures
- Consider prefetching to include pre-connected, preloaded data.
- Replace current httpclient with httpurlconnection and can have default gzip compression and connection multiplexing implementations
- DNS optimization to determine how IP direct and DNS caching are combined
- Multi-Connection download, for larger files, such as large pictures, file download can consider multi-connection download
Need to control the maximum concurrency of requests, after all, the mobile network is limited
Increase the monitoring of network performance, after all, optimization needs to be compared to the data to see the effect, so monitoring system is essential, through the front and back data monitoring to determine the tuning effect.
Android Network analysis and optimization