简介Android自定义SeekBar实例工程面向有一定Android基础、希望美化控件样式的开发者。资源讲解如何用图片替代系统默认进度条背景与滑块通过继承SeekBar、定义自定义属性并在布局中引用实现个性化视觉效果可应用于音量、亮度调节或播放进度条等场景。压缩包共52个文件包含4个java源码、22个png切图、7个xml配置及可直接安装的apk整体约696KB4个java涉及自定义控件与Activity实现png提供背景与进度所需图片xml包含布局与属性定义。目前已有849人学习下载。通过该工程可获取完整MySeekBar示例代码含自定义属性声明、TypedArray读取、图片资源封装及滑动交互扩展方法适合导入Android工程运行学习也可作为模板快速迁移至实际项目。1. 自定义SeekBar用图片背景和图片进度解决系统进度条画不出UI图的硬伤拿到UI设计师给的磨砂质感进度条素材往系统SeekBar上setProgressDrawable一套发现图片被拉伸变形、进度条和背景对不齐、滑块位置总是差几个像素——这是每个做过自定义控件的开发者都踩过的坑。这个项目做的就是一件事直接接管SeekBar的onDraw绘制把背景图、进度图、滑块图分别通过setBounds画到画布上同时重写触摸坐标到进度值的换算逻辑让图片进度条在滑动时跟手、不偏移、不闪烁。适合需要把UI切图直接做成进度条、又不想被系统自带裁剪逻辑限制的Android开发者也适合想搞懂自定义View绘制链路的人当一份精简的实战参考。2. 架构决策继承SeekBar却不调super.onDraw比从零画View省一半事2.1 系统SeekBar的样式死角ProgressDrawable的裁剪逻辑为什么难调先聊清楚一个很多人没意识到的问题系统SeekBar的进度条是用ProgressDrawable画的它内部是一层LayerDrawable包着ClipDrawable绘制时按照Level去裁剪进度区域。如果你直接把这个机制换成图片麻烦立刻出现。第一ClipDrawable裁剪图片时边缘是硬切的对磨砂、渐变色这类图片素材进度条边缘会有一条清晰的锯齿线第二背景图和进度图是两套Bounds系统在测量阶段会各自设置一次稍微错位一点肉眼就能看出来而且是那种说不清哪错位了的“玄学”问题第三thumb的位置由系统内部计算想把滑块中心精准对准进度条终点得同时改好几个内部参数。更麻烦的是如果你继承SeekBar只改属性而不动它的绘制逻辑系统在刷新时会同时跑自己的绘制和你加的绘制两套内容叠在一起。那个阶段我调了整整一下午最后用Layout Inspector一帧帧看才发现系统把默认进度条也画出来了。所以这个项目的核心架构决策很直接继承SeekBar但在onDraw里完全不调用super.onDraw所有视觉效果自己画。这样setProgress、getProgress、setMax这些方法逻辑全复用只把“怎么画”这层换成自己的实现——这是性价比最高的方案。从零继承View写一个进度条也不是不行但你需要自己维护进度值、最大值、变化监听还要处理setProgress的线程安全工作量直接翻倍。继承SeekBar的做法是大多数自定义进度条项目的选择因为状态管理和触摸事件系统已经帮你兜底了你要做的只是接管最后一公里的绘制以及把触摸坐标换算成进度。2.2 项目目录与初始化链路三个Drawable如何注入构造函数整个项目结构非常精简核心就是一个自定义View类加一份属性定义文件加三张图片资源我按实际工程结构列一下app/src/main/ ├── java/com/example/imgseekbar/ │ ├── ImgSeekBar.java # 自定义控件核心类 │ └── MainActivity.java # 演示页面 ├── res/ │ ├── drawable/ │ │ ├── seekbar_bg.png # 进度条背景图 │ │ ├── seekbar_progress.png # 进度条前景图 │ │ └── seekbar_thumb.png # 滑块图片 │ ├── layout/ │ │ └── activity_main.xml # 布局文件 │ └── values/ │ └── attrs.xml # 自定义属性定义初始化链路是这样走的布局文件inflate时系统会解析XML上各级标签的属性列表从attrs.xml里匹配到declare-styleable定义的ImgSeekBar属性集然后调用ImgSeekBar(Context, AttributeSet)构造函数把AttributeSet传进来。构造函数里通过obtainStyledAttributes从AttributeSet中取出每一张图片资源的引用以及进度条高度、滑块尺寸这些数值型参数解析完再手动recycle掉TypedArray。为什么要用自定义属性而不是在代码里直接用setXxx方法注入因为XML布局里声明这种方式对使用方最友好UI调整素材时只要换layout文件里的app:imgBackground引用不用改Java代码。而且obtainStyledAttributes支持主题级别的属性覆盖将来如果要做多主题切换换一套attr即可。这也是Android官方控件一直沿用自定义属性的原因——把外观配置和业务逻辑解耦。3. 核心实现拆解属性解析、三层绘制与触摸换算的完整链路3.1 自定义属性定义与TypedArray解析先看attrs.xml这里声明了五个自定义属性它们是控件和外部世界的接口resources declare-styleable nameImgSeekBar !-- 进度条背景图 -- attr nameimgBackground formatreference / !-- 进度条前景图 -- attr nameimgProgress formatreference / !-- 滑块图片 -- attr nameimgThumb formatreference / !-- 进度条绘制高度 -- attr namebarHeight formatdimension / !-- 滑块尺寸 -- attr namethumbSize formatdimension / /declare-styleable /resources五个属性里三个是图片引用、两个是尺寸数值。formatreference表示接受drawable/xxx这类的资源引用formatdimension表示接受6dp这种尺寸值。name必须和控件类名一致这样才能在XML的declare-styleable里被索引到这是约定俗成的规范写错就取不到值。接下来是构造函数里的解析代码public class ImgSeekBar extends SeekBar { private Drawable mBgDrawable; private Drawable mProgressDrawable; private Drawable mThumbDrawable; private float mBarHeight; private float mThumbSize; public ImgSeekBar(Context context, AttributeSet attrs) { super(context, attrs); init(context, attrs); } private void init(Context context, AttributeSet attrs) { TypedArray ta context.obtainStyledAttributes(attrs, R.styleable.ImgSeekBar); mBgDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgBackground); mProgressDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgProgress); mThumbDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgThumb); mBarHeight ta.getDimension(R.styleable.ImgSeekBar_barHeight, dp2px(6)); mThumbSize ta.getDimension(R.styleable.ImgSeekBar_thumbSize, dp2px(20)); ta.recycle(); if (mBgDrawable null || mProgressDrawable null || mThumbDrawable null) { throw new IllegalArgumentException(imgBackground/imgProgress/imgThumb 必须传图片资源); } } private float dp2px(float dp) { return dp * getResources().getDisplayMetrics().density; } }这段代码的逻辑不复杂但有三个细节值得注意。第一getDimension的默认值传的是dp2px(6)和dp2px(20)的换算结果因为系统返回的已经是px单位的数值如果你在XML里写死barHeight6dp拿到手的就是经过dp * density换算后的像素值。第二ta.recycle()必须放在finally或者解析完毕后的第一时间否则这个TypedArray持有的对象池资源不会释放反复创建View时会内存泄漏。第三图片属性缺省时直接抛IllegalArgumentException而不是静默跳过因为三张图缺一张控件就画不出完整效果与其运行了几分钟才在某个奇怪的地方崩溃不如在构造函数就把问题炸出来。3.2 onDraw三层绘制背景、进度与滑块的坐标计算接管绘制是整个项目的核心直接看onDraw的实现Override protected synchronized void onDraw(Canvas canvas) { // 关键不调用 super.onDraw()避免和系统默认进度条叠加 int width getWidth(); int height getHeight(); // 进度条本体垂直居中于控件 float barTop (height - mBarHeight) / 2f; float barBottom barTop mBarHeight; // 第1层画背景整条宽 mBgDrawable.setBounds(0, (int) barTop, width, (int) barBottom); mBgDrawable.draw(canvas); // 第2层画进度按比例宽 float ratio getMax() 0 ? 0 : getProgress() * 1f / getMax(); int progressWidth (int) (width * ratio); mProgressDrawable.setBounds(0, (int) barTop, progressWidth, (int) barBottom); mProgressDrawable.draw(canvas); // 第3层画滑块让滑块中心对准进度终点 float thumbLeft progressWidth - mThumbSize / 2f; float thumbTop (height - mThumbSize) / 2f; mThumbDrawable.setBounds( (int) thumbLeft, (int) thumbTop, (int) (thumbLeft mThumbSize), (int) (thumbTop mThumbSize)); mThumbDrawable.draw(canvas); }绘制逻辑分三层推进。背景图从控件左边缘铺到右边缘进度图从左边铺到progressWidth这个计算出来的像素点上滑块中心点正好落在进度条终点。这里最容易出错的是背景和进度图如果用同一个Drawable实例setBounds改了之后两层的矩形尺寸会被最后一层覆盖所以三张图必须是三个独立的Drawable对象。mBarHeight决定了进度条本体的厚度而整个控件的高度height要留得比mBarHeight大这样thumb才有空间画。常见的布局里控件高度直接wrap_content如果thumbSize是24dp、barHeight是6dponMeasure后控件高度会是max(barHeight, thumbSize)的24dp背景条就在垂直正中滑块上下各露出9dp观感上正好。如果你想要滑块超出控件边界的沉浸效果需要在onMeasure里给高度加上超出的部分否则setBounds的矩形跑到控件边界外面会被父布局裁剪掉。synchronized关键字是系统SeekBar自带的行为因为setProgress可能在主线程被触摸事件触发而onDraw渲染时如果读了半个进度值画面会撕裂。加了这个锁之后绘制和设置进度值串行化代价是极小的性能损耗对于进度条这种低频绘制控件完全感知不到。3.3 onTouchEvent把手指坐标换算成进度值的完整代码绘制搞定之后触摸联动是最后一块拼图Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: // 按下就要立刻定位不能等MOVE updateProgressFromTouch(event.getX()); return true; case MotionEvent.ACTION_MOVE: updateProgressFromTouch(event.getX()); return true; case MotionEvent.ACTION_UP: performClick(); return true; } return super.onTouchEvent(event); } private void updateProgressFromTouch(float x) { float usableWidth getWidth() - getPaddingLeft() - getPaddingRight(); if (usableWidth 0) { return; } float ratio (x - getPaddingLeft()) / usableWidth; ratio Math.max(0f, Math.min(1f, ratio)); setProgress((int) (ratio * getMax())); }坐标换算的思路是先把控件宽度去掉左右padding得到真正可以滑动的区间然后把触摸点x减去getPaddingLeft()除以可用宽度得到0到1的比例再乘以getMax()拿到进度值。Math.max和Math.min两个夹逼操作把比例锁在[0,1]之间防止手指滑出控件边界时进度变成了负数或超过最大值。这里有一个新手经常翻车的细节event.getX()返回的是相对控件左上角的坐标如果是相对屏幕的getRawX()还要再减去控件在屏幕中的位置多一层换算反而复杂了。另一个细节是ACTION_DOWN时如果直接返回false后续的MOVE和UP事件都不会再传进来所以DOWN分支必须return true。控件默认在XML里设了android:clickabletrue的话performClick()会确保无障碍事件正常发送否则测试工具会报View does not call performClick的警告。4. 避坑指南图片变形、touch偏移与滑动卡顿的三个经典翻车现场4.1 背景图和进度条高度不一致进度跑完一半能看到背景露出来曾经遇到一个现象进度到50%的时候进度条和背景明显不在同一个水平线上仔细看是背景图比进度图高了两三个像素。原因在于我给两张图设置了不同的setBounds矩形——背景用了一个独立计算的高度进度图用了另一个高度甚至有时候是Drawable原始尺寸本身高矮不一致绘制时系统按各自Bounds缩放自然对不上。解决方式很简单所有层级的setBounds矩形高度统一使用同一个mBarHeight变量背景的top和进度条的top都是(height - mBarHeight) / 2f从源头保证两条矩形完全重叠。这里给个排查思路在onDraw里临时画两条辅助线一条在背景矩形的垂直中心一条在进度矩形的垂直中心看两条线是否重合不重合就是高度计算不一致一调一个准。4.2 手指按下去thumb总偏一截没减padding但左手画右手算不一致这个坑的典型表现是手指点在进度条30%的位置thumb中心却落在28%的地方。原因是我在绘制时用getWidth()作为进度条总长但触摸换算时减掉了getPaddingLeft()和getPaddingRight()导致触摸算出来的比例和绘制算出来的比例基准不一致。绘制按全宽画触摸按减掉padding后的宽度算偏差量等于padding值。解决方式是让绘制和触摸换算使用同一套坐标系。要么两边都算padding要么两边都不算。我在项目里选了都算padding的方案绘制背景和进度时宽度都用width - getPaddingLeft() - getPaddingRight()绘制起点也从getPaddingLeft()开始触摸换算保持和绘制一致。改完之后手指按哪里thumb中心就落在哪里指哪打哪。4.3 快速拖动时进度跳变加卡顿touch事件频率太高setProgress没有做阈值过滤触摸事件在ACTION_MOVE里的触发频率远高于屏幕刷新率三星和国产旗舰机在120Hz刷新率下一秒钟能来上百个MOVE事件。每次事件都调用setProgress而setProgress内部会触发监听回调、更新绘制、可能还要发无障碍事件低频时候感觉不到快速滑动时就会出现“进度跳了一下又退回来”的粘滞感。解决思路是给updateProgressFromTouch加一个最小变化阈值计算出的targetProgress与当前getProgress()的差值小于2像素对应的进度值时直接忽略这次事件。private void updateProgressFromTouch(float x) { float usableWidth getWidth() - getPaddingLeft() - getPaddingRight(); if (usableWidth 0) { return; } float ratio (x - getPaddingLeft()) / usableWidth; ratio Math.max(0f, Math.min(1f, ratio)); int target (int) (ratio * getMax()); // 过滤掉变化幅度小于1的事件避免高频刷新 if (Math.abs(target - getProgress()) 1) { setProgress(target); } }另外还有一个隐藏性能点onDraw里每次都通过getMax()和getProgress()计算比例如果setProgress的监听回调里又调用了setProgress会造成synchronized方法的重入等待表现为偶发的ANR卡顿。血泪经验是onProgressChanged回调里不要再去setProgress只在onStopTrackingTouch里做一次结果处理就够。5. 运行与调试把Demo跑起来并验证每个绘制环节5.1 工程结构与依赖配置这个项目不依赖任何三方库纯手写View所以工程导入很简单Android Studio新建一个Empty Activity工程把ImgSeekBar.java复制进包目录attrs.xml合并到values目录三张图片放进drawable目录然后在布局里引用自定义控件。需要注意build.gradle里的minSdkVersion不能低于21因为getActionMasked()虽然老版本也有但getPaddingLeft()在某些系统版本上对绘制逻辑有差异建议最低API 21起步。targetSdkVersion建议跟着你主工程的走不需要特调这个控件不涉及权限和隐私API。布局文件的用法如下com.example.imgseekbar.ImgSeekBar android:idid/seekbar android:layout_widthmatch_parent android:layout_heightwrap_content android:max100 android:paddingLeft12dp android:paddingRight12dp app:imgBackgrounddrawable/seekbar_bg app:imgProgressdrawable/seekbar_progress app:imgThumbdrawable/seekbar_thumb app:barHeight6dp app:thumbSize24dp /注意app:命名空间需要确保根布局标签里声明了xmlns:apphttp://schemas.android.com/apk/res-auto。android:max100沿用系统属性代码里getMax()会自动拿到这个值。如果你忘了加android:paddingLeft和android:paddingRight且你的背景图从视觉上确实需要留出左右边距那么进度条会被画到和背景图边缘对齐视觉上不够“透气”材质设计规范里一般推荐左右留出12dp以上。MainActivity里初始化并设置监听器ImgSeekBar seekBar findViewById(R.id.seekbar); seekBar.setProgress(30); seekBar.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() { Override public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) { // 实时刷新进度文案不能在此回调里再次setProgress } Override public void onStartTrackingTouch(SeekBar seekBar) { // 按下时触发 } Override public void onStopTrackingTouch(SeekBar seekBar) { // 松手时触发适合在这里做上报或动画 } });5.2 图片资源的尺寸与多密度适配图片素材是整个控件的灵魂尺寸没做好代码写得再对效果也出不来。我把建议规格列出来资源建议尺寸说明seekbar_bg.png宽度匹配布局宽度高度为barHeight对应像素例如barHeight6dp在xxhdpi设备下就是18px高图片高度建议等于这个值seekbar_progress.png宽度和背景一致高度一致颜色、纹理与背景区分开即可seekbar_thumb.png正方形例如60x60px建议透明背景圆角方形过大的图片会因缩放变得模糊图源的分辨率建议直接按三倍图导出即背景图高度18px、2倍图12px、默认6px分别放进drawable-xxhdpi、drawable-xhdpi、drawable-hdpi。如果你只放一套图系统会拿它做缩放小屏上会模糊大屏上边缘会有锯齿。进度图宽度要和背景图一样因为进度层按比例绘制宽度小于背景的话进度条永远到不了最右端。5.3 用辅助线和日志验证绘制边界绘制类的调试手段和业务代码不一样断点只能看变量看不到画面。我的习惯是在onDraw里临时加两行辅助线代码Paint debugPaint new Paint(); debugPaint.setColor(0xFFFF0000); debugPaint.setStrokeWidth(1); canvas.drawLine(0, barTop, width, barTop, debugPaint); canvas.drawLine(progressWidth, barTop, progressWidth, barBottom, debugPaint);红色横线确认背景条的上下边界红色竖线确认进度条的终点边界。如果进度到50%时竖线不在控件水平中点说明progressWidth计算有问题。验证完记得删掉这段调试代码或者用一个BuildConfig.DEBUG标志包起来发布包不会带进去。另外可以配合Layout Inspector看三张图的Bounds值是否和你算的一致这个方法检查bounds偏差特别好用。6. 二次开发加上数值气泡指示器和离散刻度吸附6.1 在thumb上方绘制数值气泡把进度数值实时显示在滑块上方是播放器和音频类应用最常见的需求。思路是在onDraw的滑块绘制之后追加一层气泡绘制根据progressWidth算出气泡中心的X坐标在滑块上方留出固定间距画一个圆角矩形里面写当前进度文字。// 在 onDraw 的滑块绘制之后追加 float bubbleCenterX progressWidth; float bubbleTop thumbTop - dp2px(34); RectF bubbleRect new RectF(bubbleCenterX - dp2px(20), bubbleTop, bubbleCenterX dp2px(20), bubbleTop dp2px(24)); canvas.drawRoundRect(bubbleRect, dp2px(4), dp2px(4), bubblePaint); canvas.drawText(String.valueOf(getProgress()), bubbleRect.centerX(), bubbleRect.centerY(), textPaint);实现时注意两个点气泡宽度要能容纳三位数textPaint的文字居中要对齐bubbleRect.centerY()用Paint.setTextAlign(CENTER)加上FontMetrics计算ascent和descent的偏移量否则文字不在气泡垂直中心。气泡超出控件顶部时父布局会裁掉需要给控件layout_height增加一段气泡高度的余量。6.2 离散刻度模式让进度按档位吸附如果要做倍速调节、星级评分这类离散档位的进度条可以在updateProgressFromTouch里把计算出的比例映射到最近的分档位置取值。private int mapToStep(int target) { int stepCount 5; // 档位数 float step getMax() / (float) stepCount; return Math.round(target / step) * Math.round(step); }Math.round本身带四舍五入效果滑到一半时会自动吸附到最近的档位。触摸手感上会有一个“卡点”的反馈用户不需要精确对准刻度线。配合onStopTrackingTouch里回调档位变化适合做倍数选择器。我一般会顺手加一个轻量震动反馈HapticFeedback在ACTION_UP时调用performHapticFeedback手感立刻高级一个档次。从那以后我每次接手新的自定义View都会强制自己先花十分钟梳理绘制和触摸这两条链路的坐标系基准再写代码。毕竟坐标系不统一后面调起来全是玄学这次分享出来希望帮到你。本文还有配套的精品资源点击获取
简介Android自定义SeekBar实例工程面向有一定Android基础、希望美化控件样式的开发者。资源讲解如何用图片替代系统默认进度条背景与滑块通过继承SeekBar、定义自定义属性并在布局中引用实现个性化视觉效果可应用于音量、亮度调节或播放进度条等场景。压缩包共52个文件包含4个java源码、22个png切图、7个xml配置及可直接安装的apk整体约696KB4个java涉及自定义控件与Activity实现png提供背景与进度所需图片xml包含布局与属性定义。目前已有849人学习下载。通过该工程可获取完整MySeekBar示例代码含自定义属性声明、TypedArray读取、图片资源封装及滑动交互扩展方法适合导入Android工程运行学习也可作为模板快速迁移至实际项目。1. 自定义SeekBar用图片背景和图片进度解决系统进度条画不出UI图的硬伤拿到UI设计师给的磨砂质感进度条素材往系统SeekBar上setProgressDrawable一套发现图片被拉伸变形、进度条和背景对不齐、滑块位置总是差几个像素——这是每个做过自定义控件的开发者都踩过的坑。这个项目做的就是一件事直接接管SeekBar的onDraw绘制把背景图、进度图、滑块图分别通过setBounds画到画布上同时重写触摸坐标到进度值的换算逻辑让图片进度条在滑动时跟手、不偏移、不闪烁。适合需要把UI切图直接做成进度条、又不想被系统自带裁剪逻辑限制的Android开发者也适合想搞懂自定义View绘制链路的人当一份精简的实战参考。2. 架构决策继承SeekBar却不调super.onDraw比从零画View省一半事2.1 系统SeekBar的样式死角ProgressDrawable的裁剪逻辑为什么难调先聊清楚一个很多人没意识到的问题系统SeekBar的进度条是用ProgressDrawable画的它内部是一层LayerDrawable包着ClipDrawable绘制时按照Level去裁剪进度区域。如果你直接把这个机制换成图片麻烦立刻出现。第一ClipDrawable裁剪图片时边缘是硬切的对磨砂、渐变色这类图片素材进度条边缘会有一条清晰的锯齿线第二背景图和进度图是两套Bounds系统在测量阶段会各自设置一次稍微错位一点肉眼就能看出来而且是那种说不清哪错位了的“玄学”问题第三thumb的位置由系统内部计算想把滑块中心精准对准进度条终点得同时改好几个内部参数。更麻烦的是如果你继承SeekBar只改属性而不动它的绘制逻辑系统在刷新时会同时跑自己的绘制和你加的绘制两套内容叠在一起。那个阶段我调了整整一下午最后用Layout Inspector一帧帧看才发现系统把默认进度条也画出来了。所以这个项目的核心架构决策很直接继承SeekBar但在onDraw里完全不调用super.onDraw所有视觉效果自己画。这样setProgress、getProgress、setMax这些方法逻辑全复用只把“怎么画”这层换成自己的实现——这是性价比最高的方案。从零继承View写一个进度条也不是不行但你需要自己维护进度值、最大值、变化监听还要处理setProgress的线程安全工作量直接翻倍。继承SeekBar的做法是大多数自定义进度条项目的选择因为状态管理和触摸事件系统已经帮你兜底了你要做的只是接管最后一公里的绘制以及把触摸坐标换算成进度。2.2 项目目录与初始化链路三个Drawable如何注入构造函数整个项目结构非常精简核心就是一个自定义View类加一份属性定义文件加三张图片资源我按实际工程结构列一下app/src/main/ ├── java/com/example/imgseekbar/ │ ├── ImgSeekBar.java # 自定义控件核心类 │ └── MainActivity.java # 演示页面 ├── res/ │ ├── drawable/ │ │ ├── seekbar_bg.png # 进度条背景图 │ │ ├── seekbar_progress.png # 进度条前景图 │ │ └── seekbar_thumb.png # 滑块图片 │ ├── layout/ │ │ └── activity_main.xml # 布局文件 │ └── values/ │ └── attrs.xml # 自定义属性定义初始化链路是这样走的布局文件inflate时系统会解析XML上各级标签的属性列表从attrs.xml里匹配到declare-styleable定义的ImgSeekBar属性集然后调用ImgSeekBar(Context, AttributeSet)构造函数把AttributeSet传进来。构造函数里通过obtainStyledAttributes从AttributeSet中取出每一张图片资源的引用以及进度条高度、滑块尺寸这些数值型参数解析完再手动recycle掉TypedArray。为什么要用自定义属性而不是在代码里直接用setXxx方法注入因为XML布局里声明这种方式对使用方最友好UI调整素材时只要换layout文件里的app:imgBackground引用不用改Java代码。而且obtainStyledAttributes支持主题级别的属性覆盖将来如果要做多主题切换换一套attr即可。这也是Android官方控件一直沿用自定义属性的原因——把外观配置和业务逻辑解耦。3. 核心实现拆解属性解析、三层绘制与触摸换算的完整链路3.1 自定义属性定义与TypedArray解析先看attrs.xml这里声明了五个自定义属性它们是控件和外部世界的接口resources declare-styleable nameImgSeekBar !-- 进度条背景图 -- attr nameimgBackground formatreference / !-- 进度条前景图 -- attr nameimgProgress formatreference / !-- 滑块图片 -- attr nameimgThumb formatreference / !-- 进度条绘制高度 -- attr namebarHeight formatdimension / !-- 滑块尺寸 -- attr namethumbSize formatdimension / /declare-styleable /resources五个属性里三个是图片引用、两个是尺寸数值。formatreference表示接受drawable/xxx这类的资源引用formatdimension表示接受6dp这种尺寸值。name必须和控件类名一致这样才能在XML的declare-styleable里被索引到这是约定俗成的规范写错就取不到值。接下来是构造函数里的解析代码public class ImgSeekBar extends SeekBar { private Drawable mBgDrawable; private Drawable mProgressDrawable; private Drawable mThumbDrawable; private float mBarHeight; private float mThumbSize; public ImgSeekBar(Context context, AttributeSet attrs) { super(context, attrs); init(context, attrs); } private void init(Context context, AttributeSet attrs) { TypedArray ta context.obtainStyledAttributes(attrs, R.styleable.ImgSeekBar); mBgDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgBackground); mProgressDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgProgress); mThumbDrawable ta.getDrawable(R.styleable.ImgSeekBar_imgThumb); mBarHeight ta.getDimension(R.styleable.ImgSeekBar_barHeight, dp2px(6)); mThumbSize ta.getDimension(R.styleable.ImgSeekBar_thumbSize, dp2px(20)); ta.recycle(); if (mBgDrawable null || mProgressDrawable null || mThumbDrawable null) { throw new IllegalArgumentException(imgBackground/imgProgress/imgThumb 必须传图片资源); } } private float dp2px(float dp) { return dp * getResources().getDisplayMetrics().density; } }这段代码的逻辑不复杂但有三个细节值得注意。第一getDimension的默认值传的是dp2px(6)和dp2px(20)的换算结果因为系统返回的已经是px单位的数值如果你在XML里写死barHeight6dp拿到手的就是经过dp * density换算后的像素值。第二ta.recycle()必须放在finally或者解析完毕后的第一时间否则这个TypedArray持有的对象池资源不会释放反复创建View时会内存泄漏。第三图片属性缺省时直接抛IllegalArgumentException而不是静默跳过因为三张图缺一张控件就画不出完整效果与其运行了几分钟才在某个奇怪的地方崩溃不如在构造函数就把问题炸出来。3.2 onDraw三层绘制背景、进度与滑块的坐标计算接管绘制是整个项目的核心直接看onDraw的实现Override protected synchronized void onDraw(Canvas canvas) { // 关键不调用 super.onDraw()避免和系统默认进度条叠加 int width getWidth(); int height getHeight(); // 进度条本体垂直居中于控件 float barTop (height - mBarHeight) / 2f; float barBottom barTop mBarHeight; // 第1层画背景整条宽 mBgDrawable.setBounds(0, (int) barTop, width, (int) barBottom); mBgDrawable.draw(canvas); // 第2层画进度按比例宽 float ratio getMax() 0 ? 0 : getProgress() * 1f / getMax(); int progressWidth (int) (width * ratio); mProgressDrawable.setBounds(0, (int) barTop, progressWidth, (int) barBottom); mProgressDrawable.draw(canvas); // 第3层画滑块让滑块中心对准进度终点 float thumbLeft progressWidth - mThumbSize / 2f; float thumbTop (height - mThumbSize) / 2f; mThumbDrawable.setBounds( (int) thumbLeft, (int) thumbTop, (int) (thumbLeft mThumbSize), (int) (thumbTop mThumbSize)); mThumbDrawable.draw(canvas); }绘制逻辑分三层推进。背景图从控件左边缘铺到右边缘进度图从左边铺到progressWidth这个计算出来的像素点上滑块中心点正好落在进度条终点。这里最容易出错的是背景和进度图如果用同一个Drawable实例setBounds改了之后两层的矩形尺寸会被最后一层覆盖所以三张图必须是三个独立的Drawable对象。mBarHeight决定了进度条本体的厚度而整个控件的高度height要留得比mBarHeight大这样thumb才有空间画。常见的布局里控件高度直接wrap_content如果thumbSize是24dp、barHeight是6dponMeasure后控件高度会是max(barHeight, thumbSize)的24dp背景条就在垂直正中滑块上下各露出9dp观感上正好。如果你想要滑块超出控件边界的沉浸效果需要在onMeasure里给高度加上超出的部分否则setBounds的矩形跑到控件边界外面会被父布局裁剪掉。synchronized关键字是系统SeekBar自带的行为因为setProgress可能在主线程被触摸事件触发而onDraw渲染时如果读了半个进度值画面会撕裂。加了这个锁之后绘制和设置进度值串行化代价是极小的性能损耗对于进度条这种低频绘制控件完全感知不到。3.3 onTouchEvent把手指坐标换算成进度值的完整代码绘制搞定之后触摸联动是最后一块拼图Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: // 按下就要立刻定位不能等MOVE updateProgressFromTouch(event.getX()); return true; case MotionEvent.ACTION_MOVE: updateProgressFromTouch(event.getX()); return true; case MotionEvent.ACTION_UP: performClick(); return true; } return super.onTouchEvent(event); } private void updateProgressFromTouch(float x) { float usableWidth getWidth() - getPaddingLeft() - getPaddingRight(); if (usableWidth 0) { return; } float ratio (x - getPaddingLeft()) / usableWidth; ratio Math.max(0f, Math.min(1f, ratio)); setProgress((int) (ratio * getMax())); }坐标换算的思路是先把控件宽度去掉左右padding得到真正可以滑动的区间然后把触摸点x减去getPaddingLeft()除以可用宽度得到0到1的比例再乘以getMax()拿到进度值。Math.max和Math.min两个夹逼操作把比例锁在[0,1]之间防止手指滑出控件边界时进度变成了负数或超过最大值。这里有一个新手经常翻车的细节event.getX()返回的是相对控件左上角的坐标如果是相对屏幕的getRawX()还要再减去控件在屏幕中的位置多一层换算反而复杂了。另一个细节是ACTION_DOWN时如果直接返回false后续的MOVE和UP事件都不会再传进来所以DOWN分支必须return true。控件默认在XML里设了android:clickabletrue的话performClick()会确保无障碍事件正常发送否则测试工具会报View does not call performClick的警告。4. 避坑指南图片变形、touch偏移与滑动卡顿的三个经典翻车现场4.1 背景图和进度条高度不一致进度跑完一半能看到背景露出来曾经遇到一个现象进度到50%的时候进度条和背景明显不在同一个水平线上仔细看是背景图比进度图高了两三个像素。原因在于我给两张图设置了不同的setBounds矩形——背景用了一个独立计算的高度进度图用了另一个高度甚至有时候是Drawable原始尺寸本身高矮不一致绘制时系统按各自Bounds缩放自然对不上。解决方式很简单所有层级的setBounds矩形高度统一使用同一个mBarHeight变量背景的top和进度条的top都是(height - mBarHeight) / 2f从源头保证两条矩形完全重叠。这里给个排查思路在onDraw里临时画两条辅助线一条在背景矩形的垂直中心一条在进度矩形的垂直中心看两条线是否重合不重合就是高度计算不一致一调一个准。4.2 手指按下去thumb总偏一截没减padding但左手画右手算不一致这个坑的典型表现是手指点在进度条30%的位置thumb中心却落在28%的地方。原因是我在绘制时用getWidth()作为进度条总长但触摸换算时减掉了getPaddingLeft()和getPaddingRight()导致触摸算出来的比例和绘制算出来的比例基准不一致。绘制按全宽画触摸按减掉padding后的宽度算偏差量等于padding值。解决方式是让绘制和触摸换算使用同一套坐标系。要么两边都算padding要么两边都不算。我在项目里选了都算padding的方案绘制背景和进度时宽度都用width - getPaddingLeft() - getPaddingRight()绘制起点也从getPaddingLeft()开始触摸换算保持和绘制一致。改完之后手指按哪里thumb中心就落在哪里指哪打哪。4.3 快速拖动时进度跳变加卡顿touch事件频率太高setProgress没有做阈值过滤触摸事件在ACTION_MOVE里的触发频率远高于屏幕刷新率三星和国产旗舰机在120Hz刷新率下一秒钟能来上百个MOVE事件。每次事件都调用setProgress而setProgress内部会触发监听回调、更新绘制、可能还要发无障碍事件低频时候感觉不到快速滑动时就会出现“进度跳了一下又退回来”的粘滞感。解决思路是给updateProgressFromTouch加一个最小变化阈值计算出的targetProgress与当前getProgress()的差值小于2像素对应的进度值时直接忽略这次事件。private void updateProgressFromTouch(float x) { float usableWidth getWidth() - getPaddingLeft() - getPaddingRight(); if (usableWidth 0) { return; } float ratio (x - getPaddingLeft()) / usableWidth; ratio Math.max(0f, Math.min(1f, ratio)); int target (int) (ratio * getMax()); // 过滤掉变化幅度小于1的事件避免高频刷新 if (Math.abs(target - getProgress()) 1) { setProgress(target); } }另外还有一个隐藏性能点onDraw里每次都通过getMax()和getProgress()计算比例如果setProgress的监听回调里又调用了setProgress会造成synchronized方法的重入等待表现为偶发的ANR卡顿。血泪经验是onProgressChanged回调里不要再去setProgress只在onStopTrackingTouch里做一次结果处理就够。5. 运行与调试把Demo跑起来并验证每个绘制环节5.1 工程结构与依赖配置这个项目不依赖任何三方库纯手写View所以工程导入很简单Android Studio新建一个Empty Activity工程把ImgSeekBar.java复制进包目录attrs.xml合并到values目录三张图片放进drawable目录然后在布局里引用自定义控件。需要注意build.gradle里的minSdkVersion不能低于21因为getActionMasked()虽然老版本也有但getPaddingLeft()在某些系统版本上对绘制逻辑有差异建议最低API 21起步。targetSdkVersion建议跟着你主工程的走不需要特调这个控件不涉及权限和隐私API。布局文件的用法如下com.example.imgseekbar.ImgSeekBar android:idid/seekbar android:layout_widthmatch_parent android:layout_heightwrap_content android:max100 android:paddingLeft12dp android:paddingRight12dp app:imgBackgrounddrawable/seekbar_bg app:imgProgressdrawable/seekbar_progress app:imgThumbdrawable/seekbar_thumb app:barHeight6dp app:thumbSize24dp /注意app:命名空间需要确保根布局标签里声明了xmlns:apphttp://schemas.android.com/apk/res-auto。android:max100沿用系统属性代码里getMax()会自动拿到这个值。如果你忘了加android:paddingLeft和android:paddingRight且你的背景图从视觉上确实需要留出左右边距那么进度条会被画到和背景图边缘对齐视觉上不够“透气”材质设计规范里一般推荐左右留出12dp以上。MainActivity里初始化并设置监听器ImgSeekBar seekBar findViewById(R.id.seekbar); seekBar.setProgress(30); seekBar.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() { Override public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) { // 实时刷新进度文案不能在此回调里再次setProgress } Override public void onStartTrackingTouch(SeekBar seekBar) { // 按下时触发 } Override public void onStopTrackingTouch(SeekBar seekBar) { // 松手时触发适合在这里做上报或动画 } });5.2 图片资源的尺寸与多密度适配图片素材是整个控件的灵魂尺寸没做好代码写得再对效果也出不来。我把建议规格列出来资源建议尺寸说明seekbar_bg.png宽度匹配布局宽度高度为barHeight对应像素例如barHeight6dp在xxhdpi设备下就是18px高图片高度建议等于这个值seekbar_progress.png宽度和背景一致高度一致颜色、纹理与背景区分开即可seekbar_thumb.png正方形例如60x60px建议透明背景圆角方形过大的图片会因缩放变得模糊图源的分辨率建议直接按三倍图导出即背景图高度18px、2倍图12px、默认6px分别放进drawable-xxhdpi、drawable-xhdpi、drawable-hdpi。如果你只放一套图系统会拿它做缩放小屏上会模糊大屏上边缘会有锯齿。进度图宽度要和背景图一样因为进度层按比例绘制宽度小于背景的话进度条永远到不了最右端。5.3 用辅助线和日志验证绘制边界绘制类的调试手段和业务代码不一样断点只能看变量看不到画面。我的习惯是在onDraw里临时加两行辅助线代码Paint debugPaint new Paint(); debugPaint.setColor(0xFFFF0000); debugPaint.setStrokeWidth(1); canvas.drawLine(0, barTop, width, barTop, debugPaint); canvas.drawLine(progressWidth, barTop, progressWidth, barBottom, debugPaint);红色横线确认背景条的上下边界红色竖线确认进度条的终点边界。如果进度到50%时竖线不在控件水平中点说明progressWidth计算有问题。验证完记得删掉这段调试代码或者用一个BuildConfig.DEBUG标志包起来发布包不会带进去。另外可以配合Layout Inspector看三张图的Bounds值是否和你算的一致这个方法检查bounds偏差特别好用。6. 二次开发加上数值气泡指示器和离散刻度吸附6.1 在thumb上方绘制数值气泡把进度数值实时显示在滑块上方是播放器和音频类应用最常见的需求。思路是在onDraw的滑块绘制之后追加一层气泡绘制根据progressWidth算出气泡中心的X坐标在滑块上方留出固定间距画一个圆角矩形里面写当前进度文字。// 在 onDraw 的滑块绘制之后追加 float bubbleCenterX progressWidth; float bubbleTop thumbTop - dp2px(34); RectF bubbleRect new RectF(bubbleCenterX - dp2px(20), bubbleTop, bubbleCenterX dp2px(20), bubbleTop dp2px(24)); canvas.drawRoundRect(bubbleRect, dp2px(4), dp2px(4), bubblePaint); canvas.drawText(String.valueOf(getProgress()), bubbleRect.centerX(), bubbleRect.centerY(), textPaint);实现时注意两个点气泡宽度要能容纳三位数textPaint的文字居中要对齐bubbleRect.centerY()用Paint.setTextAlign(CENTER)加上FontMetrics计算ascent和descent的偏移量否则文字不在气泡垂直中心。气泡超出控件顶部时父布局会裁掉需要给控件layout_height增加一段气泡高度的余量。6.2 离散刻度模式让进度按档位吸附如果要做倍速调节、星级评分这类离散档位的进度条可以在updateProgressFromTouch里把计算出的比例映射到最近的分档位置取值。private int mapToStep(int target) { int stepCount 5; // 档位数 float step getMax() / (float) stepCount; return Math.round(target / step) * Math.round(step); }Math.round本身带四舍五入效果滑到一半时会自动吸附到最近的档位。触摸手感上会有一个“卡点”的反馈用户不需要精确对准刻度线。配合onStopTrackingTouch里回调档位变化适合做倍数选择器。我一般会顺手加一个轻量震动反馈HapticFeedback在ACTION_UP时调用performHapticFeedback手感立刻高级一个档次。从那以后我每次接手新的自定义View都会强制自己先花十分钟梳理绘制和触摸这两条链路的坐标系基准再写代码。毕竟坐标系不统一后面调起来全是玄学这次分享出来希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
