‘壹’ android的自定义View的实现原理哪位能给我个思路呢。谢谢。
如果说要按类型来划分的话，自定义View的实现方式大概可以分为三种，自绘控件、组合控件、以及继承控件。那么下面我们就来依次学习一下，每种方式分别是如何自定义View的。
一、自绘控件
自绘控件的意思就是，这个View上所展现的内容全部都是我们自己绘制出来的。绘制的代码是写在onDraw()方法中的，而这部分内容我们已经在Android视图绘制流程完全解析，带你一步步深入了解View(二)中学习过了。
下面我们准备来自定义一个计数器View，这个View可以响应用户的点击事件，并自动记录一共点击了多少次。新建一个CounterView继承自View，代码如下所示：
<?xmlversion="1.0"encoding="utf-8"?>
<RelativeLayoutxmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="50dp"
android:background="#ffcb05">
<Button
android:id="@+id/button_left"
android:layout_width="60dp"
android:layout_height="40dp"
android:layout_centerVertical="true"
android:layout_marginLeft="5dp"
android:background="@drawable/back_button"
android:text="Back"
android:textColor="#fff"/>
<TextView
android:id="@+id/title_text"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerInParent="true"
android:text="ThisisTitle"
android:textColor="#fff"
android:textSize="20sp"/>
</RelativeLayout>
在这个布局文件中，我们首先定义了一个RelativeLayout作为背景布局，然后在这个布局里定义了一个Button和一个TextView，Button就是标题栏中的返回按钮，TextView就是标题栏中的显示的文字。
接下来创建一个TitleView继承自FrameLayout，代码如下所示：
{
privateButtonleftButton;
privateTextViewtitleText;
publicTitleView(Contextcontext,AttributeSetattrs){
super(context,attrs);
LayoutInflater.from(context).inflate(R.layout.title,this);
titleText=(TextView)findViewById(R.id.title_text);
leftButton=(Button)findViewById(R.id.button_left);
leftButton.setOnClickListener(newOnClickListener(){
@Override
publicvoidonClick(Viewv){
((Activity)getContext()).finish();
}
});
}
publicvoidsetTitleText(Stringtext){
titleText.setText(text);
}
publicvoidsetLeftButtonText(Stringtext){
leftButton.setText(text);
}
(OnClickListenerl){
leftButton.setOnClickListener(l);
}
}TitleView中的代码非常简单，在TitleView的构建方法中，我们调用了LayoutInflater的inflate()方法来加载刚刚定义的title.xml布局，这部分内容我们已经在Android LayoutInflater原理分析，带你一步步深入了解View(一)这篇文章中学习过了。
接下来调用findViewById()方法获取到了返回按钮的实例，然后在它的onClick事件中调用finish()方法来关闭当前的Activity，也就相当于实现返回功能了。
另外，为了让TitleView有更强地扩展性，我们还提供了setTitleText()、setLeftButtonText()、setLeftButtonListener()等方法，分别用于设置标题栏上的文字、返回按钮上的文字、以及返回按钮的点击事件。
到了这里，一个自定义的标题栏就完成了，那么下面又到了如何引用这个自定义View的部分，其实方法基本都是相同的，在布局文件中添加如下代码：
<RelativeLayoutxmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<com.example.customview.TitleView
android:id="@+id/title_view"
android:layout_width="match_parent"
android:layout_height="wrap_content">
</com.example.customview.TitleView>
</RelativeLayout>
这样就成功将一个标题栏控件引入到布局文件中了，运行一下程序。
现在点击一下Back按钮，就可以关闭当前的Activity了。如果你想要修改标题栏上显示的内容，或者返回按钮的默认事件，只需要在Activity中通过findViewById()方法得到TitleView的实例，然后调用setTitleText()、setLeftButtonText()、setLeftButtonListener()等方法进行设置就OK了。
‘贰’ android 绘制过程，onmeasure 的原理，解决了什么问题
Android中View的绘制过程
当Activity获得焦点时，它将被要求绘制自己的布局，Android
framework将会处理绘制过程，Activity只需提供它的布局的根节点。
绘制过程从布局的根节点开始，从根节点开始测量和绘制整个layout
tree。
每一个ViewGroup
负责要求它的每一个孩子被绘制，每一个View负责绘制自己。
因为整个树是按顺序遍历的，所以父节点会先被绘制，而兄弟节点会按照它们在树中出现的顺序被绘制。
绘制是一个两遍（two
pass）的过程：一个measure
pass和一个layout
pass。
测量过程（measuring
pass）是在measure(int,
int)中实现的，是从树的顶端由上到下进行的。
在这个递归过程中，每一个View会把自己的dimension
specifications传递下去。
在measure
pass的最后，每一个View都存储好了自己的measurements，即测量结果。
第二个是布局过程（layout
pass），它发生在
layout(int,
int,
int,
int)中，仍然是从上到下进行（top-down）。
在这一遍中，每一个parent都会负责用测量过程中得到的尺寸，把自己的所有孩子放在正确的地方。
‘叁’ Android的UI底层是用CPU绘图的还是GPU绘图的呢
安卓有2种绘制模型：
一．软件绘制模型，这里由CPU主导绘图，视图按照以下2个步骤绘图。
让视图结构(view hierarchy)失效。
绘制整个视图结构。
当应用程序需要更新它的部分UI时，都会调用内容发生改变的View对象的invalidate()方法。无效（invalidation）消息请求会在View对象层次结构中传递，以便计算出需要重绘的屏幕区域（脏区）。然后，Android系统会在View层次结构中绘制所有的跟脏区相交的区域。但是，这种方法有两个缺点：
1. 绘制了不需要重绘的视图（与脏区域相交的区域）
2. 掩盖了一些应用的bug（由于会重绘与脏区域相交的区域）
注意：在View对象的属性发生变化时，如背景色或TextView对象中的文本等，Android系统会自动的调用该View对象的invalidate()方法。
二．硬件加速绘制模型，这里由GPU主导绘图，视图按照以下3个步骤绘图。
让视图结构失效。
记录和更新显示列表（Display List)。
绘制显示列表。
这种模式下，Android系统依然会使用invalidate()方法和draw()方法来请求屏幕更新和展现View对象。但Android系统并不是立即执行绘制命令，而是首先把这些View的绘制函数作为绘制指令记录一个显示列表中，然后再读取显示列表中的绘制指令调用OpenGL相关函数完成实际绘制。另一个优化是，Android系统只需要针对由invalidate()方法调用所标记的View对象的脏区进行记录和更新显示列表。没有失效的View对象就简单重用先前显示列表记录的绘制指令来进行简单的重绘工作。
使用显示列表的目的是，把视图的各种绘制函数翻译成绘制指令保存起来，对于没有发生改变的视图把原先保存的操作指令重新读取出来重放一次就可以了，提高了视图的显示速度。而对于需要重绘的View，则更新显示列表，然后再调用OpenGL完成绘制。
在这种绘制模型下，不能依赖一个视图与脏区(dirty region)相交而导致它的draw()方法被自动调用，所以必须要手动调用该视图的invalidate()方法去更新显示列表。如果忘记这么做可能导致视图在改变后不会发生变化。
‘肆’ android绘图，怎么才能做出拖动画布效果
使用卡马克地图缓冲算法。
基本原理是使用drawBitmap (Bitmap bitmap, Rect src, RectF dst, Paint paint）方法。
将位图上指定的部分（src矩形部分）绘制到指定的屏幕位置（dst矩形部分），通过改变src矩形的位置改变实现地图的移动。
给你个连接，自己先看看。
http://xys289187120.blog.51cto.com/3361352/656998
‘伍’ 要掌握Android的画图，首先就要了解一下，基本用到的图形接口：
定义canvas，在canvas上用paint画出自己想要画的东西。画图形，写字都行
‘陆’ Android 重学系列 View的绘制流程(六) 硬件渲染(上)
本文开始聊聊Android中的硬件渲染。如果跟着我的文章顺序，从SF进程到App进程的绘制流程一直阅读，我们到这里已经有了一定的基础，可以试着进行横向比对如Chrome浏览器渲染流程，看看软件渲染，硬件渲染，SF合成都做了什么程度的优化。
先让我们回顾一下负责硬件渲染的主体对象ThreadedRenderer在整个绘制流程中做了哪几个步骤。
在硬件渲染的过程中，有一个很核心的对象RenderNode，作为每一个View绘制的节点对象。
当每一次进行准备进行绘制的时候，都会雷打不动执行如下三个步骤：
如果遇到什么问题欢迎来到 https://www.jianshu.com/p/c84bfa909810 下进行讨论
实际上整个硬件渲染的设计还是比较庞大。因此本文先聊聊ThreadedRender整个体系中主要对象的构造以及相关的原理。
首先来认识下面几个重要的对象有一个大体的印象。
在java层中面向Framework中，只有这么多，下面是一一映射的简图。
能看到实际上RenderNode也会跟着View 树的构建同时一起构建整个显示层级。也是因此ThreadedRender也能以RenderNode为线索构建出一套和软件渲染一样的渲染流程。
仅仅这样？如果只是这么简单，知道我习惯的都知道，我喜欢把相关总结写在最后。如果把总揽写在正文开头是因为设计比较繁多。因为我们如果以流水线的形式进行剖析容易造成迷失细节的困境。
让我继续介绍一下，在硬件渲染中native层的核心对象。
如下是一个思维导图：
有这么一个大体印象后，就不容易迷失在源码中。我们先来把这些对象的实例化以及上面列举的ThreadedRenderer在ViewRootImpl中执行行为的顺序和大家来聊聊其原理，先来看看ThreadedRenderer的实例化。
当发现mSurfaceHolder为空的时候会调用如下函数：
而这个方法则调用如下的方法对ThreadedRenderer进行创建：
文件：/ frameworks / base / core / java / android / view / ThreadedRenderer.java
能不能创建的了ThreadedRenderer则决定于全局配置。如果ro.kernel.qemu的配置为0，说明支持OpenGL 则可以直接返回true。如果qemu.gles为-1说明不支持OpenGL es返回false，只能使用软件渲染。如果设置了qemu.gles并大于0，才能打开硬件渲染。
我们能看到ThreadedRenderer在初始化，做了三件事情：
关键是看1-3点中ThreadRenderer都做了什么。
文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp
能看到这里是直接实例化一个RootRenderNode对象，并把指针的地址直接返回。
能看到RootRenderNode继承了RenderNode对象，并且保存一个JavaVM也就是我们所说的Java虚拟机对象，一个java进程全局只有一个。同时通过getForThread方法，获取ThreadLocal中的Looper对象。这里实际上拿的就是UI线程的Looper。
在这个构造函数有一个mDisplayList十分重要，记住之后会频繁出现。接着来看看RenderNode的头文件：
文件：/ frameworks / base / libs / hwui / RenderNode.h
实际上我把几个重要的对象留下来：
文件：/ frameworks / base / core / java / android / view / RenderNode.java
能看到很简单，就是包裹一个native层的RenderNode返回一个Java层对应的对象开放Java层的操作API。
能看到这个过程生成了两个对象：
这个对象实际上让RenderProxy持有一个创建动画上下文的工厂。RenderProxy可以通过ContextFactoryImpl为每一个RenderNode创建一个动画执行对象的上下文AnimationContextBridge。
文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp
在这里有几个十分重要的对象被实例化，当然这几个对象在聊TextureView有聊过( SurfaceView和TextureView 源码浅析 )：
我们依次看看他们初始化都做了什么。
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.cpp
能看到其实就是简单的调用RenderThread的构造函数进行实例化，并且返回对象的指针。
RenderThread是一个线程对象。先来看看其头文件继承的对象：
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.h
其中RenderThread的中进行排队处理的任务队列实际上是来自ThreadBase的WorkQueue对象。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
ThreadBase则是继承于Thread对象。当调用start方法时候其实就是调用Thread的run方法启动线程。
另一个更加关键的对象，就是实例化一个Looper对象到WorkQueue中。而直接实例化Looper实际上就是新建一个Looper。但是这个Looper并没有获取当先线程的Looper，这个Looper做什么的呢？下文就会揭晓。
WorkQueue把一个Looper的方法指针设置到其中，其作用可能是完成了某一件任务后唤醒Looper继续工作。
而start方法会启动Thread的run方法。而run方法最终会走到threadLoop方法中，至于是怎么走进来的，之后有机会会解剖虚拟机的源码线程篇章进行讲解。
在threadloop中关键的步骤有如下四个：
在这个过程中创建了几个核心对象：
另一个核心的方法就是，这个方法为WorkQueue的Looper注册了监听：
能看到在这个Looper中注册了对DisplayEventReceiver的监听，也就是Vsync信号的监听，回调方法为displayEventReceiverCallback。
我们暂时先对RenderThread的方法探索到这里，我们稍后继续看看回调后的逻辑。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
能看到这里的逻辑很简单实际上就是调用Looper的pollOnce方法，阻塞Looper中的循环，直到Vsync的信号到来才会继续往下执行。详细的可以阅读我写的 Handler与相关系统调用的剖析 系列文章。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
实际上调用的是WorkQueue的process方法。
文件：/ frameworks / base / libs / hwui / thread / WorkQueue.h
能看到这个过程中很简单，几乎和Message的loop的逻辑一致。如果Looper的阻塞打开了，则首先找到预计执行时间比当前时刻都大的WorkItem。并且从mWorkQueue移除，最后添加到toProcess中，并且执行每一个WorkItem的work方法。而每一个WorkItem其实就是通过从某一个压入方法添加到mWorkQueue中。
到这里，我们就明白了RenderThread中是如何消费渲染任务的。那么这些渲染任务又是哪里诞生呢？
上文聊到了在RenderThread中的Looper会监听Vsync信号，当信号回调后将会执行下面的回调。
能看到这个方法的核心实际上就是调用drainDisplayEventQueue方法，对ui渲染任务队列进行处理。
能到在这里mVsyncRequested设置为false，且mFrameCallbackTaskPending将会设置为true，并且调用queue的postAt的方法执行ui渲染方法。
还记得queue实际是是指WorkQueue，而WorkQueue的postAt方法实际实现如下：
/ frameworks / base / libs / hwui / thread / WorkQueue.h
情景带入，当一个Vsync信号达到Looper的监听者，此时就会通过WorkQueue的drainDisplayEventQueue 压入一个任务到队列中。
每一个默认的任务都是执行dispatchFrameCallback方法。这里的判断mWorkQueue中是否存在比当前时间更迟的时刻，并返回这个WorkItem。如果这个对象在头部needsWakeup为true，说明可以进行唤醒了。而mWakeFunc这个方法指针就是上面传下来：
把阻塞的Looper唤醒。当唤醒后就继续执行WorkQueue的process方法。也就是执行dispatchFrameCallbacks方法。
在这里执行了两个事情：
先添加到集合中，在上面提到过的threadLoop中，会执行如下逻辑：
如果大小不为0，则的把中的IFrameCallback全部迁移到mFrameCallbacks中。
而这个方法什么时候调用呢？稍后就会介绍。其实这部分的逻辑在TextureView的解析中提到过。
接下来将会初始化一个重要对象：
这个对象名字叫做画布的上下文，具体是什么上下文呢？我们现在就来看看其实例化方法。
文件：/ frameworks / base / libs / hwui / renderthread / CanvasContext.cpp
文件：/ device / generic / goldfish / init.ranchu.rc
在init.rc中默认是opengl，那么我们就来看看下面的逻辑：
首先实例化一个OpenGLPipeline管道，接着OpenGLPipeline作为参数实例化CanvasContext。
文件：/ frameworks / base / libs / hwui / renderthread / OpenGLPipeline.cpp
能看到在OpenGLPipeline中，实际上就是存储了RenderThread对象，以及RenderThread中的mEglManager。透过OpenGLPipeline来控制mEglManager进而进一步操作OpenGL。
做了如下操作：
文件：/ frameworks / base / libs / hwui / renderstate / RenderState.cpp
文件：/ frameworks / base / libs / hwui / renderthread / DrawFrameTask.cpp
实际上就是保存这三对象RenderThread；CanvasContext；RenderNode。
文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp
能看到实际上就是调用RenderProxy的setName方法给当前硬件渲染对象设置名字。
文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp
能看到在setName方法中，实际上就是调用RenderThread的WorkQueue，把一个任务队列设置进去，并且调用runSync执行。
能看到这个方法实际上也是调用post执行排队执行任务，不同的是，这里使用了线程的Future方式，阻塞了执行，等待CanvasContext的setName工作完毕。
‘柒’ android ScrollView实现原理，求助
视图的滚动过程，其实是在不断修改原点坐标。当手指触摸后，ScrollView会暂时拦截触摸事件，使用一个计时器。
假如在计时器到点后没有发生手指移动事件，那么ScrollView发送tracking events到被点击的subView；若是在计时器到点后发生了移动事件，那么ScrollView取消tracking自己促发滚动。
其子类可以重载
touchesShouldBegin: withEvent: inContentView: 决定自己是否接收touch事件。
pagingEnabled: 当值是YES会自动滚动到subView的边界，默认是NO。
: 开始发送tracking messages消息给subView的时候会调用这个方法。以决定是否发送tracking messages消息到subView。假如返回NO，发送。YES则不发送。若是canCancelContentTouches属性是NO，则不调用这个方法来影响如何处理滚动手势。
ScrollView还可处理缩放和平移手势，要实现这必须实现委托viewForZoomingInScrollView:和scrollViewDidEndZooming: withView: atScale:两个方法。另外maximumZoomScale和minimumZoomScale两个属性要不一样。
常用属性介绍
maximumZoomScale 能放大的最大倍数，是浮点数。
minimumZoomScale 能缩小的最小倍数，是浮点数。
pagingEnabled 是否自动滚动到subView边界
scrollEnabled 是否可以滚动
contentSize 里面内容的大小，即可以滚动的大小，默认是0，没有滚动效果
滚动时是否显示水平滚动条
showsVerticalScrollIndicator 滚动时是否显示垂直滚动条
bounces 默认是YES，就是滚动超过边界会反弹，即有反弹回来的效果。若是NO，则滚动到达边界会立刻停止
bouncesZoom 与bounces类似，只是反映在缩放效果上。
directionalLockEnabled 默认是NO，可以在垂直和水平方向同时运动。当值是YES时，视哪个方向开始则锁定另外一个方向的滚动。
indicatorStyle 滚动条的样式。总共3色：默认、黑、白
scrollIndicatorInsets 设置滚动条位置
tracking 当touch后还没有拖动的时候是YES，否则NO
zoomBouncing 当内容放大到最大或者最小的时候值是YES，否则NO
zooming 当正在缩放的时候值是YES，否则NO
decelerating 当滚动后，手指放开但还在继续滚动中。此时是YES，其它时候都是NO
decelerationRate 设置手指放开后的减速率
基本使用方法：
初始化：一般的控件初始化都是可以用alloc和init来初始化的。
UIScrollView *sv = [[UIScrollView alloc] initWithFrame:CGRectMake(0.0,0.0,self.view.frame.size.width, 400)];
关于控件添加与初始化，建议都采用代码调用合适的初始化方法来操作，虽然IB布局能够节省时间，但不能哪过很好了解整个代码执行流程。
委托方法：UIScrollView也要指定委托对象，该委托对象的控制器同样也要遵循UIScrollViewDelegate协议，实现其相应的代理方法。
scrollViewDidScroll:
scrollViewWillBeginDragging:
scrollViewDidEndDragging:
scrollViewDidEndDecelerating:
属性作用CGPoint contentOffSet监控目前滚动的位置CGSize contentSize滚动范围的大小UIEdgeInsets contentInset视图在scrollView中的位置id<UIScrollerViewDelegate>
delegate设置协议BOOL directionalLockEnabled指定控件是否只能在一个方向上滚动BOOL bounces控制控件遇到边框是否反弹BOOL alwaysBounceVertical控制垂直方向遇到边框是否反弹BOOL alwaysBounceHorizontal控制水平方向遇到边框是否反弹BOOL pagingEnabled控制控件是否整页翻动BOOL scrollEnabled控制控件是否能滚动BOOL 控制是否显示水平方向的滚动条BOOL
showsVerticalScrollIndicator控制是否显示垂直方向的滚动条UIEdgeInsets scrollIndicatorInsets指定滚动条在scrollerView中的位置UIScrollViewIndicatorStyle
indicatorStyle设定滚动条的样式float decelerationRate改变scrollerView的减速点位置BOOL tracking监控当前目标是否正在被跟踪BOOL dragging监控当前目标是否正在被拖拽BOOL decelerating监控当前目标是否正在减速BOOL delaysContentTouches控制视图是否延时调用开始滚动的方法BOOL canCancelContentTouches控制控件是否接触取消touch的事件float minimumZoomScale缩小的最小比例float maximumZoomScale放大的最大比例float zoomScale设置变化比例BOOL bouncesZoom控制缩放的时候是否会反弹BOOL zooming判断控件的大小是否正在改变BOOL zoomBouncing判断是否正在进行缩放反弹BOOL scrollsToTop控制控件滚动到顶部
这里把UIScrollView的几个要点总结下：
从你的手指touch屏幕开始，scrollView开始一个timer，如果：
1. 150ms内如果你的手指没有任何动作，消息就会传给subView。
2. 150ms内手指有明显的滑动（一个swipe动作），scrollView就会滚动，消息不会传给subView，这里就是产生问题二的原因。
3. 150ms内手指没有滑动，scrollView将消息传给subView，但是之后手指开始滑动，scrollView传送touchesCancelled消息给subView，然后开始滚动。
观察下tableView的情况，你先按住一个cell，cell开始高亮，手不要放开，开始滑动，tableView开始滚动，高亮取消。
delaysContentTouches的作用：
这个标志默认是YES，使用上面的150ms的timer，如果设置为NO，touch事件立即传递给subView，不会有150ms的等待。
cancelsTouches的作用：
这个标准默认为YES，如果设置为NO，这消息一旦传递给subView，这scroll事件不会再发生。
‘捌’ Android UI绘制之View绘制的工作原理
这是AndroidUI绘制流程分析的第二篇文章，主要分析界面中View是如何绘制到界面上的具体过程。
ViewRoot 对应于 ViewRootImpl 类，它是连接 WindowManager 和 DecorView 的纽带，View的三大流程均是通过 ViewRoot 来完成的。在 ActivityThread 中，当 Activity 对象被创建完毕后，会将 DecorView 添加到 Window 中,同时会创建 ViewRootImpl 对象，并将 ViewRootImpl 对象和 DecorView 建立关联。
measure 过程决定了 View 的宽/高， Measure 完成以后，可以通过 getMeasuredWidth 和 getMeasuredHeight 方法来获取 View 测量后的宽/高，在几乎所有的情况下，它等同于View的最终的宽/高，但是特殊情况除外。 Layout 过程决定了 View 的四个顶点的坐标和实际的宽/高，完成以后，可以通过 getTop、getBottom、getLeft 和 getRight 来拿到View的四个顶点的位置，可以通过 getWidth 和 getHeight 方法拿到View的最终宽/高。 Draw 过程决定了 View 的显示，只有 draw 方法完成后 View 的内容才能呈现在屏幕上。
DecorView 作为顶级 View ，一般情况下，它内部会包含一个竖直方向的 LinearLayout ，在这个 LinearLayout 里面有上下两个部分，上面是标题栏，下面是内容栏。在Activity中，我们通过 setContentView 所设置的布局文件其实就是被加到内容栏中的，而内容栏id为 content 。可以通过下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通过 content.getChildAt(0) 可以得到设置的 view 。 DecorView 其实是一个 FrameLayout , View 层的事件都先经过 DecorView ，然后才传递给我们的 View 。
MeasureSpec 代表一个32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指测量模式，而 SpecSize 是指在某种测量模式下的规格大小。
SpecMode 有三类，如下所示：
UNSPECIFIED
EXACTLY
AT_MOST
LayoutParams需要和父容器一起才能决定View的MeasureSpec，从而进一步决定View的宽/高。
对于顶级View，即DecorView和普通View来说，MeasureSpec的转换过程略有不同。对于DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同确定；
对于普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同决定；
MeasureSpec一旦确定，onMeasure就可以确定View的测量宽/高。
小结一下
当子 View 的宽高采用 wrap_content 时，不管父容器的模式是精确模式还是最大模式，子 View 的模式总是最大模式+父容器的剩余空间。
View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即测量、布局、绘制。其中 measure 确定 View 的测量宽/高， layout 确定 view 的最终宽/高和四个顶点的位置，而 draw 则将 View 绘制在屏幕上。
measure 过程要分情况，如果只是一个原始的 view ，则通过 measure 方法就完成了其测量过程，如果是一个 ViewGroup ，除了完成自己的测量过程外，还会遍历调用所有子元素的 measure 方法，各个子元素再递归去执行这个流程。
如果是一个原始的 View，那么通过 measure 方法就完成了测量过程，在 measure 方法中会去调用 View 的 onMeasure 方法，View 类里面定义了 onMeasure 方法的默认实现:
先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源码：
可以看到， getMinimumWidth 方法获取的是 Drawable 的原始宽度。如果存在原始宽度（即满足 intrinsicWidth > 0），那么直接返回原始宽度即可；如果不存在原始宽度（即不满足 intrinsicWidth > 0），那么就返回 0。
接着看最重要的 getDefaultSize 方法：
如果 specMode 为 MeasureSpec.UNSPECIFIED 即未指定模式，那么返回由方法参数传递过来的尺寸作为 View 的测量宽度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精确模式，那么返回从 measureSpec 中取出的 specSize 作为 View 测量后的宽度和高度。
看一下刚才的表格：
当 specMode 为 EXACTLY 或者 AT_MOST 时，View 的布局参数为 wrap_content 或者 match_parent 时，给 View 的 specSize 都是 parentSize 。这会比建议的最小宽高要大。这是不符合我们的预期的。因为我们给 View 设置 wrap_content 是希望View的大小刚好可以包裹它的内容。
因此：
如果是一个 ViewGroup，除了完成自己的 measure 过程以外，还会遍历去调用所有子元素的 measure 方法，各个子元素再递归去执行 measure 过程。
ViewGroup 并没有重写 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 这几个方法专门用于测量子元素。
如果是 View 的话，那么在它的 layout 方法中就确定了自身的位置（具体来说是通过 setFrame 方法来设定 View 的四个顶点的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 这四个值）， layout 过程就结束了。
如果是 ViewGroup 的话，那么在它的 layout 方法中只是确定了 ViewGroup 自身的位置，要确定子元素的位置，就需要重写 onLayout 方法；在 onLayout 方法中，会调用子元素的 layout 方法，子元素在它的 layout 方法中确定自己的位置，这样一层一层地传递下去完成整个 View 树的 layout 过程。
layout 方法的作用是确定 View 本身的位置，即设定 View 的四个顶点的位置，这样就确定了 View 在父容器中的位置；
onLayout 方法的作用是父容器确定子元素的位置，这个方法在 View 中是空实现，因为 View 没有子元素了，在 ViewGroup 中则进行抽象化，它的子类必须实现这个方法。
1.绘制背景（ background.draw(canvas); ）；
2.绘制自己（ onDraw ）；
3.绘制 children（ dispatchDraw(canvas) ）；
4.绘制装饰（ onDrawScrollBars ）。
dispatchDraw 方法的调用是在 onDraw 方法之后，也就是说，总是先绘制自己再绘制子 View 。
对于 View 类来说， dispatchDraw 方法是空实现的，对于 ViewGroup 类来说， dispatchDraw 方法是有具体实现的。
通过 dispatchDraw 来传递的。 dispatchDraw 会遍历调用子元素的 draw 方法，如此 draw 事件就一层一层传递了下去。dispatchDraw 在 View 类中是空实现的，在 ViewGroup 类中是真正实现的。
如果一个 View 不需要绘制任何内容，那么就设置这个标记为 true，系统会进行进一步的优化。
当创建的自定义控件继承于 ViewGroup 并且不具备绘制功能时，就可以开启这个标记，便于系统进行后续的优化；当明确知道一个 ViewGroup 需要通过 onDraw 绘制内容时，需要关闭这个标记。
参考：《Android开发艺术探索》
‘玖’ android绘图之Canvas基础（2）
Canvas画布，用于绘制出各种形状配合画布的变幻操作可以绘制出很多复杂图形，基本的绘制图形分类。
提供的绘制函数：
上面四个函数都可以绘制canvas的背景，注意到PorterDuff.Mode变量，它只对两个canvas绘制bitmap起作用，所以此处暂时不讨论mode参数（没有设置mode默认使用srcover porterff mode）。
Rect 和RectF都是提供一个矩形局域。
(1)精度不一样，Rect是使用int类型作为数值，RectF是使用float类型作为数值。
(2)两个类型提供的方法也不是完全一致。
**
rect：RectF对象，一个矩形区域。
rx：x方向上的圆角半径。
ry：y方向上的圆角半径。
paint：绘制时所使用的画笔。**
**
cx 圆心x
cy 圆心y
radius半径**
需要一个Path,代表路径后面会讲解。
绘制线的集合，参数中pts是点的集合，两个值代表一个点，四个值代表一条线，互相之间不连接。
offset跳过的点，count跳过之后要绘制的点的总数，可以用于集合中部分点的绘制。
跳过部分节点：
没有跳过点
RectF oval:生成弧的矩形，中心为弧的圆心
float startAngle：弧开始的角度，以X轴正方向为0度，顺时针
float sweepAngle：弧持续的角度
boolean useCenter:是否有弧的两边，True，还两边，False，只有一条弧
在矩形框内画一个椭圆，如果是个正方形会画出一个圆。
canvas.drawPoint();
canvas.drawPoints();
**
只需要提供两个点一个坐标就可以绘制点。
canvas.drawPoint(20,20,mPaint);
float[] points = {30,40,40,50,60,60};
canvas.drawPoints(points,mPaint);**
这几种方法类似：
canvas.drawText("好好学习，天天向上",100,100,mPaint);
drawTextOnPath
沿着一条 Path 来绘制文字
text 为所需要绘制的文字
path 为文字的路径
hOffset 文字相对于路径的水平偏移量，用于调整文字的位置
vOffset 文字相对于路径竖直偏移量，用于调整文字的位置
值得注意的是，在绘制 Path 的时候，应该在拐弯处使用圆角，这样文字显示时更舒服
大致讲解，后面会重点讲解。
Rect src
Rect dst
其中src和dst这两个矩形区域是用来做什么的？
Rect src：指定绘制图片的区域
Rect dst或RectF dst：指定图片在屏幕上的绘制（显示）区域
首先指定图片区域，然后指定绘制图片的区域。
android绘图之Paint(1)
android绘图之Canvas基础（2）
Android绘图之Path（3）
Android绘图之drawText绘制文本相关（4）
Android绘图之Canvas概念理解（5）
Android绘图之Canvas变换（6）
Android绘图之Canvas状态保存和恢复（7）
Android绘图之PathEffect （8）
Android绘图之LinearGradient线性渐变（9）
Android绘图之SweepGradient（10）
Android绘图之RadialGradient 放射渐变（11）
Android绘制之BitmapShader（12）
Android绘图之ComposeShader，PorterDuff.mode及Xfermode（13）
Android绘图之drawText,getTextBounds,measureText,FontMetrics,基线（14）
Android绘图之贝塞尔曲线简介（15）
Android绘图之PathMeasure（16）
Android 动态修改渐变 GradientDrawable