第三章 Android控件架构与事件拦截机制

Android 群英传笔记
第一章Android体系与系统架构
第二章 Android开发工具及技巧
第三章 Android控件架构与事件拦截机制
第四章 ListView 使用技巧
第五章 Android Scroll 分析
第六章 Android 绘图机制与屏幕适配
第七章 Android 动画机制与使用技巧
第八章 Activity与Activity调用栈分析
第九章 Android 系统信息与安全机制
第十章 Android性能优化
本文出自:
http://www.jianshu.com/u/a1251e598483

Android 控件架构

Android的每个控件都是占一块矩形的区域，大致的分两类，继承View和ViewGroup，ViewGroup相当于一个容器，他可以管理多个字View，，整个界面上的控件形成了一个树形结构，也就是我们常说的控件树，上层控件负责下层控件的测量和绘制，并且传递交互事件，通过findviewbyid（）这个方法来获取，其实就是遍历查找，在树形图的顶部都有一个ViewParent对象，这就是控制核心，所有的交互管理事件都是由它统一调度和分配，从而进行整个视图的控制
通常情况下，我们要显示一个activity的视图，需要使用setContentView（）方法，那么这个方法到底做了些什么呢？我们先来看看Android界面的架构图

View 树结构

UI界面架构图

我们可以看到，每个activity都有一个window对象，在Android中，window对象通常由一个phoneWindow去实现的，phoneWindow将一个DecorView设置为整个窗口的根View，DecorView作为窗口界面的顶层视图，封装了一些通用的方法，可以说，DecorView将要显示的内容都给了phoneWindow，这里面所有的View监听，都是通过WindowManagerService来接收的，通过相应的回调来OnClicListener，在显示上，他将屏幕分成了两部分，一个title一个content，看到这里，大家应该能看到一个熟悉的界面ContentView，它是一个ID为content的FrameLayout，activity_main.xml就是设置在这个FrameLayout里面

默认是有title 的,如果我们想让页面全屏显示,比如: 启动页,不要显示title,就可以通过requestWindowFeature(Window.FEATURE_NO_TITLE)来设置全屏显示
这个需要再setContentView()方法调用之前.
或者通过设置theme的方式处理全屏的问题,继承正常的theme 增加一个 true 也是可以全屏显示页面 同样的 setTheme(R.style.AppTheme);要在setContentView()方法调用之前调用

而在onCreate()调用setContentView()方法后，ActivityManagerService会直接调用onResume,这个时候系统会把整个DecorView添加到PhoneWindow,然后显示出来完成最后的绘制.

自定义View 前面已经写过很详细的系列文章了.https://www.jianshu.com/p/bd153dfc0095

再补充点内容:
在View中通常有以下一些比较重要的回调方法.

• onFinishInflate(): 从XML 加载组件后回调;
• onSizeChanged(): 组件大小改变时回调;
• onMeasure(): 回调改方法来进行测量;
• onLayout(); 回调该方法来确定显示的位置;
• onTouchEvent(): 监听到触摸事件时回调;

自定义View 可以分为三种:

• 对现有控件进行拓展;
• 通过组合来实现新的控件;
• 重写View 来实现全新的控件

事件拦截机制

想自己敲来着,发现我按照例子来写布局, ViewGroupB 和View C怎么都显示不出来,我再调调,先借用 吴小龙同学的 原文 http://wuxiaolong.me/2015/12/19/MotionEvent/ 来说一下理论

image.png

角色：
一个经理：MotionEventViewGroupA，最外层的ViewGroupA；
一个组长：MotionEventViewGroupB，中间的ViewGroupB；
一个你：MotionEventViewC，最底层的码农。
模拟：
经理分派任务，下属处理这个任务的过程。
不做任何修改，点击MotionEventViewC

MotionEventViewGroupA dispatchTouchEventA
MotionEventViewGroupA onInterceptTouchEventA
MotionEventViewGroupB dispatchTouchEventB
MotionEventViewGroupB onInterceptTouchEventB
MotionEventViewC dispatchTouchEventC
MotionEventViewC onTouchEventC
MotionEventViewGroupB onTouchEventB
MotionEventViewGroupA onTouchEventA

log信息看出，正常情况，事件传递顺序：
经理 –> 组长 –> 你，先执行dispatchTouchEvent（分发），再执行onInterceptTouchEvent（拦截）

事件处理顺序：
你 –> 组长 –> 经理，事件处理都是执行onTouchEvent（处理）。

事件传递返回值：true，拦截，交给自己的onTouchEvent处理；false，不拦截，传给下属。

事件处理返回值：true，自己搞定，不用上报上司；false，上报上司处理。

初始返回都是false。

事件传递，dispatchTouchEvent一般不太会改写，只关心onInterceptTouchEvent。
经理觉得这个任务太简单，自己处理
即MotionEventViewGroupA里onInterceptTouchEvent返回true，我们看下log信息：

MotionEventViewGroupA dispatchTouchEventA
MotionEventViewGroupA onInterceptTouchEventA
MotionEventViewGroupA onTouchEventA

组长觉得这个任务太简单，自己处理
即MotionEventViewGroupB里onInterceptTouchEvent返回true，我们看下log信息：

MotionEventViewGroupA dispatchTouchEventA
MotionEventViewGroupA onInterceptTouchEventA
MotionEventViewGroupB dispatchTouchEventB
MotionEventViewGroupB onInterceptTouchEventB
MotionEventViewGroupB onTouchEventB
MotionEventViewGroupA onTouchEventA

你迫于压力，辞职不干了，任务闲置
即MotionEventViewC里onTouchEvent返回true，我们看下log信息：

MotionEventViewGroupA dispatchTouchEventA
MotionEventViewGroupA onInterceptTouchEventA
MotionEventViewGroupB dispatchTouchEventB
MotionEventViewGroupB onInterceptTouchEventB
MotionEventViewC dispatchTouchEventC
MotionEventViewC onTouchEventC

事件处理到你这里就结束了。

组长觉得你任务完成太烂，不敢上报
即MotionEventViewB里onTouchEvent返回true，我们看下log信息：

MotionEventViewGroupA dispatchTouchEventA
MotionEventViewGroupA onInterceptTouchEventA
MotionEventViewGroupB dispatchTouchEventB
MotionEventViewGroupB onInterceptTouchEventB
MotionEventViewC dispatchTouchEventC
MotionEventViewC onTouchEventC
MotionEventViewGroupB onTouchEventB

事件处理经过你和组长，到组长那里就结束了。