我做了快十年Android开发，自定义View一直是面试必考、项目必用的硬功夫。早期我也觉得这玩意儿玄乎，动不动就MeasureSpec、Canvas、手势冲突，看一遍忘一遍。直到完整啃下几个复杂项目，踩了无数坑之后，才把这些知识点串成了一条线。
这篇指南不是API文档的搬运，而是把我这些年实际用到的核心方法论、关键源码解读、以及那些文档里不会写的坑，一次性梳理清楚。不管你是刚接触自定义View的新手，还是已经被onDraw折磨过几次的进阶开发者，这篇文章都能帮你把知识体系补完整。我会从整体设计思路开始，逐步拆解测量、布局、绘制三大流程，再深入到触摸事件处理和动画优化，最后附上高频问题和排查技巧。
1. 内容整体设计与思路拆解
很多人学自定义View最大的障碍是"一上来就写代码"，结果写了半天发现效果不对，也不知道问题出在哪。这其实不是代码能力的问题，而是对整个View的工作机制缺少顶层认知。
自定义View的本质，是系统提供了一套完整的绘制框架，而我们是在这套框架的特定节点上注入自己的逻辑。理解这个"框架优先"的思路，比记住任何单个API都重要。
1.1 核心需求解析：自定义View到底是什么
自定义View无非三种情况：把多个系统控件组合在一起、对现有控件做扩展改造、从零绘制一个全新控件。我见过不少新手一上来就想着从零绘制，实际上工作中80%的需求用组合和扩展就能解决，而且稳定性和性能都好得多。
从零绘制的场景通常是那些系统控件无法表达的内容：图表、进度环、富文本标签、复杂的背景装饰、特殊的交互按钮等。这类控件需要直接跟Canvas打交道，涉及测量、布局、绘制的完整流程，也是这篇指南的重点。
在学习路线上，我建议按照"先会看、再会改、最后会造"的顺序来。先能读懂一个自定义View的源码，知道每个回调在什么时候触发、负责什么；然后尝试在小需求上做扩展改造；最后才是从零设计一个完整控件。这个顺序能帮你少走很多弯路。
1.2 方案选型：为什么选择从三大流程切入
Android的View体系无论多复杂，最终都归结为三个核心流程：measure（测量）、layout（布局）、draw（绘制）。这三个流程决定了View的大小、位置和外观，任何自定义View都逃不开这套规则。
我见过不少人学了几个月自定义View还是云里雾里，原因就是没抓住这条主线。有的教程一上来就贴一大段Canvas绘图代码，看着很炫，但遇到尺寸适配就懵了。有的教程大讲特讲坐标系，但到了实际项目中还是不会用。
真正高效的学习路径是先理解三大流程如何协作，再去学习具体的绘制API和事件处理。因为测量决定了你的View有多大，布局决定了它在哪，绘制决定了它长什么样——这三者是有严格先后顺序的。你可以先只重写onDraw画一个静态图形，跑通最小流程，再逐渐加入测量逻辑、事件逻辑、动画逻辑。每加一层，你对整个框架的理解就深一层。
2. 核心细节解析与实操要点
理解了大框架之后，接下来要深入每个流程的内部机制。这一部分我尽量把源码里最关键的逻辑讲清楚，同时给出在实际开发中怎么用的建议。记住，面试问的原理和写代码关注的点，往往不完全一样，但底层的理解能让你写出更稳的代码。
2.1 View的测量流程：MeasureSpec与模式匹配
测量是三大流程的第一步，也是最容易出问题的一步。系统在测量一个View时，会传入一个MeasureSpec，它由两部分组成：specMode（测量模式）和specSize（测量大小）。这两个值打包在一个32位的int里，高2位是模式，低30位是大小。
MeasureSpec有三种模式：EXACTLY（精确模式）、AT_MOST（最大模式）、UNSPECIFIED（未指定模式）。在大部分实际场景下，父容器传给我们的是EXACTLY（比如match_parent或具体dp值）或AT_MOST（比如wrap_content）。
这里有一个很多人容易忽略的关键点：当你自定义View时，如果只重写onDraw而不处理onMeasure，那么wrap_content会表现得跟match_parent一样。这是Android的一个"深坑"，原因是View的默认onMeasure在wrap_content时直接使用了父容器传入的specSize，导致View占满了可用空间。
解决这个问题的方法是重写onMeasure，针对AT_MOST模式设置一个默认大小。比如自定义一个圆形进度控件，期望wrap_content时是100dp的正方形，那么代码可以这样写：
@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int desiredSize = dp2px(100); int width = resolveSize(desiredSize, widthMeasureSpec); int height = resolveSize(desiredSize, heightMeasureSpec); setMeasuredDimension(width, height); }resolveSize()是系统提供的一个便捷方法，它内部会根据MeasureSpec的模式来决策：EXACTLY就直接用specSize，AT_MOST则取min(desiredSize, specSize)，UNSPECIFIED就用desiredSize。这个方法看似简单，但它能帮我们避免自己写一堆if-else来判断模式，是日常开发中最高频使用的工具方法。
2.2 布局流程：onLayout应该关注什么
布局流程的核心任务是为每个子View确定最终的坐标位置。对于继承自View的自定义控件来说，因为没有子View，通常不需要重写onLayout。但如果你自定义的是ViewGroup，onLayout就是必须实现的方法。
onLayout的难点不在于怎么调用子View的layout方法，而在于你要自己在里面做排列计算。LinearLayout是线性排列，RelativeLayout是相对约束，FrameLayout是重叠摆放——这些不同的布局策略，本质上都是不同的坐标计算算法。
注意：onLayout里做的计算量直接影响布局性能。如果列表项里用了一个复杂的自定义ViewGroup，onLayout里的每次计算都会在滑动时被反复执行。能用简单的计算就坚决不写复杂循环，能在onMeasure阶段缓存的结果就不要放到onLayout再算一遍。
2.3 绘制流程：onDraw的正确打开方式
onDraw是自定义View里大家最熟悉的方法，也是很多人的"主战场"。这里的核心逻辑就是拿到Canvas，然后调用各种drawXXX方法画出期望的内容。
不过有几个细节值得注意。第一，Canvas的坐标系原点在View的左上角，x轴向右，y轴向下。这个坐标系和数学里的坐标系是反着的，很多刚入门的人画图形时总画反，就是没记住这点。第二，Canvas本身有平移、旋转、缩放等矩阵操作，合理利用这些变换可以让绘制代码简洁很多。比如要画一个带动画的指针表盘，可以把坐标系平移到圆心，然后旋转画布画刻度，这样就避免了一堆三角函数计算。
还有一个非常容易被忽视的问题：onDraw里不能new对象。因为onDraw在每次重绘时都会被调用，如果在这里频繁创建对象，会触发大量的GC，导致掉帧。正确的做法是把画笔、Paint、Rect等对象在初始化时创建好，onDraw里只做绘制逻辑。
关于绘制性能，还有一个实用技巧：用invalidate()只刷新局部区域。invalidate有一个重载方法invalidate(Rect dirty)，可以指定脏区域，系统只会重绘这一块，而不是整个View。这在绘制大面积内容时性能提升非常明显。
3. 实操过程与核心环节实现
理论说完，该上手了。我挑一个最具代表性的自定义View——支持进度显示和拖动的圆形进度控件，作为完整案例来走一遍。这个控件涵盖了测量、绘制、触摸事件处理、动画，以及状态管理，几乎所有核心知识点都能串起来。
3.1 实操准备：搭建自定义View的基础骨架
任何一个自定义View，都需要先做几件事：定义自定义属性、初始化画笔、构造必要的Rect或Path对象。这些内容虽然不涉及具体效果，但骨架不牢，后面全是坑。
先看属性定义。在res/values/attrs.xml里声明自定义属性：
<resources> <declare-styleable name="CircleProgressView"> <attr name="progress" format="integer" /> <attr name="progressColor" format="color" /> <attr name="trackColor" format="color" /> <attr name="strokeWidth" format="dimension" /> <attr name="showText" format="boolean" /> </declare-styleable> </resources>然后在构造函数里解析这些属性：
public CircleProgressView(Context context, AttributeSet attrs) { super(context, attrs); TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.CircleProgressView); progress = ta.getInt(R.styleable.CircleProgressView_progress, 0); progressColor = ta.getColor(R.styleable.CircleProgressView_progressColor, Color.BLUE); trackColor = ta.getColor(R.styleable.CircleProgressView_trackColor, Color.LTGRAY); strokeWidth = ta.getDimension(R.styleable.CircleProgressView_strokeWidth, dp2px(8)); showText = ta.getBoolean(R.styleable.CircleProgressView_showText, true); ta.recycle(); init(); }注意：
TypedArray用完之后一定要调用recycle()。早期版本不回收会有内存泄漏风险，虽然新版系统会自动处理，但保持这个习惯是个好工程素养。
init方法里只做对象的初始化：
private void init() { progressPaint = new Paint(Paint.ANTI_ALIAS_FLAG); progressPaint.setColor(progressColor); progressPaint.setStyle(Paint.Style.STROKE); progressPaint.setStrokeWidth(strokeWidth); progressPaint.setStrokeCap(Paint.Cap.ROUND); trackPaint = new Paint(Paint.ANTI_ALIAS_FLAG); trackPaint.setColor(trackColor); trackPaint.setStyle(Paint.Style.STROKE); trackPaint.setStrokeWidth(strokeWidth); textPaint = new Paint(Paint.ANTI_ALIAS_FLAG); textPaint.setTextSize(dp2px(20)); textPaint.setTextAlign(Paint.Align.CENTER); }这里有一个细节值得多说一句：Paint的所有配置都应该在init阶段完成，不要在onDraw里动态修改Paint的属性。因为每次修改Paint属性都可能触发内部的重新计算，放在onDraw里不仅浪费性能，还容易因为状态互相污染而产生奇怪的绘制问题。
3.2 测量与绘制：让圆环正确显示
接下来处理测量。圆环进度控件在一个理想情况下应该是一个正方形，宽高相等，因为圆环必须是正圆。所以onMeasure的逻辑是取宽高的较小值，然后保证最终测量结果是一个正方形：
@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int width = MeasureSpec.getSize(widthMeasureSpec); int height = MeasureSpec.getSize(heightMeasureSpec); int size = Math.min(width, height); setMeasuredDimension(size, size); }这个写法有个边界问题：如果父容器传的是wrap_content，MeasureSpec.getSize返回的是父容器的剩余空间，那这个控件就会直接占满整个剩余区域。为了处理这个问题，需要加上AT_MOST的判断：
@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthMode = MeasureSpec.getMode(widthMeasureSpec); int heightMode = MeasureSpec.getMode(heightMeasureSpec); int widthSize = MeasureSpec.getSize(widthMeasureSpec); int heightSize = MeasureSpec.getSize(heightMeasureSpec); int defaultSize = dp2px(100); int width = (widthMode == MeasureSpec.AT_MOST) ? Math.min(defaultSize, widthSize) : widthSize; int height = (heightMode == MeasureSpec.AT_MOST) ? Math.min(defaultSize, heightSize) : heightSize; int size = Math.min(width, height); setMeasuredDimension(size, size); }接下来是绘制。圆环的绘制逻辑很简单：先画底部的灰色轨道，再画上面有颜色的进度弧，最后根据开关决定是否画中间的文字：
@Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); float centerX = getWidth() / 2f; float centerY = getHeight() / 2f; float radius = (Math.min(getWidth(), getHeight()) - strokeWidth) / 2f; // 绘制轨道 canvas.drawCircle(centerX, centerY, radius, trackPaint); // 绘制进度弧 RectF arcRect = new RectF(centerX - radius, centerY - radius, centerX + radius, centerY + radius); canvas.drawArc(arcRect, -90, progress * 360f / maxProgress, false, progressPaint); // 绘制文字 if (showText) { String percentText = Math.round(progress * 100f / maxProgress) + "%"; float textY = centerY - (textPaint.ascent() + textPaint.descent()) / 2f; canvas.drawText(percentText, centerX, textY, textPaint); } }这里有三个值得说的点。第一，进度弧的起始角度我设成了-90度，也就是12点钟方向，这是Android的Canvas角度规则决定的——0度在3点钟方向，角度顺时针增加。第二，drawArc的进度是按比例映射到360度上的，所以需要计算progress * 360f / maxProgress。第三，文字垂直居中的公式centerY - (ascent() + descent())/2是标准写法，因为drawText的基准线在水平中线的下方，直接画在centerY上会导致文字偏下。
注意：RectF对象在onDraw里创建了。严格来说这不符合我前面说的"不要在onDraw里new对象"原则。如果你这个控件会在列表里频繁刷新，建议把RectF提为成员变量，在onDraw里复用。控件绘制频率很低的话，这里问题不大，但好习惯要养成。
3.3 触摸与动画：增加交互能力
静态的进度环没有实用价值，真实业务场景里通常需要用户拖动进度，或者用动画从旧值过渡到新值。先说触摸拖动。
要让进度环支持拖动，需要重写onTouchEvent，核心逻辑是：根据手指落点坐标计算角度，再把角度映射为进度值：
@Override public boolean onTouchEvent(MotionEvent event) { float x = event.getX(); float y = event.getY(); float centerX = getWidth() / 2f; float centerY = getHeight() / 2f; double angle = Math.toDegrees(Math.atan2(y - centerY, x - centerX)); angle = (angle + 90 + 360) % 360; // 调整为从12点钟方向开始 int newProgress = (int) (angle * maxProgress / 360f); setProgress(newProgress); return true; }这个算法里最核心的是Math.atan2(y - centerY, x - centerX)。atan2返回的角度范围是-180到180度，0度在3点钟方向；加上90度后变成-90到270度，相当于把起始点移到了12点钟方向；再对360取模，确保角度落在0到360之间。这样算出来的角度就能直接映射为进度值。
如果你希望用户只能滑到某个位置停下来而不是随手松开时乱跳，可以加上一个简单的touchSlop判断。这个在真实项目中经常用到，可以避免用户误触。
至于动画，最简单的做法是用ValueAnimator从当前进度动画到目标进度：
public void animateProgressTo(int targetProgress) { ValueAnimator animator = ValueAnimator.ofInt(progress, targetProgress); animator.setDuration(800); animator.setInterpolator(new DecelerateInterpolator()); animator.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() { @Override public void onAnimationUpdate(ValueAnimator animation) { setProgress((int) animation.getAnimatedValue()); } }); animator.start(); }每次setProgress里只需要调用invalidate()触发重绘即可。不要在这里直接调用onDraw——onDraw是系统回调，我们只负责在数据变化时通知系统"该重绘了"。
3.4 完整实例：一个带百分比显示的仪表盘控件
上面这些逻辑拼起来，就是一个基础版的圆形进度仪表盘。我把完整代码整理在下面，你可以直接拷贝运行看看效果：
public class CircleProgressView extends View { private Paint progressPaint; private Paint trackPaint; private Paint textPaint; private int progress = 0; private int maxProgress = 100; private boolean showText = true; private int progressColor; private int trackColor; private float strokeWidth; public CircleProgressView(Context context) { this(context, null); } public CircleProgressView(Context context, AttributeSet attrs) { super(context, attrs); initAttrs(context, attrs); initPaints(); } private void initAttrs(Context context, AttributeSet attrs) { // 解析自定义属性的逻辑 } private void initPaints() { // 初始化画笔的逻辑 } @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { // 保证正方形尺寸，处理wrap_content } @Override protected void onDraw(Canvas canvas) { // 绘制轨道、进度弧和文字 } @Override public boolean onTouchEvent(MotionEvent event) { // 处理拖动交互 } public void setProgress(int value) { progress = Math.max(0, Math.min(value, maxProgress)); invalidate(); } }这只是一个骨架，真正的业务控件还需要考虑更多边界：进度值越界保护、方向键或无障碍焦点支持、动画中断时的状态恢复、控件禁用状态下的交互限制等。这些看起来是细节，但往往是决定控件质量的关键。
4. 常见问题与排查技巧实录
这部分是我最想分享的。下面这些坑，每一个我都在实际项目里踩过，有些甚至困扰了我好几天才定位到根因。把它们整理成速查表，希望能帮你省下这些排查时间。
4.1 高频问题速查表
| 现象 | 根本原因 | 解决方法 |
|---|---|---|
| wrap_content和match_parent效果一样 | 没有重写onMeasure或没有处理AT_MOST模式 | 重写onMeasure，针对AT_MOST计算默认大小 |
| 绘制内容不显示 | 绘制区域超出View边界或Paint透明度为0 | 检查setWillNotDraw(false)是否调用，检查Canvas绘制坐标范围 |
| 文字位置总有偏差 | 忽略了drawText的基线机制 | 用ascent和descent计算垂直居中，不要直接在centerY绘制 |
| 点击事件没反应 | onTouchEvent返回了false | 确保onTouchEvent返回true，表示消费了事件 |
| 在ScrollView里滑动卡顿 | onTouchEvent里有耗时操作或onDraw里创建对象 | 将对象创建移到初始化阶段，使用invalidate(Rect)局部刷新 |
| 动画结束后进度回到原点 | 没有保持动画结束帧的状态 | 在动画结束时获取动画目标值并set进View |
这里重点说一下setWillNotDraw(false)这个坑。View默认有一个优化：如果onDraw没有被重写或者View被标记为不需要绘制，系统会跳过绘制流程以节省性能。当你继承ViewGroup或者自定义了一个只有绘制逻辑的View时，如果不显式调用setWillNotDraw(false)，onDraw可能根本不会执行。这个问题的隐蔽性在于代码编译运行都正常，但屏幕上就是什么都不出现。
4.2 自定义View性能优化实战记录
性能问题在自定义View里最常见的表现是滑动列表时的掉帧。有一次做一个嵌套在RecyclerView里的卡片式进度圆环，滑动时明显卡顿，用Profile GPU Rendering一看，帧渲染时间超过16ms的标准线很多。
排查过程分为三步：第一步，检查onDraw里是否创建了对象。果然，代码里在一个for循环中new了一个RectF，这会导致每帧绘制时都会产生大量临时对象，触发GC。把RectF提为成员变量后，卡顿明显改善。
第二步，检查invalidate的调用频率。原始代码在动画的每一帧里调用了整个View的invalidate()，由于View占据了屏幕很大一块区域，重绘代价很高。改成invalidate(Rect dirty)只刷新变化区域后，渲染压力又降了一截。
第三步，检查是否有不必要的绘制层级。圆环的背景是一个渐变层，但用户根本看不到效果，因为被进度条完全盖住了。删除这层渐变后，帧渲染时间降到了8ms以内，彻底解决了卡顿。
这次排查给我的经验是：自定义View的性能瓶颈通常不在绘制算法本身，而在对象分配、调用频率、重复绘制这三个点上。遇到卡顿不要急着优化算法，先检查这三个问题。
4.3 不同复杂度的自定义View方案与取舍
| 复杂度等级 | 适用场景 | 推荐方案 | 性能预期 |
|---|---|---|---|
| 低 | 圆角图片、有阴影的背景 | 用GradientDrawable或系统现成Drawable套一层 | 很好 |
| 中 | 进度条、标签组、状态切换控件 | 组合现有ViewGroup + 少量onDraw | 良好 |
| 高 | 图表、仪表盘、富文本图文混排 | 继承View，完整重写测量与绘制 | 需仔细优化 |
| 极高 | 复杂图形编辑器、地图标记层 | 继承ViewGroup，自定义布局与绘制 | 必须性能专项优化 |
我的经验是，能用低复杂度方案解决的，就绝对不要上高复杂度。这不仅是性能问题，更是维护成本的问题。一个组合控件出的bug，排查起来比一个从零绘制的控件容易得多。
5. 触摸事件分发机制：自定义View的核心进阶
很多自定义View做出来静态效果没问题，一加交互就乱套，根本原因是对事件分发机制理解不透。这一节把触摸事件分发讲清楚，这是自定义View从"会画"进阶到"能交互"的必经之路。
5.1 事件分发核心链条：dispatchTouchEvent与onTouchEvent
触摸事件的分发是一个从Activity到View的链条：Activity -> ViewGroup -> View。每一层的事件分发都通过dispatchTouchEvent入口，而具体消费事件则通过onTouchEvent完成。
理解这套机制的钥匙是三个方法的返回值：
- dispatchTouchEvent返回true，表示事件在本层被消费掉了，不再继续分发
- onInterceptTouchEvent返回true，表示父View要拦截这个事件，不再向下分发
- onTouchEvent返回true，表示本View消费了这个事件，不会再往上回传
实际的传递规则是：事件先由外到内分发（从Activity到最内层的View），如果最内层View不消费，事件再由内到外回溯（从最内层的View往父View传），直到找到一个能处理的层。这套机制保证了一个原则：先问子View要不要处理，子View不处理父View再来。
做一个自定义控件时，最常见的错误是：在ViewGroup的onInterceptTouchEvent里无条件返回true，导致内部的RecyclerView或ScrollView无法滑动。正确的做法是先判断事件类型，通常只在ACTION_MOVE且移动方向符合预期时才拦截，并且要同时考虑事件坐标和子View的位置关系。
5.2 滑动冲突的核心解法：内外部拦截法
滑动冲突经典到几乎是自定义View必考，但它有固定的套路。我这里分享实际项目中最常用的两个方案。
外部拦截法：在父View的onInterceptTouchEvent中做判断，如果父View需要处理这次滑动就拦截当前事件，否则就放行让子View处理。判断依据通常是事件的坐标差，比如手指横向移动距离大于纵向移动距离时，父View的横向滑动应该接管。
内部拦截法：把决定权交给子View。子View在onTouchEvent中根据情况决定是否消费事件，如果发现自己处理不了，就调用getParent().requestDisallowInterceptTouchEvent(false)，把事件还给父View。
两种方案没有绝对的优劣，但我的习惯是优先使用外部拦截法。原因是它思路清晰，控制权集中，调试方便。内部拦截法在处理比较复杂的嵌套结构时可能更灵活，但心智负担较大，出了问题也不容易定位。
5.3 实战建议：手势检测器的选型
在自定义View里实现复杂手势（双击、长按、快速滑动、捏合缩放）时，千万不要自己用坐标加时间戳去算，直接用系统提供的现成工具类。
单点手势用GestureDetector，它可以帮你识别单击、双击、长按、滑动等手势，内部已经做了防抖和阈值判断。多点触控用ScaleGestureDetector，它专门处理缩放手势，能帮你计算出缩放因子和焦点坐标。这两个类都只需要在onTouchEvent里把事件转发过去，然后在回调里做自己的逻辑就行。
注意：GestureDetector的onTouchEvent返回值并不代表事件是否被消费。如果你在使用GestureDetector时发现自己的onTouchEvent不触发，检查一下是不是在onTouchEvent入口处就返回了true，把后面的事件都截断了。
6. 动画与性能优化：让自定义View更流畅
自定义View如果只是静态展示，那学习门槛会低一半。实际项目里，动画和性能往往是决定控件体验的核心，也是拉开普通开发者和资深开发者差距的地方。
6.1 动画驱动方式对比与选型
做自定义View动画主要有三种方式：Property Animator（属性动画）、ViewPropertyAnimator（View属性动画）、以及通过Choreographer或监听Vsync手动驱动绘制。
属性动画适合常规的场景：改变进度值、旋转角度、透明度等。它是侵入性最低的方案，代码也很简洁，示例中的ValueAnimator就是其中一种。
ViewPropertyAnimator是View特有的便捷写法，适合同时改变多个View属性的场景：
view.animate() .alpha(0.5f) .rotation(45f) .scaleX(1.2f) .setDuration(300) .start();它比用ObjectAnimator逐个设置属性要高效，因为它在内部做了优化，同类属性会合并到同一帧去执行。
如果你需要精确控制每一帧的绘制内容（比如复杂粒子动画、逐帧手写动画），那就要用Choreographer或者自定义Runnable配合postOnAnimation。这种方式能够实现最精细的帧控制，但代码量大，逻辑复杂，除非必要，日常开发不用直接上这个级别。
6.2 绘制性能优化进阶：Layer与硬件加速
硬件加速是Android 3.0之后就默认开启的，但很多人并不知道它带来的能力和限制。开启硬件加速后，Canvas的某些操作（如drawPicture、clipPath的某些模式）可能会不支持或表现不同。
这里有一个我常用的优化技巧：当View带有复杂的分层绘制且经常透明度动画时，用View.setLayerType(View.LAYER_TYPE_HARDWARE, null)把View渲染到一个离屏缓冲，动画时直接操作这个缓冲图层，这样透明度动画不会反复触发整个绘制流程，性能会好很多。但要注意，LAYER_TYPE_HARDWARE会占用额外的GPU内存，使用完或动画结束后，要记得调用setLayerType(View.LAYER_TYPE_NONE, null)恢复。
还有一个原则：能走Drawable的动画就尽量用Drawable的动画，不要每次都重写onDraw画一个新帧。比如圆角矩形的变化、颜色的过渡，Drawable自身有比较好的优化。在onDraw里更新复杂Path的性能损耗，往往比预先缓存Bitmap再贴图高一个数量级。
6.3 布局与绘制的性能指标拆解
对于重度使用自定义View的项目，我在交付前有一套自己的性能检查清单：
- 用
Layout Inspector检查View层级深度，层级超过5层的嵌套布局要重点警惕 - 用
Profile GPU Rendering检查渲染时长，确保核心场景在16ms以内 - 用
Systrace追踪掉帧原因，区分是measure耗时还是draw耗时 - 检查onDraw和onMeasure里的对象分配，确保没有高频GC
- 检查动画执行期间是否有多余的requestLayout
这五个检查点基本能覆盖绝大多数自定义View的性能问题。其中检查object分配最简单的方法是在Android Studio的Memory Profiler里观察内存分配折线，正常情况下动画执行期间不应该出现频繁的锯齿状波动。
7. 学习路径与实战经验
最后聊点实在的：怎么从这篇指南继续深入，以及我在实际项目中积累的一些心得。
7.1 从入门到精通的进阶路线
如果你是完全的新手，我建议的学习顺序是：先照着网上现成的案例抄几个简单的自定义View，比如进度条、圆环、标签云，跑通了再回头读这篇指南里的原理部分，然后自己动手改功能、加逻辑。
第二个阶段是模仿系统控件的实现，没事的时候就翻翻Android源码里的View子类，比如TextView、ImageView、ViewPager的源码。这些源码是Google工程师写的，代码质量和注释都很好，从中能学到很多工程实践：状态管理、测量策略、绘制缓存、事件分发边界处理。我当年就是从阅读ViewPager的源码中理解了ViewGroup的布局策略。
第三个阶段就是自己设计控件了。从需求分析开始，画出视觉稿和交互稿，然后拆解成测量、布局、绘制、触摸处理四个模块，逐个实现，最后做性能和兼容性测试。走完这个流程，你的自定义View水平基本就到了一定级别。
7.2 项目落地时的工程化建议
自定义View不是玩具，它是要进生产环境的。在项目落地时，我特别强调几件事。
第一，自定义属性的设计要有规划。属性的命名和使用方式要跟系统控件保持一致性，比如颜色用color类型、尺寸用dimension类型、开关用boolean类型。同时属性的默认值必须有合理的兜底策略，防止XML配置遗漏导致空指针或绘制异常。
第二，状态恢复要做全。自定义View里如果有进度、选中状态等可变数据，要重写onSaveInstanceState和onRestoreInstanceState，否则屏幕旋转后视图状态就会丢失。这个小细节经常被忽略，但一旦遇到问题，用户体感很差。
第三，合理使用clipChildren和clipToPadding。这两个属性常用来控制ViewGroup的子View是否可以被裁剪出边界。用好了能实现很多高级布局效果，用错了则可能引发莫名其妙的绘制异常。调试这类问题的时候，第一反应应该是检查父ViewGroup的这两个属性设置。
第四，如果控件要在多个页面复用，建议写成独立的module并附带demo页面。这能帮你把控件的使用成本降到最低，也更容易沉淀成团队的基础组件。
7.3 避坑心得与个人总结
写完这么多，最后聊点我个人的体会。自定义View确实能带来很大的成就感和技术成长，但也要务实地认识到：它只是解决问题的工具，不是炫技的舞台。
能用系统控件解决的，就不要自定义。能用组合解决的，就不要从零绘制。很多时候，一个复杂的自定义View在后续维护时，会成为一个团队的知识盲区——新增需求的人不敢动，排查bug的人无从下手。这其实是比性能问题更隐蔽的成本。
但反过来说，一旦你真的需要自定义View时，前面这些基础打不打得牢，就决定了你能不能在有限的项目周期内交付一个稳定的控件。测量、布局、绘制、事件分发、动画、性能优化，每一个环节都可以往深了挖，而它们之间又是相互联动的。
我见过太多人学自定义View时只盯着onDraw里的绘制代码，进度图画得越来越炫，但遇到尺寸适配就懵，遇到触摸冲突就抓狂。这不是因为能力不行，而是知识体系缺了环。把这篇文章里的知识串起来，形成自己的完整认知框架，再上手实际项目，你很快就能体会到那种"一眼看穿本质"的感觉。
