Android滑块验证码：自绘控件与服务端轨迹判定实践

1. 先搞清楚滑块验证码到底防的是谁

注册页被脚本刷短信、登录接口被撞库、活动页被羊毛党批量扫，这几件事我这两年碰到的次数比过去五年加起来都多。一开始团队里的方案是四位数图形码，后来改成算式验证，再后来干脆上滑块。Android 滑块验证码这个方案之所以能在移动端活下来，并不是因为它技术上多高深，而是因为它在“用户操作成本”和“绕过成本”之间找到了一个还算舒服的位置。用户只需要按住往右一推，手指划一下就过去了；而要让脚本自动完成这一步，攻击方得额外投入识别和轨迹模拟的工量。

先说我个人的结论：滑块验证不是一道墙，更像是一道减速带。它真正的价值不是“拦住”，而是“让批量的成本高于收益”。如果你指望靠前端一个自绘控件把攻击全部挡在门外，那方向一开始就错了。我这几年见过的失败案例，八成都是把安全判定放在了客户端：本地算一个坐标，比对一下，返回 true，然后继续流程。这种写法用反编译工具打开就是明文，改两行 smali 就绕过去了。

所以读这篇内容之前，先明确它适合谁看。如果你正在做一个 App，注册、登录、找回密码、领券这些入口被人刷过或者担心被刷，你想自己实现一个不依赖第三方 SDK 的滑块验证控件，那这套东西可以直接拿去改；如果你只是想找个现成的验证组件贴上，那这篇里关于协议设计和轨迹判定的部分可能对你还更有用一些，因为即便用第三方服务，你也要懂这套逻辑才能配好参数。

我在项目里落地过三个版本，从最开始单纯比对 x 坐标，到后来加了轨迹采样、耗时判定、一次性 token，中间踩的坑基本都集中在两个地方：一是图片坐标从原图空间到控件空间的换算，二是触摸事件被父容器抢走。这两个问题后面会单独拆开讲。

1.1 滑块验证防得住什么，防不住什么

这个问题必须放在最前面说清楚，否则后面的架构设计会跑偏。滑块验证能有效拦住的是“低成本的批量脚本”：直接调接口不带验证参数、用固定坐标硬编码提交、用简单的坐标枚举碰运气。这类攻击的实现成本极低，加一道滑块就能挡掉绝大部分，这也是它性价比最高的地方。

它防不住的是定向逆向。因为滑块的正确答案（缺口位置）必然要以某种形式存在于客户端：要么在图片里，要么在接口返回的坐标里。有心人把图片抠出来跑一遍边缘检测，或者直接 hook 内存读字段，都能拿到位置。这一点无法彻底解决，只能提高门槛。我的做法是让“知道位置”不足以通过校验——服务端还要看轨迹、看耗时、看 token 是否一次性、看同一设备短时间内的请求频次。

注意：任何声称“纯客户端就能保证验证安全”的方案都不要信。客户端的定位永远是采集行为数据并上报，判定权必须在服务端。

理解了这条边界，你在做技术选型时就会从容很多：前端部分可以大胆追求体验和美观，把复杂度花在服务端的判定模型上，而不是在前端做各种花哨的加密混淆——那些东西收益很低，维护成本还高。

1.2 三种常见形态的选型对照

同样是滑块，形态差异其实挺大，不同形态对应的实现难度和防护强度完全不同。我做了一张对照表，是我们团队内部选型时用的，直接贴出来：

拼图滑块是我最推荐给绝大多数团队的方案，理由很实际：它的视觉反馈非常直观，用户一看就知道要干什么，学习成本接近零；同时它产生了一次带有方向和时间的连续手势，能采集到的行为特征足够多。纯拖动条虽然实现最简单，但因为终点是固定的最右端，脚本一行代码就能完成，除非你只是想做个“用户是不是在认真操作”的软性提示，否则不建议用。

旋转类方案防护强度更高，但对交互设计要求也高：角度容差设多少、旋转手柄放在哪、用户误操作后怎么回退，这些细节处理不好，通过率会明显下降。我们内部做过一次小范围测试，旋转类的首次通过率比拼图低了将近一成，最后没在核心链路上用，只放在了风控等级最高的提现入口。

2. 架构拆解：客户端只负责画和采，判定交给服务端

这一节是整个项目的地基。我见过太多人一上来就写自定义 View，画得很漂亮，结果接口设计是错的，后面推倒重来的成本非常高。正确的顺序应该是先把一次校验的完整生命周期想清楚，再动手画图。

2.1 一次完整校验的生命周期

整个过程分成四步，每一步都有明确的职责边界。第一步，客户端向后端请求一个 challenge，后端生成随机缺口位置，把背景图和拼图块图（或者一张合成了拼图块的图）返回，同时下发一个一次性 token，并把真实位置、创建时间存进缓存。第二步，用户在客户端拖动，客户端记录拖动过程中的轨迹点、起止时间、最终位移。第三步，松手后客户端把 token、位移值、轨迹数组、耗时一并提交。第四步，后端校验 token 是否有效未过期、位移与真实位置的误差是否在容差内、轨迹是否符合人类特征、耗时是否在合理区间，全部通过才返回一个短期的通行凭证，客户端拿着这个凭证去调真正的业务接口。

这里有个细节容易被忽略：通行凭证必须和业务接口绑定。我见过有的实现是验证通过后直接放行，业务接口完全不校验凭证，那攻击者只要跳过验证页直接调业务接口就行了，整个验证形同虚设。正确的做法是业务接口强制要求带上凭证，后端验签后再执行业务逻辑。

2.2 接口约定与数据模型

接口这块我倾向于把参数设计得“宽进严出”：客户端上报的东西尽量全，方便后端做判定和后续建模；后端返回的东西尽量少，不泄露任何可能帮助攻击者的信息。下面是我们实际用的数据模型，Kotlin 写的，Java 项目直接改写成 POJO 就行：

data class CaptchaChallenge( val token: String, // 一次性凭证 val bgUrl: String, // 带缺口的背景图 val pieceUrl: String, // 拼图块（带透明通道） val originWidth: Int, // 原图宽，用于坐标换算 val originHeight: Int, // 原图高 val pieceWidth: Int, // 拼图块在原图中的宽 val pieceHeight: Int, // 拼图块在原图中的高 val expireAt: Long // 过期时间戳 ) data class SlidePayload( val token: String, val offsetX: Int, // 换算回原图空间的位移 val durationMs: Long, // 从按下到松手的总耗时 val tracks: List<TrackPoint>, val deviceTag: String // 设备标识，用于频次统计 ) data class TrackPoint( val x: Float, val y: Float, val t: Long // 相对按下的毫秒偏移 )

offsetX为什么一定要换算回原图空间？因为控件在不同机型上的宽度不一样，背景图被缩放的比例也不一样。如果直接上报控件内的像素位移，后端拿到的是一个随屏幕变化的数值，没法跟存储的真实位置比较。这个问题我在第一个版本就踩了，测试机上一切正常，换到平板上全部失败，查了半天才发现是缩放比例没换算。

轨迹数组我建议做个简单的抽稀再上传。原始采样点如果按帧记录，一次拖动两秒能有上百个点，序列化后 JSON 体积不小，而且对判定模型来说信息是冗余的。我的做法是保留首尾点，中间按时间间隔大于 20ms 或者位移变化大于 2px 才记录一个，实测下来点数能压到 30 个以内，特征基本没损失。

3. 自绘控件：把背景、缺口和拼图块画出来

到这一步才开始写代码。控件本身不复杂，难点在于测量的兼容性和绘制的性能取舍。我把它拆成三块讲：测量、绘制顺序、坐标换算。

3.1 测量与尺寸计算

控件的高度不能写死，必须跟着背景图的比例走，否则不同尺寸的图会出现拉伸或者留白。我的做法是在onMeasure里根据已知的图片宽高比计算背景区高度，再加上底部滑块条的高度和间距。

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) { val width = MeasureSpec.getSize(widthMeasureSpec) val bgHeight = if (originWidth > 0) { (width * originHeight.toFloat() / originWidth).toInt() } else { width * 9 / 16 // 图片还没加载完时的占位比例 } val totalHeight = bgHeight + trackHeight + trackGap setMeasuredDimension(width, totalHeight) }

trackHeight我一般设成 44dp 到 48dp 之间。低于 44dp 手指按起来会别扭，尤其是冬天手指干燥的时候；高于 48dp 又会让整个控件显得笨重，挤压页面其他元素的空间。这个数值不是拍脑袋定的，是参照了移动端可点击区域的一般经验值，也和我实际测试时的手指感受吻合。

还有一个坑：图片是异步加载的，加载完成后宽高比变了，必须重新调用requestLayout()，否则控件高度不会更新。我第一个版本忘了这一步，表现是图片加载完后被压扁了，看起来很别扭。

3.2 绘制顺序与性能取舍

绘制顺序很关键，错了就会出现拼图块被背景盖住或者滑块条被裁掉的问题。正确的顺序是：背景图、拼图块、遮罩层（可选）、底部轨道、滑块按钮。拼图块要跟随滑块位置移动，所以它的绘制坐标依赖当前的拖动进度。

override fun onDraw(canvas: Canvas) { drawBackground(canvas) drawPiece(canvas) drawTrack(canvas) drawThumb(canvas) } private fun drawBackground(canvas: Canvas) { val bmp = bgBitmap ?: return srcRect.set(0, 0, bmp.width, bmp.height) dstRect.set(0f, 0f, width.toFloat(), bgHeight.toFloat()) canvas.drawBitmap(bmp, srcRect, dstRect, bgPaint) } private fun drawPiece(canvas: Canvas) { val bmp = pieceBitmap ?: return // 把原图空间的拼图尺寸按控件缩放比换算到控件空间 val scale = width.toFloat() / originWidth val pw = pieceWidth * scale val ph = pieceHeight * scale val left = thumbX - thumbRadius + (pieceStartX * scale) val top = (pieceStartY * scale) dstRect.set(left, top, left + pw, top + ph) canvas.drawBitmap(bmp, null, dstRect, bgPaint) }

这里有个性能上的选择值得说一下：我一开始想用invalidate(Rect)做局部刷新，只重绘滑块和拼图块所在的区域，理论上能省一点 GPU 开销。后来实测发现，因为拼图块会横跨整个背景区移动，实际上每次要刷新的区域几乎等于整个控件，局部刷新反而多了一次区域计算的成本。最终我放弃了局部刷新，直接用整块invalidate()。这个例子的启示是：优化要看实际数据，不要看到“局部刷新”这个词就往上套。

Paint对象一定要在成员变量里初始化好，绝对不要在onDraw里 new。onDraw一秒钟可能被调用几十次，每次 new 一个 Paint 会产生大量临时对象，导致 GC 频繁触发，表现出来就是滑动的时候偶尔卡一下。这个坑几乎所有自定义 View 的新手都会踩，我第一次写的时候也踩了。

3.3 缺口坐标的随机生成约束

缺口位置虽然是后端生成的，但生成逻辑里的约束条件值得说清楚，因为它直接影响体验。约束有这么几条：缺口左边距要大于一个最小值，避免拼图块贴边导致视觉上不好判断；右边距也要留够，不能贴着右边缘，因为滑块拖到底部时拼图块要有地方放；纵向位置一般限制在图片高度的中间三分之一区域，太靠上或太靠下会让用户视线来回跳。

fun generateGap(originW: Int, originH: Int, pieceW: Int, pieceH: Int, random: Random): Point { val minLeft = (originW * 0.15f).toInt() val maxLeft = originW - pieceW - (originW * 0.08f).toInt() val minTop = (originH * 0.3f).toInt() val maxTop = originH - pieceH - (originH * 0.25f).toInt() return Point( random.nextInt(maxLeft - minLeft) + minLeft, random.nextInt(maxTop - minTop) + minTop ) }

这套约束看着简单，但每一条都有来由。最左边留 15% 是因为人的手指刚按下时会有轻微抖动，如果缺口就在起手位置旁边，用户还没反应过来就滑过去了，体验很怪。右边留 8% 是为了让拼图块滑动到终点时不会超出背景边界，不然视觉上会“飞出去”。

4. 手势交互：状态机、回弹和轨迹采集

控件画出来只是第一步，能不能用起来舒服，八成取决于这一块的细节。我见过功能完全正确的实现，但因为松手后没有任何反馈，用户以为没点上，反复拖了三四次。

4.1 onTouchEvent 的状态机设计

滑块的触摸处理本质上是一个三态机：空闲、拖拽中、结算中。用两个布尔变量就能表达，没必要引入复杂的状态库。

override fun onTouchEvent(event: MotionEvent): Boolean { when (event.actionMasked) { MotionEvent.ACTION_DOWN -> { if (isInThumbArea(event.x, event.y)) { parent?.requestDisallowInterceptTouchEvent(true) state = State.DRAGGING downX = event.x startAt = SystemClock.uptimeMillis() tracks.clear() tracks.add(TrackPoint(0f, 0f, 0L)) return true } } MotionEvent.ACTION_MOVE -> { if (state == State.DRAGGING) { val dx = (event.x - downX).coerceIn(0f, maxDragDistance) thumbX = dx recordTrack(event.x, event.y, event.eventTime) invalidate() return true } } MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL -> { if (state == State.DRAGGING) { state = State.IDLE parent?.requestDisallowInterceptTouchEvent(false) recordTrack(event.x, event.y, event.eventTime) onSlideEnd(thumbX, SystemClock.uptimeMillis() - startAt) return true } } } return super.onTouchEvent(event) }

requestDisallowInterceptTouchEvent(true)这一行是整个方法里最关键的一句。只要控件放在 ViewPager2、RecyclerView、或者带横向滚动效果的容器里，不加这一行，手指一横滑，事件就被父容器抢走了，表现是滑块拖到一半突然不动了。这个问题的排查难度在于：单独把控件放在一个空 Activity 里测试完全正常，一放进真实页面就复现，很容易被误判成控件的绘制问题。

触摸热区也要适当扩大。用户不会精确地按在滑块正中心，按偏一点点就点不中会让人很烦躁。我的做法是把判断区域的上下左右各外扩 8dp，同时用 ViewConfiguration 的 scaledTouchSlop 做最小移动判定，避免轻微的抖动被当成拖动。

4.2 松手后的吸附与失败反馈

松手之后必须给反馈，而且反馈要能表达三种结果：成功、失败、还需要继续拖。成功的反馈是拼图块吸附到缺口位置并高亮一下；失败的反馈是滑块弹回起点，同时给一个短促的左右抖动；如果用户根本没拖到位，就直接回弹，不触发校验。

回弹动画我用的是ObjectAnimator，因为它足够简单，不需要引入额外的物理引擎。抖动动画也是同理，左右各 6dp，来回三次，总时长 300ms 左右，太长会让人等得烦，太短又感知不到。

private fun shakeAndReset() { val reset = ObjectAnimator.ofFloat(this, "thumbX", thumbX, 0f) val shake = ObjectAnimator.ofFloat(this, "thumbX", 0f, -6f, 6f, -4f, 0f) AnimatorSet().apply { playSequentially(shake, reset) duration = 420 start() } }

这里的thumbX要用@JvmName或者自定义 setter 触发invalidate()，否则动画改了值但画面不刷新。这个小细节我第一次写的时候漏了，动画跑完了界面还停在原地，查了半小时才发现是属性 setter 没通知重绘。

4.3 轨迹采集的采样策略与人类特征

轨迹采集看着像是最枯燥的部分，其实是整个方案里最有价值的一环，因为它是区分人和脚本的核心依据。采样策略上，我按时间间隔采：距离上一个采样点超过 16ms 就记一个，也就是大约一帧一个点。这样既能保证运动细节不丢，又不会因为触摸事件的密集回调把数组撑爆。

采集到的轨迹应该具备哪些人类特征？我总结了四条实际用到的判据。一是起点抖动：人按下之后通常有一小段几乎没位移的时间，脚本往往是一上来就匀速移动。二是速度曲线：人的拖动是加速再减速的，中间有波动，脚本的速度往往恒定或者呈完美线性。三是纵向漂移：人的手指横向拖动时 y 坐标会有几像素的自然波动，脚本常常 y 恒定不变。四是总耗时的区间：正常操作一般在 600ms 到 3000ms 之间，低于 300ms 的多半是脚本或者误触，高于 5000ms 的可能是用户在犹豫，判定时要放宽。

提示：这四条判据不要做成一票否决，做成打分制更稳妥。我给每一条分配权重，总分低于阈值才判定为异常，这样能大幅降低误伤真实用户的概率。

说实话，这套判定模型需要数据喂养。上线初期我建议只记录不拦截，跑一周看看真实用户的分布，再定阈值。我们第一版阈值定得太严，导致一部分老年用户和手部不便的用户反复失败，后来把耗时上限放宽到 8 秒才好起来。

5. 封装成“5 行代码”的接入方式

标题里说的 5 行代码，指的是封装之后调用方的接入量，不是控件本身的实现只有 5 行。这个概念要分清楚，否则容易被人误解成“随便贴贴就行”。封装的价值在于把加载图片、处理生命周期、失败重试这些琐碎逻辑收进去，让业务方只关心结果。

5.1 DSL 风格的调用封装

我用 Kotlin 的扩展函数加 lambda 做了一层很薄的封装，调用方看起来就像在配置一个普通控件：

sliderCaptcha.apply { onVerifyResult = { payload -> viewModel.submit(payload) } onLoadFailed = { fallbackToSmsCode() } load() }

业务侧真正要写的就这么几行，剩下的内容都在封装层里。封装层负责的事情包括：请求 challenge 接口、下载两张图并做采样压缩、把图片设置给控件、在onDetachedFromWindow时取消未完成的请求、在验证成功后自动清理。

图片下载这里有个必须做的优化：一定要用BitmapFactory.Options的inSampleSize做降采样。背景图原图可能是 1080×600 甚至更大，而控件实际显示宽度也就 300dp 出头，直接加载原图纯属浪费内存，在低端机上很容易触发 OOM。计算inSampleSize的公式很简单，先算出目标宽度和原图宽度的比例，取这个比例的倒数向下取整到 2 的幂。

fun calcInSampleSize(options: BitmapFactory.Options, reqWidth: Int): Int { val rawWidth = options.outWidth var sample = 1 while (rawWidth / (sample * 2) >= reqWidth) { sample *= 2 } return sample }

这段代码我在好几个项目里都复用，实测下来内存占用能降六七成，视觉上看不出差别。

5.2 老项目与 Compose 的兼容处理

Java 老项目接入的话，把控件直接当普通 View 用就行，回调改成接口实现。需要注意的是 Java 里没有默认参数，构造方法要写全三个，否则在 XML 里引用会崩溃。这个报错信息很不友好，只告诉你找不到构造方法，新手容易卡住。

Compose 项目里我一般不去重写一遍，而是用AndroidView把这个控件包一层，改造成本最低：

@Composable fun SliderCaptcha(modifier: Modifier = Modifier, onResult: (SlidePayload) -> Unit) { AndroidView( modifier = modifier, factory = { ctx -> SliderCaptchaView(ctx).apply { this.onVerifyResult = onResult } }, update = { view -> view.load() } ) }

纯 Compose 重写当然也可以，用Canvas加pointerInput就能实现，但如果项目里已经有这个自绘控件，包一层是最省事、最不容易出 bug 的选择。我在一个纯 Compose 项目里试过重写，绘制部分没问题，麻烦的是图片异步加载和状态恢复，最后算下来省不了多少时间。

5.3 失败降级与兜底策略

这条我觉得比滑块本身还重要，因为它决定了最坏情况下的用户流失率。必须预设三种兜底：图片加载失败、验证连续失败、网络异常。

图片加载失败的兜底是本地内置一张图，缺口位置随机生成，虽然防护强度下降了，但至少流程不断。连续失败三次以上，直接切到短信验证码或者语音验证码，不要死磕滑块——用户已经失败三次了，再让他拖第四次，大概率直接卸载。网络异常就更好处理，给个重试按钮，同时把 token 标记作废，下次重新申请。

我们线上跑的数据是：滑块通道的验证通过率在 92% 左右，剩下 8% 里有一多半是网络或者图片加载问题，真正因为轨迹判定被拒的不到 2%。所以优化重点应该放在加载成功率上，而不是把判定阈值调得更严。

6. 常见问题与排查实录

这一节是我这几年被问得最多的问题合集，基本覆盖了 90% 的落地障碍。

6.1 高频问题速查表

先上速查表，遇到问题先对号入座，能省不少时间：

6.2 几个印象深刻的排查过程

第一个印象最深的是坐标换算的问题。测试同学报的现象是“小米某机型上十次有九次失败”，其他机型正常。我一开始怀疑是屏幕密度的问题，查了半天不是。后来把上报的 offsetX 和后端存的位置打印出来对比，发现上报值总是偏大，比例大概是 1.3 倍。原因找到了：这个机型的屏幕宽度比较大，控件被拉宽，背景图放大后缺口位置也跟着放大，但上报时用的是控件坐标没换算回去。修完之后所有机型一次通过。

第二个是触摸事件被抢的问题。这个问题的迷惑性在于它跟页面结构有关，控件单独用没事，放进横向滚动的卡片列表里就废了。排查方法很简单，在onTouchEvent的每个分支加日志，看 ACTION_MOVE 是否只进来一两次就没了。如果只进来一两次，基本可以确定是被父容器拦截。这个问题的标准解法就是那句requestDisallowInterceptTouchEvent，但要记得在 UP 和 CANCEL 的时候恢复成 false，否则会影响页面其他区域的滚动。

第三个是动画不刷新。前面提过，ObjectAnimator直接改成员变量，如果没有对应的 setter 触发invalidate()，画面不会变。这个问题在 Debug 包里不明显，因为其他原因触发重绘的频率高，Release 包里就暴露了。我的建议是凡是参与动画的属性，一律写显式 setter。

注意：如果你在控件里用了协程做图片加载，一定要绑定生命周期，在onDetachedFromWindow里取消。我见过因为在 RecyclerView 里被复用时协程没取消，图片回调打到了已经复用的 ViewHolder 上，显示成别人的图。

6.3 无障碍与特殊场景的补丁

这块容易被忽略，但确实会影响一部分用户。控件必须设置合适的contentDescription，让读屏软件能读出来“拖动滑块完成验证”。拖动过程中可以通过announceForAccessibility播报当前进度百分比，虽然啰嗦，但对完全依赖读屏的用户来说，这是唯一能感知状态的方式。

另外，如果项目需要支持外接键盘或者电视遥控器，滑块的触摸操作是完全不可用的。这种情况我一般直接降级到短信验证码，不去强行适配方向键控制滑块——硬做的结果往往是操作极其别扭，还不如不给。

还有个细节是防误触。有些用户习惯用手掌边缘滑，这时候触摸事件的getToolType会返回不明确的值，我的处理是只响应TOOL_TYPE_FINGER和TOOL_TYPE_UNKNOWN，其他类型直接忽略。这个改动上线后，客服反馈的“拖了没反应”类工单少了不少。

最后再分享一个我在实际项目里的体会：滑块验证这套东西，前端部分大概占三成工作量，剩下七成都在服务端的判定和风控上。如果你的团队资源有限，前端不要过度设计，把自绘控件做稳定、坐标换算做准确、降级路径做完整，这三件事做好就已经能挡住绝大多数批量请求了。真正需要投入精力的地方，是那条从“用户拖了一下”到“系统判断这是不是人”的链路，以及失败之后用户还能不能顺利走完流程。我在第二个项目里就吃过亏，前端控件做得花里胡哨，结果服务端判定逻辑只有一句“误差小于 5 像素就通过”，上线第三天就被刷了。后来老老实实把轨迹判定补上，才算是把窟窿堵住。