Android Kernel Analysis Reading Notes Chapter 1 view working principle [Message Type and key message distribution]

View is one of the three core components of the Android system (the other two are AMS and WMS ), we often mention activity/service/content provider/broadcast aggreger, which is four major components of application development;

View provides an abstraction for displaying various elements on pages. All UI controls (such as buttons and text boxes) used in Android are inherited from the View class, he mainly implements two core functions: one is to provide corresponding processing mechanisms for various buttons and touch screen input messages; the other is: complete the painting of various UI controls on the canvas and the re-painting triggered under various conditions;

User Message Type

Messages generated by users using input devices such as the keyboard or touch screen do not directly enter the view system. Instead, messages are intercepted and converted by the message processing front-end, after the conversion from the original hardware code value to the code value that can be recognized by the operating system, WMS then filters the corresponding messages based on some rules, therefore, the message is sent to the corresponding application window. After arriving at the target window, it is the internal processing logic of the application. This is the function to be completed by the view system described in this chapter; converted messages are roughly divided into three categories: keyevent, motionevent, and trackball. With the development of mobile phone hardware, trackball has been completely discarded, physical buttons are also being weakened gradually, but some vendors have begun to use touch screen clicks to simulate button messages to keep apps backward compatible;

1. The key event of the key message, which defines the parameters contained in the key message. The core API interfaces include:
   1. Getaction (): return the specific actions of the buttons, which are action_down/
      Action_up/action_multiple;
   2. Getkeycode (): return the key code. Commonly used keys include power keys, sound size adjustment, mute keys, return keys, home keys, and menu keys, which are marked by the corresponding constant value;
   3. Getrepeat (): return the number of repeat times after the button is pressed, which is equal to the number of characters displayed on the screen-1; returns 0 after the button is released;
   4. Note that when the button is pressed to start repeating, the process from 1 to 2 will take a lot of time, the subsequent 2-3, 3-4 and so on are the same, and the time is less than 1-2. This design is automatically processed within the view system and is completely transparent to developers. The reason for this design is to provide a better user experience, this is because when you press the button for the first time, you may just want to complete a click operation, instead of triggering duplicate keys. If our response is too fast, the logic of repeated keys may be triggered, which is obviously contrary to your expectation, however, when the user keeps pressing the button, the user's requirements are clearly long-pressed, so the duplicate button message is generated at this time, which is consistent with the user's expectation;
   5. Keyevent. Callback interface: this interface defines the callback Method for key message processing, such as onkeydown/onkeylongpress/onkeyup;
      This interface is implemented mainly by view and activity, which will be involved in the subsequent key message processing process;
      Note that although the keyevent. Callback interface is not implemented in phonewindow, The onkeydown/onkeyup method is also used to process some special logic. For details, see the key message processing process;
2. The Touch message motionevent class defines the touch-related message parameters. The core API interfaces include:
   1. Getaction (): gets message actions. There are many types of actions, because touch screens currently support multi-touch operations, the most common include action_down/
      Action_up/action_move;
   2. Geteventtime () and getdowntime (): the former obtains the time when the message occurred, and the latter obtains the time when the down message occurred;
   3. Getx (.) and Gety (.): returns the x/y coordinates of the touch point. If no parameter is set, the coordinates of the first touch point are returned. For multi-touch, the index parameter indicates the specific point, starting from 0;
   4. Note: There is usually a jitter problem in the touch. For example, when a user presses the screen, he thinks his fingers are not moving, but the move event actually occurs, users need to pay special attention to this situation when processing touch messages. For example, they can add the moving distance before and after the move event to avoid the troubles caused by the high sensitivity of the underlying hardware;

Two types of Long press monitoring

1. Message Processing front-end "Long press": As mentioned above, this is to eliminate users' physiological response time. To avoid confusion, it can be called "physiological long press ", it refers to the time interval between the first two down messages generated when you press the button. The specific value is defined in the underlying C ++ source code, generally, application developers do not need to care about the message;
   It is reflected in the Code. To respond to the "physiological long press" message, you need to overload the onkeylongpress () method in the View class;
2. Common "Long-pressed": a key message that developers often access. It refers to the time interval between two down messages after physiological long-pressed. The default value is in viewconfiguration.
   The 500 ms defined in default_long_press_timeout;
   It is reflected in the Code. To respond to the long-pressed message, you can execute setonlongclicklistener (.) on the view object that needs to respond to the event (.), the parameter is Android. view. view. onlongclicklistener interface implementation class instance;
3. How is "Long press" triggered? After "physiological long press", the system sends an asynchronous message by default, specifying that the message runs a runnable code after the specified time (500 ms by default, this code is called back to the onlongclicklistener interface instance set for the view.
   Onlongclick (.) method; if the user has released the button before the specified time, the system will automatically delete the asynchronous message sent previously, so that it will naturally not perform logic-based execution;

Overall Dispatch process of key messages

As mentioned earlier, when a page is displayed, viewrootimpl. setview (…) is executed (...), Here, the windowsession is called to complete the request to submit a new window to the WMS server, and the system also registers the callback interface instance windowinputeventventer when the window has a message, when a message is generated, WMS performs some preprocessing first. The core is to process the messages that are pressed in some system-level windows (for example, when the screen is in the screen lock window, press the Home Key, in this case, the launcher application cannot be started. For example, you can monitor the long press of the Home key. If you press the home long press, the list of recently loaded applications will be displayed.) The specific code is in phonewindowmanager. interceptkeybeforedispatching (...);

Then, it calls back to the windowinputeventreceiver and then enters the deliverinputevent (.) method to process all input messages, including buttons and touch screens, and then execute different logic based on different categories. For the key message, enter deliverkeyevent (.), the specific execution logic is as follows:

1. Execute mview. dispatchkeyeventpreime (event), that is, some callbacks before processing the input method. For the view system, if an input method window exists, the key message is first distributed to the input method window, only when the input method window does not process the message will the message be distributed to the real view. For information displayed in the input method window, what do developers want to do before the input method actually processes the message, you can reload this method in the view;
2. If an input method window exists, run Imm. dispatchkeyevent (...), Let the input method process related messages;
3. Run deliverkeyeventpostime (.) to distribute the message to the real view, which is called
   Mview. dispatchkeyevent (event );
   Note: The mview variable here refers to the phonewindow. decorview instance, so the execution method is not the dispatchkeyevent method in the base class view!
   The specific logic in phonewindow. decorview. dispatchkeyevent (.) includes:
   1. Process system shortcuts. For example, the most common option is to trigger the menu key to call up the corresponding panel menu item;
   2. If the message has not been processed, check whether the phonewindow instance has a window. Callback instance (this instance is set during phonewindow initialization). If there is an activity that is generally corresponding to the current window;
      1. The activity callback instance does not exist. Execute decorview. super. dispatchkeyevent (.) method. The parent class of decorview is framelayout --> viewgroup --> View at one time, so the view is executed. dispatchkeyevent (.);
         1. Check whether the current view has set an onkeylistener interface instance. If yes, call
            Onkey (...) Method to process messages;
         2. If no callback is set, the view. onkeydown/onkeyup callback method is executed;
            Here we will process two types of events: Click and long-pressed longclick. The specific scheme has been mentioned before, that is, it will be called when the down event is generated.
            Postdelayed (mpendingcheckforlongpress, viewconfiguration. getlongpresstimeout ()-delayoffset); generates a delayed asynchronous task, and selects whether to execute or delete the asynchronous task based on whether the user duration exceeds the interval;
         3. Note: when processing a key message in viewgroup, super is called first. dispatchkeyevent (), that is, the parent view is preferentially processed. If the parent view is not consumed, the Child view mfocusedview is called. dispatchkeyevent () for processing;
      2. If an activity callback instance exists, execute the activity. dispatchkeyevent (.) method;
         1. Execute onuserinteraction (); you can reload this method in your own activity to do something before the message is processed;
         2. Run phonewindow. superdispatchkeyevent (.); actually, it is transferred to execute decorview. super. dispatchkeyevent (.), this step is consistent with the logic when no activity callback instance exists above, that is, the view system will first process the key information;
         3. If the view system does not process the message, the callback method of activity. onkeydown/onkeyup is executed;
   3. If the message has not been processed, call the phonewindow. This. onkeydown/up (.) method to process the volume key, rollback key, menu key, and search key;
4. If the message has been consumed, run finishinputevent (...) Complete a message distribution;

If the above content is reproduced, please indicate the source, welcome to visit the column http://blog.csdn.net/sfdev of laotang