A brief analysis of the message mechanism in Android-Solution: Only the original thread, created a view hierarchy can touch its views.

Before analyzing the Android messaging mechanism, let's look at a piece of code:

[HTML]View Plaincopyprint?

2. public class Mainactivity extends Activity implements View.onclicklistener {
6. Private TextView Statetext;
8. Private Button btn;
12. @Override
14. public void OnCreate (Bundle savedinstancestate) {
16. Super.oncreate (savedinstancestate);
18. Setcontentview (R.layout.main);
20. Statetext = (TextView) Findviewbyid (r.id.tv);
22. btn = (Button) Findviewbyid (R.ID.BTN);
26. Btn.setonclicklistener (this);
28. }
32. @Override
34. public void OnClick (View v) {
36. New Workthread (). Start ();
38. }
42. Worker threads
44. Private class Workthread extends Thread {
46. @Override
48. public void Run () {
50. //...... Handle more time-consuming operations
54. Change status after processing is complete
56. Statetext.settext ("completed");
58. }
60. }
62. }

This code seems to look normal, but when you run it you will find that it will report a fatal exception:

[HTML]View Plaincopyprint?

1. Error/androidruntime (421): FATAL exception:thread-8
2. Error/androidruntime (421): android.view.viewroot$calledfromwrongthreadexception:
3. Only the original thread, created a view hierarchy can touch its views.

What the hell is going on here? The reason is that the view components in the Android system are not thread-safe, and if you want to update the view, you must update it in the main thread, and you cannot perform the updated operation on the child thread.

In this case, we will notify the main thread in the child threads, let the main thread do the update operation. So how do we notify the main thread? We need to use the handler object.

Let's modify the above code a little bit:

[HTML]View Plaincopyprint?

2. public class Mainactivity extends Activity implements View.onclicklistener {
6. private static final int completed = 0;
10. Private TextView Statetext;
12. Private Button btn;
16. Private Handler Handler = new Handler () {
18. @Override
20. public void Handlemessage (Message msg) {
22. if (msg.what = = completed) {
24. Statetext.settext ("completed");
26. }
28. }
30. };
34. @Override
36. public void OnCreate (Bundle savedinstancestate) {
38. Super.oncreate (savedinstancestate);
40. Setcontentview (R.layout.main);
42. Statetext = (TextView) Findviewbyid (r.id.tv);
44. btn = (Button) Findviewbyid (R.ID.BTN);
48. Btn.setonclicklistener (this);
50. }
54. @Override
56. public void OnClick (View v) {
58. New Workthread (). Start ();
60. }
64. Worker threads
66. Private class Workthread extends Thread {
68. @Override
70. public void Run () {
72. //...... Handle more time-consuming operations
76. Send message to Handler when processing is complete
78. Message msg = new Message ();
80. msg.what = completed;
82. Handler.sendmessage (msg);
84. }
86. }
88. }

In this way, we can solve the problem of thread safety, the complex task processing to the child thread to complete, and then the child thread through the handler object to inform the main thread, the main thread to update the view, the process of the message mechanism plays an important role.

Let's look at the message mechanism in Android.

A friend familiar with Windows programming knows that Windows programs are message-driven and have a global messaging system. Google has referenced the Windows message loop mechanism, and also implemented a message loop mechanism in the Android system. Android uses Looper, handler to implement the message loop mechanism. The message loop for Android is thread-specific, and each thread can have its own message queue and message loop.

The Looper in the Android system is responsible for managing thread Message Queuing and message loops. The Looper object of the current thread is obtained through Looper.mylooper (), and the Looper object of the current process's main thread is obtained through Looper.getmainlooper ().

As mentioned earlier, both the message queue and message loop for Android are specific threads, one thread can have a message queue and a message loop, and a particular thread's message can only be distributed to this thread, and cannot be communicated across threads and across processes. However, the worker threads created by default do not have Message Queuing and message loops, and if you want the worker thread to have Message Queuing and message loops, you will need to call Looper.prepare () to create the message queue in the thread and then call Looper.loop () to enter the message loop. Here are the worker threads we created:

[HTML]View Plaincopyprint?

2. Class Workthread extends Thread {
4. Public Handler Mhandler;
8. public void Run () {
10. Looper.prepare ();
14. Mhandler = new Handler () {
16. public void Handlemessage (Message msg) {
18. Process the received message
20. }
22. };
26. Looper.loop ();
28. }
30. }

In this way, the worker threads we create have a message handling mechanism.

So why do we not see Looper.prepare () and Looper.loop () calls in the preceding example? The reason is that our activity is a UI thread that runs in the main thread, and the Android system creates a message queue and message loop for the activity when it starts.

The most mentioned is Message Queuing (MessageQueue) and message loop (Looper), but we see that every message processing place has a handler existence, what does it do? The role of handler is to add messages to a message queue that is managed by a particular looper and to distribute and process messages in that message queue. When constructing handler, you can specify a Looper object that is created with the Looper object of the current thread if not specified. Here are the two construction methods for handler:

[HTML]View Plaincopyprint?

2. /**
4. * Default Constructor Associates This handler with the queue for the
6. * Current thread.
8. *
10. * If there isn ' t one, this handler won ' is able to receive messages.
12. */
14. Public Handler () {
16. if (Find_potential_leaks) {
18. Final Class<?  extends Handler> klass = getclass ();
20. if (Klass.isanonymousclass () | | klass.ismemberclass () | | klass.islocalclass ()) &&
22. (Klass.getmodifiers () & modifier.static) = = 0) {
24. LOG.W (TAG, "the following Handler class should be static or leaks might occur:" +
26. Klass.getcanonicalname ());
28. }
30. }
34. mlooper = looper.mylooper ();
36. if (mlooper = = null) {
38. throw New RuntimeException (
40. "Can ' t create handler inside thread that have not called looper.prepare ()");
42. }
44. mqueue = mlooper.mqueue;
46. mcallback = null;
48. }
52. /**
54. * Use the provided queue instead of the default one.
56. */
58. Public Handler (Looper Looper) {
60. mlooper = looper;
62. mqueue = looper.mqueue;
64. mcallback = null;
66. }

Here is a diagram of several important members of the messaging mechanism:

In one activity, multiple worker threads can be created, and if those threads put their messages in the message queue of the activity's main thread, the message is processed in the main thread. Because the main thread is generally responsible for updating the view component, this is a good way to implement the view update for a view component that is not thread-safe.

So how does a child thread put the message into the message queue of the main thread? As long as the handler object is created with the looper of the main thread, when the SendMessage method of handler is called, the system puts the message queue of the main thread of the message, and the message in the main thread message queue is processed when the Handlemessage method is called.

For a child thread to access the handler object of the main thread, you might ask that many sub-threads have access to the handler object of the main thread, and that data inconsistencies will occur during the sending and processing of messages. The answer is that there is no problem with the handler object, because the Looper object managed by the handler object is thread-safe, regardless of whether the message is added to the message queue or read from the message queue is synchronously protected, so there is no data inconsistency.

In-depth understanding of the Android message processing mechanism is very important for application development, but also allows us to have a deeper understanding of thread synchronization, I hope this article can help friends.

Articles reproduced at source: http://blog.csdn.net/liuhe688/article/details/6407225#

A brief analysis of the message mechanism in Android-Solution: Only the original thread, created a view hierarchy can touch its views.