1. 为什么值得把 Path 的这几个方法吃透做 Android 自定义 View 的朋友大概都有过这种体验拿到设计稿看着一条曲线挺简单真到onDraw里下手moveTo、lineTo、quadTo、cubicTo、arcTo五个方法摆在那儿一时不知道从哪个开始写。更尴尬的是写出来了形状也差不多但拐角发虚、弧线接不上、动画跑起来一顿一顿的。这类问题十有八九不是画笔的问题而是 Path 的构建逻辑没理顺。这篇内容就围绕这五个方法展开讲清楚它们各自负责什么、参数怎么算、什么场景该用哪个、组合起来怎么画出一条顺滑的路径。适合已经能写基础自定义 View、但一遇到曲线和圆弧就发怵的开发者也适合刚接触Path不久、想系统把这块补齐的新手。文中所有示例都是模拟项目里的通用写法不绑定任何具体业务你可以直接拿去改。先把结论摆前面moveTo是抬笔定位lineTo是画直线quadTo是画一段二次贝塞尔曲线一个控制点cubicTo是画一段三次贝塞尔曲线两个控制点arcTo是往路径里追加一段椭圆弧。五个方法本质上都在做同一件事——往Path对象里追加几何片段区别只在于片段的形状和参数表达方式。理解了这一点后面所有的组合技巧都是水到渠成。我在实际项目里踩过最多的坑是把arcTo的两个重载混着用结果路径莫名其妙多出一条连线其次是quadTo的控制点凭感觉给曲线形状完全不受控。这些问题在后面章节会逐个拆开讲先把每个方法的脾气摸清楚。2. 五个方法的核心定位与参数拆解2.1 moveTo 与 lineTo路径的起点与直线骨架moveTo(float x, float y)的作用是设置下一个片段的起始点它本身不产生任何可见图形相当于把画笔“抬起来”挪到新位置。lineTo(float x, float y)则是从当前点画一条直线到目标点画完之后当前点自动更新为目标点。这两个方法看着简单但有一个细节很多人没注意Path 的第一个片段如果是lineTo它会默认从(0,0)开始画。也就是说如果你不先moveTo第一条线会从画布左上角拉过来屏幕上就多出一条莫名其妙的斜线。这个现象在调试时特别容易让人抓狂因为代码逻辑看起来完全没问题。Path path new Path(); // 错误示范没有 moveTo第一条线从 (0,0) 拉过来 path.lineTo(200, 200); // 正确写法先定位起点 path.moveTo(100, 100); path.lineTo(200, 200);moveTo还有一个容易被忽略的用途在同一条 Path 里画多个不连续的图形。比如你要画两个分开的矩形不需要建两个 Path中间moveTo一下就行。这在做图标、做多段折线图的时候很实用能减少对象创建。Path path new Path(); // 第一个矩形 path.moveTo(50, 50); path.lineTo(150, 50); path.lineTo(150, 150); path.lineTo(50, 150); path.close(); // 抬笔画第二个矩形 path.moveTo(200, 50); path.lineTo(300, 50); path.lineTo(300, 150); path.lineTo(200, 150); path.close();这里顺带提一下close()。它会把当前点连回该子路径的起点形成一个闭合图形。画填充色的时候闭合与否直接影响填充结果——不闭合的路径填充时系统会隐式补一条线回来但描边时那条线是不画的。所以画封闭图形close()该加就加别省。2.2 quadTo一个控制点撑起的二次曲线quadTo(float x1, float y1, float x2, float y2)画的是二次贝塞尔曲线。参数里(x1, y1)是控制点(x2, y2)是终点起点就是当前点。曲线从起点出发被控制点“拽”向它所在的方向但不会真正经过控制点最后落到终点。理解二次贝塞尔的关键在于那个控制点。你可以把它想象成一根橡皮筋起点和终点是钉在墙上的两颗钉子控制点是你的手指勾住橡皮筋中间往外拉的位置。手指拉得越远曲线鼓得越厉害手指位置偏左曲线就往左弯。数学上二次贝塞尔的点坐标是这么算的t 从 0 到 1B(t) (1-t)² · P0 2(1-t)t · P1 t² · P2其中 P0 是起点P1 是控制点P2 是终点。这个公式不用背但知道它存在有好处当你想精确控制曲线在某个 t 值处的弯曲程度时可以反推控制点位置。实际开发中更常用的是经验法——控制点大致放在起点和终点连线的中垂线方向上距离取弦长的 0.5 到 1 倍之间形状比较自然。Path path new Path(); path.moveTo(100, 300); // 起点 path.quadTo(250, 100, 400, 300); // 控制点(250,100)终点(400,300)这段代码画出来是一条开口向下的拱形曲线顶点大概在(250, 200)附近。注意顶点不在控制点上控制点在(250, 100)曲线最高只到y200左右。这个“控制点不等于曲线经过点”的认知差是新手画曲线时最常见的困惑来源。2.3 cubicTo两个控制点带来的自由度cubicTo(float x1, float y1, float x2, float y2, float x3, float y3)是三次贝塞尔曲线两个控制点(x1,y1)和(x2,y2)终点(x3,y3)。相比二次曲线它多了一个控制点意味着曲线两端可以各自拥有独立的切线方向。这个差别在实际画图时很关键。二次贝塞尔曲线在起点和终点处的切线方向分别由“起点到控制点”和“控制点到终点”决定两端是耦合的——你调控制点位置两端的弯曲会同时变化。三次贝塞尔则解耦了第一个控制点管起点方向的切线第二个控制点管终点方向的切线互不干扰。Path path new Path(); path.moveTo(100, 400); // 控制点1(150,100) 控制点2(350,700) 终点(400,400) path.cubicTo(150, 100, 350, 700, 400, 400);这段代码画出来是一条 S 形曲线从(100,400)出发先向上翘中途拐下来最后从下方进入(400,400)。两个控制点一上一下曲线就呈现出这种波浪感。如果换成quadTo无论控制点放哪儿都画不出这种两端切线方向相反的 S 形。三次贝塞尔的公式是B(t) (1-t)³ · P0 3(1-t)²t · P1 3(1-t)t² · P2 t³ · P3同样不用背但要知道它的一个实用性质当两个控制点分别位于起点和终点附近、且方向与期望的切线一致时曲线最平滑。做路径动画、画平滑折线图的时候这个性质就是控制点取值的依据。2.4 arcTo椭圆弧的两种接入方式arcTo有两个重载这是最容易出问题的地方必须分开说。第一个重载arcTo(float left, float top, float right, float bottom, float startAngle, float sweepAngle, boolean forceMoveTo)它在一个由left, top, right, bottom确定的椭圆内切于这个矩形上从startAngle开始扫过sweepAngle度把这段弧追加到路径里。角度单位是度0 度指向三点钟方向顺时针为正。第二个重载arcTo(RectF oval, float startAngle, float sweepAngle, boolean forceMoveTo)参数含义一样只是椭圆用RectF表达。关键就在最后那个forceMoveTo布尔值。它的行为差异如下表forceMoveTo行为true弧的起点作为新的当前点弧之前不连线相当于先moveTo到弧起点再画弧false如果路径已有当前点会先从当前点画一条直线到弧起点再画弧这个差异在实际效果上非常明显。假设你先moveTo(100,100)然后arcTo一个从别处开始的弧forceMoveTo true路径里只有那段弧(100,100)到弧起点之间没有线。forceMoveTo false路径里多出一条从(100,100)到弧起点的直线然后才是弧。很多“弧线旁边莫名多一条斜线”的 bug根源就是这里传了false却没意识到会连线。我的习惯是除非明确需要那条连接线比如画圆角矩形的连续轮廓否则一律传true。Path path new Path(); RectF oval new RectF(100, 100, 300, 300); // 从 0 度开始扫 90 度不连线 path.arcTo(oval, 0, 90, true);这段代码画的是椭圆右下四分之一段弧0 度在右侧中点顺时针扫 90 度到下方中点。2.5 五个方法的能力对照把五个方法放在一张表里对比选型时一目了然方法片段类型控制点数量是否经过控制点典型场景moveTo无定位0不适用设置起点、分隔子路径lineTo直线0不适用折线、多边形、矩形边框quadTo二次曲线1否单峰拱形、简单波浪、聊天气泡尾巴cubicTo三次曲线2否S 形曲线、平滑折线、路径动画arcTo椭圆弧0用角度描述不适用圆角、扇形、环形进度选型的基本逻辑是能用直线就别用曲线能用二次就别用三次能用弧就别用贝塞尔拟合。原因很实在——直线计算最省二次曲线比三次少一个控制点的调参成本而arcTo画标准圆弧比用贝塞尔逼近更精确系统内部对弧的渲染也有优化。3. 组合使用的实操流程与关键细节3.1 从零构建一条复合路径的完整步骤光看单个方法不够真实场景里几乎都是组合使用。我拿一个模拟项目里的“带尾巴的圆角气泡”举例把完整构建流程走一遍。这个图形包含圆角矩形主体加一个三角尾巴正好把moveTo、lineTo、arcTo都用上。第一步确定整体尺寸和圆角半径。假设气泡宽 300、高 120圆角半径 20尾巴在底部中间偏右宽 40、高 30。第二步规划路径走向。从左上角圆角的起点开始顺时针绕一圈上边直线、右上圆角、右边直线、右下圆角、底边直线到尾巴起点、尾巴两条斜线、底边直线尾巴之后、左下圆角、左边直线、左上圆角闭合。第三步把每个片段翻译成对应方法。圆角部分用arcTo直线部分用lineTo起点用moveTo。float left 50, top 50, right 350, bottom 170; float r 20; float tailStartX 220, tailEndX 260, tailTipY 200; Path path new Path(); // 左上圆角起点从左边 r 处开始 path.moveTo(left, top r); // 左上圆角从 180 度扫到 270 度 path.arcTo(new RectF(left, top, left 2*r, top 2*r), 180, 90, false); // 上边直线 path.lineTo(right - r, top); // 右上圆角270 到 360 path.arcTo(new RectF(right - 2*r, top, right, top 2*r), 270, 90, false); // 右边直线 path.lineTo(right, bottom - r); // 右下圆角0 到 90 path.arcTo(new RectF(right - 2*r, bottom - 2*r, right, bottom), 0, 90, false); // 底边到尾巴起点 path.lineTo(tailEndX, bottom); // 尾巴 path.lineTo((tailStartX tailEndX) / 2f, tailTipY); path.lineTo(tailStartX, bottom); // 底边继续到左下圆角 path.lineTo(left r, bottom); // 左下圆角90 到 180 path.arcTo(new RectF(left, bottom - 2*r, left 2*r, bottom), 90, 90, false); // 左边直线回到起点 path.lineTo(left, top r); path.close();这段代码里arcTo全部传false因为我们要的是连续轮廓圆角之间本来就有直线连接false让弧起点和当前点自然衔接。如果这里传true每个圆角都会断开轮廓就碎了。这就是前面说的“什么时候该传 false”的典型场景——画连续闭合轮廓时传 false画独立弧段时传 true。3.2 圆角矩形的角度计算过程上面代码里每个arcTo的起始角度和扫描角度不是随便写的有明确的推导逻辑。以左上圆角为例这个圆角的圆心在(left r, top r)我们要画的弧是从圆的左侧中点180 度方向到上方中点270 度方向顺时针扫 90 度。所以startAngle 180sweepAngle 90。四个圆角的角度对应关系整理如下圆角位置圆心起始角度扫描角度左上(leftr, topr)18090右上(right-r, topr)27090右下(right-r, bottom-r)090左下(leftr, bottom-r)9090这里有个容易算错的地方arcTo的椭圆矩形参数是外接矩形不是圆心加半径。左上圆角的外接矩形是(left, top, left2r, top2r)宽高都是2r内切出来的圆半径才是r。我见过有人直接把(left, top, leftr, topr)传进去结果圆角只有预期的一半大排查半天才发现是矩形尺寸给错了。提示arcTo的矩形参数是椭圆的外接矩形宽高是直径而非半径。圆角半径 r 对应的外接矩形宽高都是 2r。3.3 用 quadTo 和 cubicTo 画平滑折线图折线图是另一个高频场景。原始数据点直接lineTo连起来是硬邦邦的折线要做成平滑曲线就得在相邻点之间插入贝塞尔片段。这里有个经典做法用相邻两点的中点作为曲线端点原始数据点作为控制点。float[] xs {50, 120, 200, 280, 350}; float[] ys {300, 150, 250, 100, 200}; Path path new Path(); path.moveTo(xs[0], ys[0]); for (int i 1; i xs.length - 1; i) { float midX (xs[i] xs[i 1]) / 2f; float midY (ys[i] ys[i 1]) / 2f; path.quadTo(xs[i], ys[i], midX, midY); } // 最后一段连到终点 path.lineTo(xs[xs.length - 1], ys[xs.length - 1]);这个写法的原理是每段二次曲线以数据点为控制点、以中点为终点曲线在数据点附近被“拽”过去但真正落点在中点于是相邻两段在中点处自然衔接整体看起来就是一条穿过数据点附近的平滑曲线。它不保证曲线精确经过每个数据点但视觉上足够顺计算量也小。如果要求曲线必须精确经过每个数据点那就得用三次贝塞尔配合切线计算控制点位置由前后点的斜率推导。这套算法在图表库里很常见核心是根据每个点的前后邻居算出切线方向然后沿切线方向取 1/3 弦长作为控制点偏移。实现起来代码量翻倍但曲线质量更高。我的建议是普通展示型图表用中点法足够需要精确贴合数据语义的场景再上三次贝塞尔。3.4 路径方向与填充规则的影响组合路径时还有一个隐性因素子路径的绘制方向。Path默认使用FillType.WINDING填充规则它根据路径环绕方向判断某个区域是否在内部。如果两个子路径方向相同重叠区域算内部方向相反重叠区域可能被挖空。这个特性在做环形、镂空图形时是利器。比如画一个圆环外圆顺时针、内圆逆时针中间就自动镂空不需要用两个 Path 做裁剪。Path ring new Path(); ring.addCircle(200, 200, 100, Path.Direction.CW); // 外圆顺时针 ring.addCircle(200, 200, 60, Path.Direction.CCW); // 内圆逆时针 // 直接填充就是一个圆环arcTo的扫描角度正负也影响方向正角度顺时针负角度逆时针。做镂空效果时把内圈的sweepAngle取负值方向就反过来了。这个技巧比用Path.Op做布尔运算轻量渲染开销更小。4. 常见问题排查与避坑实录4.1 弧线旁边多出一条直线这是arcTo最高频的问题前面提过这里给完整的排查路径。现象是明明只想画一段弧结果弧的起点和路径之前的某个点之间多了一条直线。排查顺序检查arcTo最后一个参数是不是false。如果是且路径已有当前点系统必然连线。如果确实需要false连续轮廓场景检查当前点是否就是弧起点。不是的话先moveTo到弧起点或者调整前一个片段让当前点落在弧起点上。检查弧的起始角度算得对不对。角度错了弧起点位置就错连线看起来就像“从奇怪的地方拉过来”。速查表现象可能原因解决弧前多一条斜线forceMoveTo传了 false 且当前点不在弧起点改传 true或先 moveTo 到弧起点弧的形状不对、位置偏移外接矩形参数给成了半径尺寸矩形宽高改为 2r弧的方向反了sweepAngle正负号错顺时针为正逆时针为负弧画不出来起始角度和扫描角度组合超出预期打印角度值核对0 度在三点钟方向4.2 贝塞尔曲线形状不受控quadTo和cubicTo的控制点凭感觉给是另一个常见痛点。画出来的曲线要么太鼓要么太扁反复调参调半天。我的经验是建立一个参照系控制点到弦起点终点连线的垂直距离决定了曲线的最大偏移量。二次贝塞尔曲线在 t0.5 处的偏移量正好是控制点到弦垂直距离的一半。也就是说如果你希望曲线在中点处偏离弦 30 像素控制点就要放在偏离弦 60 像素的位置。三次贝塞尔稍微复杂t0.5 处的偏移量约等于两个控制点偏移量的平均值乘以 0.75。实际调参时先按“期望偏移量 ÷ 0.75”估算控制点偏移再微调比盲试快得多。还有一个实用技巧画对称曲线时两个控制点关于弦的中垂线对称布置。这样曲线在 t0.5 处达到极值形状最规整。画不对称曲线比如 S 形时两个控制点分居弦两侧各自控制一端的弯曲方向。4.3 路径动画卡顿与重置问题用Path做动画比如路径绘制动画、沿路径运动常见问题是卡顿和状态残留。卡顿多半是因为在onDraw里反复new Path()或者反复构建路径。Path对象的构建涉及大量浮点运算和内存分配每帧重建会触发 GC帧率就掉下来了。正确做法是在构造阶段建好 Path动画过程中只改PathMeasure的截取比例或者用reset()复用对象。// 错误每帧重建 Override protected void onDraw(Canvas canvas) { Path p new Path(); p.moveTo(...); // ... } // 正确复用成员变量 private final Path path new Path(); Override protected void onDraw(Canvas canvas) { // 直接使用已构建好的 path }状态残留则是reset()和rewind()的区别没搞清楚。reset()清空所有片段和填充类型设置rewind()只清空片段但保留填充类型等配置。做路径动画循环播放时用rewind()更合适省去重新设置FillType的开销。注意Path不是线程安全的别在子线程里构建路径然后丢给主线程绘制容易出诡异问题。构建和绘制放在同一线程。4.4 浮点精度导致的接缝组合大量弧和曲线时偶尔会看到接缝处有 1 像素左右的缝隙或重叠。这通常是浮点精度累积误差导致的——每个片段的终点坐标经过多次三角函数计算和下一个片段的起点对不齐。解决办法有两个一是尽量用整数或简单小数作为关键坐标减少计算链长度二是在接缝处用lineTo显式补一小段把当前点“拉”到精确位置。后者虽然多一个片段但能保证视觉上无缝。// 弧画完后当前点可能有微小误差 path.arcTo(oval, 0, 90, false); // 显式对齐到精确坐标 path.lineTo(exactX, exactY);这个技巧在画复杂图标时特别管用尤其是多个圆角、弧线拼接的图形。多写一行lineTo省下半小时找缝隙。4.5 硬件加速下的路径限制开启硬件加速后Path的某些操作行为会变化。比如Path包含大量片段时硬件加速可能把它拆分成多个纹理导致渲染结果和软件渲染不一致。另外Path的setFillType在某些旧版本上对复杂路径的支持不完整。排查这类问题的思路是先在AndroidManifest里对目标 View 关闭硬件加速看问题是否消失。如果消失了说明是硬件加速的兼容性问题再针对性处理——要么简化路径复杂度要么对该 View 单独关闭硬件加速。View android:layerTypesoftware ... /这个属性只对特定 View 生效不影响全局是排查路径渲染问题的常用手段。5. 参数计算与选型的经验沉淀5.1 控制点位置的快速估算方法前面讲了控制点偏移量的估算这里给一个更完整的操作流程方便直接套用。画二次曲线时假设起点 P0、终点 P2期望曲线在中间偏离弦的最大距离为 d算出弦的中点 M。算出弦的单位法向量 n垂直于 P0P2 方向。控制点 P1 M n × (2d)。这个公式来自二次贝塞尔 t0.5 处偏移量为控制点偏移量一半的性质。代入后曲线中点正好偏离弦 d符合预期。画三次曲线时假设期望中间偏移 d两个控制点对称布置弦中点 M单位法向量 n。控制点 P1 P0 (P2-P0)/3 n × (d/0.75)。控制点 P2 P0 2(P2-P0)/3 n × (d/0.75)。这套估算在实际调参时能省掉大量试错。我一般先用它算出初始值再根据视觉效果微调 10% 到 20%基本两三次就能定稿。5.2 弧与贝塞尔的选型边界什么时候用arcTo什么时候用贝塞尔拟合弧这个问题值得单独说。arcTo画的是真正的椭圆弧数学上精确渲染时系统有专门优化适合标准圆弧、圆角、扇形、环形进度。缺点是参数用角度描述做非标准形状时不够灵活。贝塞尔拟合弧的优势是灵活——你可以用任意控制点画出近似弧形的曲线方便和其他曲线片段平滑衔接。缺点是拟合有误差一段 90 度弧用三次贝塞尔拟合最大误差约 0.027% 半径视觉上完全看不出来但数学上不精确。选型原则标准圆弧用arcTo需要和贝塞尔曲线平滑衔接的弧用贝塞尔拟合。比如画一个圆角矩形四个角是标准圆弧用arcTo但如果这个圆角要和一条波浪线平滑连接连接处的过渡弧用贝塞尔拟合更自然因为切线方向可以精确控制。5.3 路径复杂度与性能的平衡Path的片段数量直接影响渲染性能。一条包含几百个lineTo的路径在低端设备上绘制时可能掉帧。优化思路有几个层次第一层减少不必要的片段。能用addRect、addRoundRect这类批量方法就别手动lineTo拼系统内部有优化。第二层合并共线片段。连续多个lineTo如果方向一致合并成一个减少片段数。第三层用Path.Op做布尔运算替代手动拼接。两个图形求并集、交集用op()方法比手动算轮廓点简单且高效。第四层缓存渲染结果。静态路径可以渲染到Bitmap缓存每帧直接贴图避免重复构建和光栅化。实测下来一个包含 50 个以内片段的路径性能开销可以忽略超过 200 个片段在低端机上就要留意了超过 500 个基本要考虑缓存方案。这个数字不是绝对的和路径的填充面积、是否描边、画笔复杂度都有关但可以作为粗略的警戒线。5.4 调试路径的实用手段路径画得不对光看代码很难定位。几个实用的调试手段一是用Paint的STROKE模式把路径描出来同时用不同颜色标记起点和终点。起点画个小圆终点画个叉一眼就能看出路径走向对不对。二是分段绘制。把复合路径拆成单个片段每个片段用不同颜色画看哪一段出了问题。这个方法在排查弧线角度错误时特别有效。三是用PathMeasure打印路径长度和关键点坐标。PathMeasure能沿着路径采样任意位置的坐标和切线把采样点打印出来和预期值对比误差一目了然。PathMeasure pm new PathMeasure(path, false); float len pm.getLength(); float[] pos new float[2]; for (float d 0; d len; d len / 10) { pm.getPosTan(d, pos, null); // 打印 pos[0], pos[1] 核对 }这套组合拳下来绝大多数路径问题都能快速定位。我个人的习惯是只要路径超过三个片段就先描边看走向确认无误再上填充和动画能省掉大量返工。6. 写在最后的几句实操体会这五个方法单独看都不复杂难的是组合时的衔接和参数控制。我自己的经验是先把每个方法的“当前点”变化规律在纸上画一遍搞清楚每次调用后画笔停在哪里再动手写代码比边写边试快得多。尤其是arcTo的forceMoveTo参数理解它和当前点的关系能避开一大半的连线 bug。另一个体会是贝塞尔曲线的控制点不要凭感觉给。先用估算公式算出初始值再微调效率比盲试高一个数量级。曲线画多了会有手感但手感建立在理解了参数和形状的对应关系之上否则只是碰运气。最后分享一个小习惯每写完一段路径代码立刻用描边模式跑一遍确认走向和接缝再继续往下写。路径问题越早发现越好改等整个图形拼完再回头找成本翻倍。这个习惯帮我省下的调试时间比任何技巧都多。
