android创建view

‘壹’ android中如何用代码生成View控件

在代码中，如果需要生成一个View控件，只需要像对待一般对象一样，使用new关键字，即可创建一个View。
代码演示：
TextView mTextView = new TextView(this);//此例代指系统自带控件View
M_drawView m_drawView = new M_drawView(this);// 此例代指自定义控件View
View是所有UI控件，容器控件的基类，View需要放到容器组件中或者，使用Activity将它显示出来。
开发者可以通过继承View类来派生出自定义的View。

‘贰’ Android - View 绘制流程

我们知道，在 Android 中，View 绘制主要包含 3 大流程：

Android 中，主要有两种视图： View 和 ViewGroup ，其中：

虽然 ViewGroup 继承于 View ，但是在 View 绘制三大流程中，某些流程需要区分 View 和 ViewGroup ，它们之间的操作并不完全相同，比如：

对 View 进行测量，主要包含两个步骤：

对于第一个步骤，即求取 View 的 MeasureSpec ，首先我们来看下 MeasureSpec 的源码定义：

MeasureSpec 是 View 的一个公有静态内部类，它是一个 32 位的 int 值，高 2 位表示 SpecMode（测量模式），低 30 位表示 SpecSize（测量尺寸/测量大小）。
MeasureSpec 将两个数据打包到一个 int 值上，可以减少对象内存分配，并且其提供了相应的工具方法可以很方便地让我们从一个 int 值中抽取出 View 的 SpecMode 和 SpecSize。

一个 MeasureSpec 表达的是：该 View 在该种测量模式（SpecMode）下对应的测量尺寸（SpecSize）。其中，SpecMode 有三种类型：

对 View 进行测量，最关键的一步就是计算得到 View 的 MeasureSpec ，子View 在创建时，可以指定不同的 LayoutParams （布局参数）， LayoutParams 的源码主要内容如下所示：

其中：

LayoutParams 会受到父容器的 MeasureSpec 的影响，测量过程会依据两者之间的相互约束最终生成子View 的 MeasureSpec ，完成 View 的测量规格。

简而言之，View 的 MeasureSpec 受自身的 LayoutParams 和父容器的 MeasureSpec 共同决定（ DecorView 的 MeasureSpec 是由自身的 LayoutParams 和屏幕尺寸共同决定，参考后文）。也因此，如果要求取子View 的 MeasureSpec ，那么首先就需要知道父容器的 MeasureSpec ，层层逆推而上，即最终就是需要知道顶层View（即 DecorView ）的 MeasureSpec ，这样才能一层层传递下来，这整个过程需要结合 Activity 的启动过程进行分析。

我们知道，在 Android 中， Activity 是作为视图组件存在，主要就是在手机上显示视图界面，可以供用户操作， Activity 就是 Andorid 中与用户直接交互最多的系统组件。

Activity 的基本视图层次结构如下所示：

Activity 中，实际承载视图的组件是 Window （更具体来说为 PhoneWindow ），顶层View 是 DecorView ，它是一个 FrameLayout ， DecorView 内部是一个 LinearLayout ，该 LinearLayout 由两部分组成（不同 Android 版本或主题稍有差异）： TitleView 和 ContentView ，其中， TitleView 就是标题栏，也就是我们常说的 TitleBar 或 ActionBar ， ContentView 就是内容栏，它也是一个 FrameLayout ，主要用于承载我们的自定义根布局，即当我们调用 setContentView(...) 时，其实就是把我们自定义的布局设置到该 ContentView 中。

当 Activity 启动完成后，最终就会渲染出上述层次结构的视图。

因此，如果我们要求取得到子View 的 MeasureSpec ，那么第一步就是求取得到顶层View（即 DecorView ）的 MeasureSpec 。大致过程如下所示：

经过上述步骤求取得到 View 的 MeasureSpec 后，接下来就可以真正对 View 进行测量，求取 View 的最终测量宽/高：

Android 内部对视图进行测量的过程是由 View#measure(int, int) 方法负责的，但是对于 View 和 ViewGroup ，其具体测量过程有所差异。

因此，对于测量过程，我们分别对 View 和 ViewGroup 进行分析：

综上，无论是对 View 的测量还是 ViewGroup 的测量，都是由 View#measure(int widthMeasureSpec, int heightMeasureSpec) 方法负责，然后真正执行 View 测量的是 View 的 onMeasure(int widthMeasureSpec, int heightMeasureSpec) 方法。

具体来说， View 直接在 onMeasure(...) 中测量并设置自己的最终测量宽/高。在默认测量情况下， View 的测量宽/高由其父容器的 MeasureSpec 和自身的 LayoutParams 共同决定，当 View 自身的测量模式为 LayoutParams.UNSPECIFIED 时，其测量宽/高为 android:minWidth / android:minHeight 和其背景宽/高之间的较大值，其余情况皆为自身 MeasureSpec 指定的测量尺寸。

而对于 ViewGroup 来说，由于布局特性的丰富性，只能自己手动覆写 onMeasure(...) 方法，实现自定义测量过程，但是总的思想都是先测量 子View 大小，最终才能确定自己的测量大小。

当确定了 View 的测量大小后，接下来就可以来确定 View 的布局位置了，也即将 View 放置到屏幕具体哪个位置。

View 的布局过程由 View#layout(...) 负责，其源码如下：

View#layout(...) 主要就做了两件事：

ViewGroup 的布局流程由 ViewGroup#layout(...) 负责，其源码如下：

可以看到， ViewGroup#layout(...) 最终也是通过 View#layout(...) 完成自身的布局过程，一个注意的点是， ViewGroup#layout(...) 是一个 final 方法，因此子类无法覆写该方法，主要是 ViewGroup#layout(...) 方法内部对子视图动画效果进行了相关设置。

由于 ViewGroup#layout(...) 内部最终调用的还是 View#layout(...) ，因此， ViewGroup#onLayout(...) 就会得到回调，用于处理 子View 的布局放置，其源码如下：

由于不同的 ViewGroup ，其布局特性不同，因此 ViewGroup#onLayout(...) 是一个抽象方法，交由 ViewGroup 子类依据自己的布局特性，摆放其 子View 的位置。

当 View 的测量大小，布局位置都确定后，就可以最终将该 View 绘制到屏幕上了。

View 的绘制过程由 View#draw(...) 方法负责，其源码如下：

其实注释已经写的很清楚了， View#draw(...) 主要做了以下 6 件事：

我们知道，在 Activity 启动过程中，会调用到 ActivityThread.handleResumeActivity(...) ，该方法就是 View 视图绘制的起始之处：

可以看到， ActivityThread.handleResumeActivity(...) 主要就是获取到当前 Activity 绑定的 ViewManager ，最后调用 ViewManager.addView(...) 方法将 DecorView 设置到 PhoneWindow 上，也即设置到当前 Activity 上。 ViewManager 是一个接口， WindowManager 继承 ViewManager ，而 WindowManagerImpl 实现了接口 WindowManager ，此处的 ViewManager.addView(...) 实际上调用的是 WindowManagerImpl.addView(...) ，源码如下所示：

WindowManagerImpl.addView(...) 内部转发到 WindowManagerGlobal.addView(...) ：

在 WindowManagerGlobal.addView(...) 内部，会创建一个 ViewRootImpl 实例，然后调用 ViewRootImpl.setView(...) 将 ViewRootImpl 与 DecorView 关联到一起：

ViewRootImpl.setView(...) 内部首先关联了传递过来的 DecorView （通过属性 mView 指向 DecorView 即可建立关联），然后最终调用 requestLayout() ，而 requestLayout() 内部又会调用方法 scheleTraversals() ：

ViewRootImpl.scheleTraversals() 内部主要做了两件事：

Choreographer.postCallback(...) 会申请一次 VSYNC 中断信号，当 VSYNC 信号到达时，便会回调 Choreographer.doFrame(...) 方法，内部会触发已经添加的回调任务， Choreographer 的回调任务有以下四种类型：

因此， ViewRootImpl.scheleTraversals(...) 内部通过 mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null) 发送的异步视图渲染消息就会得到回调，即回调 mTra

‘叁’ 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

‘肆’ 如何在android studio中实现自定义view

一、首先新建一个项目，项目及名称自拟。
二、在app上点击右键->new->Mole 选择Android library。
三、在topbar下的values中新建一个attrs.xml文件，用来存放自定义view的属性。
4.在topbar下实现view。
5.上面两部做完后就是引用这个view，这里需要注意的是要在主app的build.gradle中添加引用如下：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':topbar')
}
topbar就是要使用的moudle，切记添加引用。然后就可以使用了。
6.要想使用自定义view中的属性的话任然需要添加xmlns:custom="schemas.android.com/apk/res-auto"，前面加上http。
在这里还要注意命名空间也就是xustom之前一定不能定义过，否则重复的话就无法使用。

‘伍’ Android开发 自定义View

Android自定义View实现很简单:
1、继承View，重写构造函数、onDraw，（onMeasure）等函数。
2、如果自定义的View需要有自定义的属性，需要在values下建立attrs.xml。在其中定义你的属性。
3、在使用到自定义View的xml布局文件中需要加入xmlns:前缀="http://schemas.android.com/apk/res/你的自定义View所在的包路径".
4、在使用自定义属性的时候，使用前缀：属性名，如my:textColor="#FFFFFFF"。
实例：
自定义TextView类：
复制代码
package com.zst.service.component;
import com.example.hello_wangle.R;
import android.content.Context;
import android.content.res.TypedArray;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.util.AttributeSet;
import android.util.Log;
import android.view.View;
import android.widget.TextView;
public class MyTextView extends TextView {
//不能在布局文件中使用
public MyTextView(Context context) {
super(context);
}

//布局文件中用到此构造函数

‘陆’ Android宝典|View必考知识点总结

我们知道，Activity 是在 ActivityThread 的 performLaunchActivity 中进行创建的，在创建完成之后就会调用其 attach 方法，它是先于 onCreate、onStart、onResume 等生命周期函数的，因此将 attach 方法作为这篇文章主线的开头：

attach() 方法就是 new 一个 PhoneWindow 并且关联 WindowManager。

接下来就到了 onCreate 方法：

这一步就是把我们的布局文件解析成 View 塞到 DecorView 的一个 id 为 R.id.content 的 ContentView 中，DecorView 本身是一个 FrameLayout，它还承载了 StatusBar、NavigationBar 。

然后在 handleResumeActivity 中，通过 WindowManager 的 addView 方法把 DecorView 添加进去，实际实现是 WindowManagerImpl 的 addView 方法，它里面再通过 WindowManagerGlobal 的实例去 addView 的，在它里面就会 new 一个 ViewRootImpl，也就是说最后是把 DecorView 传给了 ViewRootImpl 的 setView 方法。ViewRootImpl 是 DecorView 的管理者，它负责 View 树的测量、布局、绘制，以及通过 Choreographer 来控制 View 的刷新。

WMS 是所有 Window 窗口的管理员，负责 Window 的添加和删除、Surface 的管理和事件派发等等，因此每一个 Activity 中的 PhoneWindow 对象如果需要显示等操作，就必须要与 WMS 交互才能进行。

在 ViewRootImpl 的 setView 方法中，会调用 requestLayout，并且通过 WindowSession 的 addToDisplay 与 WMS 进行交互。WMS 会为每一个 Window 关联一个 WindowStatus。

SurfaceFlinger 主要是进行 Layer 的合成和渲染。

在 WindowStatus 中，会创建 SurfaceSession，SurfaceSession 会在 Native 层构造一个 SurfaceComposerClient 对象，它是应用程序与 SurfaceFlinger 沟通的桥梁。

经过步骤四和步骤五之后，ViewRootImpl 与 WMS、SurfaceFlinger 都已经建立起连接，但此时 View 还没显示出来，我们知道，所有的 UI 最终都要通过 Surface 来显示，那么 Surface 是什么时候创建的呢？

这就要回到前面所说的 ViewRootImpl 的 requestLayout 方法了，首先会 checkThread 检查是否是主线程，然后调用 scheleTraversals 方法，scheleTraversals 方法会先设置同步屏障，然后通过 Choreographer 类在下一帧到来时去执行 doTraversal 方法。简单来说，Choreographer 内部会接受来自 SurfaceFlinger 发出的 Vsync 垂直同步信号，这个信号周期一般是 16ms 左右。doTraversal 方法首先会先移除同步屏障，然后 performTraversals 真正进行 View 的绘制流程，即调用 performMeasure、performLayout、performDraw。不过在它们之前，会先调用 relayoutWindow 通过 WindowSession 与 WMS 进行交互，即把 Java 层创建的 Surface 与 Native 层的 Surface 关联起来。

接下来就是正式绘制 View 了，从 performTraversals 开始，Measure、Layout、Draw 三步走。

第一步是获取 DecorView 的宽高的 MeasureSpec 然后执行 performMeasure 流程。MeasureSpec 简单来说就是一个 int 值，高 2 位表示测量模式，低 30 位用来表示大小。策略模式有三种，EXACTLY、AT_MOST、UNSPECIFIED。EXACTLY 对应为 match_parent 和具体数值的情况，表示父容器已经确定 View 的大小；AT_MOST 对应 wrap_content，表示父容器规定 View 最大只能是 SpecSize；UNSPECIFIED 表示不限定测量模式，父容器不对 View 做任何限制，这种适用于系统内部。接着说，performMeasure 中会去调用 DecorView 的 measure 方法，这个是 View 里面的方法并且是 final 的，它里面会把参数透传给 onMeasure 方法，这个方法是可以重写的，也就是我们可以干预 View 的测量过程。在 onMeasure 中，会通过 getDefaultSize 获取到宽高的默认值，然后调用 setMeasureDimension 将获取的值进行设置。在 getDefaultSize 中，无论是 EXACTLY 还是 AT_MOST，都会返回 MeasureSpec 中的大小，这个 SpecSize 就是测量后的最终结果。至于 UNSPECIFIED 的情况，则会返回一个建议的最小值，这个值和子元素设置的最小值以及它的背景大小有关。从这个默认实现来看，如果我们自定义一个 View 不重写它的 onMeasure 方法，那么 warp_content 和 match_parent 一样。所以 DecorView 重写了 onMeasure 函数，它本身是一个 FrameLayout，所以最后也会调用到 FrameLayout 的 onMeasure 函数，作为一个 ViewGroup，都会遍历子 View 并调用子 View 的 measure 方法。这样便实现了层层递归调用到了每个子 View 的 onMeasure 方法进行测量。

第二步是执行 performLayout 的流程，也就是调用到 DecorView 的 layout 方法，也就是 View 里面的方法，如果 View 大小发生变化，则会回调 onSizeChanged 方法，如果 View 状态发生变化，则会回调 onLayout 方法，这个方法在 View 中是空实现，因此需要看 DecorView 的父容器 FrameLayout 的 onLayout 方法，这个方法就是遍历子 View 调用其 layout 方法进行布局，子 View 的 layout 方法被调用的时候，它的 onLayout 方法又会被调用，这样就布局完了所有的 View。

第三步就是 performDraw 方法了，里面会调用 drawSoftware 方法，这个方法需要先通过 mSurface lockCanvas 获取一个 Canvas 对象，作为参数传给 DecorView 的 draw 方法。这个方法调用的是 View 的 draw 方法，先绘制 View 背景，然后绘制 View 的内容，如果有子 View 则会调用子 View 的 draw 方法，层层递归调用，最终完成绘制。

完成这三步之后，会在 ActivityThread 的 handleResumeActivity 最后调用 Activity 的 makeVisible，这个方法就是将 DecorView 设置为可见状态。

https://juejin.im/post/5c67c1e16fb9a04a05403549

https://juejin.im/post/5bf16ff5f265da6141712acc

‘柒’ Android自定义View——从零开始实现书籍翻页效果（一）

前言 ：本篇是系列博客的第三篇，这次我们要研究 书籍翻页效果 。不知道大家平时有没用过iReader、掌阅这些小说软件，里面的翻页效果感觉十分的酷炫。有心想研究研究如何实现，于是网上找了找，发现这方面的教学资料非常少，所幸能找到 何明桂大大 的 Android 实现书籍翻页效果----原理篇 这样的入门博客（感谢大大 Orz），我们就以这篇博客为切入点从零实现我们自己的翻页效果。由于这次坑比较深，预计会写好几期，感兴趣的小伙伴可以点下关注以便及时收到更新提醒，谢谢大家的支持 ~

本篇只着重于思路和实现步骤，里面用到的一些知识原理不会非常细地拿来讲，如果有不清楚的api或方法可以在网上搜下相应的资料，肯定有大神讲得非常清楚的，我这就不献丑了。本着认真负责的精神我会把相关知识的博文链接也贴出来（其实就是懒不想写那么多哈哈），大家可以自行传送。为了照顾第一次阅读系列博客的小伙伴，本篇会出现一些在之前 系列博客 就讲过的内容，看过的童鞋自行跳过该段即可

国际惯例，先上效果图，本次主要实现了 基本的上下翻页效果 与 右侧最大翻页距离的限制

在看这篇博客之前，希望大家能先了解一下书籍翻页的实现原理，博客链接我已经贴出来了。通过原理讲解我们知道，整个书籍翻页效果界面分成了三个区域， A 为当前页区域， B 为下一页区域， C 为当前页背面，如图所示

书籍翻页效果的实现就是要以我们 触摸屏幕位置的坐标 为基础绘制出这三个区域，形成模拟翻页的特效。要绘制这三个区域，我们需要通过一组 特定的点 来完成，这些点的坐标需要通过两个已知的点（ 触摸点 、 相对边缘角 ）计算得到，下图我将各个特定点的位置和计算公式贴出来，大家对照着原理一起理解（渣画工望体谅 ╮(╯▽╰)╭ ），其中 b 点是由 ae 和 cj 的交点， k 点是由 ah 和 cj 的交点

简单总结一下， a 是触摸点， f 是触摸点相对的边缘角， eh 我们设置为 af 的垂直平分线，则 g 是 af 的中点， ab 、 ak 、 dj 是 直线 ； 曲线cdb 是起点为 c ，控制点为 e ，终点为 b 的 二阶贝塞尔曲线 ； 曲线kij 是起点为 k ，控制点为 h ，终点为 j 的 二阶贝塞尔曲线 ，区域 A 、 B 、 C 就由这些点和线划分开来。我们将这些点称为标识点，下一步就是模拟设定 a 和 f 点的位置，将这组标识点绘制到屏幕上来验证我们的计算公式是否正确，创建 BookPageView

实体类 MyPoint 用来存放我们的标识点坐标

界面布局：

在Activity中进行注册

效果如图

前文我们提到 ab 、 ak 、 dj 是 直线 ； 曲线cdb 是起点为 c ，控制点为 e ，终点为 b 的 二阶贝塞尔曲线 ； 曲线kij 是起点为 k ，控制点为 h ，终点为 j 的 二阶贝塞尔曲线 。通过观察分析得知， 区域A 是由View 左上角 ， 左下角 ， 曲线cdb ， 直线 ab 、 ak ， 曲线kij ， 右上角 连接而成的区域，修改 BookPageView ，利用 path 绘制处 区域A

效果如图

区域C 理论上应该是由点 a , b , d , i , k 连接而成的闭合区域,但由于 d 和 i 是曲线上的点，我们没办法直接从 d 出发通过 path 绘制路径连接 b 点（ i , k 同理），也就不能只用 path 的情况下直接绘制出 区域C ，我们需要用 PorterDuffXfermode 方面的知识“曲线救国”。我们试着先将点 a , b , d , i , k 连接起来，观察闭合区域与 区域A 之间的联系。修改 BookPageView

效果如图

我们将两条曲线也画出来对比观察

观察分析后可以得出结论， 区域C 是 由直线ab,bd,dj,ik,ak连接而成的区域 减去 与区域A交集部分 后剩余的区域。于是我们设置 区域C 画笔 Xfermode 模式为 DST_ATOP

效果如图

最后是 区域B ，因为 区域B 处于最底层，我们直接将 区域B 画笔 Xfermode 模式设为 DST_ATOP ，在 区域A、C 之后绘制即可，修改 BookPageView

效果如图

翻页可以从右下方翻自然也可以从右上方翻，我们将 f 点设在右上角，由于View上下两部分是呈 镜像 的，所以各标识点的位置也应该是镜像对应的，因为 区域B和C 的绘制与 f 点没有关系，所以我们只需要修改 区域A 的绘制逻辑，新增 getPathAFromTopRight() 方法

效果如图

之前由于测试效果没有对View的大小进行重新测量，在实现触摸翻页之前先把这个结了。重写View的 onMeasure() 方法

我们的需求是，在上半部分翻页时 f 点在右上角，在下半部分翻页时 f 则在右下角，当手指离开屏幕时回到 初始状态 ，根据需求，修改 BookPageView

在Activity中监听View的 onTouch 状态

注意，要设置 android:clickable 为 true ，否则无法监听到 ACTION_MOVE 和 ACTION_UP 状态

效果如图

到这里我们已经实现了基本的翻页效果，但要还原真实的书籍翻页效果，我们还需要设置一些限制条件来完善我们的项目

对于一般的书本来说，最左侧应该是钉起来的，也就是说如果我们从右侧翻页，翻动的距离是 有限制的 ，最下方翻页形成的曲线起点（ c 点）的x坐标不能小于0（上方同理），按照这个限定条件，修改我们的 BookPageView

效果如图

至此本篇教程就告一段落了，当然还有许多功能需要继续完善，例如横向翻页、翻页动画、阴影效果等等，这些都会在后面的教程中一一解决。如果大家看了感觉还不错麻烦点个赞，你们的支持是我最大的动力~

‘捌’ Android 动态创建View，是否可以使用 style，如何使用

Android 是可以使用 style的，具体方法为：
1、在Android中可以这样定义样式：
在res/values/styles.xml文件中添加以下内容
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name=“itcast”>
<item name="android:textSize">18px</item>
<item name="android:textColor">#0000CC</item>
</style>
</resources>
2、在layout文件中可以像下面这样使用上面的android样式：
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" ....>
<TextView style="@style/itcast"
..... />
3、可以使他继承父样式，当然，如果父样式的值不符合需求，你也可以对它进行修改，如下：
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="itcast">
<item name="android:textSize">18px</item>
<item name="android:textColor">#0000CC</item>
</style>
<style name="subitcast" parent="@style/itcast">
<item name="android:textColor">#FF0000</item>
</style>
</resources>

‘玖’ android 自定义view 怎么规定view的样式

android 自定义view的样式的实现：

1.在values文件夹下，打开attrs.xml，其实这个文件名称可以是任意的，写在这里更规范一点，表示里面放的全是view的属性。

2.因为我们下面的实例会用到2个长度，一个颜色值的属性，所以我们这里先创建3个属性。

<declare-styleable name="rainbowbar">
<attr name="rainbowbar_hspace" format="dimension"></attr>
<attr name="rainbowbar_vspace" format="dimension"></attr>
<attr name="rainbowbar_color" format="color"></attr>
</declare-styleable>

举例说明：

蓝色的进度条

public class RainbowBar extends View {

//progress bar color
int barColor = Color.parseColor("#1E88E5");
//every bar segment width
int hSpace = Utils.dpToPx(80, getResources());
//every bar segment height
int vSpace = Utils.dpToPx(4, getResources());
//space among bars
int space = Utils.dpToPx(10, getResources());
float startX = 0;
float delta = 10f;
Paint mPaint;

public RainbowBar(Context context) {
super(context);
}

public RainbowBar(Context context, AttributeSet attrs) {
this(context, attrs, 0);
}

public RainbowBar(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
//read custom attrs
TypedArray t = context.obtainStyledAttributes(attrs,
R.styleable.rainbowbar, 0, 0);
hSpace = t.getDimensionPixelSize(R.styleable.rainbowbar_rainbowbar_hspace, hSpace);
vSpace = t.getDimensionPixelOffset(R.styleable.rainbowbar_rainbowbar_vspace, vSpace);
barColor = t.getColor(R.styleable.rainbowbar_rainbowbar_color, barColor);
t.recycle(); // we should always recycle after used
mPaint = new Paint();
mPaint.setAntiAlias(true);
mPaint.setColor(barColor);
mPaint.setStrokeWidth(vSpace);
}

.......
}

View有了三个构造方法需要我们重写，这里介绍下三个方法会被调用的场景，

第一个方法，一般我们这样使用时会被调用，View view = new View(context);

第二个方法，当我们在xml布局文件中使用View时，会在inflate布局时被调用，
<View layout_width="match_parent" layout_height="match_parent"/>。

第三个方法，跟第二种类似，但是增加style属性设置，这时inflater布局时会调用第三个构造方法。
<View style="@styles/MyCustomStyle" layout_width="match_parent" layout_height="match_parent"/>。

‘拾’ 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工作完毕。