android绘制过程
A. Android：一篇文章带你完全梳理自定义View工作流程！
了解自定义View流程前，需了解一定的自定义View基础，具体请看文章： （1）自定义View基础 - 最易懂的自定义View原理系列
下面，我将详细讲解 View 绘制的三大流程： measure 过程、 layout 过程、 draw 过程
请看文章： 自定义View Layout过程 - 最易懂的自定义View原理系列（3）
至此，关于自定义 View 的工作流程讲解完毕。
结合原理 & 实现步骤，若需实现1个自定义View，请看文章： 手把手教你写一个完整的自定义View
B. 安卓开发中矢量图的绘制及动画
矢量图也称为面向对象的图像或绘图图像，是根据几何特性来绘制的图形，在安卓开发中可以使用失量图代替原来的图片资源，矢量图具有占用空间小和可以随意缩放但不失真的优势，在我的多个项目中都有运用。
通过学习和实践，我总结了一些与矢量图相关的知识，方便今后更好的使用矢量图，同时也可以供大家查阅参考。
绘制矢量图之前需要先定义画布的宽高，后续的绘制效果都展示在这个画布上。在绘制过程中需要输入的坐标就是这个画布上的点。
安卓的矢量图常见于 drawable 文件夹下，是一个xml文件，由 vector 标签包裹，在 vector 标签中可包含多个 path 标签，依次叠加显示。
在矢量图中最重要的就是 path 属性，图像的样式就是由 path 属性中的数据绘制而成，这些数据由不同的命令组合而成，下面就介绍一些矢量图的绘制命令。
将前面的命令示例连接起来就可以生成一个完整的图像，它大概长这个样子：
画布的尺寸为500x500，图上的顶点是200,10的位置，也是我们开始作图的起点。通过这个图片可以更好的理解每一个绘图命令。
安卓中可以为矢量图添加动画效果，这样用户就可以看到一个动的图片，可以一定程度的提高app的交互效果。矢量图动画是图形内部的变化，可以做到View动画无法实现的效果。
这种动画针对的是矢量图中 path 字段的值，通过连续改变 path 字段的值而达到产生动画的效果。
注：pathData动画所需的AnimatedVectorDrawable最低要求API等级为25
实现一个矢量图动画需要以下几步：
1. 准备起始状态和结束状态的矢量图两张。
2. 创建动画配置文件。
3. 创建动画矢量图文件。
4. 启动动画。
基于这种要求，我准备了两个矢量图：
控制动画运行的是一个 objectAnimator ，此处把 objectAnimator 包裹在一个 set 中也是可以的，说白了就是执行这个动画文件。
ration 用来指定动画的持续时间。
propertyName 中的pathData指的就是矢量图中的pathData。
valueFrom 和 valueTo 一个是起始路径，一个是结束路径，可以想到，这个动画就是在持续修改pathData，从而达到展示动画的效果。而 valueFrom 和 valueTo 的值是直接从先前准备的矢量图中复制过来的，所以那个结束状态的矢量图中唯一有用的东西就是pathData属性，没有那个文件也无所谓。
valueType 这里必须填判型写pathType，这是专门用来计算path的类型。
此时，文件的最外层由 animated-vector 包裹，同时需要添加一个 drawable 参数，这个 drawable 用于指定动画应用于那个矢量图上，我们是要从未启用状态变成启用状态，所以是在未启用状态开始执行动画，在动画未开始的时候展示的也是未启用状态。此处我们指定为 @drawable/icon_filter_off 。
内部有一个 target 标签，这个标签可以有多个，分别对应不同的动画，但同一个 path 只能应用一个动画。
name 用于指定要执行动画的 path 。status正是我们为右下角小图标path设置的名称。
animation 用于指定需要执行的动画。此处引用我们刚刚创建的猛冲山动画资源 @animator/filter_turn_on 。
当我们创建枝中好动画矢量图之后，页面中引用的资源就不再是之前的静态矢量图了，需要把 ImageView 的图片替换成 @drawable/animated_filter_on
经过这么多的步骤，我们终于做出了一个矢量图动画，而且是一个。说实话，有点累，然而我这个状态切换的动画一套就要两个，所以我又加了一个回来的动画和对应的动画矢量图，一共六个文件，完成了筛选状态的两个切换动画。这还是比较简单的实现方式，对于两种状态切换的动画，网上还有一种使用selector的方式，这种方式更麻烦，而且使用方法并没有简单一些，所以我的选择是在需要切换状态的时候更改 ImageView 的图片资源，然后再执行动画。
trimPath动画相当于是改变了矢量图绘制的位置，是从头开始画还是从80%的位置开始画，然后再动态的修改这个百分比，从而达到动画的效果。理解起来倒不是很难。
先放一个我使用trimPath动画做的loading效果，这个动画效果被我用在LoadingDialog中，在界面加载的时候会重复播放这个动画。
android:name="load" 不用多说，这个是我们做动画时路径名称。这里为了让心电图路径更清晰，我设置了描边宽度为20( android:strokeWidth="20" )，同时还要设置描边的颜色才能展示出来。后面的 android:trimPathStart="0" 和 android:trimPathEnd="0" 是本次trimPath动画的重点。
这两个属性都设置为0是因为动画的起始帧都为0，然后通过 objectAnimator 慢慢把这两个属性变为1，这样一个慢慢增长的动画就形成了。
网络上一个横线变成搜索按钮的示例是将这两个属性分别应用到了两个 path 上，而我是将两个属性同时应用到一个 path 上，原理都是一样的。
在配置文件中，我将两个动画都设置为3秒且循环播放，起始点的动画慢于终点的动画1秒，达到只画中间1秒间隔线段的效果。和路径变形动画的区别是 android:valueType="floatType" ，我们只需要计算从0到1的数字，然后应用到 trimPathStart 和 trimPathEnd 字段上。至此，loading的动画就配置完了。
这一步已经没什么可说的了，就是将指定的矢量图中指定的路径设置一个指定的动画。
通过几天的学习，已经大致掌握了矢量图的展示及动画的制作，但这一套流程下来成本比较高，是程序员方式的动画制作流程。除了制作成本，创意成本也是相当高的，一个好的创意能极大的提升用户体验，而好多时候我们的创意能够被实现也是很困难的。希望以后能实现一些更好的效果，让用户使用起来更舒服。
SVG—最简单的SVG动画
SVG路径（path）中的圆弧(A)指令的语法说明及计算逻辑
Android中的矢量图
Android高级动画（2）
C. Android 自定义控件 layout
Android 绘制流程
View ：View主要执行layout方法，使用 serFrame 方法来设置本身 View 的四个顶点的位置，确定View本身的位置。
ViewGroup ：ViewGroup主要执行onLayout方法，递归遍历所有子View，确定子View的位置。
我们来看ViewRootImpl中的 performLayout() 方法
看到这里，那host.getMeasuredWidth() / host.getMeasuredHeight()是什么？它是直接调用View中的方法，其实就是经过measure后的DecorView的测量宽度和高度。在 Android 自定义控件 measure 中有说明。
2.3.2.1 我们先来看ViewGroup中的 layout() 方法
ViewGroup里面的layout最终会调入到父类View中的layout，View的layout后面讲解。这里可以先告诉大家，最终会调用View的onLayout方法，而ViewGroup的onLayout是抽象方法，所以它的子类LinearLayout必须要实现。
2.3.2.2 我们再来看LinearLayout中的 onLayout() 方法。
2.3.2.3 挑一个纵向的吧，我们再来看LinearLayout中的 layoutVertical() 方法。
2.3.2.4 我们再来看LinearLayout中的 setChildFrame() 方法。
又一次回到了View的layout方法，接下来就看View分发的layout。
我们先来看View中的 layout() 方法。
我们先来看View中的 onLayout() 方法。
空空如也，其实View的布局由父容器决定，所以空实现是正常的，当然也可以在自定义View中进行更改。
《Android 视图模块 全家桶》
Android开发之自定义控件(二)---onLayout详解
自定义View Layout过程 - 最易懂的自定义View原理系列（3）
D. 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开发艺术探索》
E. Android 自定义View之Layout过程
系列文章：
在上篇文章： Android 自定义View之Measure过程 ，我们分析了Measure过程，本次将会掀开承上启下的Layout过程神秘面纱，
通过本篇文章，你将了解到：
在上篇文章的比喻里，我们说过：
该ViewGroup 重写了onMeasure(xx)和onLayout(xx)方法：
同时，当layout 执行结束，清除PFLAG_FORCE_LAYOUT标记，该标记会影响Measure过程是否需要执行onMeasure。
该View 重写了onMeasure(xx)和onLayout(xx)方法：
MyViewGroup里添加了MyView、Button两个控件，最终运行的效果如下：
可以看出，MyViewGroup 里子布局的是横向摆放的。我们重点关注Layout过程。实际上，MyViewGroup里我们只重写了onLayout(xx)方法，MyView也是重写了onLayout(xx)方法。
接下来，分析View Layout过程。
与Measure过程类似，连接ViewGroup onLayout(xx)和View onLayout(xx)之间的桥梁是View layout(xx)。
可以看出，最终都调用了setFrame(xx)方法。
对于Measure过程在onMeasure(xx)里记录了尺寸的值，而对于Layout过程则在layout(xx)里记录了坐标值，具体来说是在setFrame(xx)里，该方法两个重点地方：
View.onLayout(xx)是空实现
从layout(xx)和onLayout(xx)声明可知，这两个方法都是可以被重写的，接下来看看ViewGroup是否重写了它们。
ViewGroup.layout(xx)虽然重写了layout(xx)，但是仅仅做了简单判断，最后还是调用了View.layout(xx)。
这重写后将onLayout变为抽象方法，也就是说继承自ViewGroup的类必须重写onLayout(xx)方法。
我们以FrameLayout为例，分析其onLayout(xx)做了什么。
FrameLayout.onLayout(xx)为子布局Layout的时候，起始坐标都是以FrameLayout为基准，并没有记录上一个子布局占了哪块位置，因此子布局的摆放位置可能会重叠，这也是FrameLayout布局特性的由来。而我们之前的Demo在水平方向上记录了上一个子布局的摆放位置，下一个摆放时只能在它之后，因此就形成了水平摆放的功能。
由此类推，我们常说的某个子布局在父布局里的哪个位置，决定这个位置的即是ViewGroup.onLayout(xx)。
上边我们分析了View.layout(xx)、View.onLayout(xx)、ViewGroup.layout(xx)、ViewGroup.onLayout(xx)，这四者什么关系呢？
View.layout(xx)
View.onLayout(xx)
ViewGroup.layout(xx)
ViewGroup.onLayout(xx)
View/ViewGroup 子类需要重写哪些方法：
用图表示：
通过上述的描述，我们发现Measure过程和Layout过程里定义的方法比较类似：
它俩的套路比较类似：measure(xx)、layout(xx)一般不需要我们重写，measure(xx)里调用onMeasure(xx)，layout(xx)为调用者设置坐标值。
若是ViewGroup：onMeasure(xx)里遍历子布局，并测量每个子布局，最后将结果汇总，设置自己测量的尺寸；onLayout(xx)里遍历子布局，并设置每个子布局的坐标。
若是View：onMeasure(xx)则测量自身，并存储测量尺寸；onLayout(xx)不需要做什么。
Measure过程虽然比Layout过程复杂，但仔细分析后就会发现其本质就是为了设置两个成员变量：
而Layout过程虽然比较简单，其本质是为了设置坐标值
将Measure设置的变量和Layout设置的变量联系起来：
此外，Measure过程通过设置PFLAG_LAYOUT_REQUIRED 标记来告诉需要进行onLayout，而Layout过程通过清除 PFLAG_FORCE_LAYOUT来告诉Measure过程不需要执行onMeasure了。
这就是Layout的承上作用
我们知道View的绘制需要依靠Canvas绘制，而Canvas是有作用区域限制的。例如我们使用：
Cavas绘制的起点是哪呢？
对于硬件绘制加速来说：正是通过Layout过程中设置的RenderNode坐标。
而对于软件绘制来说：
关于硬件绘制加速/软件绘制 后续文章会分析。
这就是Layout的启下作用
以上即是Measure、Layout、Draw三者的内在联系。
当然Layout的"承上"还需要考虑margin、gravity等参数的影响。具体用法参见最开始的Demo。
getMeasuredWidth()/getMeasuredHeight 与 getWidth/getHeight区别
我们以获取width为例，分别来看看其方法：
getMeasuredWidth()：获取测量的宽，属于"临时值"
getWidth()：获取View真实的宽
在Layout过程之前，getWidth() 默认为0
何时可以获取真实的宽、高
下篇将分析Draw()过程，我们将分析"一切都是draw出来的"道理
本篇基于 Android 10.0
F. android帧的绘制过程以及fps的获取
帧的渲染过程中一些关键组件的流程图
任何可以产生图形信息的组件都统称为图像的生产者，比如OpenGL ES, Canvas 2D, 和 媒体解码器等。
SurfaceFlinger是最常见的图像消费者，Window Manager将图形信息收集起来提供给SurfaceFlinger,SurfaceFlinger接受后经过合成再把图形信息传递给显示器。同时，SurfaceFlinger也是唯一一个能够改变显示器内容的服务。SurfaceFlinger使用OpenGL和Hardware Composer来生成surface.
某些OpenGL ES 应用同样也能够充当图像消费者，比如相机可以直接使用相机的预览界面图像流，一些非GL应用也可以是消费者，比如ImageReader 类。
Window Manager是一个用于控制window的系统服务，包含一系列的View。每个Window都会有一个surface，Window Manager会监视window的许多信息，比如生命周期、输入和焦点事件、屏幕方向、转换、动画、位置、转换、z-order等，然后将这些信息（统称window metadata）发送给SurfaceFlinger，这样，SurfaceFlinger就能将window metadata合成为显示器上的surface。
为硬件抽象层（HAL）的子系统。SurfaceFlinger可以将某些合成工作委托给Hardware Composer，从而减轻OpenGL和GPU的工作。此时，SurfaceFlinger扮演的是另一个OpenGL ES客户端，当SurfaceFlinger将一个缓冲区或两个缓冲区合成到第三个缓冲区时，它使用的是OpenGL ES。这种方式会比GPU更为高效。
一般应用开发都要将UI数据使用Activity这个载体去展示，典型的Activity显示流程为：
一般app而言，在任何屏幕上起码有三个layer：
那么android是如何使用这两种合成机制的呢？这里就是Hardware Composer的功劳。处理流程为：
借用google一张图说明，可以将上面讲的很多概念展现，很清晰。地址位于 https://source.android.com/devices/graphics/
即 Frame Rate，单位 fps，是指 gpu 生成帧的速率，如 33 fps，60fps，越高越好。
但是对于快速变化的游戏而言，你的FPS很难一直保持同样的数值，他会随着你所看到的显示卡所要描画的画面的复杂程度而变化。
安卓系统中有 2 种 VSync 信号：
如上图，CPU/GPU 向 Buffer 中生成图像，屏幕从 Buffer 中取图像、刷新后显示。这是一个典型的生产者——消费者模型。理想的情况是帧率和刷新频率相等，每绘制一帧，屏幕显示一帧。而实际情况是，二者之间没有必然的大小关系，如果没有锁来控制同步，很容易出现问题。
所谓”撕裂”就是一种画面分离的现象，这样得到的画像虽然相似但是上半部和下半部确实明显的不同。这种情况是由于帧绘制的频率和屏幕显示频率不同步导致的，比如显示器的刷新率是75Hz,而某个游戏的FPS是100. 这就意味着显示器每秒更新75次画面，而显示卡每秒更新100次，比你的显示器快33%。
两个缓存区分别为 Back Buffer 和 Frame Buffer。GPU 向 Back Buffer 中写数据，屏幕从 Frame Buffer 中读数据。VSync 信号负责调度从 Back Buffer 到 Frame Buffer 的复制操作，可认为该复制操作在瞬间完成。
双缓冲的模型下，工作流程这样的：
应用和SurfaceFlinger的渲染回路必须同步到硬件的VSYNC，在一个VSYNC事件中，显示器将显示第N帧，SurfaceFlinger合成第N+1帧，app合成第N+2帧。
使用VSYNC同步可以保证延迟的一致性，减少了app和SurfaceFlinger的错误，以及显示在各个阶段之间的偏移。然而，前提是app和SurfaceFlinger每帧时间的变化并不大。因此，从输入到显示的延迟至少有两帧。
为了解决这个问题，您可以使用VSYNC偏移量来减少输入到显示的延迟，其方法为将app和SurfaceFlinger的合成信号与硬件的VSYNC关联起来。因为通常app的合成耗时是小于两帧的（33ms左右）。
VSYNC偏移信号细分为以下3种，它们都保持相同的周期和偏移向量：
注意，当 VSync 信号发出时，如果 GPU/CPU 正在生产帧数据，此时不会发生复制操作。屏幕进入下一个刷新周期时，从 Frame Buffer 中取出的是“老”数据，而非正在产生的帧数据，即两个刷新周期显示的是同一帧数据。这是我们称发生了“掉帧”（Dropped Frame，Skipped Frame，Jank）现象。
第一列t1： when the app started to draw （开始绘制图像的瞬时时间）
第二列t2： the vsync immediately preceding SF submitting the frame to the h/w （VSYNC信令将软件SF帧传递给硬件HW之前的垂直同步时间），也就是对应上面所说的软件Vsync
第三列t3： timestamp immediately after SF submitted that frame to the h/w （SF将帧传递给HW的瞬时时间，及完成绘制的瞬时时间）
每mpsys SurfaceFlinger一次计算汇总出一个fps,计算规则为：
frame的总数N：127行中的非0行数
绘制的时间T：设t=当前行t2 - 上一行的t2，求出所有行的和∑t
fps=N/T (要注意时间转化为秒)
一次mpsys SurfaceFlinger会输出127帧的信息，但是这127帧可能是这个样子：
如果t3-t1>16.7ms，则认为发生一次卡顿
设目标fps为target_fps，目标每帧耗时为target_ftime=1000/target_fps
从以下几个维度衡量流畅度：
参考文章：
http://windrunnerlihuan.com/2017/05/21/VSync%E4%BF%A1%E5%8F%B7/
G. Android 自定义View之Draw过程(上)
Draw 过程系列文章
Android 展示之三部曲：
前边我们已经分析了：
这俩最主要的任务是： 确定View/ViewGroup可绘制的矩形区域。
接下来将会分析，如何在这给定的区域内绘制想要的图形。
通过本篇文章，你将了解到：
Android 提供了关于View最基础的两个类：
然而ViewGroup 并没有约定其内部的子View是如何布局的，是叠加在一起呢？还是横向摆放、纵向摆放等。同样的View 也没有约定其展示的内容是啥样，是矩形、圆形、三角形、一张图片、一段文字抑或是不规则的形状？这些都要我们自己去实现吗？
不尽然，值得高兴的是Android已经考虑到上述需求了，为了开发方便已经预制了一些常用的ViewGroup、View。
如：
继承自ViewGroup的子类
继承自View的子类
虽然以上衍生的View/ViewGroup子类已经大大为我们提供了便利，但也仅仅是通用场景下的通用控件，我们想实现一些较为复杂的效果，比如波浪形状进度条、会发光的球体等，这些系统控件就无能为力了，也没必要去预制千奇百怪的控件。想要达到此效果，我们需要自定义View/ViewGroup。
通常来说自定义View/ViewGroup有以下几种：
3 一般不怎么用，除非布局比较特殊。1、2、4 是我们常用的手段，对于我们常说的"自定义View" 一般指的是 4。
接下来我们来看看 4是怎么实现的。
在xml里引用MyView
效果如下：
黑色部分为其父布局背景。
红色矩形+黄色圆形即是MyView绘制的内容。
以上是最简单的自定义View的实现，我们提取重点归纳如下：
由上述Demo可知，我们只需要在重写的onDraw(xx)方法里绘制想要的图形即可。
来看看View 默认的onDraw(xx)方法：
发现是个空实现，因此继承自View的类必须重写onDraw(xx)方法才能实现绘制。该方法传入参数为：Canvas类型。
Canvas翻译过来一般叫做画布，在重写的onDraw(xx)里拿到Canvas对象后，有了画布我们还需要一支笔，这只笔即为Paint，翻译过来一般称作画笔。两者结合，就可以愉快的作画(绘制)了。
你可能发现了，在Demo里调用
并没有传入Paint啊，是不是Paint不是必须的？实际上调用该方法后，底层会自动生成Paint对象。
可以看到，底层初始化了Paint，并且给其设置的颜色为在java层设置的颜色。
onDraw(xx)比较简单，开局一个Canvas，效果全靠画。
试想，这个Canvas怎么来的呢，换句话说是谁调用了onDraw(xx)。发挥一下联想功能，在Measure、Layout 过程有提到过两者套路很像：
那么Draw过程是否也是如此套路呢？看见了onDraw(xx)，那么draw(xx)还远吗？
没错，还真有draw(xx)方法：
可以看出，draw(xx)主要分为两个部分：
不管是A分支还是B分支，都进行了好几步的绘制。
通常来说，单一一个View的层次分为：
后面绘制的可能会遮挡前边绘制的。
对于一个ViewGroup来说，层次分为：
来看看A分支标注的4个点:
(1)
onDraw(canvas)
前面分析过，对于单一的View，onDraw(xx)是空实现，需要由我们自定义绘制。
而对于ViewGroup，也并没有具体实现，如果在自定义ViewGroup里重写onDraw(xx)，它会执行吗？默认是不会执行的，相关分析请移步：
Android ViewGroup onDraw为什么没调用
(2)
dispatchDraw(canvas)，来看看在View.java里的实现:
发现是个空实现，再看看ViewGroup.java里的实现:
也即是说，对于单一View，因为没有子布局，因此没必要再分发Draw，而对于ViewGroup来说，需要触发其子布局发起Draw过程(此过程后续分析)，可以类比事件分发过程View、ViewGroup的处理。感兴趣的请移步：
Android 输入事件一撸到底之View接盘侠（3）
(3)
OverLay，顾名思义就是"盖在某个东西上面"，此处是在绘制内容之后，绘制前景之前。怎么用呢？
以上是给一个ViewGroup设置overLay，效果如下：
你可能发现了，这和设置overLay差不多的嘛，实际还是有差别的。在onDrawForeground(xx)里会重新调整Drawable的尺寸，该尺寸与View大小一致，之前给Drawable设置的尺寸会失效。运行效果如下：
可以看出，ViewGroup都被前景盖住了。
再来看看B分支的重点：边缘渐变效果
先来看看TextView 边缘渐变效果：
加上这俩参数。
实际上系统自带的一些控件也使用了该效果，如NumberPicker、YearPickerView
以上是NumberPicker 的效果，可以看出是垂直方向渐变的。
对于View.java 里的onDraw(xx)、draw(xx)，ViewGroup.java里并没有重写。
而对于dispatchDraw(xx)，在View.java里是空实现。在ViewGroup.java里发起对子布局的绘制。
来看看标记的2点：
(1)
设置padding的目的是为了让子布局留出一定的空隙出来，因此当设置了padding后，子布局的canvas需要根据padding进行裁减。判断标记为：
FLAG_CLIP_TO_PADDING 默认设置为true
FLAG_PADDING_NOT_NULL 只要有padding不为0，该标记就会打上。
也就是说：只要设置了padding 不为0，子布局显示区域需要裁减。
能不能不让子布局裁减显示区域呢？
答案是可以的。
考虑到一种场景：使用RecyclerView的时候，我们需要设置paddingTop = 20px，效果是：RecyclerView Item展示时离顶部有20px，但是滚动的时候永远滚不到顶部，看起来不是那么友好。这就是上述的裁减起作用了，需要将此动作禁止。通过设置：
当然也可以在xml里设置：
(2)
drawChild(xx)
从方法名上看是调用子布局进行绘制。
child.draw(x1,x2,x3)里分两种情况:
这两者具体作用与区别会在下篇文章分析，不管是硬件加速绘制还是软件加速绘制，最终都会调用View.draw(xx)方法，该方法上面已经分析过。
注意，draw(x1,x2,x3)与draw(xx)并不一样，不要搞混了。
用图表示：
View/ViewGroup Draw过程的联系：
一般来说，我们通常会自定义View，并且重写其onDraw(xx)方法，有没有绘制内容的ViewGroup需求呢？
是有的，举个例子，大家可以去看看RecyclerView ItemDecoration 的绘制，其中运用到了ViewGroup draw(xx)、ViewGroup onDraw(xx) 、View onDraw(xx)绘制的先后顺序来实现分割线，分组头部悬停等功能的。
本篇文章基于 Android 10.0
H. 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工作完毕。