Why is Android event distribution completely resolved?

Why is Android event distribution completely resolved?

Respect Original reprinted Please note: From AigeStudio (http://blog.csdn.net/aigestudio) Power by Aige infringement must be investigated!

ArtilleryTown Building

I remember the teacher who taught me code said to me that if you want to learn a new thing, you only need three W: Why, What, and How, that is, Why? What is it? How? After you understand these three things, you must have a thorough understanding of new things. However, for most Student, What they are most interested in is "How", which is also the first W they come into contact with, followed by "What ", while "Why" is often ignored, which is also the root cause Why we cannot raise the level of existing knowledge.

Similarly, for event distribution, I don't plan to go into the topic to teach you how to view the source code and how to analyze the complex thinking logic of Android engineers, how to clarify the intricate abstract layers. As we have mentioned above, we will first try to pursue the ideas of Android designers and try to understand why event distribution is required. We all know that event distribution is a Breaking Point of Android event processing, which is hard to understand, in this case, why do we need to make such complicated things a part of Android? Since it is necessary, it must be indispensable, but why? Calm down and follow the detective ermos to pursue this ugly secret.

We all know that our mobile phones, other handheld devices, and even display devices have limited display areas, even the stock dashboard display is limited, and there are no unlimited screens, what's more, it's a big area of display. If you are a Android designer and want you to determine the display mode of an interface element, you have only two options based on the traditional operating habits and thinking methods:

Chioce:

Display the interface elements one by one on the screen, for example:

This method allows all interface elements to have their own space. It is much easier for the system to manage these spaces because they occupy a definite area of the screen, you only need to record these areas when they are displayed. Each element does not interfere with each other. However, the blind man can also see that such a display method has an eye-catching disadvantage. As the interface elements increase, once the screen is full, the size of all elements will be constantly adjusted so that more interface elements can be placed. In addition, if we want to arrange the elements in a stacked manner, this display method cannot be achieved, so, pass it.

Chioce B:

Display the interface elements hierarchically. Each element has an area of the same size as the display device theoretically. For example:

In this way, we can put down countless interface elements in the limited display device area, and solve many restrictions caused by Chioce. However, the world is not perfect. Even in the omnipotent code world, there are always flaws. In the Chioce A solution, because each interface element has its own unique independent region, every time A user interacts with it by means of A Touch display device, it will always Touch A unique element. But Chioce B does not work ...... Because of the stacked relationship between interface elements, every time we Touch, we may Touch N stacked elements. What should we do? At this time, we must introduce a mechanism that enables the system to process and determine which element the user wants to Touch. So, the event mechanism comes into being.

Of course, the emergence of the event mechanism is not due to the touch screen, and the above two interface display ideas are not from Android's shooting staff. They have existed since the day when the display device appeared, here is only an introduction.

Since Choice B is our Choice, how should we deliver the event? Suppose consists of the following interface elements:

Note: we do not consider windows or DecorView for the time being. We try to abstract our thinking as much as possible and do not confuse logic with code.

As shown in, G is our display device screen. A, C, and E are all at the same level in G, while B, D, and F are in A, C, and E respectively, the stacked effect is shown in. At this time, assume that a certain area of the Touch screen, such as the Red Area in:

In this case, the Touch event should be obtained by the F element according to the human behavior pattern. That is to say, when Touch occurs on the screen G, it is handed over to the F element:

G -----> F

After being handed over to F, F has the responsibility to inform the system that I have eaten this event. But there will be a problem. What if we want E below F to respond to this Touch event? Then our transmission method should be like this:

G -----> F -----> E

That is to say, both E and F can eat this event. What if DCBA is located under F and E? This is in a dilemma. We don't know who needs to eat it every time. Maybe someone wants to eat it for a while, it would be unscientific to pass events in the current "top-priority" mode, and it would not be in line with the relationship between the stacked structures of our interface elements. Well, we can pass events from the bottom layer. For the Touch point, when the Touch area is in the red position, we can let the system know the region of the event point through a series of calculations. Once an event point is found to fall within the range of a certain interface element (the event point falls within the range of all elements) in this case, events are delivered sequentially in the stacked order. For example, an event is triggered by the gpoint on the screen:

G -----> A -----> B -----> C -----> D -----> E -----> F

In this way, an event can be captured by Multiple Elements in sequence. This transmission method has a professional title: tunnel transmission. Once an element wants to eat this event, we only need to use some logic to inform the system that I have eaten this event, and you do not need to pass it to others! At this time, we should submit this signal to the system layer by layer. This submission method also has an interesting name: the bubble mechanism. Just like the fish in the water are spitting at a certain position, they always come back to the surface. This kind of chain structure transmission method can also be traced in the design model, for more information, see the responsibility chain model produced by Aige In the Android and design model series launched by the SAOS open-source organization of SM brother. Of course, you can also make an event unordered or even out-of-the-box transfer, but do not advocate it.

In actual processing of Android, the event mechanism is not as simple as we mentioned above. The above analysis is only a concentrated version of the event mechanism structure. This section is only the beginning. As an introduction to the event mechanism, there is no code involved. Originally, when writing a custom series of interactive articles, we found that the event mechanism is certainly involved, if it seems too bloated to write together, simply split it apart to better elaborate. This series serves as a custom series connected to an intermediate bridge and is analyzed by the GUI framework. So, stay tuned.