Android Handler as the most commonly used type, responsible for inter-thread communication.
Associated class has Looper, MessageQueue, Message; this is mainly the record about Handler lead to memory leaks, as well as some common problems.
A. Handler lead to memory leaks
Memory leak phenomenon is no longer required object can not be recovered GC; for example, an Activity has quit, but can not be recovered GC, in severe cases can lead to OOM.
The reason Handler lead to memory leaks if within the Activity Handler object created by a new class of non-static anonymous way, then the Handler object implicitly hold a reference (JAVA Central African static inner classes to hold classes outside of Activity references); then if Activity Handler destruction and has not been in the news process, will lead Handler object holds a reference to the Activity, resulting Activity can not release memory leaks.
A friend said at the time Activity quit calling Handler's removeCallbacksAndMessages to remove the message, this approach can indeed reduce Handler objects continue handlerMessage overhead caused after Activity quit, but did not solve the memory leak problem mentioned above; the reason is that handler sends message objects to the MessageQueue, Mesaage object target will hold Handler object sends the message reference, a reference to the object if Meassage Handler exists, then the Handler object can not be recycled, resulting Activity can not be recycled and memory leaks.
The solution is
1. Handler is defined as static, because static inner classes do not hold a reference to the outer class
2 is defined as the static inner class, for the operation of the external Handler Activity class member variables, passing through Handler Activity object constructor implemented, then wrapped with weak references Activity incoming objects, to ensure that each Activity in the GC objects can be recycled.
Activity can ensure that the problem does not exist when using a memory leak Handler by the above two steps. The above-described embodiment is the principle, the package will be simplified by the use of actual use, to define each time to avoid a static Handler.
Two. Looper infinite loop related issues
Looper is a wireless loop, then the main thread Looper will lead to the main thread blocked, causing ANR?
This is a relatively high level of interview questions, the answer is clearly no, but would like to sort out what you need to answer.
Streamline the answer is: the main thread Andrews by Looper infinite loop to ensure that the main thread will not quit just started, otherwise the process will exit the main thread pulled out; and when we have problems operating ANR is because in Activity, Service, BroadcastReceiver in callbacks should not be time-consuming operation, run the code that takes a timeout lead to ANR.
The principle is the system in which there will be a System Server process; APP process in the application layer is running, System Server main thread of the process Activity onCreate, onResume, onPause and other systems are passed to the callback process by APP Binder communication, and finally the message transmitted to the main thread executes the corresponding callback, ANR problem does not exist in this process, and after ANR If you receive a callback message APP process, such as performing a time-consuming operation beyond a certain time in the onCreate.
