1. 滑块验证码真正在防什么以及“5行代码”这个说法该怎么理解这两年做 Android 端登录、注册、找回密码这类页面只要稍微有点规模安全或者风控那边总会提出一个要求给入口加一道滑块验证码。原因不复杂单靠图形字符验证码已经被打得很惨了而滑块验证码在用户体验和防护成本之间找到了一个还不错的平衡点。它的核心诉求不是“挡住所有人”而是把机器批量请求的成本抬到一个不划算的位置同时保证正常用户一次就能过去。如果你正在做 Android 端的登录页、活动页、短信发送入口或者单纯想搞清楚这一类交互控件的实现原理下面这些内容应该都能直接拿去用。先泼一盆冷水。标题里说的“5行代码”我理解它指的是业务接入层的那几行——控件初始化、设置回调、拿到结果、拿着 token 去请求接口确实差不多五行。但如果你真以为整个滑块验证码只有五行那大概率会在联调阶段被现实教育坐标错位、拼图块糊成一片、用户手指一抬就白屏、安全同学一句“这个能直接抓包拿到目标位置”就把方案打回来。所以这篇我想按真实落地的顺序来写先讲清楚它的原理和边界再一行一行把控件写出来最后把踩过的坑列成表。1.1 一道滑块背后的三层校验很多人对滑块验证码的理解停留在“拖动距离够不够”。实际上一个能上线用的方案至少有三层第一层是交互层。用户按住滑块横向拖动松手后判断拼图块的横向位置和缺口的横向位置偏差是否在容差范围内。这一层只在客户端做作用是给出即时反馈让用户知道“我拖得对不对”。多数场景容差给到 5 到 10 个物理像素就够给太大容易被暴力枚举给太小会让手指粗糙的用户反复失败。第二层是行为层。人在拖动的时候速度曲线是“先加速、中途波动、临近终点减速”的中间还会有几毫秒的停顿和纵向抖动。而脚本通常是匀速直线或者用贝塞尔曲线做得很平滑但没有微抖动。这一层采集的是拖动过程中的采样点包含相对时间、X 偏移、Y 偏移最终形成一条轨迹交给后端做特征比对。这一层才是真正拉开人和机器差距的地方。第三层是凭证层。校验通过之后后端下发一个一次性的、带过期时间的 token业务接口比如发送短信、登录必须带着这个 token 才能放行。这样即使有人把验证码控件的逻辑逆向了也没法凭空造出一个有效凭证因为他造不出后端签发的签名。这三层里第一层决定体验第二层决定防护强度第三层决定最终能不能守住业务。只做第一层等于在门口挂了一块“请勿入内”的牌子三层都做才算是装了一道门。1.2 5行代码指的是接入层不是全部我把业务侧真正需要写的东西整理一下大概长这样sliderCaptcha.onResult { result - when (result) { is SliderResult.Success - loginViewModel.submit(result.token) is SliderResult.Failed - toast(验证失败请重试) } } sliderCaptcha.load()确实是五行左右。但这段代码背后你需要一个能画的 View、一套能采到轨迹的触摸逻辑、一个图片下发接口、一个校验接口还有容错和重试策略。这些是控件作者要做的事接入方可以完全不关心——这才是“5行代码”这个说法真正的价值把复杂度收敛在控件内部对外只暴露一个结果回调。顺带说一句如果你的 App 只有一个登录页需要滑块接入方和控件作者是同一个人那“5行”就没什么意义老老实实把原理搞懂更重要。2. 方案选型自绘控件、现成库还是换一种形态动手之前我对比过几条路这里把结论摆出来省得你重复走一遍。2.1 三条路线的对比路线开发成本视觉可控性轨迹数据掌控体积影响适用场景自绘自定义 View中2 到 3 人天可出可用版本完全可控完全自己说了算几乎为零想统一 UI 规范、要自定义轨迹采集、包体积敏感引入第三方验证 SDK低半天接入受限于对方提供的样式通常拿不到原始轨迹视 SDK 而定几 MB 到十几 MB项目排期紧、没有风控自研能力、愿意接受外部依赖WebView 承载 H5 验证页低由 H5 决定需要 JS 桥接小已有成熟的 Web 端方案、多端复用第三方 SDK 的优势是把“图片下发、轨迹判定、token 签发”整套都打包好了你只需要接一个回调风险模型也经过大量线上数据打磨。但它的问题也明显包体积上去了视觉风格和自己的 App 未必一致轨迹数据你也拿不到没法跟自己已有的风控系统做特征融合。WebView 那条路在多端统一的项目里很常见好处是 Web 和 App 复用同一套后端接口坏处是首屏加载会有一个明显的白屏时间弱网下体验相当差而且拖动手势和原生页面滚动容易打架。2.2 我为什么最后还是自己写控件说几个决定性的理由。第一是坐标安全。不少现成方案会把缺口的目标 X 直接下发到客户端虽然做了简单加密或者混淆但只要有人在运行时把内存里的值 dump 出来这个方案就废了。自研的话我可以把目标 X 完全留在服务端客户端只上报“我把拼图拖到了哪个 X”比对在后端做客户端拿不到答案就没有作弊入口。第二是轨迹数据。已有的风控系统里通常会有一套行为特征模型我希望滑块的轨迹能直接喂进去包括按下到抬起的毫秒数、每一步的 delta、纵向抖动幅度。第三方 SDK 一般只给一个“通过/不通过”拿不到原始数据。第三是视觉一致性。我们的设计体系里有明确的圆角、阴影、主色规范第三方 SDK 的皮肤定制能力有限最后做出来总有点“贴上去”的感觉。当然如果你只是想在内部后台的登录页上加一道门槛用现成方案完全没问题别为了自研而自研。3. 把坐标体系理顺后面 80% 的坑都能绕过去我见过太多同学在这一步栽跟头拼图块总是偏一点或者在不同的屏幕上偏移量还不一样。根因几乎都是坐标系混用。3.1 三个坐标系不要混用一个滑块验证控件里同时存在三套坐标第一套是原图坐标也就是服务端下发的图片自身的像素坐标比如 600×300 的位图。缺口的目标位置、拼图块的裁剪区域都在这套坐标里描述。第二套是控件坐标也就是 View 内部的绘制坐标单位是 px原点在 View 左上角范围是0..width × 0..height。因为图片是按控件尺寸缩放绘制的所以需要一个scale viewWidth / bitmapWidth的映射。第三套是触摸坐标MotionEvent给出的x、y同样是相对 View 左上角的 px但它还带有rawX、rawY这样的屏幕绝对坐标。拖动逻辑只用event.x千万别混进rawX否则页面一滚动位置就全乱了。我的做法是控件内部只存控件坐标服务端下发的图片只负责绘制所有比较、上报、动画统一用控件 px。上报给服务端的值再换算回原图比例// 上报比例而不是绝对像素避免不同分辨率下容差失真 val reportRatio pieceX / (width - pieceWidth).toFloat()用比例而不是像素上报好处是后端只需要一个 0 到 1 的浮点容差阈值而不用关心用户的手机宽度。3.2 触摸命中判定与事件消费自定义 View 想收到ACTION_MOVE和ACTION_UP有两个前置条件onTouchEvent必须在ACTION_DOWN时返回true或者 View 设置了clickable true。我见过有人onTouchEvent里只处理 DOWN 就返回了 false结果 MOVE 一次都收不到还以为是自己写的拖动逻辑有问题。override fun onTouchEvent(event: MotionEvent): Boolean { when (event.actionMasked) { MotionEvent.ACTION_DOWN - { if (!hitTestSlider(event.x, event.y)) return false dragging true downX event.x startPieceX pieceX track.clear() record(event) performClickSafely() return true // 关键返回 true 才能继续收 MOVE } MotionEvent.ACTION_MOVE - { if (!dragging) return false record(event) updatePieceX(event.x - downX startPieceX) return true } MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL - { if (!dragging) return false dragging false onRelease() return true } } return super.onTouchEvent(event) }hitTestSlider我建议做成“滑块热区比视觉区域上下各扩 12dp”因为手指按压点未必精准落在滑块上尤其是单手操作的时候。实测下来这个扩展能显著降低“点了没反应”的投诉率。还有一点容易忽略父容器的拦截。如果滑块控件放在ScrollView或者ViewPager2里用户横向拖动时可能被父容器抢走事件。处理方式是在控件内部调用parent.requestDisallowInterceptTouchEvent(true)在ACTION_UP或ACTION_CANCEL时再放开。4. 从零实现背景、缺口、拼图块怎么画出来4.1 图片下发与二次采样服务端下发的底图尺寸建议控制在 600×300 到 720×360 之间格式用 WebP 或者 JPEG 质量 80。更大的图在移动端没必要反而增加解码开销。客户端加载的时候一定要做二次采样。控件宽度往往只有 300dp 左右一张 720 宽的图直接BitmapFactory.decodeStream会申请好几 MB 的堆内存放在列表里滚几下就 OOM 了。fun decodeSampled(stream: InputStream, reqWidth: Int, reqHeight: Int): Bitmap { val opts BitmapFactory.Options().apply { inJustDecodeBounds true } val bytes stream.readBytes() BitmapFactory.decodeByteArray(bytes, 0, bytes.size, opts) opts.inSampleSize calculateInSampleSize(opts, reqWidth, reqHeight) opts.inJustDecodeBounds false opts.inPreferredConfig Bitmap.Config.RGB_565 // 底图不需要 alpha省一半内存 return BitmapFactory.decodeByteArray(bytes, 0, bytes.size, opts) }注意inPreferredConfig用RGB_565只适用于底图。拼图块因为要用 Path 裁剪出透明边缘必须是ARGB_8888否则边缘会发黑。4.2 缺口轮廓的绘制缺口形状如果只是矩形视觉上有种“没做完”的感觉。我一般用一个矩形加两段贝塞尔曲线做出不规则的凸起既有辨识度脚本也不容易靠边缘检测逆推出精确位置。private fun buildPiecePath(w: Float, h: Float): Path Path().apply { moveTo(0f, 0f) lineTo(w * 0.42f, 0f) cubicTo(w * 0.42f, -h * 0.20f, w * 0.70f, -h * 0.20f, w * 0.70f, 0f) lineTo(w, 0f) lineTo(w, h * 0.55f) cubicTo(w * 1.16f, h * 0.55f, w * 1.16f, h * 0.86f, w, h * 0.86f) lineTo(w, h) lineTo(0f, h) close() }这里有两个实操要点。一是cubicTo的控制点会超出0..w的范围所以绘制的时候canvas必须做一次clipRect否则拼图块的凸起部分会画到 View 边界外面去在父容器里留一条脏边。二是我把凸起的幅度控制在宽高的一小段比例内太夸张的形状在小屏手机上会让用户看不出这是拼图。缺口本身在底图上怎么表现常见做法有两种一种是直接挖空用PorterDuff.Mode.CLEAR另一种是叠加一层半透明黑。我倾向后者的变体——在缺口区域盖一层 alpha 约 0.35 的黑色遮罩并且加一条 1px 的浅色描边。理由很简单如果底图刚好在那个位置是浅色挖空之后用户根本看不出缺口在哪。4.3 onDraw 里的绘制顺序与离屏缓冲onDraw的执行顺序直接影响性能和观感我固定成这个次序绘制缩放后的底图绘制缺口遮罩Path 半透明画刷save()后平移画布到pieceX再用clipPath裁出拼图区域绘制拼图块位图restore()绘制滑块轨道和圆形滑块。第 3 步有两种实现方式。用PorterDuffXfermode做SRC_IN可以但它会触发离屏缓冲saveLayer在低端机上滑动会明显掉帧。我改用clipPath之后再drawBitmap硬件加速下走的是剪切路径开销小很多。代价是边缘抗锯齿略差可以通过给 Paint 开isAntiAlias加一层描边来补偿。另外一个细节onDraw里不要 new 对象。RectF、Paint、Path全部作为字段提前创建好每次只改值。这个习惯在调试时不明显但一个页面里如果有多个自定义控件同时刷新GC 抖动会非常直观。5. 拖动交互与轨迹采集的实操细节5.1 拖动逻辑与回弹动画拖动过程中pieceX的更新很直接但要限制在0..(width - pieceWidth)之间越界了做一次阻尼效果。阻尼我用的是一条简单公式private fun clampWithResistance(raw: Float): Float { val max (width - pieceWidth).toFloat() return when { raw 0f - -sqrt(-raw) * 6f raw max - max sqrt(raw - max) * 6f else - raw } }这样拖到底还能再往外带一点点手感上会“软”一些比硬邦邦地卡住舒服。松手后的回弹用ValueAnimator从当前位置回到 0时长 260ms插值器用DecelerateInterpolator。这里有个体验细节失败回弹时先停顿 120ms 再动画回位如果立刻弹回去用户会以为自己没按到会疯狂重复拖动。5.2 轨迹数据结构与采样频率轨迹点我定义成这样一个结构data class TrackPoint( val t: Long, // 相对按下时刻的毫秒数 val x: Float, // 控件坐标保留一位小数足够 val y: Float )采样不能每个 MOVE 事件都记。MotionEvent在 60Hz 屏幕上大约 16ms 一次在 120Hz 上能到 8ms全部记录会让上报体积翻倍而且高频抖动对判定没有帮助。我的策略是按时间窗口采样最小间隔 12ms同时强制记录终点一条正常的拖动轨迹大概 30 到 60 个点序列化之后 2KB 以内完全可以随请求一起提交。有一点务必注意上报的t必须是相对时间且不能由客户端单独决定可信度。所有时间戳在服务端只作为特征参考不能作为判定“是否超时”的唯一依据否则改了手机系统时间就能绕过。5.3 本地判定与服务端判定怎么分工这里我要说一个非常容易做错的点。如果服务端把缺口的目标 X 下发给客户端客户端本地判断“偏差 8px 就通过”那这个方案基本等于没有因为攻击者只需要 hook 一下拿到 targetX直接调用通过逻辑就行。正确的分工是客户端只做视觉呈现和交互松手后把{token, trackList, finalRatio, durationMs}上报服务端持有targetRatio比对偏差、检查轨迹特征、检查 token 有效期和一次性通过后签发业务 token客户端拿到服务端返回的成功/失败再决定动画方向。那客户端怎么知道拼图块该画在哪儿不知道。它只知道拼图块现在被拖到了哪个位置具体对不对等后端说话。这样实现的好处是即使有人在客户端把整个控件逆向了他也拿不到答案。6. 安全加固几件让脚本不那么好写的事6.1 图片与坐标不下发明文服务端生成校验图的时候我建议的流程是从图库里挑一张底图在服务端随机取一个 Y 比例和 X 比例在那里裁剪出拼图块返回三个东西——底图不带缺口、拼图块带透明边的 PNG、一个随机 token。目标 X 比例只存在 Redis 或者缓存里key 就是 token有效期 2 分钟。这里还有个小优化拼图块返回之前做一次随机的轻微旋转或者透明度渐变让它在视觉上像是“浮起来”的同时增加图像识别的难度。不过旋转角度别超过 3 度超过了用户自己都对不齐。6.2 一次性 token 与有效期token 必须满足三个条件随机性足够用安全随机数生成长度 32 位以上、一次性校验成功或失败都立即失效、有有效期我一般给 120 秒。这三个条件不满足任何一个都可能被重放。顺带说校验失败也要消耗 token。有些实现失败后不删 token攻击者可以用同一个 token 反复试不同的 X理论上几百次就能试出来。这是个很隐蔽但很致命的漏洞。6.3 风控联动滑块不是万能的滑块验证码的定位是“抬高批量请求成本”不是“绝对防住”。真实的风控系统里它通常和这些信号一起工作设备指纹是否异常、同 IP 在时间窗口内的请求频次、账号历史行为、请求的 UA 与传感器特征是否匹配。所以我个人的做法是滑块的校验结果只作为一个加权因子不作为唯一放行条件。同时对“短时间内多次校验失败”的会话做降级处理比如直接要求走更强的验证方式而不是让他在滑块上一直试。7. 常见问题与排查实录7.1 坐标与点击类问题拼图块总是偏右或者偏左一段固定距离八成是把event.rawX和event.x混用了或者滑块在拖动时父布局有 padding 没减掉。排查方法很简单在 DOWN 时打一条日志把event.x和event.rawX都打出来如果两者差值等于控件在屏幕上的位置那就是用错了。拖不动或者只能拖一次检查onTouchEvent的 DOWN 分支是否返回了 false。另外检查performClick()有没有被调用虽然不调用不影响功能但无障碍服务和无痕测试工具会报错。松开后没有回弹多半是ValueAnimator被复用了但没cancel()上一次的动画导致新旧动画互相覆盖。养成习惯每次启动新动画前先cancel()。7.2 内存与性能类问题滑动时掉帧按前面的建议把onDraw里的对象分配全部提到字段上同时确认没有用PorterDuffXfermode配合saveLayer。页面退出后 OOM底图和拼图块这两个 Bitmap 需要在onDetachedFromWindow里主动recycle()并置空。虽然现代 Android 的 GC 能处理但图片尺寸较大的时候及时释放能显著降低峰值内存。首次加载有白屏如果用网络图片务必在控件内部先画一个占位骨架一个浅灰的圆角矩形加一条呼吸动画不要让用户盯着空白。7.3 适配与兼容类问题深色模式下拼图块边缘发黑拼图块位图的 config 必须是ARGB_8888且绘制时Paint不能开filterBitmap false否则缩放会有硬边。横屏或者平板下拼图变形控件高度固定但宽度随屏幕拉伸时缩放比例要用max而不是按宽度算同时底图用centerCrop的方式裁切避免拉伸。RTL 语言环境下滑块跑到右边如果产品要支持 RTL滑块的起始位置需要用layoutDirection判断或者干脆强制 LTR因为滑动方向本身就是从右到左的语言习惯里也是从左往右拖。7.4 问题速查表现象高概率原因快速验证方式处理方式拼图块偏移固定值坐标系混用打印event.x与event.rawX统一用控件坐标拖一下就卡住DOWN 返回 false 或父容器拦截打日志看 MOVE 是否进来返回 true 禁止父容器拦截拼图块边缘有黑边位图 config 不是 ARGB_8888打印bitmap.config改用 ARGB_8888滑动掉帧onDraw 内分配对象或用了离屏缓冲开 GPU 渲染分析看过度绘制复用对象改用 clipPath偶尔校验失败容差过小或上报比例为 px对比上报值和服务端值上报比例 容差 6 到 10px退出页面后内存不降未回收 Bitmap用内存分析工具看引用链onDetachedFromWindow 里 recycle8. 让它好看视觉与反馈的打磨8.1 视觉规范滑块的视觉部分其实就这么几个元素轨道、滑块、拼图块、缺口遮罩。但要把它们做“好看”我的经验是三个统一。圆角统一轨道、滑块、拼图块、遮罩的圆角半径都取同一个基础值比如 8dp不要一个 4 一个 12。阴影克制滑块只用一层 2dp 高度的柔和阴影阴影颜色用主色的深色版本加很低的不透明度不要用纯黑纯黑在浅色背景上会显得脏。留白均匀轨道和控件上下边缘的间距等于滑块半径视觉上最舒服。配色上轨道的未填充部分用一层很浅的灰比背景深一档填充部分用主色滑块用白色加一点点描边。这样用户一眼就能看出“已经走了多远”。8.2 动效与状态反馈成功的反馈我是这样做的拼图块落到缺口位置后先把遮罩的 alpha 从 0.35 动画到 0 并保持 180ms然后整个控件淡出并向业务回调。失败的话滑块颜色短暂变红同时做一次水平抖动抖动幅度控制在 6dp 以内太快太猛都会显得廉价。拖动过程中滑块的尺寸可以随拖动进度从 1.0 缩到 0.92 再回弹这种“按下有反馈”的细节对质感提升非常明显代码也就两行scaleX。还有一个我特别喜欢的小设计拖动时让拼图块带着一点轻微的跟随阴影位移越大阴影越深。视觉上会让人觉得这个块是“浮在图上”的而不是贴上去的色块。8.3 无障碍与测试contentDescription要写上“拖动滑块完成验证”并且在成功和失败时通过announceForAccessibility播报状态视障用户才知道发生了什么。另外performClick()一定要在 DOWN 里调用不然无障碍服务点了没反应。测试方面我一般会写两组。一组是纯逻辑的单测给固定的targetRatio和一组人工构造的轨迹验证判定函数是否正确包括匀速直线应该拒绝、带抖动的缓入缓出应该通过、以及时间过短应该拒绝。另一组是手工回归清单重点覆盖不同屏幕尺寸、深色浅色主题、横竖屏切换、弱网图片加载失败、以及连续快速失败三次后的降级逻辑。我在实际项目里踩得最深的一个坑是弱网。图片请求超时了但控件没有超时回调用户就一直看到占位骨架以为页面卡死最后是给图片加载加了一个 8 秒超时并把错误态做成“点击重试”的文案才解决。这类问题的共同点是功能逻辑写对了但边界状态没人管。所以后来我写这个控件的习惯是先把所有失败态列一遍再写正经逻辑反而更快。
1. 滑块验证码真正在防什么以及“5行代码”这个说法该怎么理解这两年做 Android 端登录、注册、找回密码这类页面只要稍微有点规模安全或者风控那边总会提出一个要求给入口加一道滑块验证码。原因不复杂单靠图形字符验证码已经被打得很惨了而滑块验证码在用户体验和防护成本之间找到了一个还不错的平衡点。它的核心诉求不是“挡住所有人”而是把机器批量请求的成本抬到一个不划算的位置同时保证正常用户一次就能过去。如果你正在做 Android 端的登录页、活动页、短信发送入口或者单纯想搞清楚这一类交互控件的实现原理下面这些内容应该都能直接拿去用。先泼一盆冷水。标题里说的“5行代码”我理解它指的是业务接入层的那几行——控件初始化、设置回调、拿到结果、拿着 token 去请求接口确实差不多五行。但如果你真以为整个滑块验证码只有五行那大概率会在联调阶段被现实教育坐标错位、拼图块糊成一片、用户手指一抬就白屏、安全同学一句“这个能直接抓包拿到目标位置”就把方案打回来。所以这篇我想按真实落地的顺序来写先讲清楚它的原理和边界再一行一行把控件写出来最后把踩过的坑列成表。1.1 一道滑块背后的三层校验很多人对滑块验证码的理解停留在“拖动距离够不够”。实际上一个能上线用的方案至少有三层第一层是交互层。用户按住滑块横向拖动松手后判断拼图块的横向位置和缺口的横向位置偏差是否在容差范围内。这一层只在客户端做作用是给出即时反馈让用户知道“我拖得对不对”。多数场景容差给到 5 到 10 个物理像素就够给太大容易被暴力枚举给太小会让手指粗糙的用户反复失败。第二层是行为层。人在拖动的时候速度曲线是“先加速、中途波动、临近终点减速”的中间还会有几毫秒的停顿和纵向抖动。而脚本通常是匀速直线或者用贝塞尔曲线做得很平滑但没有微抖动。这一层采集的是拖动过程中的采样点包含相对时间、X 偏移、Y 偏移最终形成一条轨迹交给后端做特征比对。这一层才是真正拉开人和机器差距的地方。第三层是凭证层。校验通过之后后端下发一个一次性的、带过期时间的 token业务接口比如发送短信、登录必须带着这个 token 才能放行。这样即使有人把验证码控件的逻辑逆向了也没法凭空造出一个有效凭证因为他造不出后端签发的签名。这三层里第一层决定体验第二层决定防护强度第三层决定最终能不能守住业务。只做第一层等于在门口挂了一块“请勿入内”的牌子三层都做才算是装了一道门。1.2 5行代码指的是接入层不是全部我把业务侧真正需要写的东西整理一下大概长这样sliderCaptcha.onResult { result - when (result) { is SliderResult.Success - loginViewModel.submit(result.token) is SliderResult.Failed - toast(验证失败请重试) } } sliderCaptcha.load()确实是五行左右。但这段代码背后你需要一个能画的 View、一套能采到轨迹的触摸逻辑、一个图片下发接口、一个校验接口还有容错和重试策略。这些是控件作者要做的事接入方可以完全不关心——这才是“5行代码”这个说法真正的价值把复杂度收敛在控件内部对外只暴露一个结果回调。顺带说一句如果你的 App 只有一个登录页需要滑块接入方和控件作者是同一个人那“5行”就没什么意义老老实实把原理搞懂更重要。2. 方案选型自绘控件、现成库还是换一种形态动手之前我对比过几条路这里把结论摆出来省得你重复走一遍。2.1 三条路线的对比路线开发成本视觉可控性轨迹数据掌控体积影响适用场景自绘自定义 View中2 到 3 人天可出可用版本完全可控完全自己说了算几乎为零想统一 UI 规范、要自定义轨迹采集、包体积敏感引入第三方验证 SDK低半天接入受限于对方提供的样式通常拿不到原始轨迹视 SDK 而定几 MB 到十几 MB项目排期紧、没有风控自研能力、愿意接受外部依赖WebView 承载 H5 验证页低由 H5 决定需要 JS 桥接小已有成熟的 Web 端方案、多端复用第三方 SDK 的优势是把“图片下发、轨迹判定、token 签发”整套都打包好了你只需要接一个回调风险模型也经过大量线上数据打磨。但它的问题也明显包体积上去了视觉风格和自己的 App 未必一致轨迹数据你也拿不到没法跟自己已有的风控系统做特征融合。WebView 那条路在多端统一的项目里很常见好处是 Web 和 App 复用同一套后端接口坏处是首屏加载会有一个明显的白屏时间弱网下体验相当差而且拖动手势和原生页面滚动容易打架。2.2 我为什么最后还是自己写控件说几个决定性的理由。第一是坐标安全。不少现成方案会把缺口的目标 X 直接下发到客户端虽然做了简单加密或者混淆但只要有人在运行时把内存里的值 dump 出来这个方案就废了。自研的话我可以把目标 X 完全留在服务端客户端只上报“我把拼图拖到了哪个 X”比对在后端做客户端拿不到答案就没有作弊入口。第二是轨迹数据。已有的风控系统里通常会有一套行为特征模型我希望滑块的轨迹能直接喂进去包括按下到抬起的毫秒数、每一步的 delta、纵向抖动幅度。第三方 SDK 一般只给一个“通过/不通过”拿不到原始数据。第三是视觉一致性。我们的设计体系里有明确的圆角、阴影、主色规范第三方 SDK 的皮肤定制能力有限最后做出来总有点“贴上去”的感觉。当然如果你只是想在内部后台的登录页上加一道门槛用现成方案完全没问题别为了自研而自研。3. 把坐标体系理顺后面 80% 的坑都能绕过去我见过太多同学在这一步栽跟头拼图块总是偏一点或者在不同的屏幕上偏移量还不一样。根因几乎都是坐标系混用。3.1 三个坐标系不要混用一个滑块验证控件里同时存在三套坐标第一套是原图坐标也就是服务端下发的图片自身的像素坐标比如 600×300 的位图。缺口的目标位置、拼图块的裁剪区域都在这套坐标里描述。第二套是控件坐标也就是 View 内部的绘制坐标单位是 px原点在 View 左上角范围是0..width × 0..height。因为图片是按控件尺寸缩放绘制的所以需要一个scale viewWidth / bitmapWidth的映射。第三套是触摸坐标MotionEvent给出的x、y同样是相对 View 左上角的 px但它还带有rawX、rawY这样的屏幕绝对坐标。拖动逻辑只用event.x千万别混进rawX否则页面一滚动位置就全乱了。我的做法是控件内部只存控件坐标服务端下发的图片只负责绘制所有比较、上报、动画统一用控件 px。上报给服务端的值再换算回原图比例// 上报比例而不是绝对像素避免不同分辨率下容差失真 val reportRatio pieceX / (width - pieceWidth).toFloat()用比例而不是像素上报好处是后端只需要一个 0 到 1 的浮点容差阈值而不用关心用户的手机宽度。3.2 触摸命中判定与事件消费自定义 View 想收到ACTION_MOVE和ACTION_UP有两个前置条件onTouchEvent必须在ACTION_DOWN时返回true或者 View 设置了clickable true。我见过有人onTouchEvent里只处理 DOWN 就返回了 false结果 MOVE 一次都收不到还以为是自己写的拖动逻辑有问题。override fun onTouchEvent(event: MotionEvent): Boolean { when (event.actionMasked) { MotionEvent.ACTION_DOWN - { if (!hitTestSlider(event.x, event.y)) return false dragging true downX event.x startPieceX pieceX track.clear() record(event) performClickSafely() return true // 关键返回 true 才能继续收 MOVE } MotionEvent.ACTION_MOVE - { if (!dragging) return false record(event) updatePieceX(event.x - downX startPieceX) return true } MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL - { if (!dragging) return false dragging false onRelease() return true } } return super.onTouchEvent(event) }hitTestSlider我建议做成“滑块热区比视觉区域上下各扩 12dp”因为手指按压点未必精准落在滑块上尤其是单手操作的时候。实测下来这个扩展能显著降低“点了没反应”的投诉率。还有一点容易忽略父容器的拦截。如果滑块控件放在ScrollView或者ViewPager2里用户横向拖动时可能被父容器抢走事件。处理方式是在控件内部调用parent.requestDisallowInterceptTouchEvent(true)在ACTION_UP或ACTION_CANCEL时再放开。4. 从零实现背景、缺口、拼图块怎么画出来4.1 图片下发与二次采样服务端下发的底图尺寸建议控制在 600×300 到 720×360 之间格式用 WebP 或者 JPEG 质量 80。更大的图在移动端没必要反而增加解码开销。客户端加载的时候一定要做二次采样。控件宽度往往只有 300dp 左右一张 720 宽的图直接BitmapFactory.decodeStream会申请好几 MB 的堆内存放在列表里滚几下就 OOM 了。fun decodeSampled(stream: InputStream, reqWidth: Int, reqHeight: Int): Bitmap { val opts BitmapFactory.Options().apply { inJustDecodeBounds true } val bytes stream.readBytes() BitmapFactory.decodeByteArray(bytes, 0, bytes.size, opts) opts.inSampleSize calculateInSampleSize(opts, reqWidth, reqHeight) opts.inJustDecodeBounds false opts.inPreferredConfig Bitmap.Config.RGB_565 // 底图不需要 alpha省一半内存 return BitmapFactory.decodeByteArray(bytes, 0, bytes.size, opts) }注意inPreferredConfig用RGB_565只适用于底图。拼图块因为要用 Path 裁剪出透明边缘必须是ARGB_8888否则边缘会发黑。4.2 缺口轮廓的绘制缺口形状如果只是矩形视觉上有种“没做完”的感觉。我一般用一个矩形加两段贝塞尔曲线做出不规则的凸起既有辨识度脚本也不容易靠边缘检测逆推出精确位置。private fun buildPiecePath(w: Float, h: Float): Path Path().apply { moveTo(0f, 0f) lineTo(w * 0.42f, 0f) cubicTo(w * 0.42f, -h * 0.20f, w * 0.70f, -h * 0.20f, w * 0.70f, 0f) lineTo(w, 0f) lineTo(w, h * 0.55f) cubicTo(w * 1.16f, h * 0.55f, w * 1.16f, h * 0.86f, w, h * 0.86f) lineTo(w, h) lineTo(0f, h) close() }这里有两个实操要点。一是cubicTo的控制点会超出0..w的范围所以绘制的时候canvas必须做一次clipRect否则拼图块的凸起部分会画到 View 边界外面去在父容器里留一条脏边。二是我把凸起的幅度控制在宽高的一小段比例内太夸张的形状在小屏手机上会让用户看不出这是拼图。缺口本身在底图上怎么表现常见做法有两种一种是直接挖空用PorterDuff.Mode.CLEAR另一种是叠加一层半透明黑。我倾向后者的变体——在缺口区域盖一层 alpha 约 0.35 的黑色遮罩并且加一条 1px 的浅色描边。理由很简单如果底图刚好在那个位置是浅色挖空之后用户根本看不出缺口在哪。4.3 onDraw 里的绘制顺序与离屏缓冲onDraw的执行顺序直接影响性能和观感我固定成这个次序绘制缩放后的底图绘制缺口遮罩Path 半透明画刷save()后平移画布到pieceX再用clipPath裁出拼图区域绘制拼图块位图restore()绘制滑块轨道和圆形滑块。第 3 步有两种实现方式。用PorterDuffXfermode做SRC_IN可以但它会触发离屏缓冲saveLayer在低端机上滑动会明显掉帧。我改用clipPath之后再drawBitmap硬件加速下走的是剪切路径开销小很多。代价是边缘抗锯齿略差可以通过给 Paint 开isAntiAlias加一层描边来补偿。另外一个细节onDraw里不要 new 对象。RectF、Paint、Path全部作为字段提前创建好每次只改值。这个习惯在调试时不明显但一个页面里如果有多个自定义控件同时刷新GC 抖动会非常直观。5. 拖动交互与轨迹采集的实操细节5.1 拖动逻辑与回弹动画拖动过程中pieceX的更新很直接但要限制在0..(width - pieceWidth)之间越界了做一次阻尼效果。阻尼我用的是一条简单公式private fun clampWithResistance(raw: Float): Float { val max (width - pieceWidth).toFloat() return when { raw 0f - -sqrt(-raw) * 6f raw max - max sqrt(raw - max) * 6f else - raw } }这样拖到底还能再往外带一点点手感上会“软”一些比硬邦邦地卡住舒服。松手后的回弹用ValueAnimator从当前位置回到 0时长 260ms插值器用DecelerateInterpolator。这里有个体验细节失败回弹时先停顿 120ms 再动画回位如果立刻弹回去用户会以为自己没按到会疯狂重复拖动。5.2 轨迹数据结构与采样频率轨迹点我定义成这样一个结构data class TrackPoint( val t: Long, // 相对按下时刻的毫秒数 val x: Float, // 控件坐标保留一位小数足够 val y: Float )采样不能每个 MOVE 事件都记。MotionEvent在 60Hz 屏幕上大约 16ms 一次在 120Hz 上能到 8ms全部记录会让上报体积翻倍而且高频抖动对判定没有帮助。我的策略是按时间窗口采样最小间隔 12ms同时强制记录终点一条正常的拖动轨迹大概 30 到 60 个点序列化之后 2KB 以内完全可以随请求一起提交。有一点务必注意上报的t必须是相对时间且不能由客户端单独决定可信度。所有时间戳在服务端只作为特征参考不能作为判定“是否超时”的唯一依据否则改了手机系统时间就能绕过。5.3 本地判定与服务端判定怎么分工这里我要说一个非常容易做错的点。如果服务端把缺口的目标 X 下发给客户端客户端本地判断“偏差 8px 就通过”那这个方案基本等于没有因为攻击者只需要 hook 一下拿到 targetX直接调用通过逻辑就行。正确的分工是客户端只做视觉呈现和交互松手后把{token, trackList, finalRatio, durationMs}上报服务端持有targetRatio比对偏差、检查轨迹特征、检查 token 有效期和一次性通过后签发业务 token客户端拿到服务端返回的成功/失败再决定动画方向。那客户端怎么知道拼图块该画在哪儿不知道。它只知道拼图块现在被拖到了哪个位置具体对不对等后端说话。这样实现的好处是即使有人在客户端把整个控件逆向了他也拿不到答案。6. 安全加固几件让脚本不那么好写的事6.1 图片与坐标不下发明文服务端生成校验图的时候我建议的流程是从图库里挑一张底图在服务端随机取一个 Y 比例和 X 比例在那里裁剪出拼图块返回三个东西——底图不带缺口、拼图块带透明边的 PNG、一个随机 token。目标 X 比例只存在 Redis 或者缓存里key 就是 token有效期 2 分钟。这里还有个小优化拼图块返回之前做一次随机的轻微旋转或者透明度渐变让它在视觉上像是“浮起来”的同时增加图像识别的难度。不过旋转角度别超过 3 度超过了用户自己都对不齐。6.2 一次性 token 与有效期token 必须满足三个条件随机性足够用安全随机数生成长度 32 位以上、一次性校验成功或失败都立即失效、有有效期我一般给 120 秒。这三个条件不满足任何一个都可能被重放。顺带说校验失败也要消耗 token。有些实现失败后不删 token攻击者可以用同一个 token 反复试不同的 X理论上几百次就能试出来。这是个很隐蔽但很致命的漏洞。6.3 风控联动滑块不是万能的滑块验证码的定位是“抬高批量请求成本”不是“绝对防住”。真实的风控系统里它通常和这些信号一起工作设备指纹是否异常、同 IP 在时间窗口内的请求频次、账号历史行为、请求的 UA 与传感器特征是否匹配。所以我个人的做法是滑块的校验结果只作为一个加权因子不作为唯一放行条件。同时对“短时间内多次校验失败”的会话做降级处理比如直接要求走更强的验证方式而不是让他在滑块上一直试。7. 常见问题与排查实录7.1 坐标与点击类问题拼图块总是偏右或者偏左一段固定距离八成是把event.rawX和event.x混用了或者滑块在拖动时父布局有 padding 没减掉。排查方法很简单在 DOWN 时打一条日志把event.x和event.rawX都打出来如果两者差值等于控件在屏幕上的位置那就是用错了。拖不动或者只能拖一次检查onTouchEvent的 DOWN 分支是否返回了 false。另外检查performClick()有没有被调用虽然不调用不影响功能但无障碍服务和无痕测试工具会报错。松开后没有回弹多半是ValueAnimator被复用了但没cancel()上一次的动画导致新旧动画互相覆盖。养成习惯每次启动新动画前先cancel()。7.2 内存与性能类问题滑动时掉帧按前面的建议把onDraw里的对象分配全部提到字段上同时确认没有用PorterDuffXfermode配合saveLayer。页面退出后 OOM底图和拼图块这两个 Bitmap 需要在onDetachedFromWindow里主动recycle()并置空。虽然现代 Android 的 GC 能处理但图片尺寸较大的时候及时释放能显著降低峰值内存。首次加载有白屏如果用网络图片务必在控件内部先画一个占位骨架一个浅灰的圆角矩形加一条呼吸动画不要让用户盯着空白。7.3 适配与兼容类问题深色模式下拼图块边缘发黑拼图块位图的 config 必须是ARGB_8888且绘制时Paint不能开filterBitmap false否则缩放会有硬边。横屏或者平板下拼图变形控件高度固定但宽度随屏幕拉伸时缩放比例要用max而不是按宽度算同时底图用centerCrop的方式裁切避免拉伸。RTL 语言环境下滑块跑到右边如果产品要支持 RTL滑块的起始位置需要用layoutDirection判断或者干脆强制 LTR因为滑动方向本身就是从右到左的语言习惯里也是从左往右拖。7.4 问题速查表现象高概率原因快速验证方式处理方式拼图块偏移固定值坐标系混用打印event.x与event.rawX统一用控件坐标拖一下就卡住DOWN 返回 false 或父容器拦截打日志看 MOVE 是否进来返回 true 禁止父容器拦截拼图块边缘有黑边位图 config 不是 ARGB_8888打印bitmap.config改用 ARGB_8888滑动掉帧onDraw 内分配对象或用了离屏缓冲开 GPU 渲染分析看过度绘制复用对象改用 clipPath偶尔校验失败容差过小或上报比例为 px对比上报值和服务端值上报比例 容差 6 到 10px退出页面后内存不降未回收 Bitmap用内存分析工具看引用链onDetachedFromWindow 里 recycle8. 让它好看视觉与反馈的打磨8.1 视觉规范滑块的视觉部分其实就这么几个元素轨道、滑块、拼图块、缺口遮罩。但要把它们做“好看”我的经验是三个统一。圆角统一轨道、滑块、拼图块、遮罩的圆角半径都取同一个基础值比如 8dp不要一个 4 一个 12。阴影克制滑块只用一层 2dp 高度的柔和阴影阴影颜色用主色的深色版本加很低的不透明度不要用纯黑纯黑在浅色背景上会显得脏。留白均匀轨道和控件上下边缘的间距等于滑块半径视觉上最舒服。配色上轨道的未填充部分用一层很浅的灰比背景深一档填充部分用主色滑块用白色加一点点描边。这样用户一眼就能看出“已经走了多远”。8.2 动效与状态反馈成功的反馈我是这样做的拼图块落到缺口位置后先把遮罩的 alpha 从 0.35 动画到 0 并保持 180ms然后整个控件淡出并向业务回调。失败的话滑块颜色短暂变红同时做一次水平抖动抖动幅度控制在 6dp 以内太快太猛都会显得廉价。拖动过程中滑块的尺寸可以随拖动进度从 1.0 缩到 0.92 再回弹这种“按下有反馈”的细节对质感提升非常明显代码也就两行scaleX。还有一个我特别喜欢的小设计拖动时让拼图块带着一点轻微的跟随阴影位移越大阴影越深。视觉上会让人觉得这个块是“浮在图上”的而不是贴上去的色块。8.3 无障碍与测试contentDescription要写上“拖动滑块完成验证”并且在成功和失败时通过announceForAccessibility播报状态视障用户才知道发生了什么。另外performClick()一定要在 DOWN 里调用不然无障碍服务点了没反应。测试方面我一般会写两组。一组是纯逻辑的单测给固定的targetRatio和一组人工构造的轨迹验证判定函数是否正确包括匀速直线应该拒绝、带抖动的缓入缓出应该通过、以及时间过短应该拒绝。另一组是手工回归清单重点覆盖不同屏幕尺寸、深色浅色主题、横竖屏切换、弱网图片加载失败、以及连续快速失败三次后的降级逻辑。我在实际项目里踩得最深的一个坑是弱网。图片请求超时了但控件没有超时回调用户就一直看到占位骨架以为页面卡死最后是给图片加载加了一个 8 秒超时并把错误态做成“点击重试”的文案才解决。这类问题的共同点是功能逻辑写对了但边界状态没人管。所以后来我写这个控件的习惯是先把所有失败态列一遍再写正经逻辑反而更快。
文法实现详解)
