1. 先把“root”这个词拆开看很多人第一步就搜错了方向“连点器”这个话题里被问得最多的一句话就是root 后最好用的连点器是什么有没有不需要 root 的连点器。我自己从安卓 4.x 时代折腾到现在从最早的按键精灵脚本到后来自己写 shell 循环再到现在用免 root 的注入方案几乎每一条路线都踩过坑。所以这篇文章我想把这两条路一次讲透root 方案强在哪、免 root 方案能不能顶得住、具体怎么搭环境、参数怎么算、什么情况下会突然失灵。先说一个特别容易混淆的点。你搜“root 连点器”搜索结果里一定会混进一大堆完全不相干的东西error 1045 (28000): access denied for user rootlocalhost、ubuntu 切换 root 用户命令、更改 root 密码、银河麒麟图形界面 root 登录、wsl -d ubuntu -u root……这不是搜索引擎坏了是“root”这个词在很多领域都指代“最高权限账号”字符串撞车了而已。手机上的 root 和 Linux 服务器上的 root虽然名字一样但不是同一件事。手机端 root 的本质是让用户拿到su这个超级用户入口从而可以读写系统分区、挂载可写、给普通 App 授予它原本拿不到的权限。Linux 桌面和服务器上的 root 是一个账户sudo -i切过去passwd root改密码恢复模式单用户改/etc/shadow。数据库里的 root 更简单它只是一个用户名error 1045的意思是“密码错了或者这个 host 没授权”跟你手机能不能点击一点关系没有。所以当你搜连点器搜到“MySQL access denied”时直接划过去就行那是另一条赛道的问题。为什么“连点器”会和 root 绑得这么紧因为在没有 root 的年代一个 App 想让屏幕上别的地方产生一次触摸几乎做不到。安卓的输入系统对普通应用是封闭的你能读到自己窗口内的触摸事件但没法往系统输入管道里塞事件。谁有这个能力只有/dev/input/event*的读写者而这批设备节点的属主是root:input普通 App 连读都读不了。所以早期凡是能“真·后台点击”的工具清一色要求 root。这构成了接下来要讲的所有技术路线的基础。1.1 root 到底给了连点器哪几项具体能力很多人以为 root 就是“能给连点器开个开关”其实它给的是一整套底层操作能力具体可以拆成四块。第一块是输入事件注入也就是往/dev/input/eventX写结构化的事件序列或者打开/dev/uinput创建一个虚拟输入设备让系统把它当成一块真的触摸屏。第二块是系统级界面点击像权限确认弹窗、安装确认框、锁屏界面这些属于系统进程的窗口普通应用的无障碍服务点不到但输入注入可以。第三块是保活与调度可以调整进程优先级、把应用加入系统豁免名单、甚至改 cgroup 分组让它在后台长时间不被回收。第四块是参数级调整比如改触摸采样率、改分辨率、改 DPI这些在免 root 环境下只能用wm size临时改重启就没了。这四块里第一块是连点器的命脉也是最难替代的。事件注入的精度极高理论上间隔可以压到十几毫秒而且它不依赖任何 App 进程的存活——哪怕连点器 App 自己被杀了只要注入逻辑是写在常驻脚本里点击照样继续。这也是为什么不少老玩家至今仍然认 root 方案。1.2 免 root 不是做不到而是换了一套“代打”的授权机制安卓从 7.0 开始提供了AccessibilityService#dispatchGesture也就是无障碍手势分发。它让普通应用可以告诉系统“帮我在这片区域做一次点击或者划动”。这条路彻底改变了局面不需要 root也能实现真实的触摸。代价是系统会做校验、会插入延迟、会在点击位置画一个视觉反馈点而且对系统弹窗无效。另一条路是ADB / Shizuku 授权。ADB shell 在安卓里的身份是shell用户它本身就拥有注入输入事件的权限所以adb shell input tap x y能点屏幕而且不需要 root。问题在于每次调用都要起一个 shell 进程开销大、间隔粗。Shizuku 这类框架的价值就是把 ADB 的权限在设备本地转交给普通 App让它直接通过 binder 调用系统服务省掉起进程的开销间隔能压到 30 到 80 毫秒量级稳定性也上了一个台阶。所以对这个标题的准确回答是有免 root 的连点器而且现在主流就是免 root 方案。root 方案在极端场景下仍然更优但对 90% 的日常需求免 root 已经完全够用。2. 三条技术路线的取舍什么时候非得 root什么时候完全不必先把三条路摆在一起做个横向对比这样后面选方案的时候心里有数。三条路分别是root 输入事件注入、无障碍服务手势、ADB/Shizuku 注入。它们的差别不只是“要不要 root”还包括最小间隔、能否点系统弹窗、后台存活能力、以及被系统更新打断后的恢复成本。对比维度root 事件注入无障碍手势ADB / Shizuku 注入是否需要 root需要不需要不需要首次配置是否需要电脑需要刷入/授权完全不需要Android 11 可无线自激活最小可用间隔10-20 ms50-150 ms30-80 ms能否点击系统弹窗能不能部分能息屏后能否继续一般不能不能一般不能长时间后台稳定性高中中高系统更新后失效需要重新 root一般不受影响需重新激活上手门槛高低中从这张表能看出来免 root 方案的短板其实很集中系统弹窗点不到、间隔下限偏高、连续运行的稳定性略差。而 root 方案的短板也很明显刷机成本、机型限制、部分应用直接拒绝在已 root 设备上运行。2.1 root 输入注入精度最高也最“重”root 下做连点主流有两种写法。一种是读事件转写用getevent抓取真实触摸的事件序列再用sendevent回放。这种方式兼容性最好因为它模仿的是设备原生的触摸协议但要处理每个设备的ABS_MT_POSITION_X绝对值范围不同、协议类型 A/B 不同等问题麻烦。另一种是写/dev/uinput创建一个虚拟的输入设备然后按标准的 input_event 结构体往里写。这种做法更加干净位置用像素坐标不需要换算绝对值还能自定义支持的坐标范围。从精度上说两种方式都能做到 10 毫秒级别的间隔但实际有意义的下限取决于目标应用。多数 UI 的按钮响应本身就是 100 毫秒级的你点得再快也没意义反而容易堆积事件导致误触。所以我的经验是极端精度只在你需要对抗不可预测的响应时才有价值比如某些需要抢时序的场景节奏快了甚至会被判定为异常输入。代价方面root 会清空用户数据解锁 Bootloader 的必经流程、会导致部分应用拒启、会让系统更新变成一件需要重新处理的事。对主力机来说这笔账要算清楚。2.2 无障碍手势零门槛但有两个硬伤无障碍服务的实现非常直白App 声明一个AccessibilityService在配置里声明canPerformGestures用户手动开启后App 就能构造一个GestureDescription里面放若干个StrokeDescription每个 stroke 有起点、终点和持续时间最后dispatchGesture交给系统执行。点击就是把起点终点设成同一个坐标持续时间设成 30 到 80 毫秒。它有两个绕不过去的硬伤。第一是系统弹窗点不到。因为你是在应用层请求系统执行手势系统出于安全考虑不会把手势投放到自己的权限对话框、系统设置确认框上。第二是间隔下限明显偏高。每次手势都要走一遍无障碍框架平均一次往返在 50 到 150 毫秒之间机型差异很大。如果你目标是 20 次每秒的点击无障碍做不到。优点则是极为省事不装电脑、不激活、不折腾 shell重启后只要无障碍服务还在开启状态立刻能用。这也是为什么市面上绝大多数自动点击器 App 都走这条路——包括热词里提到的actus 连点器这一类工具本质上都是无障碍 悬浮窗录点的组合。2.3 ADB / Shizuku现在最平衡的一条路Shizuku 的思路其实很朴素既然shell用户天生有注入权限那我就想办法把这份权限借给普通 App 用。Android 11 之前它需要连接电脑跑一条adb shell sh /sdcard/...之类的启动脚本Android 11 引入无线调试配对之后可以完全在设备上自己完成激活配合配对码就能拿到 shell 权限再通过 binder 把这个身份转交给注册过的应用。拿到权限的连点器 App就有了接近 root 的一部分能力注入延迟低、能点到一些无障碍点不到的区域、不受无障碍服务的各种系统限制。它美中不足的是重启后需要重新激活以及部分机型会限制无线调试的配对窗口。但综合来看这是目前免 root 方案里性价比最高的一条。我自己的做法是主力机用 Shizuku 这条线把常用配置导成 JSON 存着遇到需要 root 才能完成的任务比如批量确认系统弹出的授权框再考虑临时切到 root 方案。这个组合基本覆盖了我这两年遇到的所有场景。3. 免 root 方案实操从零搭一套稳定的连点环境下面这部分是完整的落地流程。我按“前置检查 → 环境搭建 → 授权绑定 → 录点与参数配置”的顺序写每一步都说明为什么这么做而不是只给一串操作。3.1 开工前的四项检查省掉一半的返工第一项确认系统版本。Android 11 及以上才有无线调试和配对码能全程在手机上完成Android 7 到 10 需要电脑执行一次启动脚本Android 6 及以下基本只能走无障碍。第二项确认屏幕参数把分辨率和刷新率记下来可以用adb shell wm size和adb shell wm density读没有电脑的话在系统设置里的“屏幕分辨率”也能看到。第三项把电池优化关掉路径一般是“设置 → 应用 → 应用管理 → 找到这个应用 → 电池 → 无限制”同时关掉“智能省电”“后台省电”之类的厂商定制选项。第四项把自动锁屏时间设为“永不”或至少 10 分钟。这四项看起来都是小事但后面所有的“跑着跑着就停了”几乎都能追到这几项上。尤其是厂商的省电策略它会在一段时间无交互后主动冻结后台进程连点器看起来还在界面上实际上已经被挂起了。3.2 用无线调试激活 Shizuku 的完整步骤打开方式进入“设置 → 关于手机 → 版本号”连点 7 次进入开发者模式回到“设置 → 系统 → 开发者选项”打开“无线调试”。注意不要在这一层直接点“无线调试”开关就算了要点进去选择“使用配对码配对设备”此时屏幕上会显示一个六位配对码和一行 IP 加端口。然后在 Shizuku 里选择“通过无线调试启动”输入那串配对码。配对成功后Shizuku 会显示正在运行此时去连点器 App 里选择“Shizuku 模式”或“ADB 模式”授权一次即可。整个过程不需要电脑这是 Android 11 最舒服的地方。如果你的设备是 Android 10 或更低就得用电脑跑一次。常见的命令组合是这样# 确认设备已连接 adb devices # 读取当前屏幕参数用于后续坐标换算 adb shell wm size adb shell wm density # 启动 Shizuku 服务路径以应用实际安装位置为准 adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh # 需要长时间无线调试时可开启网络监听 adb tcpip 5555 adb connect 192.168.1.20:5555adb tcpip 5555这一步的意思是让设备的 adbd 监听在 5555 端口之后就能拔掉数据线走局域网。它和 root 无关只是把 USB 通道换成网络通道重启后失效。3.3 录点坐标怎么取取几个点录点有两种方式。一种是用连点器自带的悬浮窗把准星拖到目标位置点一下“添加”App 会记录下当前的绝对坐标和屏幕尺寸。另一种是用adb shell getevent -l直接抓事件流看ABS_MT_POSITION_X和ABS_MT_POSITION_Y的数值但要注意这两个值通常是绝对值范围比如 0 到 32767需要按屏幕宽度做一次比例换算。第二种方法看起来更专业但实际用起来更麻烦因为换算涉及每个设备的触摸面板分辨率不同机型不一样。悬浮窗录点简单直接而且自带分辨率记录换设备时能做自动换算我更推荐。录几个点取决于你要做什么单点循环录一个多点序列按顺序录三到五个需要滑动的话录起点和终点滑动时长单独设。这里有个容易忽略的细节不要把点录在屏幕最边缘。因为很多设备的边缘区域有手势导航、侧边返回、边缘防误触逻辑点在边缘会被系统先截获。留出至少 20 到 30 像素的安全边距听起来不起眼实际能减少一半以上的“点了没反应”。3.4 参数怎么算间隔、按住时长、抖动、循环这是最核心的一节也是大多数人凭感觉乱填的地方。我把几个关键参数的计算逻辑说清楚。按住时长。安卓的点击事件其实是“按下 抬起”两者之间要有一个持续时间系统才会判定为一次有效点击。太短小于 20 毫秒可能被过滤成噪声太长超过 300 毫秒会被识别成长按。我的经验区间是40 到 100 毫秒默认取 60 毫秒最稳。如果你用命令行方式可以用input swipe在同一个坐标上划动来模拟按住时长# 在同一点做 60 毫秒的按下抬起等价于一次带时长的点击 adb shell input swipe 540 1800 540 1800 60 # 普通点击按住时长由系统默认值决定 adb shell input tap 540 1800点击间隔。间隔和按住时长是两回事。间隔是两次点击之间的空档。如果目标按钮点击后有动画或加载间隔必须大于动画时长否则第二次点击会落在动画过程中被丢弃。一个可用的经验公式是最小安全间隔 按住时长 目标响应延迟 20% 余量举例按住 60 毫秒目标按钮的响应动画大约 200 毫秒那么最小安全间隔约等于 60 200 260 毫秒再乘 1.2 得到约 312 毫秒。实际配置里填 320 毫秒比盲目填 50 毫秒要可靠得多。反过来如果目标是纯计数场景、按钮无需反馈间隔可以压到 80 到 120 毫秒。随机抖动。固定节奏的输入在长时间运行时有一个副作用会和目标应用的某些周期性任务共振出现偶发的丢帧或者卡顿。加一个 ±10% 到 ±15% 的随机抖动就能打破这种共振。计算方式很简单实际间隔 基础间隔 × (1 random(-0.15, 0.15))。别加太大抖动超过 ±30% 会让人觉得节奏不稳反而影响体验。循环与总时长。如果你需要跑几个小时建议把循环拆成若干段每段设一个上限比如 5000 次段与段之间插入一个 1 到 2 秒的停顿。这样做有两个好处一是万一中途出问题方便定位是哪一段开始异常的二是给系统一个喘息窗口减少被判定为异常负载的概率。4. 稳定性调优让它连续跑几小时不掉链子配置对了不代表能长时间跑得住。这一节讲的是从“能跑”到“能稳跑”的差距全都是实际折腾出来的经验。4.1 电源与后台三个必须关掉的开关第一电池优化白名单。这是最重要的一条。国产 ROM 的后台管理普遍比较激进默认会在一段时间无用户交互后冻结后台进程。变成白名单之后连点器 App 的进程优先级会提升不再被随意回收。第二最近任务锁定。在多任务界面长按应用卡片选择锁图标防止被一键清理带走。第三关闭自适应电池。部分系统会学习你的使用习惯在它认为“不常用”的时候降低调度而这个学习过程会误判连点器这种长时间运行但无交互的场景。还有一个隐藏项屏幕常亮。多数方案在息屏状态下无法注入输入事件因为系统会停止向触摸设备分发。所以要么把自动锁屏设为永不要么用开发者选项里的“充电时不锁定屏幕”。长时间跑任务建议插着电顺便解决续航问题。4.2 温度与频率长时间高频点击的真实瓶颈这一点很多人没意识到。连点器连续跑两小时屏幕常亮、CPU 持续处理注入事件、GPU 持续渲染动画整机温度会明显上升。温度上去了系统会降频注入延迟跟着变大表现为“刚开始很准跑一小时后开始飘”。我的做法是把长时间任务的频率控制在5 到 10 次每秒除非确实需要更高的节奏。这个频率对绝大多数重复性操作已经足够了而且整机功耗和温度都在可控范围内。如果设备本身散热一般可以在任务开始前取下保护壳或者放在通风的地方。别为了追求“每秒 50 次”的爽感最后跑二十分钟就过热降频。4.3 坐标漂移跨设备、跨分辨率、跨姿态的换算换设备或者改分辨率之后原来录的坐标会偏。换算方法是按比例缩放新坐标 x 原坐标 x × 新屏幕宽度 ÷ 原屏幕宽度 新坐标 y 原坐标 y × 新屏幕高度 ÷ 原屏幕高度举个例子你在 1080×2400 的设备上录了一个点 (540, 1800)换到 1440×3200 的设备上x 540 × 1440 ÷ 1080 720y 1800 × 3200 ÷ 2400 2400。这是一个等比换算前提是两台设备的 UI 布局比例一致。如果布局经过厂商定制改动比如状态栏高度不同那就得重新录点。横竖屏切换也是同理切换后坐标系原点会变必须重新校准。我的习惯是在配置里给每个使用场景单独存一份命名带上分辨率和方向比如game_1080x2400_portrait换设备直接换配置不动坐标。5. 常见问题与排查技巧实录这一节是踩坑记录我把遇到过的典型现象整理成速查表再挑几个讲讲排查思路。现象可能原因排查与解决点击完全无反应无障碍服务未开启或被系统关闭检查无障碍列表重新开启并锁定后台点击偶发丢失间隔小于响应延迟按“按住 响应 20%”公式调大间隔坐标整体偏移分辨率或 DPI 变了按比例换算或重新录点边缘区域点不到手势导航或防误触拦截点位向内缩进 20-30 像素跑几分钟自动停止电池优化或后台冻结加入电池白名单、锁定最近任务重启后失效Shizuku 需重新激活重新配对待激活一次某些界面点不动属于系统级弹窗无障碍做不到需 Shizuku 或 root报 error 1045这是数据库账号错误与手机无关是另一个领域的问题5.1 一个典型的误判命令行点击比 App 慢得多我一开始用 shell 脚本写循环发现间隔怎么调都达不到预期原因是每次adb shell input tap都要起一个 shell 进程光是进程启动就要几十到一百多毫秒。正确的做法是一次 shell 里连续执行多条命令或者干脆用 Shizuku 这类框架走 binder 调用省掉进程启动的开销。这个差别在需要高频点击时非常明显。# 错误示范每次都新起进程开销大 for i in $(seq 1 100); do adb shell input tap 540 1800 done # 相对好些一次 shell 里跑完整循环 adb shell for i in $(seq 1 100); do input tap 540 1800; sleep 0.12; done注意input tap内部的休眠精度不高sleep 0.12实际可能偏差到 0.15 秒左右。需要精确节奏还是得靠 App 层的定时器或者 Shizuku 注入。5.2 无障碍服务被系统悄悄关掉的坑这是最迷惑人的一个现象任务跑着跑着停了回到设置里看无障碍开关是开着的但实际已经失效。原因是部分系统会在检测到服务长时间无用户交互后主动暂停它的运行。解决办法有两个一是定期模拟一次交互比如在某个角落做一次无害的点击二是改用 Shizuku 路线它不依赖无障碍服务不受这个机制影响。还有一个变种系统更新后无障碍服务被重置。这种情况重新开启一次就好但如果你有多个自动化工具依赖它更新前最好记一下都开了哪些服务。5.3 目标应用本身的行为变化有时候连点器没变是目标应用改了布局、加了加载动画、或者弹出了新的确认框。表现就是“昨天还好好的今天就不对了”。排查顺序建议是先看一眼目标界面是不是多了什么遮挡元素再看坐标是不是还落在按钮上最后再怀疑连点器配置。我踩过的坑里有一半以上最后发现是目标侧变了而不是工具侧。6. root 方案在今天还有什么不可替代的价值聊到这儿回到标题的完整意图root 后最好用的连点器是什么我的答案是root 方案的价值不在“点得快”而在这几个免 root 做不到的地方。第一点系统弹窗。权限确认、安装确认、系统设置里的二次确认框这些属于系统进程的窗口无障碍手势和普通注入都够不着。需要批量处理这类弹窗时只有 root 注入这条路。第二完全脱离前台。root 下可以把注入逻辑放进一个常驻的守护脚本里连点器 App 本身被卸载了都不影响。这种“无界面运行”在需要长时间无人值守的场景里很有价值。第三修改输入参数。比如调触摸采样率、临时更改屏幕分辨率、修改输入设备的坐标系这些都需要系统级权限。免 root 只能用wm size临时改重启就恢复。但代价也是实打实的解锁 Bootloader 会清空数据部分机型根本不支持解锁部分应用尤其是支付类和银行类会直接拒绝在已 root 的设备上启动系统更新之后还要重新处理一遍。对主力机来说这些成本往往超过收益。所以我的实际选择是能用免 root 解决的坚决不 root只有碰到系统弹窗这类硬需求才考虑临时上 root而且优先选那种不影响日常使用的临时方案。6.1 一个折中的思路分设备、分场景如果你确实有用 root 的需求又不想动主力机可以考虑把任务拆开主力机负责日常跑免 root 的 Shizuku 方案备用机负责需要 root 的重活解锁、root、随便折腾坏了也不心疼。这个思路听起来简单但它解决了一个根本矛盾——root 方案的收益是局部的而它的成本是全局的。我这两年就是这么安排的。备用机上跑的是永久 root 的环境专门处理需要系统级权限的任务主力机上只装 Shizuku 加一个连点器 App配置全部导出成 JSON 备份在本地和云盘各一份。换机、重装、系统更新之后恢复成本基本就是重新激活一次加导入配置几分钟的事。6.2 配置备份这件事越早做越好最后分享一个我踩过好几次坑才养成的习惯每配好一套连点方案立刻导出配置。导出的内容至少包含点位坐标、屏幕分辨率、DPI、按住时长、间隔、抖动比例、循环上限这几项。存成纯文本或者 JSON不要只存在 App 里。原因很简单这类工具经常因为系统更新、权限变更、App 版本升级而丢失配置重新录一遍点位和参数是很枯燥的事尤其是多点序列。如果你用的是命令行方案把整条命令序列写成一个.sh文件存在本地配合注释说明每个参数的含义效果和导出配置一样。我现在的做法是每个场景一个文件文件名带上场景名和分辨率比如daily_1080x2400.sh用的时候直接跑不用回忆当时是怎么配的。这套组合拳用下来我已经很久没有为了“连点器要不要 root”这个问题纠结过了。免 root 能覆盖的就用免 root覆盖不了的备用机上加一层 root。工具的边界清楚了剩下的就是把参数调准、把配置存好。