Detect memory leaks and performance with the new version of Android studio

memory leaks are the biggest headache for Android developers. Perhaps a small memory leak, could be destroyed in the dikes nest.

How can I detect a memory leak? There are many online tutorials, but many are using eclipse detection, in fact, after the 1.3 version of Android Studio detection memory is very convenient, if combined with the Mat tool, Leakcanary plug-ins, everything becomes so easy.

Familiarity with the Android studio interface

工欲善其事, its prerequisite. Let's start with the Android studio interface.

Phper Monthly Salary Test "click into" to see if your salary is low. 2000 multiplayer test, 85% accuracy rate view

General analysis of memory leaks, first run the program, open the log console, there is a tag memory, we can analyze the current application in this interface to use the situation, at a glance, we no longer need to logcat in the search for memory in the log.

The blue area in the graph is the memory used by the program, and the gray area is the free memory.
Of course, the Android memory allocation mechanism is gradually increased for each application, such as your program currently using 30M of memory, the system may assign you 40M, the current is 10M idle, if the program uses 50M, the system will immediately add a portion of the current program, such as reached the 80M, Your free memory is now 30M. Of course, if the system can no longer allocate additional memory to you, the program will naturally be oom (memory overflow). Each application can apply the highest memory and phone closely related, such as I am currently using the Huawei Mate7, the limit is probably 200M, is relatively high, the general 128M is the limit, and even some phones only poor 16M or 32M, such a cell phone relative to the probability of memory overflow is very large.

How do we detect a memory leak?

The first thing you need to understand is that memory leaks mean that the memory that should be recycled still resides in memory.
In general, high-density mobile phones, a page will probably consume 20M of memory, if you find out the interface, the program memory is slow, there may be a serious memory leak.
We can go through the interface again and then click the Dump Java heap button, and then Android Studio will start working, and the graph below is the dump

Phper Monthly Salary Test "click into" to see if your salary is low. 2000 multiplayer test, 85% accuracy rate view

When dump succeeds, the Hprof file is automatically opened, and the file is named with snapshot+ time.

Phper Monthly Salary Test "click into" to see if your salary is low. 2000 multiplayer test, 85% accuracy rate view

With Android studio's own interface, it's not smart to see a memory leak, we can use third-party tools, the common tool is mat, http://eclipse.org/mat/downloads.php, here we need to download the standalone version of Mat . It's the beginning of the mat opening, and here's a reminder that Mat doesn't tell us exactly where the memory leak is, but rather provides a whole bunch of data and clues that we need to analyze to determine if a memory leak really happened.

Phper Monthly Salary Test "click into" to see if your salary is low. 2000 multiplayer test, 85% accuracy rate view

Next we need to use the mat to open the memory analysis of the file, described above for the use of Android Studio generated hprof files, this file in the Android studio in the Captrues this directory, you can find

Note that this file cannot be directly handed to Mat, Mat is not aware of anything else, we need to right click on this file and convert it to mat recognition.

Then using the mat to open the exported hprof (File->open heap dump) Mat will help us analyze the cause of the memory leak.

Leakcanary

The above describes the mat to detect memory leaks, and then to introduce you to leakcanary.
Project Address: Https://github.com/square/leakcanary

Leakcanary detects the memory recovery of the application, and if a garbage object is found to be not recycled, it analyzes the current memory snapshot, which is the. hprof file used by the top mat, finds the object's reference chain, and displays it on the page. The advantage of this plug-in is that you can check the memory leaks directly on the phone and help us detect the memory leaks.

Use:
Add in the Build.gradle file, different compilations use different references:

?

1234	<code class=" hljs matlab">dependencies {     debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘    releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘}</code>

Add Leakcanary.install (this) to the application's application OnCreate method, as follows

?

1234567

<code class=" hljs java">public class ExampleApplication extends Application     @Override    public void onCreate() {        super.onCreate();         LeakCanary.install(this);     } }</code>

After the application is run, Leakcanary will automatically analyze the current state of memory, if a leak is detected will be sent to the notification bar, click on the notification bar to jump to the specific leak analysis page.
Tips: As far as the results are currently used, most leaks are due to the use of a singleton mode to hold the activity reference, such as the context or activity as a listener set into, so in the use of the singleton mode of special attention, There are also empty activity references for some custom listeners at the end of the activity life cycle.
More analysis of Leakcanary can be seen in the introduction of the project homepage, and here http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/

Track Memory Allocations

If we want to know more about memory allocations, you can use allocation traker to see what the memory is taking up.
The usage is simple:

Click to track, then click Stop Tracking, stop tracking after the. alloc file will open automatically, open after the interface is as follows:

When you want to view the source code of a method, right-click on the method, tap jump to Source

How long the Query method executes

Android Studio is becoming more and more powerful, and we can use as to observe a variety of performance, such as:

If we want to observe the time of the method execution, we need to come to the CPU interface

Click on Start Method Tracking, after a period of time and then click again, trace files are automatically opened,

Inclusive time: The CPU time that a function consumes, including the CPU time that the other functions are called internally.
Exclusive time: a function consumes CPU time, but does not contain the CPU time that is consumed by internal calls to other functions.

How do we judge a possible problem?

The method is usually judged by the number of calls and exclusive times of the methods:

If the number of method calls is not many, but each call will take a long time of the function, there may be problems. A function that is called very frequently can be problematic if it takes a long time. Review

Here are some of the tools used by Android Studio to check the performance of the program, the tool is always auxiliary, do not because the tool delay too long. If there are any problems, please correct them.

Detect memory leaks and performance with the new version of Android studio