Pricing

How to Identify and Locate Memory Leaks in Android Activities

When the tester tells you that your XXActivity has leaked, how do you confirm whether it has really leaked? After confirming the leak, how do you locate the problem causing the memory leak?

Introduction

When the tester tells you that your XXActivity has leaked, how do you confirm whether it has really leaked?

After confirming the leak, how do you locate the problem causing the memory leak?

In daily Android development, the hardest hit area of memory leaks is Activity. It is believed that these two issues have been encountered by every Android developer. When encountering such problems, we generally use our killer trick: Dump Java Heap and then perform static analysis on the GC chain with MAT. However, today I want to take a different approach and solve this problem from a simpler perspective.

Confirm the leak

First, let's take a look at an abstract Activity pseudocode:

public class LeakActivity extends Activity {

    ComplexLogicA; // Complex business logic code

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        ComplexLogicB; // Complex business logic code
        LeakLogic; // Business logic code causing the leak
        ComplexLogicC;
        ComplexLogicD;
    }

    @Override
    protected void onResume() {
        super.onResume();

        ComplexLogicE;
        ComplexLogicF;
        ComplexLogicG;
    }

    OtherComplexLogin... // Other business logic code
}

 

 

If we want to confirm whether this Activity has a leak, we just need to override the finalize method of the Object and add a Logcat print statement inside:

public class LeakActivity extends Activity {

    ComplexLogicA; // Complex business logic code

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        ComplexLogicB; // Complex business logic code
        LeakLogic; // Business logic code causing the leak
        ComplexLogicC;
        ComplexLogicD;
    }

    @Override
    protected void onResume() {
        super.onResume();

        ComplexLogicE;
        ComplexLogicF;
        ComplexLogicG;
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();

        Log.d("", "====LeakActivity has been recycled!");
    }

    OtherComplexLogin... // Other business logic code
}

 

Then run your project, open this Activity, press the back button to exit the Activity, and then force a GC operation through the IDE:

(Android Studio)

(Eclipse)

Next, check the Logcat to see if there is a corresponding print statement. This will confirm whether the Activity has a memory leak: if there is a print statement, there is no memory leak; if there is no print statement, there is definitely a memory leak!

Locate the cause of the leak

Locating the cause of the leak is a relatively simple and crude process of elimination. First, comment out all the complex business logic until the memory leak no longer exists:

public class LeakActivity extends Activity {

//    ComplexLogicA; // Complex business logic code

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

//        ComplexLogicB; // Complex business logic code
//        LeakLogic; // Business logic code causing the leak
//        ComplexLogicC;
//        ComplexLogicD;
    }

    @Override
    protected void onResume() {
        super.onResume();

//        ComplexLogicE;
//        ComplexLogicF;
//        ComplexLogicG;
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();

        Log.d("", "====LeakActivity has been recycled!");
    }

//    OtherComplexLogin... // Other business logic code
}

 

Next, enter and exit the Activity again, trigger GC, and confirm that the Activity leak no longer exists. Then, add the business logic back one by one until the leak reappears.

In this way, we can 100% locate the cause of the leak.

Key point

The knowledge point used here is the finalize method in the Object class in Java. When GC is ready to recycle a Java Object (all Java objects are subclasses of Object), GC will call the finalize method of this Object. This method is similar to the destructor in C++, and its original intention is to allow you to recycle some resources that are no longer needed (mainly for native resources). In fact, in daily Java development, it is not encouraged to rely on this method to implement recycling logic, because if you heavily rely on finalize, it may cause memory leaks. However, in our case, it is just used as a basis for whether it has been recycled, which is acceptable.

Conclusion

Although this method may seem simple and crude, it is indeed a convenient self-test method for developers. Without using other tools, you can quickly determine whether the newly added Activity in your current requirements has a leak. Consider it as a way to reduce the number of bugs in your code!

Latest Posts
1Seamless and Effective Device Management with WeTest UDT UDT's robust device management capabilities can ensure optimal testing efficiency and quality assurance.
2Overcoming Test Resource Expansion Challenges in Automated Testing WeTest UDT provides solution to test resource expansion by offering scalable cloud-based device resources, hybrid access and management options, and efficient automated testing capabilities.
3Introduction to Common Automated Testing Frameworks and Integrations Let's explore common automated testing frameworks and how they integrate into modern development workflows, helping businesses maintain consistency and reliability in their software.
4Streamlining Project and Permission Management with UDT Automated testing not only improves collaboration and task tracking, effective management also helps in optimizing workflow, ensuring that tasks are carried out in a timely manner and that each project progresses smoothly.
5How to Achieve Better Resource Management with UDT UDT provides a comprehensive suite of resource management tools that allow testing teams to manage their resources with ease.