每日一问 为什么 Dialog 默认弹出后 Activity 就无法响应用户事件了？

这个问题很简单，这个是因为Dialog是Focusable的。如果不是Focusable的，那么Dialog 弹出后 Activity 还是可以响应用户事件的。

首先要明确一个概念是窗口是事件分发的基本单位，而不是activity或者应用。系统的事件总是要先分给窗口，决定要分给哪个窗口是在系统的InputDispatcher.cpp这个类中。

对于touch事件，还要再由窗口交给DecorView在控件树中进行分发，最终到达某个View。但在此之前，会交由activity进行处理一下。

可以用以下demo测试一下：

view = new MyButton(this);
getWindowManager().addView(view, getWindowParams());

private WindowManager.LayoutParams getWindowParams(){
        WindowManager.LayoutParams params = new WindowManager.LayoutParams();
        //params.flags |= WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
        params.width = 490;//窗口的宽和高
        params.height = 160;
        params.x = 500;//窗口位置的偏移量
        params.y = 0;
                params.setTitle("MyDialog"); // 设置窗口的名字
        return params;
    }

    public void dismiss(){
        getWindowManager().removeView(view);
    }

    class MyButton extends AppCompatButton {

        private TestWmsActivity activity;
        public MyButton(TestWmsActivity context) {
            super(context);
            activity = context;
        }

        @Override
        public boolean onTouchEvent(MotionEvent event) {
            Log.d(Config.TAG, "onTouchEvent: " + event.getAction());
            activity.dismiss();
            return true;

        }

        @Override
        public boolean onKeyDown(int keyCode, KeyEvent event) {
            Log.d(Config.TAG, "onKeyDown: " + keyCode);
            activity.dismiss();
            return true;
        }
    }

getWindowManager().addView 这里的添加view其实是添加一个子窗口。添加完MyDialog以后，我们的activity一共就有两个窗口了，另外一个是默认生成的子窗口。这一点可以通过adb shell dumpsys window visible来查看：

Window #6 Window{57cc6f1 u0 MyDialog}:
   ...
Window #7 Window{a38a957 u0 com.example.xcm.demo/com.example.xcm.demo.wms.TestWmsActivity}:
   ...

主窗口的名字一般就是activity的ComponentName。子窗口的名字如果不调用params.setTitle()进行设置，那么默认也是所属activity的ComponentName，只是前面的地址不一样而已。

可以看到，子窗口是在主窗口上面，即子窗口的z序是小于主窗口的。

我们的MyDialog 没有加上params.flags |= WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE; 这句话的时候，子窗口的touch区域其实是整个Frame，也就是主窗口完完全全被子窗口挡住了，自然无法响应用户事件。这个说法有什么证据吗？可以通过adb shell dumpsys input 来查看一下：

在Input Dispatcher State:一栏中，有以下信息：

      6: name='Window{e3f21ef u0 MyDialog}',  paused=false, hasFocus=true visible=true, canReceiveKeys=true frame=[590,1127][1080,1287], **touchableRegion=[0,0][1080,2340]**,
            7: name='Window{d68c785 u0 com.example.xcm.demo/com.example.xcm.demo.wms.TestWmsActivity}', paused=false, hasFocus=false,  visible=true, canReceiveKeys=true, frame=[0,0][1080,2340], **touchableRegion=[0,0][1080,2340]**

可以看到虽然子窗口的看起来只有 frame=[590,1127][1080,1287] 这么大，但其touchableRegion=[0,0][1080,2340]却是全屏的，和主窗口一样大，又在主窗口上面，于是挡住了主窗口；所以主窗口，即大家经常说的acitivity，无法接收到touch事件。只有当子窗口接受到事件dismiss以后，才能接收到事件。

当MyDialog 加上params.flags |= WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE; 这句话的时候 ,它的touch区域发生了变化。

 6: name='Window{e3f21ef u0 MyDialog}',  paused=false, hasFocus=false visible=true, canReceiveKeys=false frame=[590,1127][1080,1287], **touchableRegion=[590,1127][1080,1287]**,

现在子窗口看起来多大，能接受touch事件的区域也就多大了，其余区域不会在阻拦主窗口的事件。而且现在子窗口无法接受key事件，canReceiveKeys=false。

最后，为什么谷歌要这么做？原因不是很清楚，可以猜测一下：如果一个窗口是Focusable的，那么其是要响应全局事件的，因为Focusable对应着key事件，意味可以接受key事件，而key事件是全局的（没有一个具体的区域，touch事件是有局域的，就是touchableRegion），所以为了统一，也把touchableRegion改成了全屏。如果你调反过来，如果一个子窗口是不能接受key事件的，那么它实际上多大，它的touchableRegion也就是多大。

总结：

因为Android中特意淡化了Window的概念，所以可能很多同学只知道activity而不知道Window。如果弄清楚了Window在事件分发中的作用，这个问题还是容易理解的。

结论就是子窗口弹出了以后，因为它在窗口的上面，而且他的touchableRegion是全屏，挡住了主窗口，所以系统把touch事件都发给子窗口了，主窗口无法响应。

demo代码：https://github.com/CQULittleMing/AndroidDemo/blob/master/demo/src/main/java/com/example/xcm/demo/wms/TestWmsActivity.java

这个只是个人学习的一个demo，大家看看就好哈哈～

运行以后在Window - window - TestWmsActivity中

Dialog 弹出后 Activity 就无法响应用户事件？是事件分发的原因吗？

我一直认为是后面的activity进入了onPause()，Activity在onResume()中才能与界面进行交互。

然后最近做了一个TV的自定义dialog，这个dialog本身就是一个activity，只是改了theme样式，我弹出dialog的判定本身就是使用ok键，如果弹出后还能响应原activity的用户事件那岂不是乱套了，我在本dialog中无法使用ok键，而且无限弹框了。

然后题目中说了“搞清楚 Window,Activity,DecorView 在事件分发环节的调用流程。”，我就有点头绪了，因为android的事件分发是U形的，也就是在前端中的事件捕获（从上到下）与冒泡事件（从下到上）的组合。当时我有个大胆的理解是，你在网页中，你使用的是鼠标，鼠标是在屏幕里面的，就可以把它想成一个最底层的组件，只是z-index最高就好；而在手机中，点击的一般是我们手指，你只能点到屏幕，他最开始收到信号的只能是屏幕，然后只能根据Android视图间的层级关系往下传递，最后再冒泡回来。

链接：https://juejin.im/post/5da210ccf265da5ba0778541

根据上图可以认为Android中一个页面的窗口展示，很多时候都可以认为是一个activity，这样理解没错，但更确切的说window才是负责页面展示的，在了解view的绘制流程的时候，activity持有window对象，activity负责加载布局并将布局添加到window对象中（最后绘制完后是通过AMS进行反馈，调用addWindow让系统进程加载Window）。原生dialog的显示并不由activity来控制，dialog的显示是由window来控制的。自定义的dialog就是一个新的activity，所以他的控制也不是原来的activity控制的。

就像上面链接中说到android的事件分发的时候很多都会略过PhoneWindow这一层，因为dialog的目的就是一种对话框的存在，几乎是一次性的存在（对于一次对话来说）。甚至是提示框，如果你有那么多交互的东西，你会像我一样去自定义一个dialog，其实就是一个非全屏的activity。

注意下这个问题有些歧义，其实Dialog并不是一定会挡住Activity的所有touch事件。