Memory leak solution

1. To avoid static Activity activity; such code, or destruction when set to null
2. Examples of single-mode Singleton getInstance () method of passing incoming possible context context.getApplication (because the life cycle of a single embodiment for the application life cycle)
3. To avoid static Views; such code, or destroyed when set to null
4. Inner classes to resolve memory leaks ways: 1. inner class instead of static inner classes, anonymous inner classes instead of static anonymous inner classes ,,,, 2 If you have strong references Activity in the property, then the property is changed to reference weak references ,,,,, 3. in the case of business permitting, in the Activity execution onDestroy, the end of these time-consuming tasks
5. Handler memory leak solution: a Handler class in a separate class file, or use a static inner classes can be avoided leak ,,,,,, 2 if you want to call Activity within Handler located, so can. internal Handler using a weak point where the reference in Activity, you can use a weak reference point is located inside the handler to Activity, using static + weakReference way to achieve the purpose of disconnecting the reference relationship exists between the Handler and Activity. ,,,,,, 3 At the time of the destruction of the interface, the release handler resources (set null)
6.       The main reason for the threads of the life cycle of uncontrollable, if the internal threads of the Activity class, will be holding a reference MyThread Activity when MyThread the run function is not over, MyThread will not be destroyed, so refers Activity of the old will not be destroyed, resulting in a memory leak. :::::: solution 1. Incoming Application of context, because Application life cycle is the entire application life cycle. ,,,,,,,, 2. If passed this time for the activity of context, when the context corresponding to the activity exit, take the initiative to end the tasks performed, and the release of resources ,,,,,,, 3 activity. the anonymous inner class thread instead of static inner classes ,,,,,,,,,, 4. If you need to refer to activity, the use of weak references ,,,,,,,,,,, 5. prudent use of static on cpntext
7. bitmap not call recycle () bitmap objects when not in use, we should call recycle () to free the memory before it is set to null
8. Objects in the collection does not clean up the memory leak caused ,,,, quoted some objects in the collection, it is not required when there is no clean up, so the collection will become increasingly large, if a collection of static solve more serious ,,,,, ::: activity in the exit method, a collection of the things clear, then set null, then exit program
9. Registration not cancel memory leaks caused by objects ,,,, because of some other Android application Android application can reference systems (such as registration system), even though Android program has ended, but there are still some other applications on the Android program a reference to the object, the memory leak still can not be garbage. 1 ::: solution. Instead of ActivityContext with ApplicationContext ,,,,,, 2. When activity execution onDestroy, call unregister
10. Did not close the resource object memory leaks caused by resource objects (Cursor, File documents, etc.) are often used some caching, when not in use, close the can.
11. Take up more memory objects (images are too large) cause memory overflow ,,,,,, Andrews points to the size of the bitmap is only 8M, solution. . . . . . 1. ,,,,,, 2 scaled down image. Soft reference picture, in a timely manner for recycle () operation juxtaposed null
12. WebView memory leaks (influenced) ::: ::: solution containing from onDestroy Activity with WebView new process () add the final System.exit (0); kill the current process

 

 

http://tryenough.com/android-momeryleak

https://blog.csdn.net/qq_35373333/article/details/74909811