Use android studio to detect app Memory leakage [reprinted] And androidapp

Use android studio to detect app Memory leakage [reprinted] And androidapp

In Android development, various memory leaks are inevitable. If you do not find and handle the vulnerabilities in time, the larger the memory usage, and various strange crash may occur due to memory leaks, the APP may even crash due to insufficient memory.

Generally, android Memory leakage detection uses the built-in Monitor Tool of android studio in combination with mat, or a third-party open-source library tool: leakCanary.

However, neither of the two is perfect:

Using the Monitor Tool with mat has the following problems:

LeakCanary has the following problems:

Memory leakage analysis tool

Android Memory Leak analysis tools are commonly used in Android Studio and eclipse-based MAT (Memory Analyzer Tool ). By working with the two, you can achieve amazing results. Android Studio can quickly locate Memory leakage activities. MAT can quickly find out the root cause of Memory leakage based on known activities.

Step 1: Force GC to generate a Java Heap File

We all know that Java has a very powerful garbage collection mechanism that will help me reclaim non-referenced objects. These non-referenced objects are not included in our memory leak analysis. Android Studio hasAndroid MonitorsHelp us perform forced GC and getJava HeapFile.

Force GC: ClickInitate GC(1) click the button. It is recommended that you click again several seconds later and try multiple times to make GC more adequate. Then clickDump Java Heap(2) The button is generated slowly after a period of time.

The generated Java Heap file is opened in the new window.

Step 2: Analyze memory leakage Activity

ClickAnalyzer TasksOfPerform Analysis(1) click the button and wait for several seconds or tens of seconds to find out the Activity with Memory leakage (2 ).

Then we can know the Activity with Memory leakage. Because this example is relatively simple, we can see the problem in (3). If the problem is complicated, Android Studio is not intuitive enough, MAT is not convenient enough. If Android Studio cannot solve our problem, we suggest using MAT for analysis. So we will generate a standard hprof file next and use MAT to find out the root cause of the leakage.

Step 3: convert to a standard hprof File

The Heap file generated just now is not a standard Java Heap file, so MAT cannot be opened. We need to convert it into a standard Java Heap file. This tool is provided by Android Studio calledCaptures, Right-click the selectedhprof,Export to standard .hprofSelect the Save location to generate a standard hprof file.

Step 4: MAT open the hprof File

The usage of MAT is the same as that of eclipse. Open the generated hprof file. Click (1) to open Histogram. (2) Regular Expressions are supported. Enter the Activity name and clickenterKey.

The target Activity is found.

Right-click the class name and selectMerge Shortest Paths to GC RootsOfexclude all phantom/weak/soft etc. referencesIn this step, we can see the cause of Memory leakage. We need to collect our code to analyze the cause based on the memory leakage information.

Step 6: analyze the cause based on memory leakage information and code

Using Handler case analysis, the information provided is Thread and android. OS. message. This Thread and Message are usually used in Handler and combined with the Code. So I guess it is Handler that causes memory leakage and check the code, A final Handler is defined in the function for scheduled tasks. After onDestroy of the Activity, the Handler is still working, and the Activity cannot be recycled normally.

// Code protected void onCreate (Bundle savedInstanceState) {super. onCreate (savedInstanceState); setContentView (R. layout. activity_test); textView = (TextView) findViewById (R. id. text); final Handler handler = new Handler (); handler. post (new Runnable () {@ Override public void run () {textView. setText (String. valueOf (timer ++); handler. postDelayed (this, 1000 );}});}

Modify code to avoid Memory leakage

@ Overrideprotected void onCreate (Bundle savedInstanceState) {super. onCreate (savedInstanceState); setContentView (R. layout. activity_test); textView = (TextView) findViewById (R. id. text); handler. post (new Runnable () {@ Override public void run () {textView. setText (String. valueOf (timer ++); if (handler! = Null) {handler. postDelayed (this, 1000) ;}}) ;}private Handler handler = new Handler (); @ Overrideprotected void onDestroy () {super. onDestroy (); // prevents Handler from causing memory leakage. removeCallbacksAndMessages (null); handler = null ;}

Retest to make sure the problem has been resolved.