前阵子接了个终端项目首页需要一个带刻度的速度码表既要实时显示当前速度又要有那种指针缓慢抬起的机械感。我第一时间想到的是搜现成库但找了一圈都不太合胃口要么样式没法精确控制要么引入一堆用不上的依赖要么在低版本设备上表现拉胯。最后决定用Kotlin自己写一个Android自定义View把码表从里到外画一遍。这篇文章就是那次动手实践的完整记录从刻度绘制、指针动画到触摸旋拨和性能调优全部都是可以直接拿来改的实战思路。适合正在学自定义View、对Canvas绘制有兴趣或者项目里刚好需要仪表盘类组件的读者。我很清楚自定义View的教程一抓一大把但真正把“码表”这个完整组件从头讲到尾的并不多。多数文章只教你画一个圆或者一条刻度线离能落地还有很长距离。所以这篇不玩虚的直接按照我做真实项目的顺序来写先拆绘制需求再讲静态盘面怎么一笔一笔画然后让指针动起来再加上手指旋拨最后是调优和踩坑记录。1. 码表的绘制画像动手前先想清楚要画什么很多人在自定义View上栽跟头不是代码写得不对而是动手前根本没想过这个View到底由哪些绘制单元组成。码表这东西一眼看过去好像复杂但拆开之后其实非常标准。1.1 从外观拆解码表其实只有六层我习惯把码表的视觉元素按绘制前后顺序列出来外圈底盘整个表盘的背景通常是深色圆形可能带渐变或阴影效果刻度环贴着外圈的一圈刻度线分为主刻度和次刻度数值文字与主刻度对应的标签比如0、20、40、60……160指针从圆心伸出的三角形或细长指针指向当前值中心轴指针根部盖住的一个小圆用来遮挡指针底部的交叉线条数字显示区可选有些码表中心会放一个较大的数字直接显示当前值这六层里前两层是静态的指针层是动态的中心轴和数字区可以根据需求决定要不要做。分层清楚之后写起来就不会东一榔头西一棒子。1.2 为什么码表值得用自定义View而不是控件堆叠有人会问用View叠加或图片素材也能拼一个码表吧确实能比如网上买一套表盘切图再叠加一个旋转的ImageView。但这种方式有几个硬伤切图在不同屏幕密度下要准备多套资源指针角度必须靠动画和旋转矩阵控制数值文字更是没法动态变化。码表这种强交互、强绘制、强动画的组件天生就适合走Canvas绘制这条路。用自定义View写码表还有一个额外的好处整个绘制逻辑可以封装成一个独立的组件暴露setValue()、start()、reset()这类方法业务层只需要传数值完全不关心内部是怎么画出来的。我在某个跨平台系统的终端页面里就是这样接的后面维护起来非常省心。1.3 坐标系和角度约定把所有角度的说法统一这是新手最容易崩的地方。Android的Canvas坐标系x轴向右y轴向下。角度规定是0度在3点钟方向带方向的角度值顺时针增大。也就是说90度在正下方180度在正左方270度在正上方回到360度又指向右侧。很多人在画刻度时直接套用数学课本的sin/cos结果刻度从顶部开始转画出来整个表盘都是歪的。原因就是没把Canvas的角度方向和弧度单位捋清楚。我自己定了一套统一的约定表盘起始角135度也就是7点半方向扫过角度270度顺时针画到45度方向收尾数值范围0到160和速度表习惯保持一致所有三角函数计算前先把角度转成弧度之所以从135度开始是因为码表通常在左下角起笔、右下角收笔下方留出一个对称的缺口整体视觉最稳定。这套约定贯穿全文后面所有代码都基于它展开。换算公式也简单屏幕上某个半径上的点坐标就是cx radius * cos(rad)、cy radius * sin(rad)因为Canvas的y轴向下数学上的逆时针正方向和视觉上的顺时针刚好对应上直接用就行。2. 静态盘面把刻度、数值和表圈一笔一笔画出来静态盘面是整个码表的地基。这部分没画好后面动画做得再花哨也没用。我一般先把静态层跑通再考虑指针和交互。2.1 先做onMeasure给wrap_content一条活路自定义View如果不重写onMeasure你在布局里写wrap_content会得到和match_parent一样的效果因为默认的measure直接用了父布局给的尺寸。码表正常情况下应该是正方形但也不能完全不理会父布局的约束。我用的是最简单直接的方案先算出一个默认尺寸再根据MeasureSpec模式决定最终值。override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) { val defaultSize dp(240f).toInt() val width resolveDefaultSize(defaultSize, widthMeasureSpec) val height resolveDefaultSize(defaultSize, heightMeasureSpec) val size minOf(width, height) setMeasuredDimension(size, size) } private fun resolveDefaultSize(defaultSize: Int, measureSpec: Int): Int { return when (MeasureSpec.getMode(measureSpec)) { MeasureSpec.EXACTLY - MeasureSpec.getSize(measureSpec) MeasureSpec.AT_MOST - minOf(MeasureSpec.getSize(measureSpec), defaultSize) else - defaultSize } }AT_MOST对应的就是wrap_content场景这时取父布局给的上限和默认尺寸里较小的那个EXACTLY对应固定尺寸或match_parent直接听从父布局。宽高取较小值保证正方形中心点和半径都在onSizeChanged里拿到。有一点要注意onMeasure在布局过程中可能被调用多次真正稳定的宽高是onSizeChanged里的参数。中心坐标和半径这些字段放在onSizeChanged里更新最稳妥。2.2 画外圈底盘与刻度环底盘我用的是深色圆形填充再加一圈浅色描边。为了让表盘有点质感可以给背景圆加一个从深灰到黑的径向渐变。注意渐变半径要和View尺寸绑定不能用固定像素值。底盘代码看起来大概是这样的private fun drawFace(canvas: Canvas) { val bgRect RectF(0f, 0f, width.toFloat(), height.toFloat()) val shader RadialGradient( centerX, centerY, radius, intArrayOf(faceInnerColor, faceOuterColor), null, Shader.TileMode.CLAMP ) facePaint.shader shader canvas.drawCircle(centerX, centerY, radius, facePaint) ringPaint.style Paint.Style.STROKE ringPaint.strokeWidth dp(3f) canvas.drawCircle(centerX, centerY, radius - dp(2f), ringPaint) }这段要注意的是RadialGradient的坐标必须相对当前View在onDraw里临时创建没问题但如果是静态层我更推荐把整个盘面画到离屏Bitmap上这个留到第5章细说。2.3 画刻度一次循环把所有刻度线都搞定刻度的核心是循环遍历数值范围把每个刻度对应的角度算出来然后从半径内侧的一点画到外侧的一点。我设定了每4个单位一个小刻度每20个单位一个主刻度主刻度比次刻度长且粗。用step 4遍历0到160之前每次根据当前值计算比例再换算角度private fun drawTicks(canvas: Canvas) { val tickStep 4 for (value in minValue..maxValue step tickStep) { val fraction value.toFloat() / maxValue val angle startAngle sweepAngle * fraction val rad Math.toRadians(angle.toDouble()) val cosA cos(rad).toFloat() val sinA sin(rad).toFloat() val isMajor value % 20 0 val innerRadius radius - if (isMajor) dp(22f) else dp(14f) val outerRadius radius - dp(6f) canvas.drawLine( centerX innerRadius * cosA, centerY innerRadius * sinA, centerX outerRadius * cosA, centerY outerRadius * sinA, if (isMajor) majorTickPaint else minorTickPaint ) } }这套画法没有用canvas.save()和canvas.rotate()而是直接算出每个刻度线的起点终点坐标。好处是思路直白不容易把角度绕晕也方便后续对某条刻度做特殊处理。主刻度从半径内侧22dp开始短刻度从14dp开始都画到距外沿6dp的位置这样表盘外侧留出一条完整的环带视觉上限比较整齐。关于性能多说一句刻度数量在几十条时这种逐个drawLine的方式完全没问题。如果以后要支持几百条刻度再考虑用drawLines(float[])批量绘制。2.4 数值文字的两种排布方案数值文字的排布有讲究。我做过两个版本踩过不同的坑。第一个方案是固定正立文字每个标签文字始终水平只是把文字中心定位在对应的半径位置上。实现方式简单也永远不会出现倒字。private fun drawLabelsFixed(canvas: Canvas) { for (value in 0..maxValue step 20) { val fraction value.toFloat() / maxValue val angle startAngle sweepAngle * fraction val rad Math.toRadians(angle.toDouble()) val labelX centerX labelRadius * cos(rad).toFloat() val labelY centerY labelRadius * sin(rad).toFloat() val text value.toString() val halfWidth labelPaint.measureText(text) / 2f val baselineOffset (labelPaint.fontMetrics.ascent labelPaint.fontMetrics.descent) / 2f canvas.drawText(text, labelX - halfWidth, labelY - baselineOffset, labelPaint) } }第二个方案是放射随形文字文字跟着角度一起旋转视觉效果更贴合弧形表盘。核心是用canvas.rotate()把坐标系转过去再在半径上画文字。但这里有个坑当角度落在下半区时文字会倒置需要额外判断方向并旋转180度修正。一般情况下我建议先做固定正立方案省心且已经能覆盖绝大多数需求。不管是哪种方案drawText的y坐标都是文本基线不是文字中心。这是新手必踩的坑之一。想让文字中心落在指定位置必须用fontMetrics做基线补偿也就是我代码里的baselineOffset那一行。2.5 指针的Path构造与中心轴指针我选择用Path构造一个不规则五边形尖端指向0度方向根部收窄尾部有一个小尾巴看起来更像真实码表的指针。private fun drawPointer(canvas: Canvas, pointerAngle: Float) { canvas.save() canvas.rotate(pointerAngle, centerX, centerY) val pointerPath Path().apply { moveTo(centerX pointerLength, centerY) lineTo(centerX, centerY - pointerWidth) lineTo(centerX - pointerTail, centerY) lineTo(centerX, centerY pointerWidth) close() } canvas.drawPath(pointerPath, pointerPaint) canvas.restore() canvas.drawCircle(centerX, centerY, centerAxisRadius, axisPaint) }这里最关键的是先画一个默认指向正右方的指针再通过canvas.rotate(pointerAngle, cx, cy)把它转到目标角度。很多第一次接触的人会把指针路径画在指向上方再配合rotate结果角度总是差90度。统一约定0度在正右方后面所有计算都和它对齐就不会乱。中心轴小圆是最后画的目的是盖住指针底部的尖端交汇处让表盘中心看起来干净利落。3. 指针转起来动画驱动与状态机的一次到位设计静态盘面完成后下一步就是让指针动起来。码表最迷人的地方就是指针从0到目标值时那种有节奏的转动。3.1 为什么是ValueAnimator不是自绘循环自定义View的动画实现方式有好几种可以自己开循环配合postInvalidate()也可以用ObjectAnimator还可以在onDraw里手动驱动。我自己首选ValueAnimator。原因有三点ValueAnimator由系统统一的帧回调驱动动画期间会自动处理帧刷新不需要自己管理Thread和Handler内置完整的插值器体系DecelerateInterpolator这类插值器直接拿来用动画节奏不需要自己算支持cancel()和end()在多动画切换时能干净利落地收掉旧动画自绘循环的问题在于页面不可见时还需要自己监听生命周期去停页面可见时又容易过度刷新这点对于表盘这种需要长时间存在的组件来说太费心了。3.2 动画的核心起始值是当前值不是固定0很多人的动画代码是这样写的ValueAnimator.ofFloat(0f, targetValue)。这样每次调用动画指针都会从0重新转这在真实项目里根本不能用。真实场景是业务层可能会连续下发新的速度值如果当前指针停在80下一个目标是120动画必须从80开始平滑爬到120而不是先跳回0再冲到120。正确写法是把起始值定为当前值private fun animateTo(targetValue: Float) { valueAnimator?.cancel() valueAnimator ValueAnimator.ofFloat(currentValue, targetValue).apply { duration 900L interpolator DecelerateInterpolator(2f) addUpdateListener { animation - currentValue animation.animatedValue as Float invalidate() } start() } }插值器我选的是DecelerateInterpolator(2f)也就是先快后慢。真实机械码表的指针被弹簧推动时确实有一种快速启动然后逐渐落定的感觉。用线性插值的话指针全程匀速看起来就像电子表的假指针很生硬。这里有一个细节如果在addUpdateListener里频繁创建对象动画期间会不断触发GC帧率反而上不去。currentValue直接赋值只调用invalidate()不做其他多余操作。推荐把动画的时长和插值器都提成常量后续调手感时不用翻代码改一处就生效。3.3 状态机设计防止动画打架码表除了动画还可能有用户手动拨动指针、外部指令复位等操作。如果不加状态管理很容易出现两个动画同时改currentValue指针抽搐抖动。我定义了一个枚举状态enum class MeterState { IDLE, // 初始状态 RUNNING, // 指针正在转向目标值 PAUSED, // 用户手动拨动中动画暂停 SETTLED // 指针已到达目标值并停住 }每次切换到RUNNING时统一执行valueAnimator?.cancel()确保上一个动画不会残留。手动拨动进入PAUSED后动画会被停掉用户的手指操作直接修改当前值手指抬起时再根据业务需要决定恢复动画还是保持手动位置。这套状态机看起来简单但实际效果非常好。项目里出现过一种常见问题网络数据时不时推送同一个值指针每次都从头跳一遍。加一个判断——如果abs(newTarget - currentValue) 1f直接忽略这次更新指针就不会频繁抽搐。3.4 View销毁时别忘了清理动画自定义View在页面退出时如果动画还在跑会带来两个问题一是View还持有动画引用导致内存泄漏二是动画回调还在不断invalidate()一个已经不可见的View白白浪费CPU。我习惯在onDetachedFromWindow()里收尾override fun onDetachedFromWindow() { super.onDetachedFromWindow() valueAnimator?.cancel() }这个方法很小但很多人会漏掉。漏掉之后测试时可能不觉得有问题一旦同一个Activity被频繁创建销毁内存问题就会慢慢浮现。4. 手指拨表从触摸坐标到码表值的闭环静态和动画都完成之后码表基本能看了。但我想让它更有互动性——用户可以直接按住指针或者表盘旋拨把值调到任意位置。这比单纯看动画有意思得多也更接近真实表盘的手感。4.1 触摸点转角度数学建模的第一步手指坐标是相对于View左上角的像素坐标第一步先把它转换成相对于圆心的向量然后用atan2算出角度override fun onTouchEvent(event: MotionEvent): Boolean { val dx event.x - centerX val dy event.y - centerY var touchAngle Math.toDegrees(Math.atan2(dy.toDouble(), dx.toDouble())).toFloat() if (touchAngle 0f) { touchAngle 360f } // 后续角度换算逻辑… return true }这里的一个关键点atan2返回的是-180到180度要先转成0到360度。由于Android屏幕坐标系y轴向下atan2计算出来的角度视觉上恰好和Canvas一致即0度在右、90度在下、顺时针递增不用再额外翻转。4.2 角度换算成码表值处理跨零点的回绕问题得到手指的0到360度触摸角后下一步是换算成码表的逻辑值。我的码表起始角是135度扫过270度对应区间是135度到405度。但触摸角正常范围是0到360度这里就出现一个跨零点问题。当手指触摸在0到135度范围时需要把角度加上360度才能映射到扫描区间里var logicalAngle touchAngle if (logicalAngle startAngle) { logicalAngle 360f } val fraction ((logicalAngle - startAngle) / sweepAngle) .coerceIn(0f, 1f) val newValue minValue (maxValue - minValue) * fraction currentValue newValue invalidate()这个处理非常关键。如果不做跨零处理用户从右下角接近0度位置往右上方拖动时角度会直接从0跳到360指针也会跟着乱跳。加上这个判断后角度区间变成135度到405度正好覆盖整个扫描范围。右下角缺口区域大约是45度到135度之间的某个角度里逻辑角度算出来会落到区间外coerceIn会让它停在0或最大值。实际交互表现为手指滑到缺口附近时指针会停在该端点的边界上不会飞出去符合预期。4.3 拨动与动画的协同手动优先抬起恢复用户可能正在看码表自动动画运行突然伸手去拨指针。这种情况必须定义清楚优先级。我的策略是手动拨动时立刻取消当前动画进入PAUSED状态手指抬起后如果业务层还有未完成的目标值就从这个手动停止的位置重新启动动画。when (event.actionMasked) { MotionEvent.ACTION_DOWN - { valueAnimator?.cancel() meterState MeterState.PAUSED isDragging true } MotionEvent.ACTION_MOVE - { if (isDragging) { updateValueByTouch(event) } } MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL - { isDragging false // 若外部还有pendingTarget则恢复动画 } }这样做的好处是动画和手动操作始终不会同时改currentValue指针不会出现跳动。而且用户手动调完值之后业务层如果继续推新数据码表还能正常接管。有一点容易忽略onTouchEvent返回true表示消费掉事件才能持续收到ACTION_MOVE。如果返回false手指一滑动事件就被父布局抢走了。码表这个场景必须消费触摸事件。5. 调优、踩坑与实测码表从demo变为可用组件静态盘面画完动画和触摸也跑通之后我拿到真机上测了一圈。效果基本能看但离“流畅可用”还有距离尤其是低端机上动画期间偶发掉帧。这一章记录的全是实战中真正影响体验的细节。5.1 静态盘面缓存到Bitmap每帧省掉大半工作量码表动画期间实际上每帧只需要重新画指针和中心轴。但刻度、外圈、数值文字这些静态元素如果不做处理每帧都要重新计算坐标、重新画一遍白白浪费CPU。优化思路很简单把不随值变化的内容一次性画到离屏Bitmap上onDraw里先贴Bitmap再画动态部分。private var faceBitmap: Bitmap? null private fun rebuildFaceIfNeeded() { if (faceBitmap null || faceBitmap!!.width ! width || faceBitmap!!.height ! height) { faceBitmap Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888) val canvas Canvas(faceBitmap!!) drawFace(canvas) drawTicks(canvas) drawLabelsFixed(canvas) } } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) rebuildFaceIfNeeded() canvas.drawBitmap(faceBitmap!!, 0f, 0f, null) val pointerAngle startAngle sweepAngle * (currentValue / maxValue) drawPointer(canvas, pointerAngle) drawCenterText(canvas) }我在测试机上对比过未缓存时240dp的码表单帧绘制耗时大概6到8毫秒缓存后单帧降到1.5毫秒以下。动画期间差距更明显缓存前的低端机偶尔掉帧缓存后全程60帧稳跑。这里提醒两个点第一FaceBitmap必须在尺寸变化时重建所以我放在了rebuildFaceIfNeeded里和宽高比对第二Bitmap.createBitmap的调用不应该出现在onDraw里因为onDraw每帧都可能触发而rebuildFaceIfNeeded有宽度判断能保证只在尺寸变化时重建一次。这一点设计好逻辑上是安全的但我见过有人直接在onDraw里无条件创建那是灾难。5.2 两个最常见的坑文字基线和角度原点第一个坑是文字基线。大家基本都经历过drawText明明传了坐标文字却不在预期位置。原因是drawText的y坐标代表的是基线位置不是文字顶部也不是文字中心。让文字在垂直方向上精确居中需要用fontMetricsval fm textPaint.fontMetrics val baseline centerY - (fm.ascent fm.descent) / 2f同理画在刻度半径上的标签也一定要做类似的基线补偿。我在2.4里给的baselineOffset就是这个作用。这个经验说再多都不如自己踩一次但如果看文章的人能直接避开那我这行字也算没白写。第二个坑是角度原点。Android的0度在3点钟方向很多人潜意识里认为0度在正上方于是画出来的第一个刻度总在右侧而不是顶部。码表因为起始角在左下这个偏差更隐蔽刻度全往右偏了一大截。要根治就是在动手前把“0度在右、顺时针为正”这十个字刻在脑子里所有角度的起算点都对齐到正右方。5.3 硬件加速下的绘制边界要牢记Android默认在API 14以上就开启了硬件加速。大部分Canvas操作都支持但有一些操作在硬件加速下表现不一致。我这边遇到的实际问题是早期版本用了canvas.saveLayerAlpha()来给指针做半透明阴影在部分机型上出现了阴影边缘发虚的问题。后来换成直接用带透明度的Paint绘制避开saveLayer*这一类开销大且兼容性有坑的操作问题就消失了。还有一点如果整个View用LAYER_TYPE_HARDWARE开离屏缓存绘制复杂Path和阴影时体验感确实会提升但它会额外占用显存而且和View的尺寸强绑定。用了Bitmap缓存静态盘面之后大多数场景不需要再开layer我最终也没有开启它。这个取舍要视具体需求而定不存在标准答案。5.4 一组实测数据与主观手感这个码表组件最后用在了某跨平台系统的终端首页上。我在三类设备上做了简单验证设备类型静态盘面缓存动画期间帧率主观手感模拟器无30到45fps轻微掉帧指针发飘模拟器有55到60fps流畅无明显顿挫低端真机无25到35fps动画期间偶发跳变低端真机有58到60fps顺滑手感接近机械表中端真机无45到55fps基本流畅但边缘有锯齿感中端真机有60fps全程流畅数据只是参考不同设备系统版本差异很大但整体趋势非常明确静态盘面缓存这个优化在码表这种“静态元素占比高、动态元素占比低”的组件里收益极其明显。主观手感上我把动画时长从1200ms调到了900ms配合DecelerateInterpolator(2f)指针启动时有明显加速感停止时又有轻微惯性回落的错觉。这个参数不是凭空定的而是反复对比后觉得900ms最像真实机械表。如果追求更硬朗的电子表风格可以把时长压到600ms插值器换成FastOutSlowInInterpolator。如果你正打算实现一个码表或者类似的表盘组件我的建议是先按这个顺序把盘面、刻度、指针拆开画再考虑动画和交互。动画不要一上来就追求花哨先把静态画准动态自然就顺了。最后再叮嘱一句角度、基线、动画清理这三个点提前想清楚能帮你省下大半天排查时间。