PopupWindow阻塞和AlertDialog非阻塞的区别

在一次面试中，错误的把PopupWindow的阻塞和Dialog的非阻塞口误地解释为线程阻塞与否，后面都没法纠正，一激动，越解释错得越深，很伤心。这里做一个总结，以作警示。

通常我们理解的阻塞，是阻塞了某个线程，即代码执行到这里后等待这个函数块执行完毕，才能继续向下运行。比如常见的控制台输入函数，必须要求用户输入一个值才能继续，否则等待。

在Android里，一部分人对阻塞做了另外的解释：锁死了其它UI，只有当前这个模块可以被响应。具体什么意思呢？比如原本点击屏幕，会弹出一个Toast。那么好，现在我弹出一个UI，用户只能在这个UI操作，他再去点击这个UI外围的屏幕，将触发不了“弹出Toast”这个事件，那么就认为这个UI“阻塞”了应用。

放到PopupWindow阻塞和AlertDialog非阻塞上来看，二者本质区别为：AlertDialog弹出时，后台还可以做事情；而PopupWindow弹出时，程序会等待，在PopupWindow退出前，程序一直等待，只有当我们调用了dismiss方法的后，PopupWindow退出，程序才会向下执行。这两种区别的表现是：AlertDialog弹出时，背景是黑色的，但是当我们点击背景，AlertDialog会消失，证明程序不仅响应AlertDialog的操作，还响应其他操作，其他程序没有被阻塞，这说明了AlertDialog是非阻塞式对话框；PopupWindow弹出时，背景没有什么变化，但是当我们点击背景的时候，程序没有响应，只允许我们操作PopupWindow，其他操作被阻塞。

可见，ＰｏｐｕｐＷｉｎｄｏｗ的“阻塞”，其实只是一种屏蔽。它仅仅是使得其它控件不可被操作罢了。说它是“阻塞的”，没问题，就是容易误导；但说它是“线程阻塞”的就呵呵了。

总结：ＰｏｐｕｐＷｉｎｄｏｗ的”阻塞”并没有使你的线程ｗａｉｔ。它完全取得了用户操作的响应处理权限，从而使其它ＵＩ控件的操作不被触发，仅此而已。无论AlertDialog还是PopupWindow，都不能做到传统意义上的线程阻塞。想要根据用户的某个操作来决定程序流程（否则不继续执行），只能把主线程ｗａｉｔ掉。但这样会导致ＡＮＲ，所以取巧的方法是ｗｈｉｌｅ（［某个值没有被改变］）　ｓｌｅｅｐ（１００）；是的，间歇性ｓｌｅｅｐ主线程，告诉Ａｎｄｒｏｉｄ，咱每１００ｍｓ有一次响应，你别给我ＡＮＲ了啊。