Keywords: J2ME MIDLET thread
Contact your author: xiaozuidaizhi@sina.com
============================================================================================================================================================================================================= ===============================
First define a few nouns: 1. MYMIDLET is a class inherited with MIDlet (as for the MyMIDlet to implement other interfaces, we don't care) 2. MYCANVAS is a class inherited to Canvas (Mycanvas implements other interfaces, we don't care) 3. "Enter" indicates that the first "additional" of the DEBUG is the first "additional": After debug, I found that in the main thread, the first code in a MIDET is the constructor of the object of the MyMIDlet class, and then enters The robustomcode () method of the java.lang.class class, then go to the unknown method in the comlic abstract (commissioning, if someone knows, please let inform ), Then enter the com.sun.midp.midlet.selector class (Extends Midlet ImmandListener, runnable), started the run () method, the first "additional" birth.
The second "additional": then continue Debug: The startApp method that calls the MyMIDlet class instance, execute Display.getDisplay (this) .SetCurrent (Displayable), because the parameter of the setCurrent is an instance of the Mycanvas class, so this Perform (referring to DISPLAY.GETDISPLAY (this) .SetCurrent (Displayable)) is called (enter) the Paint () method of Mycanvas, so the member method of Display should setcurrent should be similar to the following code:
Public void setcurrent (Displayable D) {... graphics g = d.getgraphics (); // Generate a Graphics instance D.Paint (g); ...}
After performing the PAINT method, enter the other unknown method in the Canvas class, and then enter the unknown method of Display, then it is broken after entering a few unrelated classes, but the reason is not looking for, but we can get the second additional additional : On the simulator clicking, you will find it to debug, then, when you execute the CommandAction method, then DEBUG a few times, you have entered such a class: com.sun.midp.lcdui.defaultEventHandler public & implements EventHandler), then into com.sun.midp.lcdui.AutomatedEventHandler (public & extends DefaultEventHandler implements AutomationHandler) class, two classes into inheritance, whereas in another class DefaultEventHandler an inner class VMEventHandler (implements Runnable) A Run () method, so the second "additional" generation :) About the first "additional": I think this thread is listening to the MIDlet status listening thread, called status listening thread
About the second "additional": I think it is listening to the listening thread input by the keyboard, called the keyboard to listen thread
This thread is similar to the following code:
Private Void Run (canvas can) {while (TRUE) {int keycode = getKeyPRESSED (); // This method is to capture the underlying method IF of the user button (Keycode> 0) {// Judgment whether there is a user button Keydeal (Canvas, Keycode ); // call the following method}}}
Private void keydeal (canvas canvas, int keycode) {canvas.keypressed (keycode);
So, in a MIDET, there is usually the following four threads:
Main thread
2. Status listening thread
3. Keyboard listening thread
4. Painting the thread of the drawing of yourself.
============================================================================================================================================================================================================= =====================
