从源码角度分析android事件分发处理机制

最新推荐文章于 2023-02-28 18:24:06 发布
转载 最新推荐文章于 2023-02-28 18:24:06 发布 · 308 阅读 · 1

本文详细解析了Android中事件分发、拦截与处理机制，包括Activity、PhoneWindow、DecorView及View组件的角色与职责。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 

从源码角度分析android事件分发处理机制

标签： 分发拦截处理
2015-12-08 12:18  465人阅读  评论(5)  收藏  举报
  分类：
 

版权声明：本文为博主原创文章，未经博主允许不得转载。

目录(?)[+]

正式开始之前的准备工作：

           之前也写过一篇《android事件拦截处理机制详解》的博客，通过博客的名字也可以知道那篇博客只是分析了android控件View对事件的拦截和处理，简单的总结如下：

           1)父View优先拦截当前事件，拦截不成功就让子View对当前事件进行拦截。

            2)如果拦截成功的话，就会沿着子view到父View的路径查找onTouchEvent返回true的那个子View，让该子View对该事件进行处理；

             3）同时如果某一个View对当前事件拦截成功的话，当前事件就不会继续分发给这个View的子View。

            一直在说事件，那么事件到底是指什么？这里所说的事件是指手指按下(down)、移动(move)、抬起(up)此为一个事件集合或者说是事件序列，从手指接触屏幕开始到手指离开屏幕结束。所以本篇所说的事件序列或者事件集合是指从手指刚接触屏幕到离开屏幕的那一瞬间产生的各个事件：

事件序列为：ACTION_DOWN-->ACTION_MOVE-->ACTION-->...->ACTION_UP事件。

             上面的总结很简单，详细的分析以及说明都在《android事件拦截处理机制详解》这篇文章里，有兴趣的可以看一下。

             其实那篇博客说的有点简单了，只是涉及到View的层面而没有涉及到Activity和Window层面。本篇就在此基础上加上对事件源码的分析来进行补充说明。

            通过《Activity+Window+View简单说明》和《Context简单说明》可以知道三者之间的关系以及关系的由来：

          


准备工作已经完成，闲言少叙书归正传吧。

和拦截处理机制详解一样，为了系统的研究android对事件的处理，我也写了一个小demo对不同的情况进行测试并结合源码分析（多说一句，其实看源码确实很枯燥，有时候因为水平有限有的部分看不懂而查阅大量资料，笨人有笨法：结合demo测试验证和理解，虽然效率低但是效果不错），可以得出如下的结论（至于结论的由来，下面会说明）：

1)android对事件分发的顺序为：Activity-->PhoneWindow->DecorView->yourView;

2)android控件对事件处理的优先级：onTouch>onTouchEvent>onClick

android既然可以对事件进行拦截，肯定有某个方法对事件进行的传递或者分发（以前我总是说事件传递，但是看了各种资料都说是事件分发，在此统一一下就用“分发”这个名词吧）。完成事件分发功能的方法由Activity的dispatchTouchEvent(MotionEvent ev)l来负责：

[java]  view plain  copy
  1. public boolean dispatchTouchEvent(MotionEvent ev) {  
  2.         if (ev.getAction() == MotionEvent.ACTION_DOWN) {  
  3.             //该方法为空方法，直接忽略之    
  4.             onUserInteraction();  
  5.         }  
  6.          //把事件ev交给phoneWindow来处理  
  7.          if (getWindow().superDispatchTouchEvent(ev)) {  
  8.             //表明整个事件到此结束，处理完毕  
  9.             return true;  
  10.         }  
  11.         //说明该事件在View中没有得到处理，由Activity自己处理  
  12.         //至于怎么处理博客后面后有说明  
  13.         return onTouchEvent(ev);  
  14.     }  
上述分发事件的方法dispatchTouchEvent,先把事件分发给Window,通过之前写的博客知道这个Window其实就是PhoneWindow，那就看看PhoneWindow方法都做了些什么：

[java]  view plain  copy
  1. @Override  
  2.    public boolean superDispatchTouchEvent(MotionEvent event) {  
  3.        return mDecor.superDispatchTouchEvent(event);  
  4.    }  

很简单，就是把此次事件直接很光棍的传给DecorView，这个View是所有视图的根视图，Activity界面中你能见到的各个View都是DecorView的子View。到此为止事件已经分发到View上面，View获取到事件后有两个选择：处理和不处理该事件，如果处理该事件那事件就不会继续向其子View分发下去；否则就继续分发下去交给子View对该事件做同样的判断，其实就是个递归的过程。在这里就可以先用如下的伪代码也表示一下事件处理流程，然后参照这个伪代码来看本篇博客下面的内容会更容易理解点：

[java]  view plain  copy
  1. public boolean dispatchTouchEvent(event){  
  2.   //如果当前View对此事件拦截成功  
  3.   if(this.onInterceptTouchEvent(event)){  
  4.       //由当前View对此事件进行处理  
  5.      //true 表示处理了该事件，false表示没有处理该事件  
  6.         return onTouchEvent(event);  
  7.   }else{//没有拦截成功  
  8.        //交给子类来分发拦截处理  
  9.         return child.dispatchTouchEvent(event);  
  10.   }  
  11. }  
更直观的用流程图可以如下表示：

其实通过上面的代码也可以得出这个结论：当Activity中所有的视图View都不处理该事件的是就交给Activity的onTouchEvent方方来处理。该DecorView对此次事件又进行分发，让子View对该事件进行拦截和处理，具体可阅读《android事件拦截处理机制详解》，DecorView的分发事件代码如下：

[java]  view plain  copy
  1. @Override  
  2.       public boolean dispatchTouchEvent(MotionEvent ev) {  
  3.           final Callback cb = getCallback();  
  4.           return cb != null && mFeatureId < 0 ? cb.dispatchTouchEvent(ev) : super  
  5.                   .dispatchTouchEvent(ev);  
  6.       }  

上面的代码通过super.dispatchTouchEvent(ev)调用了DecorView的父类FrameLayout，该类倒是没有重写dispatchTouchEvent而是由它的父类ViewGroup实现：在分析ViewGroup分发事件之前还得说两结论：

1）ViewGroup永远不会对拦截，因为他的onInterceptTouchEvent(MotionEvent ev)始终返回的是false！这样DecorView对到来的事件MotionEvent就只有分发到子View并由子View进行拦截和处理此事件了.

2)View包括直接继承于View的子类因为其父类View没有onInterceptTouchEvent方法，所以没法对事件进行拦截，如果这种View获取到了事件，那么就会执行onTouchEvent方法（当然这也是有条件的，这个前提条件在对下面onTouch方法作用的时候会有说明）。

A) View类对事件的处理：

比如Button的直接父类TextVew的父类为View，那么当Button获取事件的时候其执行分发和处理的时候调用dispatchTouchEvent,就先分析一下View的这个方法都做了什么以供博客后面的篇幅用：

[java]  view plain  copy
  1.  public boolean dispatchTouchEvent(MotionEvent event) {  
  2.         if (!onFilterTouchEventForSecurity(event)) {  
  3.             return false;  
  4.         }  
  5.   
  6.         //从这里看出，onTouch方法是优先于onTouchEvnent方法的  
  7.         //如果onTouch方法返回了true的话，那么onTouchEvent方法就没法执行  
  8.         //相应的onClick方法也不会去执行  
  9.         if (mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED &&  
  10.                 mOnTouchListener.onTouch(this, event)) {  
  11.                //如果这里返回true的话，那么也表明此次事件被处理了  
  12.                return true;  
  13.         }  
  14.         //回调onTouchEvent方法  
  15.         return onTouchEvent(event);  
  16.     }  
通过上面的方法我们可以知道几个信息，按照方法的执行顺序，可以知道onTouch方法优先于onTouchEvent执行，这个onTouch是否能实行取决于你的View有有没有调用setOnTouchListener方法设置OnTouchListener。如果onTouch方法返回的true，那么View的dispatchTouchEvent方法就返回true而结束执行，onTouchEvent方法就不会得到执行；因为onClick方法通过下面的分析也知道是在onTouchEvent方法中执行的，所以此时onClick方法也不会执行了。所以当我们为Button做如下处理的时候,Button的onClick事件就不会执行了：

[java]  view plain  copy
  1. //因为该方法返回true，所以dispatchTouchEvent方法会结束执行  
  2. //进而导致Button的onClick方法也没机会执行  
  3.                btn.setOnTouchListener(new OnTouchListener() {  
  4.               
  5.             @Override  
  6.             public boolean onTouch(View v, MotionEvent event) {  
  7.                 return true;  
  8.             }  
  9.         });  
  10.   
  11. btn.setOnClickListener(new OnClickListener() {  
  12.               
  13.             @Override  
  14.             public void onClick(View v) {             
  15.                 doClick();  
  16.                   
  17.             }  
  18.         });  
  19.           
以上简单的说下onTouch和onTouchEvent和onClick的执行顺序以及onTouch的返回值对onTouchEvent和onClick的影响，如果不对Button设置onTouchListener的话程序会执行View的onTouchEvent方法：

[java]  view plain  copy
  1. if (((viewFlags & CLICKABLE) == CLICKABLE ||  
  2.                 (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) {  
  3.             switch (event.getAction()) {  
  4.                 case MotionEvent.ACTION_UP://抬起事件才会执行onClick  
  5.                     boolean prepressed = (mPrivateFlags & PREPRESSED) != 0;  
  6.                     if ((mPrivateFlags & PRESSED) != 0 || prepressed) {  
  7.                       ..........  
  8.                         if (!mHasPerformedLongPress) {  
  9.                             .........  
  10.                             if (!focusTaken) {  
  11.                                  .........  
  12.                                 if (mPerformClick == null) {  
  13.                                     mPerformClick = new PerformClick();  
  14.                                 }  
  15.                 //这也就说明了onTouchEvent优先于onClick执行,因为onClick方法就在onTouchEvent方法里执行  
  16.                 //验证了上面的结论  
  17.                                 if (!post(mPerformClick)) {  
  18.                                      performClick();  
  19.                                 }  
  20.                             }  
  21.                         }  
  22.   
  23.                     ...........  
  24.                     }  
  25.                     break;              
  26.             }  
  27.             //此时返回了true,此View处理了该事件，事件不会再往下进行分发  
  28.             return true;  
  29.         }  

到此为止关于View对事件的分发和处理算是简单的分析完毕，也可以得到一个结论：如果View类的的dispatchTouchEvent返回true的话，就表明有某个View对该起事件负责（进行处理），记住这一点对下面的分析有帮助。

通过View类的onTouch方法我们也很容易得到如下两个结论，该结论主要有上方代码的如下语句得来的：

[java]  view plain  copy
  1. if (((viewFlags & CLICKABLE) == CLICKABLE ||  
  2.                 (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE))   
这句代码的意思是说如果这个view是可点击的（clickable=true或者longClickable=true)那么这样的View最终都会处理当前事件而让View的dispatchTouchEvent返回true，这样的View就是下面将要说道的处理事件的target！！！否则，即如果一个View既不是clickable也不是longClickable的话，那么这个View不会处理该事件。

B)ViewGroup类对事件分发的处理：

下面继续分析在ViewGroup的dispatchTouchEvent方法，该方法中开始有这么一段：

[java]  view plain  copy
  1. if (action == MotionEvent.ACTION_DOWN) {  
  2.           if (mMotionTarget != null) {  
  3.               // this is weird, we got a pen down, but we thought it was  
  4.               // already down!  
  5.               // XXX: We should probably send an ACTION_UP to the current  
  6.               // target.  
  7.               mMotionTarget = null;  
  8.           }  
  9.           //如果不允许当前View拦截该事件或者没有拦截该事件  
  10.           //就让当前View的子类去分发和拦截，递归过程  
  11.           if (disallowIntercept || !onInterceptTouchEvent(ev)) {  
  12.               // reset this event's action (just to protect ourselves)  
  13.               ev.setAction(MotionEvent.ACTION_DOWN);  
  14.               // We know we want to dispatch the event down, find a child  
  15.               // who can handle it, start with the front-most child.  
  16.               final int scrolledXInt = (int) scrolledXFloat;  
  17.               final int scrolledYInt = (int) scrolledYFloat;  
  18.               final View[] children = mChildren;  
  19.               final int count = mChildrenCount;  
  20.               //遍历ViewGroup的子View，在此为遍历DecorView的子View  
  21.               for (int i = count - 1; i >= 0; i--) {  
  22.                   final View child = children[i];  
  23.                   if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE  
  24.                           || child.getAnimation() != null) {  
  25.                       child.getHitRect(frame);  
  26.                       if (frame.contains(scrolledXInt, scrolledYInt)) {  
  27.                            .........  
  28.                           //交给子View的dispatchTouchEvent进行对此事件的分发拦截。  
  29.                           //如果返回true说明child处理了此事件，递归调用  
  30.                            if (child.dispatchTouchEvent(ev))  {  
  31.                               // Event handled, we have a target now.  
  32.                               //说明已经找到处理此次事件的子View，用mMotionTarget记录  
  33.                               mMotionTarget = child;  
  34.                                //找到目标，此次down事件结束。  
  35.                                return true;  
  36.                           }  
  37.                           // The event didn't get handled, try the next view.  
  38.                           // Don't reset the event's location, it's not  
  39.                           // necessary here.  
  40.                       }  
  41.                   }  
  42.               }  
  43.           }  
  44.       }  

上诉代码的for循环很详细的说明了View对事件进行分发的过程，当然for循环之所以能得以执行使用两个前提条件的：

1）事件为ACTION_DOWN事件，在Down事件中才去进行分拦截发事件并寻找处理事件的target View，！

2）disallowIntercept    为true，这个属性可通过requestDisallowInterceptTouchEvent(boolean disallowIntercept  )来设置，通过观察期具体实现可以知道该方法的作用就是子View干预父View的事件分发过程，当然对于ACTION_DOWN事件子类是不能干预父类的，因为if条件为(disallowIntercept ||!onInterceptTouchEvent(ev))为或操作；或者当前的View没有拦截成功该事件。

如果当前的ViewGroup（为了方便再次称之为ParentView)允许对此次事件进行拦截或者ParentView没有对此事件拦截成功(ParentView的onInterceptTouchEvent返回false）简而言之就是如果ParentView不拦截这处理该事件，就把该事件分发到ParentView的若干子类中去，循环遍历它的子类，来寻找是否有某个子类对处理该事件。可以参照上面的伪代码和流程图来理解之。

如果找到了这样的View，就对该View用一个变量mMotionTarget进行标识。如果在当前的ParentView的子View中没有找到处理该事件的子View会怎么办呢？在ViewGroup里面的dispatchTouchEvent在上面的for循环之后有如下代码：

[java]  view plain  copy
  1. //如果没有找到处理事件的View  
  2. if (target == null) {  
  3.             // We don't have a target, this means we're handling the  
  4.             // event as a regular view.  
  5.             ev.setLocation(xf, yf);  
  6.             if ((mPrivateFlags & CANCEL_NEXT_UP_EVENT) != 0) {  
  7.                 ev.setAction(MotionEvent.ACTION_CANCEL);  
  8.                 mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  9.             }  
  10.             //ViewGroup调用View的事件分发方法，之所以能进入当前的View是因为当前的View的父View没有拦截成功此事件。  
  11.             return super.dispatchTouchEvent(ev);  
  12.         }  

从上面的代码可以看出：如果在ParentView的子类中没有找到能处理问题的那个view,就调用parentView的父View的dispatchTouchEvent方法。我们应该知道之所以parentView能分发和拦截事件，前提是它的父类本来没有拦截事件的能力或如本身拦截事件的方法返回了false，所以沿着view树最终会调用的View类的dispatchTouchEvent,那么又回归到本篇博客的A）View类对事件的处理那一部分了。

注意前面讲的for循环查找的重大前提是：在down事件中，且我们要明白在手指接触屏幕到手指离开屏幕会产生一系列事件，一个down(ACTION_DOWN)事件，数个move(ACTION_MOVE)事件,和一个 UP事件。寻找到目标事件之后，之后的一些列事件都交给这个target处理，比如move事件等。当然在中倒是可以通过调用让target调用requestDisallowInterceptTouchEvent方法来干预父类关于事件分发过程。或者在在适当的情况下让target父View的onInterceptEvent返回true或者false，来解决滑动问题事件的冲突问题：

[java]  view plain  copy
  1. if (!disallowIntercept && onInterceptTouchEvent(ev)) {  
  2.             final float xc = scrolledXFloat - (float) target.mLeft;  
  3.             final float yc = scrolledYFloat - (float) target.mTop;  
  4.             mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  5.             ev.setAction(MotionEvent.ACTION_CANCEL);  
  6.             ev.setLocation(xc, yc);  
  7.             if (!target.dispatchTouchEvent(ev)) {  
  8.                 // target didn't handle ACTION_CANCEL. not much we can do  
  9.                 // but they should have.  
  10.             }  
  11.             // clear the target  
  12.             mMotionTarget = null;  
  13.             // Don't dispatch this event to our own view, because we already  
  14.             // saw it when intercepting; we just want to give the following  
  15.             // event to the normal onTouchEvent().  
  16.             return true;  
  17.         }  

最后某个View（target）如果开始处理事件，在手指离开屏幕之前的什么move事件啦，up事件啦都会交给这个View(target)来处理，因为在ViewGroup的diapatchTouchEvent代码的最后会执行:

[java]  view plain  copy
  1. //把事件交给目标视图来处理  
  2.   return target.dispatchTouchEvent(ev);  

并且本View的onInterceptTouchEvent是不会调用了。也就是说如果有一个view处理该事件，那么down之后的一系列move事件和up事件都自动交给该view处理，因为该view已经是targetView 了，所以不会对后续事件序列或者事件集合进行拦截操作，只会调用dispatchTouchEvent和onTunchEvent来处理该事件！而onInterceptTouchEvent事件不会调用。简单的举个例子，如图：


假设上图中由D进行事件的处理，也就是说D的onInterceptTouchEvent和onTouchEvent均返回true,D的父View A ,B ,C的这两个方法都返回false，那么在这个布局中D就是上面所说的 target.在首次的Down事件中会执行查找target的操作：(注：下图中分发事件指的是执行了dispatchTouchEvent,拦截事件指的是onInterceptTouchEvent,处理事件为onTouchEvent方法）

[java]  view plain  copy
  1. @Override  
  2.     public boolean dispatchTouchEvent(MotionEvent ev) {  
  3.         Log.e(null, "B--分发事件");  
  4.         return super.dispatchTouchEvent(ev);  
  5.     }  
  6.     @Override  
  7.     public boolean onInterceptTouchEvent(MotionEvent ev) {  
  8.         Log.e(null, "B--拦截事件");  
  9.         return super.onInterceptTouchEvent(ev);  
  10.     }  
  11.     @Override  
  12.     public boolean onTouchEvent(MotionEvent event) {  
  13.         Log.e(null, "B--处理事件");  
  14.         return super.onTouchEvent(event);  
  15.     }  



注意D此时的打印，D为此事件的target View,拦截和处理了该次down事件，那么如果此时手指继续移动的话将会打印如下的Log：


注意上图是手指滑动后打印的log，可以发现D只负责分发和处理该事件，而没有像down事件那样进行拦截，所以上面的log打印可以清晰的说明上面的结论：

1）targetView只会对一个事件序列拦截一次，即只拦截down事件或者说由down事件负责查找targetView

2)一旦targetView被找到，down事件之后的一些列事件都由target View负责处理，而target并不对后续事件进行再次拦截

3)当然在down事件之后的后续事件还是会先由父View进行分发拦截，也即是说文章开头所说的事件序列中把每一个事件单独来看的话，都会由父View来进行拦截和分发的，只不过到后续事件到传到target的时候直接进行处理而少了拦截的过程而已，因为在父类查找target的时候已经拦截过一次，这点很重要，也是解决滑动冲突的关键点，比如滑动的时候根据合适的时机来判断是否让父View进行事件拦截和处理。只不过省下了对targetView的寻找，因为在down事件中已经寻找到了target并有mMotionTarget变量进行了标识，（通过上面的对ViewGroup的dispatchTouchEvent源码的解析就可以表明出来）

Android事件分发机制源码解析
m0_69439527的博客
04-17 1530
} private TouchTarget addTouchTarget(View child, int pointerIdBits) { TouchTarget target = TouchTarget.obtain(child, pointerIdBits); target.next = mFirstTouchTarget; mFirstTouchTarget = target; return target; } private boolean dispatchTransformedTouchEvent
Android 必懂系列 —— 事件分发（源码分析）
zjcoming
03-22 689
【1】什么是事件分发？ 所谓事件分发，就是将一次完整的点击所包含的点击事件传递到某个具体的View或ViewGroup，让该View或该ViewGroup处理它（消费它）。分发是从上往下依次传递的，其中可能经过的对象有最上层Activity，中间层ViewGroup，最下层View。例如在屏幕中有一个Button控件，点击它时该次点击事件就会从Activity传到Button所在的ViewGroup，最后传到该Button控件去处理它。即事件分发就是从上往下依次遍历，直到找到能够处理消费这次点击事件的V.
Android事件分发机制源码分析
ws_lm的博客
09-17 1061
那么当前Activity不会回调onStop。 onStart和onResume，onPause和onStop的区别：onStart和onStop是从Activity是否可见这个角度来回调的，而onResume和onPause是从Activity是否位于前台这个角度来回调的。 我们知道onPause和onStop都不能执行耗时的操作，尤其是onPause，这也意味着，我们应当尽量在onStop
Android事件分发之源码分析
躬行之
11-24 322
原文首发于微信公众号：躬行之(jzman-blog)，欢迎关注交流！ 上篇文章中叙述了 Android 事件分发的大致流程，下面从 Activity、ViewGroup、View 三个方面介绍事件的相关方法，小节如下： Activity ViewGroup View 阅读本篇文章之前请先阅读： Android 事件分发之基础 Activity Activity中主要两个与事件传递相关...
Android从源码的角度彻底理解事件分发机制的解析(上)
01-05
其实我一直准备写一篇关于Android事件分发机制的文章，从我的第一篇博客开始，就零零散散在好多地方使用到了Android事件分发的知识。也有好多朋友问过我各种问题，比如：onTouch和onTouchEvent有什么区别，又该如何...
Android 事件分发机制
03-15
例如，可以通过阅读文章《从源码角度解析 android 事件原理》来获得更深层次的理解。 #### 六、总结 通过上述分析可以看出，Android 的事件分发机制遵循“父先子后”的原则，即先由父视图决定是否拦截事件，再由子...
Android开发知识（九）：Android事件处理机制：事件分发、传递、拦截、处理机制的原理分析（下）
lc_miao的专栏
10-18 1万+
在前面的两个章节中，我们已经分析过关于Android事件处理机制的过程，特别是关于View的触摸、点击、长按之间的处理过程的分析，在本章节是我们分析Android事件处理机制的<下>篇，我们将分析关于手指从触摸屏幕到离开屏幕期间，从顶级ViewGroup到View的事件传递过程。
Android事件分发机制完全解析，带你从源码的角度彻底理解
05-11
Android事件分发机制完全解析，带你从源码的角度彻底理解
android事件分发机制源码分析
杜壁奇的博客
02-28 639
android view事件分发源码分析
Android 事件分发机制源码解析-view层
weixin_34220834的博客
03-23 190
本篇文章我们专门来研究一下view层的事件分发机制，我们在学习过程中总会碰到关于事件分发的各种问题，如onTouch和onTouchEvent的关系，setOnTouchListener和setOnClickListener的关系等等，类似这样的问题很多，结论我们都知道，有的时候是死记硬背的，记不长久，本篇文章我们来从源码的角度来分析总结一下各种关系，这样才能理解，便于记忆。 分析工具 //And...
从源码角度解析Android事件分发机制
FSC的专栏
11-09 597
事件分发是Android中的一个重点也是一个难点，在自定义控件中很是常用。前后看了好多书和博客，感觉写的东西顺序都稍微有些不对，让刚接触的人看起来不是很好懂。在这里也是将我从不清楚到熟悉的过程写下来，希望对大家有所帮助，对自己也起到总结的作用。 下面介绍几个方法，只要先有个印象就好，以后会慢慢解释： 首先是 dispatchTouchEvent(MotionEvent ev)
深入解析Android事件分发机制源码（1）
u012578516的专栏
08-10 558
有关事件分发的文章，网上已经有了太多太多，但是看了很多，大部分都只是讲解了最外层表现给开发者看的结果，并没有深入讲解，为何会得到这个现象。基于透过现象看本质的思想，趁着手头没有太多活，写下这篇博客，一方面给自己一个研究源码的动力，另一方面也是给自己加深一个印象。
源码分析之——Android事件分发机制
aphrodite1314的博客
12-21 244
1.源码分析之——AMS启动流程 2.源码分析之——WMS启动流程 3.源码分析之——SharedPreferences 4.源码分析之——Retrofit 5.源码分析之——OKHttp 前言 基于源码，简单分析下Android事件分发机制。 流程图 源码分析 下面将从源码角度对以上流程进行分析。 做过Android开发的同学对于几大布局应该都很熟悉，像LinearLayout，RelativeLayout，FrameLayout，CoordinatorLayout等等。细心的同学就会发现这些布局全部
Android事件分发机制之源码完美解析（上）
热门推荐
qq_36523667的博客
02-03 2万+
学事件分发是为了什么呢？还不是为了解决滑动冲突的。 实际上，如果仅仅是为了解决滑动冲突的，大可不必看源码，只需要掌握事件分发的外在规律即可。 只要记住这张图，再明白内部拦截法和外部拦截法，滑动冲突这一块，都可以轻松解决了。 分享一个滑动冲突的实例：
最新阿里P7技术体系：Android事件分发机制源码解析
m0_56252652的博客
06-12 303
触摸事件传递机制是Android中一块比较重要的知识体系，了解并熟悉整套的传递机制有助于更好的分析各种滑动冲突、滑动失效问题，更好去扩展控件的事件功能和开发自定义控件。 预备知识 MotionEvent 在Android设备中，触摸事件主要包括点按、长按、拖拽、滑动等，点按又包括单击和双击，另外还包括单指操作和多指操作等。一个最简单的用户触摸事件一般经过以下几个流程： 手指按下 手指滑动 手指抬起 Android把这些事件的每一步抽象为MotionEvent这一概念，MotionEvent包含了触摸的.
Android 应用整体的事件分发体系——源码探究
tulensa的博客
04-11 1354
参考：反思 | Android 事件分发机制的设计与实现 【掘金】（本文其实相当于是对它的读后感）Android 全面解析之window机制【掘金】（主要是讲window的）Android 之window机制token验证 （wms和token相关）Android 系统源码分析 - 事件分发（这里对Native层整个过程讲的比较细）输入系统：进程间双向通信(socketpair+binder) （这个对事件分发Native层用的原理讲的很清楚） 一、概述 反思 | Android 事件分发机制的设计与实现
Android事件分发机制与源码分析实验教程
- 了解如何从源码角度分析View事件分发机制。 - 学会在实际开发中如何根据需要自定义事件的处理逻辑。 ### 结论 了解并掌握Android的View事件分发机制对于开发出交互性良好的Android应用至关重要。通过实验代码的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值