Guys!! Here is the most awaited post on my blog!! The Performance analysis and Improvement ways by using Eclipse MAT tool !!
The Application Performance improvement process is one of the real challenges in the mobile application development. Android provides various tools to analyze the performance of the application, like-DDMS, Traceview, Allocation Tracker. The memory analysis can be done through Eclipse Memory Analysis Tool which a very powerful tool. It provides various analysis, like-Histogram, Dominator Tree, Leak Suspects along with chart analysis.
Areas for Optimization
From the above performance analysis, we can
see various areas of optimization in our application which is following.
Post-optimization - Performance Analysis
The Application Performance improvement process is one of the real challenges in the mobile application development. Android provides various tools to analyze the performance of the application, like-DDMS, Traceview, Allocation Tracker. The memory analysis can be done through Eclipse Memory Analysis Tool which a very powerful tool. It provides various analysis, like-Histogram, Dominator Tree, Leak Suspects along with chart analysis.
This post covers the memory analysis
of an application, i.e. Stock Watch Application (which is one of my in-house
developments) for an example, by using Eclipse MAT (Memory Analyzer Tool) tool
and the improvements observed in the application performance on post-optimization.
Eclipse Memory Analysis Tool (MAT)
The Eclipse Memory
Analyzer is a fast, feature-rich Java heap analyzer that helps to identify
memory leakage. The Eclipse Memory Analyzer (MAT) provides a large selection of
features to help in analyzing a single snapshot of heap. MAT can be used to
identify memory leaks using a single click
In
Android, DDMS helps you creating the heap dump HPROF file of the application. A
Java heap dump is an image of the complete Java object graph at a certain point
in time. It includes all objects, Fields, Primitive types and object
references.
The Eclipse MAT helps to visualize based on Java heap dumps the
references to objects and provides tools to identify potential memory leaks.
HPROF heap
dump is a snapshot of a Java heap at a particular instance in time. The garbage
collector is triggered before the dump is written. It contains information
about all objects, all classes, GCR, and all information about the remaining
objects. Heap does not contain allocation information.
Shallow
heap is the total amount of memory used by all instances.
Retained
Heap is the total amount of memory kept alive by all instances,
including other objects that they have references to.
On running
the application, select the application process from the devices tab. DDMS
helps to create the heap dump HPROF file of the application by selecting the
‘Dump HPROF file’ Button as shown in the below image.
Top Consumers prints the most expensive objects grouped by class and by package.
Leak Suspects displays the leak suspects and a system overview.
Top Components list report for components bigger than 1 percent.
Dominator Tree lists the biggest objects what they keep alive.
Duplicate Classes detect classes loaded by multiple class loaders.
Histogram
Using the Histogram view, we can filter the object/classes based on the package names, and you can see the incoming and outgoing references.
In the
above image, we have found some of the objects are using large memory as
comparison to the other application objects as marked by red arrows. The array
objects temp_data4 and temp_dataf are having more
allocated memory than the memory they are consuming. Also, in object of
Input Stream Class is open. 
It will ask for the type of report to be
created. Select Leak Suspects Report and click Finish.
If we're
running ADT (which includes a plug-in version of DDMS) and have MAT installed
in Eclipse as well, clicking the “dump HPROF” button will automatically do the
conversion (using hprof-conv) and open the converted hprof file into Eclipse
(which will be opened by MAT).
Analysis Overview
It will
display the overview of application performance analysis report like-total
memory size no. of objects and no. of classes in the application, a pie chart
showing biggest objects by retained size the application.
Also, it
shows the various action items which produce the various analysis reports based
on the different parameters as following:
Histogram lists
number of instances per class.Top Consumers prints the most expensive objects grouped by class and by package.
Leak Suspects displays the leak suspects and a system overview.
Top Components list report for components bigger than 1 percent.
Dominator Tree lists the biggest objects what they keep alive.
Duplicate Classes detect classes loaded by multiple class loaders.
Histogram
Using the Histogram view, we can filter the object/classes based on the package names, and you can see the incoming and outgoing references.
If we sort
by shallow heap, we can see that instances of char [] are at the top.
Right-click on the char [] class and select List Objects > with incoming
references. This produces a list of all char arrays in the heap, which we can
sort based on Shallow Heap usage.
Pick some
of the big objects, and drill down on them. This will show the path from the
root set to the object -- the chain of references that keeps this object alive.
Note: MAT can't tell us for sure that this is
a leak, because it doesn't know whether these objects are needed or not -- only
the programmer can do that.
It will show us which object and classes
are the top consumers of memory in the application by using pie charts as shown
below.
In the above image, we can analyze the
biggest objects.
The above image
is showing biggest top level dominator classes. As we can analyze that a large
amount of memory is used by java.lang.class
and java.lang.string classes.
We can get a higher level of leak suspect report with a pie chart
and list of leak suspects as shown in below image.
From
the above Leak Suspects report, we can analyse which objects/classes can cause
the memory leaks. In this case, it is showing objects java.lang.string class as one of the leak suspects. For deep
analysis on the specific objects for this class, we can also make use of Dominator tree.
The
dominator tree is a data structure that allows you to answer the question about
the biggest objects in almost no time. The dominator tree can also be used to
find high memory usage in certain
areas, which is a much harder problem.
Using
the "dominates" relationship we can create a dominator tree out of
the graph of objects in memory. At each node of this tree we store the amount
of memory that would be freed (= retained size).
In
the below image of Dominator tree, we can see class of our application and
memory used by the different objects under this class.
Here we have found a many string arrays having some particular
length. But they are using the full memory as of their defined lengths. As
shown in the image, a string array of defined length 200 is containing only 39 items (e.g. string array
is using only 39 positions out of 200, leaving empty the remaining positions).
Areas for Optimization
From the above performance analysis, we can
see various areas of optimization in our application which is following.
·
java.lang.Class – we need to reduce the number of objects of
this class
·
java.lang.String- The number of objects is quiet high, some of
string arrays have defined length but still not being used fully.
We have found 9 string arrays of average
lengths 250 defined in the activity where 8 arrays are not being used fully and
containing the duplicate objects.
·
Lazy
Initialization- we have found that the high
number of String array objects
looked suspicious. Also they retain not that much memory. So instead of always
using the default constructor it would most likely better to use lazy initialization and only
initialize the field when it's first needed.
·
java.io.inputStream objects- Some of the Inputstream objects are
not closed due to which the probability of leaks is more.
Post-optimization - Performance Analysis
The total amount
of memory consumed by the application has been reduced from 2.3 MB to 2.2 MB. Also the number of total objects has
been reduced.
The inputstream
objects has been closed as we can’t see memory allocated to in object in
the below image. The objects of array strings are consuming less memory and not
having vacant spaces as marked by red arrow in the image.
If we compare
the below image chart with the earlier one (e.g. before optimization), we have
found that objects of BuySellHold
class are not being counted in the biggest objects (in the place of (f) in the image)
We have reduced
the probability ratios of the leak suspects of both the classes java.lang.Class and java.lang.String as shown in below images
The Percentage memory consumed by the
native class com.myapp.stockwatcher.BuySellHold
class has been reduced from 2.5% to
1.8%. Moreover, the number of string arrays has been reduced to 1.
Performance Improvements
Improving application performance in terms of time and memory is one
of the real challenges in mobile development. The android native tools
like-DDMS/Traceview and Eclipse MAT plays a significant role in improving the
performance. Also these performance tests can be executed during the
development life cycle.
Following are the performance improvements by using both the tools:
v Using MAT:
·
Memory consumption by the two
activities has been reduced from 2.3 MB to 2.2 MB
·
Reduction in Percentage probability
of the leaks suspects
·
Improved the program
performance by reducing the java.lang.String objects
·
Reduction in Duplicate String
arrays
·
Stream objects closed on time
Although, Performance improvement is an ongoing process, there will
always be the scope of optimization. But by using these tools we can
significantly reduce the time taken in optimization process as these tools
enable us to hit the culprit areas directly.
Guys!! This post covers the most powerful tool analysis to improve android app performance. Post your comments!! J
