PopupWindow does not contain a Window object. It will manage its own control tree and establish a two-way connection with the window service. PopupWindow does not appear at a fixed position like AlertDialog. It depends on the position of the anchor control object, that is, the position of a certain control in the interface. Before constructing and displaying the pop-up window, you need to ensure the anchor control and window management. The service establishes contact and the establishment of the window connection is an asynchronous process. That is to say, when functions such as Activity.onCreate are called, the two-way connection between the interface and the window service has not yet been established. If a pop-up window is constructed at this time, an exception will be thrown and the thread will be blocked. The message sent through the View.post() function can be put into a static queue, and when the communication is established, it will be taken out of the queue for execution.
Personally, I think the description of the online information is inaccurate In fact, both methods do not block the execution of the sub-thread. The sub-thread is still doing whatever it is supposed to do The main thread is theoretically "blocked", but one is that other areas can receive it Responding to touch events, it’s just not possible If you can’t receive and respond to touch events, it is probably described as blocking the thread
Actually, I don’t quite understand it either… because PopupWindow is less likely to affect the use of the main interface than AlertDialog. For example, Spinner was implemented in the form of AlertDialog in previous Android versions, which would pop up a dialog box in the center of the phone screen. At this time, you can only operate the content of the dialog box unless the dialog box disappears. The current version of Spinner is implemented by PopupWindow. You will find that outside of the PopupWindow display, you can click on other locations on the interface to trigger events.
As for your conjecture, I think it is wrong, or there is a misunderstanding in the online statement, or the description is ambiguous.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
PopupWindow does not contain a Window object. It will manage its own control tree and establish a two-way connection with the window service.
PopupWindow does not appear at a fixed position like AlertDialog. It depends on the position of the anchor control object, that is, the position of a certain control in the interface. Before constructing and displaying the pop-up window, you need to ensure the anchor control and window management. The service establishes contact and the establishment of the window connection is an asynchronous process.
That is to say, when functions such as Activity.onCreate are called, the two-way connection between the interface and the window service has not yet been established. If a pop-up window is constructed at this time, an exception will be thrown and the thread will be blocked.
The message sent through the View.post() function can be put into a static queue, and when the communication is established, it will be taken out of the queue for execution.
Personally, I think the description of the online information is inaccurate
In fact, both methods do not block the execution of the sub-thread. The sub-thread is still doing whatever it is supposed to do
The main thread is theoretically "blocked", but one is that other areas can receive it Responding to touch events, it’s just not possible
If you can’t receive and respond to touch events, it is probably described as blocking the thread
Actually, I don’t quite understand it either… because PopupWindow is less likely to affect the use of the main interface than AlertDialog. For example, Spinner was implemented in the form of AlertDialog in previous Android versions, which would pop up a dialog box in the center of the phone screen. At this time, you can only operate the content of the dialog box unless the dialog box disappears. The current version of Spinner is implemented by PopupWindow. You will find that outside of the PopupWindow display, you can click on other locations on the interface to trigger events.
As for your conjecture, I think it is wrong, or there is a misunderstanding in the online statement, or the description is ambiguous.
This kind of thing is just an experiment on your own, but I feel like you have been misled
Popupwindow can respond to events outside the area through settings. I don’t quite understand these two links.
That’s not right. There is no such thing as blocking a thread