(a) That's what I wrote when I first started learning Android.
1 new Thread ( new Runnable () { public void Run () {myview.invalidate (); }}). Start ();
Later saw other blog said this violation of Android single-threaded model I do not understand the need to root planing problems
So how does it violate the single-threaded model?
Baidu a bit to find the reason below
when an Android program starts running, there is a main thread that is created. This thread is primarily responsible for the display, update, and control interaction of the UI interface, so it is also called the UI thread. Because only the UI thread updates the interface,
Android is a single threading model. When an Android program was created, a process presented a single-threaded model-that is, the main thread, an exception occurred in the invalidate () refresh interface on a non-main thread (UI thread), meaning that it was not allowed to update ui,android with other threads
For example, calling invalidate in a non-UI thread can lead to thread insecurity, which means that the UI thread (or other non-UI threads) also refreshes the interface when the interface is refreshed in a non-UI thread, causing multiple interface refreshes to be unsynchronized, resulting in thread insecurity
Oh, well, I understand. It involves multiple non-UI threading operations The UI can cause conflicts so it's not recommended, but it's not going to kill you. If I write like this does not involve UI actions such as I just do HTTP operations get database data
Can it also lead to thread insecurity? I personally think that as long as the UI is not involved in the operation of such writing can be so Android is still supported
(ii) Thread+handler
It is common practice to use handler to implement UI thread updates, as everyone writes.
I usually write custom a handler and Runnable conveniently later extended
/** * Custom Handler * * @author Dragon Tower * */public abstract class MyHandler extends handler{@Overridepublic void Handlemessage (Message msg) {try{myhandlemessage (msg);} catch (Exception e) {e.printstacktrace ();}} protected abstract void Myhandlemessage (Message msg) throws Exception;}
/*** Custom runnable * *@authorDragon Tower*/ Public Abstract classMyrunnableImplementsrunnable{@Override Public voidrun () {Try{myrun (); } Catch(Exception e) {e.printstacktrace (); } } protected Abstract voidMyrun ()throwsException;}
FinalMyHandler handler =NewMyHandler () {@Overrideprotected voidMyhandlemessage (Message msg)throwsException {
} }; NewThread (Newmyrunnable () {@Overrideprotected voidMyrun ()throwsException {looper.prepare (); DynamicTable=NewDynamicTable (testactivity. This); Message Message=Handler.obtainmessage (); Test method
Message.obj=dynamictable. loadtable (questionnaire); Message.sendtotarget (); Looper.loop (); }}). Start ();
}
Handler to handle UI updates based on received messages. The thread thread sends a handler message informing the update UI that the various documents and APIs are called by the demo discovery.
So the call should be foolproof, huh?
(c) Java habits. Android platform, this does not work, which is related to the thread security of Android is also related to the UI operation if it is not the operation of the UI this way I think it can be used
In the Android platform, you can use the TimerTask class that comes with Java on a recurring basis, and TimerTask is less for resource consumption than for thread, In addition to using the Alarmmanager with Android, using the timer timer is a better solution. We need to introduce import java.util.Timer; and import Java.util.TimerTask;
Public classJavatimerextendsActivity {Timer timer=NewTimer (); TimerTask Task=NewTimerTask () { Public voidrun () {Settitle ("Hear me?"); } }; Public voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate); Setcontentview (R.layout.main); Timer.schedule (Task,10000); } }
method Four: (TimerTask + Handler) Upgrade version of Method 3
Wrong wording involves thread safety
Public classTesttimerextendsActivity {Timer timer=NewTimer (); Handler Handler=NewHandler () { Public voidhandlemessage (Message msg) {Switch(msg.what) { Case1: Settitle ("Hear me?"); Break; } Super. Handlemessage (msg); } }; TimerTask Task=NewTimerTask () { Public voidrun () {Message message=NewMessage (); Message.what= 1; Handler.sendmessage (message); } }; Public voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate); Setcontentview (R.layout.main); Timer.schedule (Task,10000); } }
The correct wording is handled by the UI thread
ImportJava.util.Timer;ImportJava.util.TimerTask;Importandroid.app.Activity;ImportAndroid.os.Bundle; Public classTesttimerextendsActivity {Timer timer=NewTimer (); TimerTask Task=NewTimerTask () { Public voidrun () {Runonuithread (NewRunnable () {@Override Public voidrun () {Settitle ("Hear me?"); }}); } }; Public voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate); Setcontentview (R.layout.main); Timer.schedule (Task,10000); }}
Correct syntax two: Handle UI updates by handler.
Packagecom.test; ImportJava.util.Timer; ImportJava.util.TimerTask; Importandroid.app.Activity; ImportAndroid.os.Bundle; ImportAndroid.os.Handler; ImportAndroid.os.Message; Public classTesttimerextendsActivity {Timer timer=NewTimer (); Handler Handler=NewHandler () { Public voidhandlemessage (Message msg) {Switch(msg.what) { Case1: Settitle ("Hear me?"); Break; } Super. Handlemessage (msg); } }; TimerTask Task=NewTimerTask () { Public voidrun () {Message message=NewMessage (); Message.what= 1; Handler.sendmessage (message); } }; Public voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate); Setcontentview (R.layout.main); Timer.schedule (Task,10000); } }
There is also an alternative to threading in Android, which is task and Asynctask
Refer to this post for specific usage
http://blog.csdn.net/liuhe688/article/details/6532519
Various methods of Android operating thread parsing