自定义view大致可以分为两个部分，一个是展示，其中包括onMeasure，onLayout，onDraw等，另一个是事件，包括事件传递，滑动冲突等。
展示
自定义view的展示过程，主要看自定义view是继承了view，还是继承了viewGroup，两者的实现方式会有一些不同。继承了view的话，一般只需要重写两个方法即可，onMeasure和onDraw，而继承了viewGroup就需要考虑子view的布局，因此需要多重写一个onLayout。
一：继承自view
onMeasure方法无论是在view还是在viewGroup中，都充当了测量的角色，测量之后就可以获得这个view或者viewGroup的getMeasuredWidth，也就是测量所得的宽度，大多数情况下，测量的宽度和最终的宽度是一样的，也就是getMeasuredWidth和getWidth，也就是view自身的最终宽度。一般获取这个测量宽度可以在onLayout中或之后都可以，如果想要在Activity中获取，可以在onWindowFocusedChanged()或者view.post()或者viewTreeObserver的注册监听中获得。
在使用onMeasure之前需要对MeasureSpec有一个了结，它其实是代表了一个32位int值，其中高2位代表了specMode,低30位代表了specSize。其中specMode测量模式有三种，分别是unspecified,at_most,exactly。系统封装了对MeasureSpec的打包和解包方法，因此通过这些方法，我们可以轻而易举从measureSpec中获得测量模式和测量规格，也可以从测量模式和测量规格中打包生成measureSpec。
对于一个view的measureSpec，它是由自己的layoutParams和父容器的measureSpec共同决定的。最顶层的decorView的measureSpec是由屏幕大小和自身的layoutparams决定的，然后它的子viewGroup的measurespec，由这个decorView的measurespec和这个子viewgroup的layotuparams决定，就这样一层一层传递下去。
specMode的三种模式分别对应着exactly精准模式(具体数值和match_parent),at_most最大模式(wrap_content),以及unspecified未指定，这种模式主要是用在系统内部，多次测量，一般情况下可以不考虑。
不过要是考虑的话，unspecified模式下：如果view没有设置背景，那么minWidth会是指定值，如果没有设置，那么就是0。如果view设置了背景，那么就会返回背景的宽度和minWidth中的最大值。这个返回值系统称之为getSuggestedMinimumWidth()。
而在另外两种模式下的返回值，常常就是从measureSpec中获得测量规格，而这个规格就是一般称之为的getMeasuredWidth()。因此我们在直接继承view重写onmeasure的时候，需要单独设置wrap_content情况下的返回值，不然wrap_content和match_parent测量出来的效果就一样了。最后我们还需要考虑padding的值，不然padding就失效了，margin的值是由父容器控制的，因此在继承view的自定义view中可以暂时不考虑。
onMeasure测量自身大小，layout开始布局view的四个顶点位置，放置view。layout()调用setFrame来设定view的四个顶点位置，然后调用onLayout()方法，确定子view的位置，如果不是viewgroup可忽略。
draw的绘制有四个流程：
- 绘制背景
- 绘制view自己
- 绘制children
- 绘制装饰 scrollbar
尽量不要在自定义view中使用handler，view中如果有线程或者动画，最好能在onDetachedFromWindow()方法中关闭移除，不然容易造成泄漏。
2:继承viewGroup
除了测量自己，还要测量子view。首先就是遍历子view，然后通过子view的layoutparams和这个viewgroup的measurespec来构造子view的measureSpec。然后调用子 view的measure()方法来完成子view的测量。在子view的测量过程中，保存子view的测量值，然后根据viewGroup的需要，根据这些子view的测量值，来测量自己的大小。
onMeasure测量自身大小，layout开始布局view的四个顶点位置，放置view。layout()调用setFrame来设定view的四个顶点位置，然后调用onLayout()方法，确定子view的位置。在viewgroup的onlayout中，会先遍历所有的子view，然后调用setchildFrame()给每个子view指定位置。而setChildFrame()又会调用view的layout方法，实现了一层一层传递的layout过程。
事件
当用户开始操作自定义view的时候，事件就应运而生。事件从activity传递到window，再传递到decorview。然后decorview再通过view的事件传递机制开始传递。
事件序列是指action_down,action_move,action_up这样的一个连串的动作。在motionEvent中getx代表了相对触摸位置，getRawx代表了原点的绝对触摸位置。touchslop表示手机能够识别的最短滑动距离。velocityTracker手势追踪器，可以得到水平速度和垂直速度。而gesturedetector则可以托管motionevent。scroller实现弹性滑动，需要重写view的computeScroll()，因为scroller是通过计算百分比来实现弹性滑动的。
关于view自己的scrollto／scrollby方法，都是滑动view的内容，而不是滑动view自身的位置。这二者的区别是前者是绝对滑动，后者是相对滑动。要想让view自身滑动，可以通过动画来实现，或者改变view自己的layoutparams。
1：事件分发
如果事件传递了当前的view，那么当前的view的dispatchTouchEvent就一定会被调用。在view中没有onInterceptTouchEvent()方法，它是用来判断是否拦截某个事件的，如果拦截了，那么这个事件序列都会被拦截，就不会再调用这个方法了，切记。如果不拦截，事件序列还是会调用这个方法询问是否拦截的。onTouchEvent则是消费事件，如果不消费，那么在同一个事件序列中，当前view无法再次接收到事件。
按照《android开发艺术探索》里面的伪代码的意思
public boolean dispatchTouchEvent(MotionEvent ev){
boolean consume=false;
if(onInterceptTouchEvent(ev)){
consume=onTouchEvent(ev);
}else{
consume=child.dispatchTouchEvent(ev);
}
return consume;
}
意味着dispatchTouchEvent的返回受到onInterCeptTouchEvent和onTouchEvent的影响。这个返回值也是表示是否消费当前事件。
在一个view的事件处理当中，onTouchListener优先处理，它的返回值false，那么就交给onTouchEvent处理，如果是返回true，那么onTouchEvent就不会调用。只有onTouchEvent调用了，那么onClickListener才能被调用。
一个事件序列正常情况下只能被一个view拦截消耗，当某个view一旦拦截了，那么这个事件序列都只能由它来处理，并且不会再调用它的onInterceptTouchEvent()。viewGroup的onInterceptTouchEvent()默认返回false，不拦截事件。view没有onInterceptTouchEvent(),一旦点击事件传递到它，那么它的onTouchEvent就会被调用，而view的ontouchEvent默认会消费事件，除非它默认是不可点击(clickable=false,longClickable=false)的，比如textview。如果view不消耗action_down，也就是onTouchEvent返回了fasle，那么同一事件的剩下序列也不会再交给view处理了。
2:滑动冲突
外部和内部滑动方向不一致也是会导致滑动冲突的，viewPager内部已经处理。外部和内部滑动方向一致肯定会导致滑动冲突。解决滑动冲突有两种方案，一种是外部拦截，一种是内部拦截，但是两种拦截的关键都是需要找到拦截条件。同时外部拦截比较简单，内部拦截需要内部和外部配合才能起到效果。因此建议使用外部拦截。
外部拦截法就意味着外部是个viewgroup，就需要在它的onInterceptTouchEvent中找到拦截条件返回true，其他条件都返回false即可。
内部拦截是在dispatchtTouchEvent中通过parent.requestDisallowInterceptTouchEvent来实现的。同时还需要父亲拦截除了action_down之外的事件。
事件拦截分为传递和处理两个方向：
- 传递是从外到内。
- 处理是从内到外。
但是不管是传递还是处理，都可能会被随时打断，当传递被中途打断时，整个事件可能被viewgroup默默消费在dispatchTouchEvent中，因为返回了true导致的。也可能被这个view的onInterceptTouchEvent给拦截了，返回true导致的，拦截之后就会交给拦截的这个viewgroup的onTouchEvent，这个方法可以选择返回true消费掉，也可以返回false，不处理，继续往上抛。也可以被这个viewgroup停止分发了，返回false。那么就会开始往上抛了。其自己是不会调用拦截和消费两个方法的。
