Android Footstep---How to look at the log program to stop running, and switch between the UI thread and the non-UI thread

When running eclipse, it burns to the phone and "stops running", so you have to check log by Logcat. This is generally the case for fatal EXCEPTION, so retrieve fatal or EXCEPTION, then look down a few lines

Example:

11-26 16:18:17.949:e/androidruntime (5363): FATAL exception:thread-193
11-26 16:18:17.949:e/androidruntime (5363): Process:com.scme.jiance, pid:5363
11-26 16:18:17.949:e/androidruntime (5363): Android.view.viewrootimpl$calledfromwrongthreadexception:only the Original thread that created a view hierarchy can touch it views.

See only the original thread that created a view hierarchy can touch it views. Description The main thread within the definition of the new thread inside cannot be called, so the remedy, search:Android U I threads and non-UI threads , the workaround is as follows:

Http://www.cnblogs.com/mengdd/p/3418780.html

Android UI threads and non-UI threads

UI threading and Android's single-threaded model principles

When the app starts, the system creates a main thread (main thread).

This main thread is responsible for distributing events to the UI component (including drawing events), and also in this main thread, your app and the Android UI components (the component from the Android UI Toolkit Android.widget and Android.view packages) interact.

So the main thread is also called the UI thread .

The system does not create a separate thread for each component, the UI component in the same process is instantiated in the UI thread, and the system's call to each component is distributed from the UI thread .

As a result, methods that respond to system callbacks, such as onkeydown () and various life-cycle callbacks that respond to user actions, are always run in the UI thread.

When the app does some heavy work (intensive), the performance of the single-threaded model will be poor unless you reasonably implement it.

In particular, if all the work is done on the UI thread, doing more time-consuming work such as accessing the network or querying the database will block the UI thread , causing the event to stop distributing (including drawing events). For the user, the app looks like it's stuck, and worse, if the UI thread blocked for too long (about 5 seconds), the user sees a dialog box for the ANR(application not responding).

In addition,andoid UI Toolkit is not thread-safe, so you cannot manipulate UI components from a non-UI thread. You have to put all the UI actions on the UI thread, so Android's single-threaded model has two principles:

　　1. Do not block the UI thread.

　　2. Do not access the Android UI Toolkit(mainly the components in these two packages: and Android.view) outside the UI thread android.widget .

working with worker threads

According to the two principles of the single-threaded model, first of all, to ensure that the application's responsiveness, not blocking the UI thread, so when your operation is not the kind of instant (not instantaneous), you should put them into the separate line approached (called background or call worker thread ).

For example, after clicking the button, download a picture and show it in ImageView:

Press CTRL + C to copy the codePublic <textarea style="width: 1319px; height: 176px; line-height: 1.5; font-family: Courier New; font-size: 12px;">void OnClick (View v) {New Thread (new Runnable () {public void run () {Bitmap b = loadimag Efromnetwork ("Http://example.com/image.png"); Mimageview.setimagebitmap (b); }}). Start ();}</textarea>Press CTRL + C to copy the code

This code handles the network operation with a new thread, but it violates the second rule:

　　Do not access the Android UI Toolkit from outside the UI thread.

Accessing the UI component from a non-UI thread can result in undefined and unpredictable behavior .

　　To solve this problem, Android provides some ways to access the UI thread from other threads:

• Activity.runonuithread (Runnable)
• View.post (Runnable)
• View.postdelayed (Runnable, long)

For example, the above code can be changed:

void OnClick (View v) {    new Thread (newvoidfinal Bitmap Bitmap = loadimagefromnetwork ("http/ Example.com/image.png "); Mimageview.post (newvoid run () {mimageview.setimagebitmap (bitmap);}});}). Start ();}        

This is a thread-safe way to change.

However, when the operation becomes complex, the code becomes very complex, and in order to handle the more complex interactions between the non-UI thread and the UI thread, consider using one in the worker thread Handler to handle the messages coming from the UI thread.

You can also inherit this class Asynctask.

communicating with the UI Thread

　　only objects in the UI thread can manipulate the alignment in the UI thread, and in order to transfer data from non-UI threads to the UI thread, a handler is used to run in the UI thread.

Handler is part of managing threads in the Android framework, and a handler object is responsible for receiving messages and processing messages.

You can create a handler for a new thread, or you can create a handler and then connect it to a wired thread.

　　If you connect a handler to your UI thread, the code that processes the message will be executed in the UI thread.

You can instantiate the handler object in the constructor of the class where you created the thread pool, and then store the object with a global variable.

To connect to the UI thread, you should use Handler(Looper) this construction method when instantiating handler.

This construction method uses an Looper object, which is another part of the framework that the Android system threads to manage.

　　When you Looper create a handler with a specific instance, the handler runs in this Looper thread.

In handler, the method is to be written handleMessage() . The Android system calls this method when a new message is received by the appropriate thread that handler manages .

　　All handler objects of a particular thread will receive the same method. (This is a "one-to-many" relationship).

Based on the workaround described above, use the second view.post (Runnable)

Program:

    Imageview1.post (new  Runnable () {                            @Override                            publicvoid  run () {                                 // TODO auto-generated Method Stub                                 Imageview1.setimagebitmap (IMG1);                            }                                                    });

Where imageview1 is defined in the main thread and therefore accessed in other threads, it needs to go back to the main thread processing through view.post (Runnable) .

Android Footstep---How to look at the log program to stop running and switch between the UI thread and the non-UI thread