Android performance optimization model (II): android Performance Optimization Model

Android performance optimization model (II): android Performance Optimization Model

Source: Hu Kai's blog (@ Hu Kai me) Welcome to share the original article with bole headlines

Google just released the Android performance optimization model 2nd course a few days ago, with a total of 20 short videos, including the following content: Power Optimization, network optimization, and how to optimize Wear, the object pool is used to improve efficiency. The LRU Cache, Bitmap scaling, caching, reuse, PNG compression, and custom View performance improve the rendering performance of the View after Setting alpha and Lint, stictMode and other tools. The following is a summary of these courses. Your understanding is limited. For more information, see here!

1) Battery Drain and Networking

For mobile phone programs, network operations are relatively power-consuming. Optimizing Network operations can significantly reduce power consumption. As mentioned in the 1st quarter of performance optimization, the power consumption of each module of the mobile phone hardware is different. The mobile Cell module consumes a large amount of power, in addition, the battery consumption of the cellular module varies with the working intensity. Before a program executes a network request, it needs to wake up the device, send the data request, and wait until the data is returned before it enters the sleep state. This process is shown in:

In the process above, the difference in cell module power consumption is shown in:

As shown in the figure, the activation moment, the sending moment, and the receiving moment all consume a lot of power, we should optimize how to transmit network data and when to initiate network requests.

1.1) When to initiate a network request

First, we need to identify which network requests need to return results in a timely manner and which can be executed in a delayed manner. For example, if you actively pull down and refresh the list, you need to immediately trigger a network request and wait for the data to return. However, data uploaded to users, synchronization program settings, and other behaviors can be delayed. We can use the Battery Historian tool to view the power consumption of the mobile Cell module (for details about this part, click the power consumption of Android performance optimization ). In the Mobile Radio line, the cell module's power consumption is displayed. The red part indicates that the module is working, and the middle part indicates that the module is sleeping. If there is a certain interval, the frequent appearance of red and interval indicates that there is a behavior that can be optimized. As shown in:

For the previously optimized parts, we can bind the request behavior to initiate a unified request at a certain time. As shown in:

After the above optimization, we will use Battery Historian to export the power consumption diagram. We can see that the wake-up status and sleep status are separated by successive large blocks, the total power consumption is reduced.

Of course, we can even delay the request task until the mobile phone network is switched to WiFi, and the mobile phone is recharged and then executed. In the previous description, we encountered a problem: how to delay network requests and execute them in batches. Fortunately, Android provides JobScheduler to help us achieve this goal.

1.2) how to transmit network data

This section mainly involves Prefetch and Compressed technologies. For Prefetch usage, we need to determine in advance whether the user's subsequent scattered requests will be triggered immediately after this operation, you can execute all the scattered requests that may be used in the next five minutes in a centralized manner. For the use of Compressed, you can use the CPU to compress and decompress the data before uploading and downloading data, which can greatly reduce the network transmission time.

You can view detailed data through the Networking Traffic Tool in Android Studio if you want to know the time when a network request occurred in our application and the data volume of each request, as shown in:

2) Wear & Sensors

In Android Wear, Sensors is widely used to implement some special functions. Therefore, we need to pay special attention to how to make good use of Sensor while saving power as much as possible. The following describes some examples of best practices on Android Wear.

Refresh requests should be minimized. For example, we can log off the listener as soon as possible without some data, reduce the refresh frequency, and batch process the Sensor data. So how can we achieve these optimizations?

• First, we should try our best to use the existing motion data provided by the Android platform, instead of monitoring and collecting data by ourselves, because most Android watches themselves record the Sensor data through Battery optimization.
• Second, when Activity does not need to listen to certain Sensor data, it needs to release the listener registration as soon as possible.
• We also need to control the update frequency as much as possible, and trigger the operation to obtain the latest data only when the display data needs to be refreshed.
• In addition, we can perform batch processing on the Sensor data, which is updated to the UI only when the data is accumulated for a certain number of times or to a certain extent.
• Finally, when Watch is connected to Phone, you can hand over some complicated operations to Phone for execution. Watch only needs to wait for the returned results.

For more information about Sensors, click here

3) Smooth Android Wear Animation

Android Material Design applications use a large number of animations for UI switching. Optimizing the animation performance not only improves user experience, but also reduces power consumption. The following describes some simple methods.

In Android, a relatively heavy task is to rotate, scale, and crop Bitmap. For example, in a circular clock chart, we rotate the clock pointer as a separate image, which is 56% higher than the frame rate formed by rotating a complete circular chart.

In addition, minimizing the number of elements for each re-painting can greatly improve the performance. If there are many complex components to be displayed on a clock interface, we can split these components, for example, set the background image to an independent View and use the setLayerType () method to force the View to be rendered using Hardware. As for the elements on the interface that need to be split, the update frequency of each element should be discussed separately.

How to use tools such as Systrace to View the rendering performance of some views, as mentioned in the previous section. If you are interested, click here.

For animations in most applications, we will use PropertyAnimation or ViewAnimation to perform operations. The Android system will automatically optimize these animations, most of the performance optimization knowledge learned on Android is also applicable to Android Wear.

To obtain