}
}
The official example is very good, monitor the cancel status in the background loop at all times to prevent not exiting in time.
In order to remind everyone, Google deliberately put a lot of English in the description of AsyncTask:
// AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java. util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
Pity me, China has a vast territory, vast land and rich resources, and lacks everything, but lacks sensitivity to English reading.
AsyncTask is suitable for short time-consuming operations, up to a few seconds. If you want to operate for a long time and time-consuming operation, please use other APIs under the java.util.concurrent package, such as Executor, ThreadPoolExecutor and FutureTask.
Learn English well and avoid stepping on pits!
8, BroadcastReceiver object
Unregister() method is not called for various reasons.
The solution is very simple, make sure to call the unregister() method.
By the way, I encountered an opposite situation in my work. The receiver object did not succeed in registerReceiver() (not called), so an error was prompted when unregistering:
// java.lang.IllegalArgumentException: Receiver not registered ...
Solution:
Solution 1: After registerReceiver() Set a FLAG, and determine whether to unregister() according to FLAG. Almost all articles found on the Internet write this way. I have encountered this kind of bug before, and I have always explained it this way. But it is undeniable that this kind of code does look a bit ugly.
Scheme 2: Later, I overheard a big cow reminder that I saw a more general way of writing in the Android source code:
// just sample, you can write tools Class
// At first glance I saw this code, damn, it was too crude, but when I thought about it, what I wanted was so simple and crude. Don't make some simple things so complicated.
private void unregisterReceiverSafe(BroadcastReceiver receiver) {
try {
getContext().unregisterReceiver(receiver);
} catch (IllegalArgumentException e) {
// ignore< br /> }
}
9. Leaks caused by the BitMap object
When the Bitmap object is not in use, it’s better to call the recycle method and assign a value of null to clear the resource directly or Indirect reference, but some people have to ask, there are many places in the android source code that are not called?
Yes, what I’m talking about here is the best. If you don’t call it, you can only rely on Java? GC is executed, the finalize method of Bitmap is called,
It will be executed here. The navtive method nativeDestructor() is used to release resources. In fact, if you look at that function, it is just a sentence of delete bitmap.
Summary
1. References to components such as Activity should be controlled within the life cycle of the Activity; if not, consider using getApplicationContext or getApplication to avoid the long life cycle of the Activity The object reference is leaked. ?
2. Try not to use non-static external member variables (including context) in static variables or static internal classes. Even if you want to use them, you should consider making the external member variables empty in time; you can also use them internally Weak references are used in classes to refer to variables of external classes. ?
3. For internal class objects whose life cycle is longer than Activity, and the member variables of the external class are used in the internal class, the internal class can be changed to a static internal class, and a weak reference can be used in the static internal class To refer to the member variables of the external class.
4. It is best to use weak references for the reference objects held by the Handler, and the messages in the Handler can also be cleared when the resource is released. For example, in Activity onStop or onDestroy, cancel the Message and Runnable of the Handler object.
5. In the implementation of Java, the release of its objects should also be considered. The best way is to explicitly assign this object to null when it is not in use, for example, after using Bitmap Call recycle() first, and then assign it to null to clear the arrays that have direct or indirect references to resources such as pictures (using array.clear(); array = null), etc. It is best to follow the principle of who creates and releases. ?
6. Correctly close the resource. For the use of resources such as BraodcastReceiver, ContentObserver, File, Cursor Cursor, Stream, Bitmap, etc., it should be closed or logged out in time when the Activity is destroyed. ?
7. Stay sensitive to the life cycle of objects, pay special attention to the life cycles of singletons, static objects, global collections, etc.
Okay, the article is over here. If you think the article is well written, give me a thumbs up? If you think there is something worth improving, please leave me a message. Will surely inquire carefully and correct deficiencies. thanks.