In this paper, we mainly introduce some concepts of electric quantity optimization and network optimization and the direction to optimize the thinking. There are no specific measures. Electric quantity optimization and network optimization is a relatively broad optimization point, which needs to be summarized from more practices in the project. In particular, there is not much we can do for network optimization. Most of the optimization work is encapsulated. For example, the Okhttp framework is widely used to do a lot of optimization.

1. Optimization of electric quantity

1. Doze and StandBy mode

When the device is not charged, the screen is off, and the device is inactive for a period of time, it enters Doze mode. And the longer the inactivity, the longer Doze lasts; After entering Doze, the system will delay the background CPU and network activities of the application. You can use ADB commands to enter and turn off Doze mode, and you can view Doze whitelist and other commands.

The Doze mode describes the system, while the StandBy mode describes the application. The application is not active and the device is not charged. The system provides a configurable whitelist, we can apply for our application in the whitelist;

We can do some things by getting the battery level in the app, whether it’s charging or not; For example, in the log system, we can upload the logs in the log system to the server when the device is charging. Also can register broadcast, obtain power changes and charging status;

2. Optimization of electric quantity

Our application can increase battery life in three ways

  • Reduce operations if there are redundant operations, such as caching downloaded data instead of redownloading it each time
  • Deferring operations allows non-urgent operations to be performed while the device is charged or wifi is connected
  • The merge operation server requests different interfaces to check whether the merge operation can be performed

3. Power consumption analysis tool

Android Studio’s built-in profiler analysis tool has power analysis

  1. Start the application on a real machine or emulator
  2. Open the Profiler screen, select the application process, and select Energy to enter the power consumption analysis screen
  3. If you place the pointer on the bar chart, you can view whether the application CPU, network, and location are active
  4. When you hover over the bar area, specific background power consumption information, such as Location, Wake Locks, Alarm&Job, is displayed below

Second, network optimization

The process for a network request is as follows

  • DNS resolution: Requests the DNS server to obtain the IP address corresponding to the domain name
  • Establish a connection with the server, including TCP three-way handshake and SSL secure connection
  • Connections are established, data is sent and received, data is parsed

So you can optimize from these three steps;

1. DNS optimization

The complete DNS resolution process takes a long time. The cache is cached from the local system first. If the cache is not cached from the nearest DNS server, the cache is cached at each layer.

Traditional DNS resolution has several disadvantages

  • The cache time is set too long, the domain name is not updated in time, and the DNS resolution request is set too short, which affects the request speed.
  • Domain name hijacking is easy to be attacked by middlemen or hijacked by carriers to resolve domain names to third-party IP addresses.
  • The DNS resolution process is not controlled, and the fastest IP address cannot be resolved.

To solve these problems, we can use HTTPDNS. It is simple to do the work of domain name resolution, through HTTP request background to get the corresponding IP address of the domain name, directly solve all the above problems.

DNS optimization can be done by using Ali’s httpDNS;

2. Connection optimization

Reuse connection, do not need to re-establish each request, how to reuse connection more efficiently, can be said to be the most important point in network request speed optimization.

keep-alive

The HTTP protocol has keep-alive, which is enabled by default in HTTP1.1 to alleviate the time required to establish a TCP three-way handshake for each request. After the request is completed, the connection is not released immediately, but is put into the connection pool. If there is another request to be sent at this time, the connection in the connection pool is directly taken out to send and receive data, reducing the connection establishment time. In fact, keep-alive is now enabled by default on both the client and the browser, and there is no longer a connection for every request to the same domain name. Pure short connections no longer exist.

However, a keep-alive connection can only send and receive one request at a time and cannot accept a new request until the previous one has been processed. If multiple requests are made at the same time, there are two cases:

If requests are sent serially, one connection can always be reused, but it is slow, with each request waiting for the last one to complete before being sent.

If requests are sent in parallel, only a TCP three-way handshake is required for each request to establish a new connection.

Http2 allows multiple requests to the same IP address to be multiplexed using a socket.

Android’s open source web library OKhttp turns keep-Alive on by default and supports HTTP2 in Okhttp3 and later.

3. Data compression

The impact of data on request speed is divided into two aspects, one is the compression rate, the other is the speed of decompression serialization deserialization. Currently, the two most popular data formats are JSON and Protobuf. Json is a string, protobuf is binary, which means a protobuf is still smaller than JSON when compressed using various compression algorithms. Protobuf has an advantage in terms of data volume. Serialization speed Protobuf also has some advantages.

In addition to choosing different serialization methods (data formats), Http can encode content (that is, the body part), using encoding such as GZIP for compression purposes.

Support for gzip decompression is automatically enabled in OKhttp’s BridgeInterceptor.

4. Optimization of other aspects

  1. Use WebP instead of PNG/JPG

  2. For different pictures on different networks, for example (for the original picture is 300×300) :

    2/3G use low definition pictures: use 100X100 pictures;

    For 4G, 300X300 images are used when the signal strength is strong, 200×200 images are used when the signal strength is medium, and 100×100 images are used when the signal strength is weak.

    WiFi network: send 300X300 pictures directly

  3. HTTP Enable cache/add home page data to cache