Press enter to see results or esc to cancel.

A common memory leak in Android

Share this

A common memory leak in Android

Although the mobile phone memory is increasing, but Android in order to achieve different applications running isolation, and will not affect each other, so the single application can make use of the maximum memory limit. Limit the size of different mobile devices and ROM may not be the same.

Such as the Android world’s first mobile phone HTC G1 is 16MB, then the Nexus One is 32MB. So even if the mobile phone memory is getting bigger, but you develop applications can use the memory space does not increase a lot, which also requires you to pay more attention to the development of memory, follow the principle of using at least memory to avoid memory leaks, so Not only allows you to avoid the system to kill the application without cause, but also allows users to use more fluid.

 A common memory leak in Android.

The generation of memory leaks

Android virtual machine mechanism imitation JVM, so there are garbage collection mechanism. Android virtual machine in memory is divided into two parts, part of the stack space, storing some global reference and static variables, the space allocation and recovery by the system mechanism, garbage collection does not work in this area; the other part of the heap Space, which is an instance of the object storage, the need to actively create the developer, the main role in this part of the garbage collection, recycling is a major strategy to detect objects in the heap object in the stack space for the corresponding reference.

 A common memory leak in Android.

If there is no reference to it, will be the priority of recycling, if there is a reference to the point will not be recycled. So if the developer does not set an object reference to null at the appropriate time, a memory leak may occur. One of the most common memory leaks in Android is the long-held Context.

Context in Android has a very big role, such as to get resources, so basically all of the view needs to be Context can be created. Improper use is likely to cause a memory leak.

Memory leak performance in Android

You’ve developed an app that’s fairly fluid at first, but as it lasts longer, the application gets slower and slower, resulting in users not having to restart the app to continue using it. This is likely to be a memory leak. As mentioned above, if a static variable holds a reference to an Activity, the user opens the Activity and creates an instance of Activity.

Even if you close the Activity, it will no longer be displayed, but its instance Will always exist in memory, because there is a static variable has been pointing to it, leading to its memory space will not be used as garbage collection. Think of this Activity may contain many attributes, a lot of view information, it has not been released, will waste a lot of memory space.

 A common memory leak in Android.

Here we start from the two examples to explain the next memory leaks and solutions.

one example

private static Drawable sBackground; @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); if (sBackground == null) { sBackground = getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); }

The above uses a static variable to hold a drawable. From the analysis can be seen, a TextView local variables hold a reference to the Activity, because label is a local variable, so it will not cause a memory leak.

But then the following used label.setBackgroundDrawable(sBackground); someone might think it also lacks the problem ah, even sBackground as a static variable, holding a drawable, this memory will not be released, but Block memory, after all, does not hold a reference to the entire Activity.

But in fact you are wrong. We look at in the setBackgroundDrawable source, the source location (frameworks / base / core / java / android / view /

public void setBackgroundDrawable(Drawable background) { ... if (background != null) { ... background.setCallback(this); ... } else { ... } ... }

There is a background.setCallback(this); , which leads to the object so that the static variable points and hold a TextView this object. In this way, because it is a static variable, as I mentioned in the previous section, the basic life cycle of static variables and the application of the same cycle, it holds a TextView object reference, so TextView will not be recycled, and then TextView has the entire Activity Of the reference, so the final result in the Activity will not be closed after the system recovery.

 A common memory leak in Android.

Of course, the solution to this problem is very simple, is to sBackground replaced by a non-static variable on the line, so that when the Activity closes recovery mechanisms will be able to judge the Activity space is not used to, so I started GC.

Another example

Let’s take a very common example, Android developers like to use the singleton model, but some developers may cause memory leaks do not pay attention, as follows:

private static DaVinci sDaVinci = null; public static DaVinci with(Context context) { if ( sDaVinci == null ) { sDaVinci = new DaVinci(context); } return sDaVinci; }

You may feel that this is not a problem ah, but this is not a good way, because it may allow users to use when a Context of the Activity, resulting in a single case to hold the Context of the Activity cited, resulting Memory leak. A good wording is to use

sDaVinci = new DaVinci(context.getApplicationContext()); . Because the Application’s life cycle is inherently throughout the application, so even if it is holding it does not matter.

Several suggestions

1, try not to use a life cycle longer than the Activity object to hold the Activity reference.

2, when the need to pass into the context of the Application Context as far as possible to consider, rather than Activity.

3, in the Activity to avoid the use of life cycle control of the non-static type of internal classes, you can use the static type of internal classes with weak references to achieve.

 A common memory leak in Android.

How useful was this Lesson?

Click on a star to rate it!

Average rating / 5. Vote count:

Be the first to rate this post.!

As you found this post useful...

Follow us on social media!

We are sorry that this lesson was not useful for you!

Let us improve this lesson!

Tell us how we can improve this lesson?

Share this