Android garbage collection mechanism solves the problem of memory leakage

In Android coding, there will be some simple writing methods and coding habits, which will lead to many memory leakage problems in our code. Here is a summary of known errors: 1. Common errors in writing single examples.

Error mode:

Error reason:

If we use foo. GetInstance () in activity a or elsewhere, we will always write "this" or "mcontext" (this variable also points to this). Imagine that the Foo we are using now is singleton, which means that it will always exist and memory after initialization, so that we will not create Foo objects when we call later. However, the "mcontext" variable in foo always holds the "context" in activity a, so that activity a cannot destroy itself even if it executes the ondestroy method. However, "ApplicationContext" is different. It always exists with our application (it may be destroyed in the middle, but it will also be recreated automatically). Therefore, there is no need to worry that the "mcontext" in foo will hold a reference to an activity so that it cannot be destroyed.

Correct way:

2. Common errors when using anonymous inner classes

Error mode:

Error reason:

When we execute the finish method of fooactivity, the delayed message will exist in the message queue of the main thread for 10 minutes before being processed, and this message contains the reference of handler. Handler is an anonymous internal class instance that holds the reference of external fooactivity, so fooactivity cannot be recycled, As a result, many resources held by fooactivity cannot be recycled, resulting in memory leakage.

Note that the above new runnable is also implemented by anonymous inner classes. It will also hold the reference of fooactivity and prevent fooactivity from being recycled.

A static anonymous inner class instance does not hold a reference to an outer class.

Correct way:

3. After using handler, remember to use handler. Removecallbacksandmessages (object token) in ondestroy;

Points needing attention in development to avoid memory leakage:

The method of obtaining context and the difference between using context and ApplicationContext:

You can see that some numbers are added to some No. in fact, these are yes in terms of ability, but why are they no? The following is an explanation:

Number 1: starting an activity is possible in these classes, but a new task needs to be created. Generally not recommended.

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

Number 3: allowed when the receiver is null. In version 4.2 or above, it is used to obtain the current value of sticky broadcast. (can be ignored)

Note: ContentProvider and broadcastreceiver are in the above table because there is a context in their internal methods.

Well, let's look at the table here, focusing on activity and application. We can see that UI related methods are basically not recommended or can not use application, and the first three operations are basically impossible to appear in application. In fact, as long as you grasp it, all UI related should be handled with activity as context; Other operations, such as service, activity and application instances, are OK. Of course, pay attention to the holding of context references to prevent memory leakage.

The above is the whole content of this article. I hope it will be helpful to your study.