Android Development: MVP mode application and memory leak solution

Recently, bloggers began to practice MVP mode in the project, but unexpectedly found that the memory leakage is serious, but few people talked about this problem, which prompted the release of this article. This article assumes that readers have understood the MVP architecture.

Introduction to MVP

M-mode, data, logical operation layer, data acquisition, data persistence. Such as network operation and database operation

V-view, interface display layer, specifically embodied in android as activity and fragment

The p-presenter, the mediator, connects the model and view layers, and holds both the model reference and the view interface reference

Example code: mode layer operation

View layer

Presenter mediator

According to the OOP idea, Java should be oriented to interface programming, so as to conform to the OCP principle. The above example code omits the more abstract interfaces imodle, iView and ipresenter, and generics are usually introduced in actual MVP practice to make it more extensible.

Google has provided relevant sample code and added a constraint in MVP: contract, which is used to define the MVP interface of each module. google MVP sample code： https://github.com/googlesamples/android-architecture

Memory leak problem

It can be seen from the above that the presenter holds the view interface object, which is actually mainactivity.this, and the presenter object instance is also contained in the modle. When the mainactivity is to be destroyed, there is a modle in the presenter getting data. Then the problem comes. Can this activity be destroyed normally?

The answer is no!

When modle obtains data, it always holds the presenter object without processing, and the presenter object holds the activity object. If this GC chain is not cut off, the activity cannot be completely recycled.

In other words: if the presenter is not destroyed, the activity cannot be recycled normally.

Resolve memory leaks in MVP

Presenter performs resource release operation when the ondestroy method of activity calls back, or uses soft reference that is easier to recycle when presenter references view object, weak application.

Example code: activity

Presenter

Modle

Personal summary

Because MVP oriented interface programming can adapt to demand changes, MVP is suitable for large projects; Because it simplifies the responsibilities of activity and fragment, it can greatly reduce the amount of code in the view layer. Compared with activity in MVC, fragment can move thousands of lines of code, which is simply elegant!

After the above operations, the memory leakage caused by MVP is almost solved. The above is all the content of this article. I hope it will be helpful to your study and support more programming tips.