1.android onTouchEvent和setOnTouchListener中onTouch的区别
2.❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️

android onTouchEvent和setOnTouchListener中onTouch的区别

       android中onTouchEvent和setOnTouchListener中onTouch的区别可以有些人并不了解，其实要说明白这个问题先要说下android的事件传递机制。 首先看下以下的代码1，这段代码反应了View处理事件的过程： 代码1： public boolean dispatchTouchEvent(MotionEvent event) { if (mOnTouchListener != null && mOnTouchListener.onTouch(this,源码 event)) { return true; } return onTouchEvent(event); } 在代码1中有一点首先需要明确，那就是如果dispatchTouchEvent返回值为true则本次事件被系统消耗掉（就是被控件处理了）， 然后一个新的事件会被传入，如果dispatchTouchEvent返回值为false，则不会有新的事件被传入。 好，明白了这一点再看那个代码1中if语句后面的条件mOnTouchListener != null && mOnTouchListener.onTouch(this, event)，mOnTouchListener 对象其实不就是你写的监听器对象吗？比如下面代码2的这个匿名对象。 代码2： xxxView.setOnTouchListener(new OnTouchListener() { @Override public boolean onTouch(View v, MotionEvent event) { return true; } }); 好，我们再看下代码2中onTouch事件中的返回值，如果代码2 return true则代表什么呢？代表代码1中将不会执行 return onTouchEvent(event);语句，这也就是说这次系统事件会被消耗掉，将会再次执行dispatchTouchEvent这个方法。 如果代码2 return false则代表代码1会执行onTouchEvent(event);这个方法，本次事件是否会被消耗掉将取决于onTouchEvent的返回值。 做个小总结其实就是如果setOnTouchListener中的onTouch方法返回值是true则onTouchEvent方法将不会被执行；只有当setOnTouchListener中的onTouch方法返回值是false时onTouchEvent方法才被执行。 以上说的情况适用于View对象而不是ViewGroup对象，ViewGroup对象下次再分析。

❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️

       Android系统中，Window、源码Activity、源码View之间的源码关系是紧密相连且相互作用的。了解这三者之间的源码关系，有助于深入理解Android应用的源码澳五源码渲染和交互机制。

       在Android中，源码通常在创建Activity时会调用`setContentView()`方法，源码以指定显示的源码布局资源。这个方法主要作用是源码将指定的布局添加到一个名为`DecorView`的容器中，并最终将其显示在屏幕上。源码这一过程涉及到多个组件的源码交互，下面分步骤解析。源码

       在`Activity`类中，源码`setContentView()`方法调用`getWindow()`方法获取`Window`对象，源码而`Window`对象在`Activity`的`attach()`方法中被初始化。`Window`对象是一个抽象类，其默认实现为`PhoneWindow`，这是hortonworks 源码Android特定的窗口实现。

       `PhoneWindow`在创建时会通过`setWindowManager()`方法与`WindowManager`进行关联。`WindowManager`是系统级组件，用于管理所有的窗口，包括窗口的创建、更新、删除等操作。`WindowManager`的管理最终由`WindowManagerService`（WMS）执行，这是一个运行在系统进程中的服务。

       在`PhoneWindow`中，litjson源码`installDecor()`方法会初始化`DecorView`和`mContentParent`。`mContentParent`是一个`ViewGroup`，用于存放`setContentView()`传入的布局。通过`mLayoutInflater`的`inflate()`方法，将指定的布局资源添加到`mContentParent`中。

       `DecorView`是一个特殊的`FrameLayout`，包含了`mContentParent`。在完成布局的添加后，`DecorView`本身并没有直接与`Activity`建立联系，backtrace源码也没有被绘制到屏幕上显示。`DecorView`的绘制和显示发生在`Activity`的`onResume()`方法执行后，这时`Activity`中的内容才真正可见。

       当`Activity`执行到`onCreate()`阶段时，其内容实际上并没有显示在屏幕上，直到执行到`onResume()`阶段，`Activity`的内容才被真正显示。这一过程涉及到`ActivityThread`中的`handleResumeActivity()`方法，该方法会调用`WindowManager`的yiya源码`addView()`方法，将`DecorView`添加到`WindowManagerService`中，完成`DecorView`的绘制和显示。

       `WindowManagerService`通过`addView()`方法将`DecorView`添加到显示队列中，并且在添加过程中，会创建关键的`ViewRootImpl`对象，进一步管理`DecorView`的布局、测量和绘制。`ViewRootImpl`会调用`mWindowSession`的`addToDisplay()`方法，将`DecorView`添加到真正的显示队列中。

       `mWindowSession`是`WindowManagerGlobal`中的单例对象，其内部实际上是一个`IWindowSession`类型，通过`AIDL`接口与系统进程中的`Session`对象进行通信，最终实现`DecorView`的添加和显示。

       通过`setView()`方法的实现，可以看到除了调用`IWindowSession`进行跨进程添加`View`之外，还会设置输入事件处理。当触屏事件发生时，这些事件首先通过驱动层的优化计算，通过`Socket`跨进程通知`Android Framework`层，最终触屏事件会通过输入管道传送到`DecorView`处理。

       在`DecorView`内部，触屏事件会通过`onProcess`方法传递给`mView`，即`PhoneWindow`中的`DecorView`。最终，事件传递到`PhoneWindow`中的`View.java`实现的`dispatchPointerEvent()`方法，并调用`Window.Callback`的`dispatchTouchEvent(ev)`方法。对于`Activity`来说，`dispatchTouchEvent()`方法最终还是会调用`PhoneWindow`的`superDispatchTouchEvent()`，然后传递给`DecorView`的`superDispatchTouchEvent()`方法，完成事件的分发和处理。

       综上所述，通过`setContentView()`的过程，我们可以清晰地看到`Activity`、`Window`、`View`之间的交互关系。整个过程主要由`PhoneWindow`组件主导，而`Activity`主要负责提供要显示的布局资源，其与屏幕的直接交互则通过`WindowManager`和`WindowManagerService`实现。