Some thoughts on Android APP performance optimization

When it comes to Android phones, most people have the impression that they become a little slow after using them for a while. Some programs crash inexplicably during operation. When they open the system folder, they find that there are many more files. Then they use the mobile phone manager APP to continuously clean and optimize them, and then they feel that the running speed has increased a little. Even if the phone scores far ahead in various performance benchmarking software, it still feels that no matter how much memory space there is, it is far from enough. I believe that every user who uses the Android system has had similar experiences as above. Indeed, the Android system is not as smooth as the IOS system. Why? Obviously, when looking at the hardware configuration of the phone, Android devices will not lose to IOS devices, and are even stronger than it. The key lies in the software. There are many reasons for this phenomenon. A few points are simply listed as follows:

In fact, in recent years, with the continuous iteration of Android versions, the Android system provided by Google has become more and more smooth. However, the Android phones used by most users in China are customized versions by major manufacturers, which are often not the latest native system kernel. Most of them may still remain in the older Android versions, and there are delays in updates.

Since the Android system source code is open, anyone can modify the source code as long as they comply with the corresponding agreement. Therefore, domestic manufacturers transform the Android source code into their own systems for external release, such as the familiar Xiaomi mobile phone Miui system, Huawei mobile phone EMUI system, Oppo mobile phone ColorOS system, etc. Since each manufacturer has modified the Android native system source code, this will cause a problem, that is, the famous Android fragmentation problem, which is essentially that the application compatibility of different Android systems is different and cannot achieve consistency.

Due to various Android fragmentation and compatibility issues, Android developers need to adapt to different systems when developing applications. At the same time, the development level of each Android developer is uneven, and the performance of the applications they write also has different types of problems, resulting in different user experiences during use. Then some problems will be converted into Android system problems by users, which in turn affects the evaluation of Android phones.

Performance Optimization

The focus of today's talk is Android APP performance optimization, that is, what points should be paid attention to when developing applications, and how to better improve the user experience. A good application, in addition to having attractive functions and interactions, should also have high requirements in terms of performance. Instant applications are very distinctive and may attract some users in the early stage of the product, but if the user experience is not good, it will also bring bad reputation to the product. So how should a good application be defined? There are mainly three aspects:

• Business/Function
• Logical interactions
• Excellent performance

As we all know, as an operating system mainly for mobile devices, the Android system has certain limitations in hardware configuration. Although the configuration is becoming more and more advanced, it still cannot be compared with PC. When the CPU and memory are used unreasonably or consume too many resources, there will be stability problems caused by insufficient memory, and freezes caused by excessive CPU consumption.

When faced with a problem, everyone thinks of contacting the user and then checking the logs, but they don’t know that the feedback about performance problems is also very difficult to find the cause, and logs are mostly useless. Why? Because most performance problems are non-essential problems, and it is difficult to locate the problem, and without key logs, of course, it is impossible to find the cause. These problems greatly affect the user experience and function usage, so it is very important to understand some performance optimization solutions, and optimize our applications in actual projects to improve user experience.

Four aspects

User experience performance issues can be summarized into four main categories:

• Smooth
• Stablize
• Save power and data
• Small installation package

What are the main causes of performance issues? There are similar and different reasons, but in the final analysis, they are nothing more than memory usage, code efficiency, appropriate strategy logic, code quality, installation package size and other issues. They are organized and classified as follows:

As can be seen from the figure, building a high-quality application should aim at four directions: fast, stable, economical, and small.

• Fast: Avoid lags during use, respond quickly, reduce user waiting time, and meet user expectations.
• Stable: Reduce the crash rate and ANR rate, and avoid crashes and unresponsiveness during user use.
• Save: Save traffic and power consumption, reduce user usage costs, and avoid overheating of the phone during use.
• Small: The small installation package can reduce the user's installation cost.

To achieve these four goals, the specific implementation is the problems in the right box: lag, unreasonable memory usage, poor code quality, chaotic code logic, and too large installation package. These problems are also the most common problems encountered during the development process. When implementing business needs, you also need to take this into consideration and spend more time thinking about how to avoid optimization after the function is completed. Otherwise, the maintenance cost after the function is implemented will increase.

Stuttering Optimization

Android applications start slowly and often freeze when in use, which greatly affects the user experience and should be avoided as much as possible. There are many scenarios for freezing, which can be divided into four categories: UI drawing, application startup, page jump, and event response, as shown in the figure:

The root causes of these four lag scenarios can be divided into two categories:

• Interface drawing. The main reasons are deep drawing levels, complex pages, and unreasonable refreshes. Due to these reasons, the lag scenes are more likely to occur in the UI and the initial interface after startup, as well as in the drawing of jumping to the page.
• Data processing. The reason for this kind of jamming is that the amount of data being processed is too large, which can generally be divided into three situations: first, the data is being processed by the UI thread; second, data processing occupies a high CPU, causing the main thread to not get a time slice; third, increased memory leads to frequent GC, which causes jamming.

There are many reasons for lag, but no matter what the reason and scenario, it will eventually reach the user through the display on the device screen. In the final analysis, there is a problem with the display. Therefore, to solve the lag, you must first understand the display principle of the Android system.

Android system display principle

The Android display process can be simply summarized as follows: Android applications cache surface data after measurement, layout, and drawing, render the data to the display screen through SurfaceFlinger, and refresh the data through Android's refresh mechanism. In other words, the application layer is responsible for drawing, the system layer is responsible for rendering, and the data that the application layer needs to draw is passed to the system layer service through inter-process communication, and the system layer service updates the data to the screen through the refresh mechanism.

We all know that there are three core steps in drawing each View in Android: Measure, Layout, and Draw. The specific implementation starts from the performTraversals() method of the ViewRootImp class. Both Measure and Layout obtain the size and position of the View through recursion, and take depth as priority. It can be seen that the deeper the hierarchy and the more elements, the longer it takes.

The actual rendering of the data to be displayed on the screen is achieved through the SurfaceFlinger service in the system-level process. So what are the main tasks of this SurfaceFlinger service? As follows:

• In response to client events, create a Layer to connect to the client's Surface.
• Receive client data and properties, and modify Layer properties such as size, color, transparency, etc.
• Refresh the created Layer content to the screen.
• Maintain the sequence of layers and perform clipping calculations on the final output of the layers.

Since they are two different processes, a cross-process communication mechanism is definitely needed to realize data transfer. In the Android display system, Android's anonymous shared memory is used: SharedClient. A SharedClient is created between each application and SurfaceFlinger, and then in each SharedClient, up to 31 SharedBufferStacks can be created. Each Surface corresponds to a SharedBufferStack, which is a Window.

A SharedClient corresponds to an Android application, and an Android application may contain multiple windows, namely Surface. That is to say, SharedClient contains a collection of SharedBufferStack, in which double buffering and triple buffering techniques are used in the display refresh mechanism. In summary, the overall display process is divided into three modules: the application layer draws to the buffer area, and SurfaceFlinger renders the buffer area data to the screen. Since they are different processes, Android's anonymous shared memory SharedClient is used to cache the data to be displayed to achieve the purpose.

In addition, we need a term: FPS. FPS means the number of frames delivered per second. Ideally, 60 FPS will not feel stuck, which means that each drawing time should be within 16 ms. However, the Android system is likely to be unable to complete those complex page rendering operations in time. The Android system sends a VSYNC signal every 16ms to trigger the rendering of the UI. If each rendering is successful, the 60FPS required for a smooth picture can be achieved. If an operation takes 24ms, the system cannot render normally when it receives the VSYNC signal, so frame loss occurs. Then the user will see the same frame within 32ms. This phenomenon is more common when performing animations or sliding lists. It may also be that your Layout is too complex, with too many drawing units stacked, and it cannot be rendered in 16ms, which eventually causes untimely refresh.

Root cause of jamming

According to the display principle of Android system, the fundamental reasons affecting drawing are as follows:

• The drawing task is too heavy and it takes too long to draw one frame of content.
• The main thread is too busy, and the data is not ready when the VSYNC signal sent by the system arrives, resulting in frame loss.

If drawing takes too long, there are some tools that can help us locate the problem. If the main thread is too busy, you need to pay attention. The main thread's key responsibilities are to handle user interactions, draw pixels on the screen, and load display-related data, so it is particularly important to avoid anything that happens on the main thread so that the application can remain responsive to user operations. In summary, the main thread mainly does the following:

• UI lifecycle control
• System event processing
• Message Processing
• Interface layout
• Interface drawing
• Interface refresh

In addition, you should try to avoid putting other processing in the main thread, especially complex data calculations and network requests.

Performance analysis tools

Performance issues are not easy to reproduce or locate, but if you encounter a problem, you still need to solve it. To analyze the problem and confirm whether it is solved, you need to use corresponding debugging tools, such as Hierarchy View of the Layout hierarchy, GPU Profile tool on the Android system, and static code checking tool Lint. These tools play a very important role in performance optimization, so you need to be familiar with them and know what tools to use for analysis in what scenarios.

1. Profile GPU Rendering

In the mobile developer mode, there is a freeze detection tool called: Profile GPU Rendering, as shown in the figure:

Its features are as follows:

• A graphics monitoring tool that can reflect the current drawing time in real time
• The horizontal axis represents time, and the vertical axis represents the time taken for each frame.
• Over time, the refresh presentation from left to right
• Provide a standard time consumption. If it is higher than the standard time consumption, it means that the current frame is lost.

2. TraceView

TraceView is a tool that comes with the Android SDK. It is used to analyze the function call process and can perform performance analysis on Android applications and Framework layer codes. It is a graphical tool that will eventually generate a chart to illustrate the performance analysis. It can analyze the execution time of each method, including the number of times the method is called and the number of recursions, the actual duration and other parameter dimensions. It is very intuitive to use and very convenient to analyze performance.

3. Systrace UI performance analysis

Systrace is a performance data sampling and analysis tool provided by Android 4.1 and above. It returns some information from the perspective of the system. It can help developers collect operating information of key Android subsystems, such as surfaceflinger, WindowManagerService and other key modules of the Framework, services, and View systems, so as to help developers more intuitively analyze system bottlenecks and improve performance. Systrace's functions include tracking system I/O operations, kernel work queues, CPU load, etc., and provides good data for UI display performance analysis, especially for problems such as animation playback not being smooth and rendering stuck.

Optimization suggestions

1. Layout optimization

Whether the layout is reasonable mainly affects the page measurement time. We know that the display measurement and drawing process of a page are completed through recursion. The time of multi-branch tree traversal is related to the height h of the tree, and its time complexity is O(h). If the level is too deep, each additional layer will increase the page display time, so the rationality of the layout is very important.

So what are the methods for layout optimization? They mainly start from three aspects: reducing the number of layers, reducing the measurement and drawing time, and improving reusability. The summary is as follows:

• Reduce the number of layers. Use RelativeLayout and LinerLayout appropriately, and use Merge appropriately.
• Improve display speed. Use ViewStub, which is an invisible view object that does not occupy layout space and occupies very little resources.
• Layout reuse. Tags can be used to improve reuse.

Use wrap_content as little as possible. wrap_content will increase the calculation cost when measuring layout. When the width and height are known to be fixed values, do not use wrap_content.

Delete unnecessary properties from the control.

2. Avoid overdrawing

Overdrawing means that a certain pixel on the screen is drawn multiple times within the same frame. In a multi-layer overlapping UI structure, if the invisible UI is also drawing, some pixel areas will be drawn multiple times, thus wasting extra CPU and GPU resources.

How to avoid overdrawing?

• Optimize layout. Remove unnecessary backgrounds in XML, remove the default background of Window, and display placeholder background images on demand
• Custom View optimization: Use canvas.clipRect() to help the system identify visible areas, and only those areas will be drawn.

3. Startup optimization

By monitoring the startup speed, we can find out the problems that affect the startup speed, optimize the startup logic, and improve the startup speed of the application. The startup mainly completes three things: UI layout, drawing, and data preparation. Therefore, startup speed optimization requires optimizing these three processes:

• UI layout. Applications generally have splash screens. To optimize the UI layout of the splash screen, you can use Profile GPU Rendering to detect frame drops.
• Startup loading logic optimization. Distributed loading, asynchronous loading, and deferred loading strategies can be used to increase application startup speed.
• Data preparation. Data initialization analysis, when loading data, you can consider using strategies such as thread initialization.

4. Reasonable refresh mechanism

During application development, due to data changes, the page needs to be refreshed to display new data. However, frequent refreshes increase resource overhead and may cause freezes. Therefore, a reasonable refresh mechanism is needed to improve the overall UI fluency. Reasonable refreshes require the following points:

• Minimize the number of refreshes.
• Try to avoid having high CPU threads running in the background.
• Reduce the refresh area.

5. Others

When implementing animation effects, you need to choose the appropriate animation framework according to different scenarios. In some cases, hardware acceleration can be used to provide smoothness.

Memory optimization

In the Android system, there is a garbage memory recovery mechanism, which automatically allocates and releases memory at the virtual machine layer. Therefore, there is no need to allocate and release a certain piece of memory in the code. From the application level, it is not easy to have problems such as memory leaks and memory overflows, but memory management is required. The Android system has a Generational Heap Memory model for memory management. Most of the pressure of memory recovery does not need to be concerned by the application layer. Generational Heap Memory has its own set of management mechanisms. When the memory reaches a threshold, the system will automatically release the memory that the system thinks can be released according to different rules. It is precisely because the Android program has handed over the power of memory control to Generational Heap Memory that once there are problems with memory leaks and overflows, troubleshooting will become an extremely difficult task. In addition, some Android application developers do not pay special attention to the reasonable use of memory during the development process, nor do they do too much optimization in terms of memory. When the application runs more and more tasks at the same time, coupled with more and more complex business needs, relying entirely on Android's memory management mechanism will lead to a series of performance problems gradually appearing, which will have an unignorable impact on the stability and performance of the application. Therefore, it is very necessary to solve memory problems and reasonably optimize memory.

Android memory management mechanism

Android applications are all run on the Android virtual machine, and the memory allocation and garbage collection of the application are all completed by the virtual machine. In the Android system, the virtual machine has two operating modes: Dalvik and ART.

1. Java object life cycle

Generally, Java objects have 7 running stages on the virtual machine:

• Creation phase -> Application phase -> Invisible phase -> Unreachable phase -> Collection phase -> Termination phase -> Object space reallocation phase

2. Memory allocation

In the Android system, memory allocation is actually the allocation and release of the heap. When an Android program is started, the application process is derived from a process called Zygote. After the system starts the Zygote process, in order to start a new application process, the system will derive the Zygote process to generate a new process, and then load and run the application code in the new process. Among them, most of the RAM pages are used to allocate to the Framework code, and at the same time enable RAM resources to be shared among all application processes.

However, in order to control the memory of the entire system, the Android system sets a hard Dalvik Heap Size maximum limit for each application. The entire threshold varies on different devices due to different RAM sizes. If the application's memory space is close to the entire threshold, it is easy to cause a memory overflow error if it tries to allocate memory.

3. Memory recycling mechanism

What we need to know is that in Java, memory is divided into three areas: Young Generation, Old Generation, and Permanent Generation. Recently allocated objects are stored in the Young Generation area. Objects trigger GC to recycle garbage at a certain time, and those that are not recycled may be moved to the Old Generation according to different rules, and finally moved to the Permanent Generation area after accumulating a certain period of time. The system will perform different GC operations according to different memory data types in the memory. GC determines whether to collect objects by determining whether the objects are referenced by active objects, and then dynamically recycles the memory space occupied by objects without any references. However, it should be noted that frequent GC will increase the jamming of the application and affect the fluency of the application. Therefore, it is necessary to minimize the system GC behavior in order to improve the fluency of the application and reduce the probability of jamming.

Memory analysis tools

Before performing memory optimization, you need to understand the current memory usage status of the application, analyze which data types have problems based on the status, the distribution of various types, and how to find out which specific objects are causing the problem after discovering the problem. This requires relevant tools to help us.

1. Memory Monitor

Memory Monitor is a very simple graphical tool that can monitor the memory usage of the system or application. It has the following functions:

• Displays available and used memory, and reflects memory allocation and recovery in real time over time.
• Quickly determine if application slowdowns are due to excessive memory collection.
• Quickly determine whether the application crashed due to insufficient memory.

2. Heap Viewer

The main function of Heap Viewer is to view the usage of different data types in memory. You can see the Heap Size of the current process, what types of data are there, and the proportion of each type of data. By analyzing these data, you can find large memory objects, and then further analyze these large objects to reduce memory overhead through optimization. You can also find memory leaks through data changes.

3. Allocation Tracker

Both Memory Monitor and Heap Viewer can monitor memory usage intuitively and in real time, and can also detect memory problems, but after discovering memory problems, you cannot further find the cause, or find an abnormal memory, but cannot distinguish whether it is normal. At the same time, after discovering the problem, you cannot locate the specific class and method. At this time, you need to use another memory analysis tool, Allocation Tracker, for more detailed analysis. Allocation Tracker can allocate and track the memory allocation of the application, and list their call stacks, so that you can view the memory allocation cycle of all objects.

4. Memory Analyzer Tool (MAT)

MAT is a fast, feature-rich Java Heap analysis tool that analyzes the memory snapshot HPROF of the Java process, analyzes a large number of objects, quickly calculates the size of objects in memory, and sees which objects cannot be reclaimed by the garbage collector. It can also visually view the objects that may cause this result.

Common memory leak scenarios

If you wait until after a memory leak occurs to find the cause and fix it, it will increase the cost of development. It is best to consider memory issues well when writing code and write higher quality code. Here are some common memory leak scenarios that need to be avoided in future development processes.

• Resource objects are not closed. For example, Cursor and File often use some buffers, and they should be closed in time when not in use.
• The registered object is not unregistered. For example, if the event is not unregistered after registration, the reference of the object will be maintained in the observer list.
• The static variables of the class hold the large data objects.
• A static instance of a non-static inner class.
• Handler temporary memory leak. If the Handler is non-static, it is easy to cause the Activity or Service not to be recycled.
• Memory leaks caused by objects in the container not being cleaned up.
• WebView. WebView has a memory leak problem. Once WebView is used in an application, the memory will not be released.

In addition, memory leaks can be monitored. The most common method is to use the LeakCanary third-party library, which is an open source library for detecting memory leaks. It is very simple to use and can issue an alarm when a memory leak occurs. It can also generate a leak tarce to analyze the leak location and provide a dump file for analysis.

Optimize memory space

The absence of memory leaks does not mean that memory does not need to be optimized. On mobile devices, due to the limited storage space of physical devices, the Android system also allocates limited heap memory to each application process. Therefore, using the smallest memory objects or resources can reduce memory overhead and allow GC to more efficiently recycle objects that are no longer needed, so that the application heap memory maintains sufficient available memory and allows the application to run more stably and efficiently. Common practices are as follows:

• Object reference. There are four reference types: strong reference, soft reference, weak reference, and virtual reference. Choose different reference types according to different business needs.
• Reduce unnecessary memory overhead. Pay attention to automatic boxing and increase memory reuse, such as effectively utilizing system-provided resources, view reuse, object pools, and Bitmap object reuse.
• Use the best data type. For example, for data class container structures, you can use the ArrayMap data structure, avoid using enumeration types, use Lrucache, and so on.
• Image memory optimization. You can set bitmap specifications, compress according to sampling factors, manage images with some image cache methods, etc.

Stability optimization

The definition of Android application stability is very broad. There are many reasons that affect stability, such as unreasonable memory usage, incomplete consideration of code exception scenarios, unreasonable code logic, etc., which will affect the stability of the application. The two most common scenarios are: Crash and ANR. These two errors will make the program unusable. The more common solutions are as follows:

• Improve code quality. For example, code review during development to check code design logic, business rationality, etc.
• Code static scanning tools. Common tools include Android Lint, Findbugs, Checkstyle, PMD, etc.
• Crash monitoring: Record some crash information and abnormal information in time for subsequent analysis and resolution.
• Crash upload mechanism: After a crash, try to save the logs locally first, and then upload the log information when the network is normal next time.

Power consumption optimization

In mobile devices, the importance of battery is self-evident. Without power, nothing can be done. For operating system and device developers, power consumption optimization has never stopped in pursuit of longer standby time. However, for an application, the issue of power usage cannot be ignored, especially for those applications that are classified as "battery killers", which will eventually be uninstalled. Therefore, application developers need to minimize power consumption while meeting their needs.

Before Android 5.0, testing power consumption in applications was troublesome and inaccurate. After 5.0, an API was introduced to obtain power consumption information on the device: Battery Historian. Battery Historian is an Android system power analysis tool provided by Google. Like Systrace, it is a graphical data analysis tool that intuitively displays the power consumption process of the phone. By inputting a power analysis file, it displays the consumption and finally provides some reference methods for power optimization.

In addition, there are some common solutions available:

• Calculation optimization, avoiding floating-point operations, etc.
• Avoid improper use of WaleLock.
• Use Job Scheduler.

Optimize the installation package size

The size of the application installation package has no effect on the use of the application, but the larger the application installation package, the higher the threshold for users to download it. Especially in the case of mobile networks, users have higher requirements for the size of the installation package when downloading applications. Therefore, reducing the size of the installation package can make more users willing to download and experience the product.

The composition of common application installation packages is shown in the figure:

From the figure we can see:

• The assets folder stores some configuration files and resource files. The assets will not automatically generate corresponding IDs, but will be obtained through the interface of the AssetManager class.
• res. res is the abbreviation of resource. This directory stores resource files. It will automatically generate corresponding IDs and map them to .R files. Resource IDs can be used directly for access.
• META-INF. Saves the signature information of the application, which can verify the integrity of the APK file.
• AndroidManifest.xml. This file is used to describe the configuration information of the Android application, the registration information of some components, the available permissions, etc.
• classes.dex. Dalvik bytecode program, which makes the Dalvik virtual machine executable. Generally, when packaging an Android application, the dx tool in the Android SDK converts the Java bytecode into Dalvik bytecode.
• resources.arsc. It records the mapping relationship between resource files and resource IDs and is used to find resources based on resource IDs.

Common solutions to reduce the size of the installation package

• Code obfuscation. Use the proGuard code obfuscator tool, which includes compression, optimization, obfuscation and other functions.
• Resource optimization. For example, use Android Lint to delete redundant resources and minimize resource files.
• Image optimization. For example, use the AAPT tool to compress PNG format images and reduce the number of color bits.
• Avoid libraries that duplicate functionality , use the WebP image format, etc.
• Plug-in. For example, the function module is placed on the server and downloaded on demand, which can reduce the size of the installation package.

summary

Performance optimization cannot be solved by updating one or two versions. It is a continuous demand, continuous integration and iterative feedback. In actual projects, at the beginning of the project, due to manpower and project completion time constraints, the priority of performance optimization is relatively low. When the project enters the commissioning stage, the priority needs to be increased. However, in the early stage of the project, when designing the architecture plan, performance optimization points also need to be considered in advance, which reflects a programmer's technical skills.

Whenever there is a need for performance optimization, it usually starts with discovering the problem, analyzing the cause and background of the problem, and then finding the best solution and finally solving the problem. This is also a processing method often used in daily work.