Shulou(Shulou.com)06/02 Report--

This article focuses on "how to solve memory leaks in Android applications". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to solve the memory leak in Android applications.

Principle

For performance issues, it is necessary to follow the following principles for analysis and improvement:

If you look at the data and talk, you can't follow your feelings. If you feel that there is something wrong, you can change it. It is very likely to be counterproductive.

Performance optimization is a continuous process that needs to be constantly improved. Don't think about doing it all at once.

For performance problems, it is not necessary to improve, limited by the architecture or other reasons, some problems may be difficult to improve, must be guaranteed to use, and then consider the good use.

It must be verified after improvement, and changes in any place need to be verified to avoid other problems caused by improved performance.

Steps

Here are my steps to solve the performance problem of memory leaks:

Give priority to common memory leaks

First of all, solve the common memory leak problem, this process can use the Analyze-Inspect Code of Android Studio to do static analysis of the code, the common memory leak problems are:

For memory leaks caused by non-static inner classes, such as Handler, the solution is to write the inner class as a static inner class, and use soft / weak references to hold instances of the external class in the static inner class, eg:

Static class ExerciseHandler extends Handler {private SoftReference exerciseActivitySoftReference = null; public ExerciseHandler (ExerciseActivity exerciseActivity) {exerciseActivitySoftReference = new SoftReference (exerciseActivity);} @ Override public void handleMessage (Message msg) {ExerciseActivity exerciseActivity = exerciseActivitySoftReference.get (); if (null! = exerciseActivity) {super.handleMessage (msg) Switch (msg.what) {case MSG_XX: exerciseActivity.***; break Default: break;}

After IO operation, memory leaks caused by not closing files, such as Cursor, FileInputStream, and FileOutputStream, are not closed. This problem can be detected by static code analysis in Android Studio 2.0 and can be improved directly.

After using TypedArray in custom View, there is no recycle. This problem can also be detected by static code analysis in Android Studio 2.0 and can be improved directly.

In some places, the context of the four major components is used, but it still holds the memory leak caused by its context after leaving these components. This problem belongs to the consensus. In the process of writing the code, you should follow the rules. Using the Context of Application can solve this kind of memory leak. As to when to use the Context of the four major components and when to use the context of Application, please see the following table:

Application usage scenario

Note: notice that some numbers have been added to some NO. In fact, these are YES in terms of ability, but why is it called NO? The following is an explanation:

1. Number 1: it is possible to start Activity in these classes, but you need to create a new task, which is not recommended.

2. Number 2: it is legal to layout inflate in these classes, but the system default theme style is used. If you customize some styles, they may not be used.

3, number 3: allowed when Receiver is null, used to get the current value of stickiness broadcast in version 4.2 or above. (can be ignored)

4. ContentProvider and BroadcastReceiver are in the above table because there is a context for use in their internal methods.

There is another kind of memory leak that does not belong to the memory leak, but should be solved when analyzing the memory leak: the same APP, put pictures in different drawable folders, and occupy different memory on the same device. For more information, please refer to: research and analysis on the relationship between picture size, memory footprint and drawable folder in Android. To solve this problem, you can follow the following principles: 1. UI only provides a set of high-resolution images, and it is recommended to put the images under the drawable-xxhdpi folder (it is not necessary to put them under the xxxhdpi or higher resolution folder, weigh the pros and cons and take care of mainstream devices). In this way, the size of the images in low-resolution devices is only compressed, and there will be no increase in memory. 2, when it comes to desktop plug-ins or images that do not need to be scaled, put them in the drawable-nodpi folder, and the pictures in this folder will not be scaled on any device.

Check for memory leaks after running the program through the tool

Through the above steps, most of the memory leaks in the application can be solved, and some memory leaks need to be solved by running the program and analyzing the running memory snapshot, such as no anti-registration after registration, memory leakage caused by static member variables in the class, memory leak in SDK, and so on. Solving such problems can be done in two steps:

Through the memory leak detection tool to locate the problem first, there are two more convenient ways to detect memory leaks: 1. One is to use the open source project Leakcanary, which needs to be added to the code, and the analysis result is generated after running. 2. Another way is to use the adb shell dumpsys meminfo packagename-d command to check the number of Activity and View before entering an interface. After exiting the interface, check the number of Activity and View again. Compare the changes in the number of Activity and View before and after entering. If there is a difference, it means there is a memory leak (remember to manually trigger GC before using the command to check the number of Activity and View).

Note: in Android Studio, you can obtain the memory information of the currently selected process in the following ways:

Then take the running memory snapshot of the program through MAT for detailed analysis, for the use of MAT, there are many high-quality articles on the Internet, such as: Android performance optimization uses MAT to analyze memory leaks, before using MAT, it is necessary to know these points: 1. Do not expect MAT to tell you exactly where there is a memory leak, which requires you to locate the class that may have memory leak according to the previous step. Then use MAT to confirm whether there is a memory leak, and where there is a memory leak. 2. Analyze the memory consumed by a class and its related instances with the help of Retained Size. If the Retained Size of this class is relatively large, give priority to the analysis. 3. When checking whether a class has memory leaks, exclude its soft / weak / virtual reference, and right-click a class → Merge Shortest Paths to GC Roots → exclude all phantom/weak/soft etc.references.

Verify the effect of improvement

According to my personal experience, I generally verify the effect of improvement like this, run the program, run each function again, make sure there is no problem, exit the program completely, trigger GC manually, and then check whether the number of Activivites and Views is close to 0 through adb shell dumpsys meminfo packagename-d; if not, check for possible memory leaks through Leakcanary, continue to pass MAT analysis, cycle and improve until you are satisfied.

At this point, I believe that everyone on the "Android application memory leak how to solve" have a deeper understanding, might as well to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.