5ms 轮询怎么做到"跟手"又不跟用户抢窗口：事件稳定判定的实现拆解

安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，再一键装到手机或模拟器上看效果。产品介绍页：https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。

上一篇我们拆了这套吸附的几何：两窗高度相等、宽度按"合计占屏"反推、只剩一条出屏兜底。这一篇讲另一半 —— 几何解决"应该摆在哪"，同步解决"多快摆到位、以及什么时候不该动"。后者看起来只是"把窗口挪过去"，实际上是一个关于高频与克制的平衡题：频率低了，拖动主窗口时右边那扇会拖出一段可见的滞后；频率高了，又容易出现"你刚把它拖开、它立刻弹回来"这种让人恼火的抢窗口行为。

一、一个 5 毫秒的循环：跟手是"读—算—写"跑出来的

同步的核心是一段跑在后台线程里的循环，默认每 5 毫秒转一圈。它做的事非常朴素，一共三步：

1. 读：取主窗口当前的矩形（左上角坐标 + 宽高）；
2. 算：按几何公式算出被吸附窗口"应该"在哪、多大；
3. 写：如果被吸附窗口此刻不在这个位置上，就把它写过去。

重复这三步，就得到了"跟手"：你每拖动主窗口一点点，最多 5 毫秒之后，右边的窗口就被按同一套关系重新摆好。人手拖动鼠标的最小可见位移大约在十几毫秒这个量级，所以 5 毫秒的周期足够让两扇窗口在视觉上"焊死"在一起 —— 你会觉得它们是同一个窗口被一条缝分成了两半。

这个线程的优先级被刻意抬高到高于普通，名字也起得清楚（在进程里叫 ApkGallary.WindowDock），目的是让它在系统繁忙时仍然能按节奏醒来。它是后台线程，程序退出时不会拖着进程不放。至于循环周期的下限，代码里做了保护：无论配置写成几毫秒，实际都不会低于 2 毫秒。这个下限不是为了省电，而是防止有人把值填成 0 或者负数，让循环变成不带睡眠的死循环，把一个核心直接吃满。

为什么是"后台线程 + 轮询"，而不是"界面线程 + 事件订阅"

上一段提到的两个选择，其实都是刻意的，值得展开讲。第一，为什么跑在后台线程而不是界面线程？因为界面线程的职责是绘制和响应交互，你拖动主窗口时，界面线程本身就忙在拖动这条流程里；把每 5 毫秒一次的读矩形、算矩形、写矩形塞进这条流程，等于让"拖动"和"同步"排队互相等，结果是拖动变卡、同步也变慢。放到后台线程之后，两件事并行推进，界面该画就画，同步该跟就跟，互相之间只通过"窗口矩形"这个共享事实打交道。

第二，为什么是轮询而不是订阅系统的窗口事件（比如挂一个"窗口移动"的事件钩子）？事件订阅听起来更"高级"，但在这种跨进程场景里有三个现实问题：一是它要求你在每台机器上正确挂载和卸载钩子，钩子本身有生命周期与权限的坑；二是事件只在特定条件下才送达，窗口被移动的路径有很多种（程序自己改、系统层重排、显示设置变化），漏掉一次就会让"跟手"断在一个谁也没注意的地方；三是事件驱动仍然要解决"一秒钟来两百条事件"的抖动问题，最终还是要靠时间窗去归并。轮询把这三件事一次性解决了：它不依赖对方的配合，也不会漏 —— 因为它每一轮直接问"你现在在哪"，而不是等别人来告诉你。对"必须在任何情况下都保持并排"这种硬需求来说，"主动去看"比"被动等通知"更可靠。

理解了这两点，就能理解这套机制的性格：它把确定性放在第一位。宁可每 5 毫秒花一点极小的代价去确认一次现实，也不去赌"事件一定会到达"。而为了不让这份确定性变成骚扰，又必须把"什么时候该收手"写清楚 —— 这就是后面几章的内容。

二、写窗口不用消息、不用布局：直接调系统的 SetWindowPos

第二步"写"的方式，决定了这套同步的手感和副作用。这里没有采用任何"应用层"的做法，而是直接调用 Windows 的窗口定位接口，一次调用同时给出坐标和尺寸，并带上三个标志位。三个标志位分别解决一个具体问题，值得逐个说清楚：

标志位	含义	为什么必须带上
不改变 Z 序	只挪位置和大小，不动"谁在前面"	避免两扇窗口在每 5 毫秒一次的重排里互相抢前后顺序，视觉上会闪
不激活窗口	不抢键盘焦点	你在右边那扇窗口里打字时，同步永远不会把光标从输入框里赶走
异步定位	请求交给系统排队，不阻塞调用方	目标程序正忙时不会把我们的同步线程一起卡住，节奏不会断

"不激活"这一条尤其关键，它直接回答了很多人的第一反应 —— "每 5 毫秒动一次别人的窗口，会不会把我的输入抢掉？" 不会。窗口的移动、缩放、置前与"激活（拿到键盘焦点）"在系统里是两件可以分开的事，这里从第一条命令开始就明确声明"只动位置，不碰焦点"。所以你在右边那扇窗口里敲需求、翻日志、选菜单，都不会因为同步而中断。

"异步定位"则是为了不打断节奏。如果采用同步定位，遇到目标程序正在忙（比如它在处理一次大的资源改动）就会卡住，卡住的是我们自己的同步线程 —— 结果是整套跟手效果出现肉眼可见的顿挫。改成异步之后，写入请求被系统接管去排队执行，我们的线程立刻返回、继续下一轮循环，节奏稳定，代价是"写入生效的时刻"由系统决定，通常只差几毫秒，肉眼不可辨。

顺便解释一个常见疑惑：有时候"跟手感"的上限并不在我方。 被吸附的是 AI 改包程序，很多同类工具是浏览器内核套壳的桌面应用，它收到"窗口变成这个尺寸"之后，内部的排版引擎还要重新排版一次页面内容。拖动时如果右边出现轻微的重绘闪烁，那是它自己渲染的节奏，而不是窗口位置没跟上 —— 判断方法很简单：把诊断日志打开，看每一轮的写入是否紧密跟随你的拖动，日志里写得清清楚楚。

三、三处防抖：一个高频循环必须学会"什么都不做"

每 5 毫秒算一次，不等于每 5 毫秒都要写一次。一个没有防抖的高频同步，会把系统资源浪费在"把窗口写到它已经在的位置"上，更糟的是会不断打断目标程序 —— 它每次收到尺寸变更都要重新布局，即使尺寸完全相同。所以这套循环里有三处明确的"该收手就收手"：

还有一处不是防抖、但同样属于"别做多余事"的设计：状态信息的发布有节流。同步线程每轮都会"想"更新一次界面上的状态文字，但真正推送到界面层时，相同文案的重复推送最多每 200 毫秒一次，只有状态或文案真正变化时才立即推送。这一点很好理解：如果状态栏每秒被刷新两百次，界面线程会被这类无意义的更新吃掉，反而让整个程序显得迟钝。

四、事件稳定判定：用"静默时间"区分人手拖动与程序写入

接下来是这个循环里最需要动脑子的一段。前面反复强调"窗口怎么写、什么时候写"，但还有一个问题没解决：当被吸附窗口的位置发生了变化，这次变化是谁造成的？

答案只有两种可能：一是我们自己的同步刚刚把它写到那里；二是用户用手把它拖走了。这两种情况必须区别对待，因为它们的正确响应完全相反：前者应当立刻停止动作（我已经放好了）；后者则要看配置，决定要不要把它吸回来。误判的代价也很具体 —— 如果把"用户的拖动"当成"自己的写入"而不理会，用户就会觉得这功能形同虚设；反过来，如果把"自己的写入"错当成"用户拖动"，就会陷入"我放好、它被判定为被拖走、我再放回去"的自激循环，窗口开始抖动。

解法不是去追问"谁干的"（窗口本身并不告诉你），而是换一个可观测的判据：变化之后，安静了多久。

这套判据之所以成立，是因为两种变化的"时间形状"完全不同：程序写入是一次性的 —— 我们在某一轮写完，之后就不再动它，于是窗口在几个毫秒内就进入静止；人手拖动是持续的 —— 只要手指还在移动，窗口的坐标就在不停地变，时间戳会被不断刷新，永远不会累积到 260 毫秒的静默。所以"静默时长"天然把两者分开了：一个会安静下来，一个不会。

实现上用两个时间戳而不是一个，因为尺寸和位置是可以分开变化的：用户可能只拖动了位置（改的是左上角坐标），也可能只改了大小（拉边框）。两个时间戳各自记录，判定时要求两者都安静下来才继续处理。这一点很重要：只拖动位置时，尺寸从未变化，尺寸时间戳可能早就超时了；反过来只拉边框时，位置时间戳也是陈旧的。要求两个都静默，才能确保"这一次动作真的结束了"。

顺带解释一个容易被忽略的细节：我们自己写入完成之后，会立刻把"我知道的当前矩形"更新成写入的目标值。 这一步是整段判定的基石。如果没有它，下一轮读到的"它变了"就会进入变化判定，时间戳被刷新一次，然后要等 260 毫秒；在等待期间任何一次误判都可能让窗口被反复重写。有了它，"自己写的那一下"在系统里几乎不留痕迹 —— 变化从源头上就不会被记录为"外部操作"。

稳定判定的时长下限也有保护：配置里无论写成多小，实际生效值都不会低于 60 毫秒。因为判定的本意是"确认动作结束"，把静默阈值调到接近零，等于把判定取消了，拖动过程中每一次细微停顿都会被当成"结束"，用户会看到窗口在手指没松开时就开始往回弹。

五、被拖走之后：两档收场、一个阈值与 500 毫秒冷却

判定"这是一次完成的用户操作"之后，程序才知道该干活了。这时候还要再分两种情况，依据是"它离该在的位置有多远"。这里用的是四个方向差值的绝对值之和（左、上、宽、高全部相加），一个粗糙但足够好用的距离度量：

• 距离大于 80 像素：走一段缓动动画把它送回原位。动画默认约 240 毫秒，用"先快后慢"的曲线（三次缓出），视觉上像是被磁铁吸回去，而不是硬生生跳过去。拖动距离越远，这段动画越能让人看清"它回去了"，反而比瞬移更不容易让人困惑。
• 距离不超过 80 像素：直接写回原位，不播动画。小距离瞬移几乎是察觉不到的，加一段动画反而显得拖沓。

还有一个和配置有关的分支值得讲清楚，因为它经常被误解。配置里有一个"被吸附窗口被拖走后是否自动吸回"的开关，默认打开。需要说明的是：关掉它并不意味着窗口可以停在别处。 从行为上看，关掉之后依然会写回原位，只是不再走那段 80 像素以上的缓动动画路径，直接一次性写回。这个开关调节的是"归位的过程"（有动画 / 无动画），而不是"归不归位"。

那如果我确实想临时把右边那扇窗口挪开、自己摆一会儿呢？正确入口不是这个开关，而是解除吸附：界面上有解除吸附的入口，触发后整个同步会停下来（配置里"启动时自动吸附"关掉、或者用命令行参数"本次不吸附"启动，也是同样的效果）。解除之后，你手里的窗口就彻底归你管；看完再点恢复吸附，它会重新被摆回主窗口右侧。用一个明确的开关，而不是靠调阈值去"绕过"行为，是这类交互设计里更省心的做法。

最后是那个 500 毫秒冷却。前面提过"被吸附窗口的尺寸变化会让主窗口反向跟随"：如果主窗口因为自身最小宽度限制没有真正变化，程序会在 500 毫秒内不再尝试反向跟随。这段冷却是防自激的：只要两个窗口的尺寸互相依赖，就必须有一个"必要时认输"的出口，否则两边会互相推着改尺寸，每秒几百次的无效写入，既费电又让 CPU 风扇转起来。

关于归位动画还有两处工程细节。一是动画不是独立线程在做：它复用同一套循环节奏，每一轮推进一步（默认 240 毫秒走完，约等于 48 个 5 毫秒的步长），步长里用"先快后慢"的曲线插值，所以动画的平滑度和你设置的轮询间隔是同一件事 —— 把间隔调到 30 毫秒，动画也会跟着变粗。二是动画期间有尺寸下限保护：每一帧算出来的宽度不低于被吸附窗口的最小宽度、高度不低于一个很小的下限，避免动画途中算出零宽或负宽这种非法矩形。同样的道理也出现在首次吸附上：如果被吸附窗口当前的位置与目标位置相差不到 12 像素，就干脆不播动画，直接写到位 —— 差这么一点还播动画，反而像是在故意晃一下。

如果你中途开始拖动主窗口，正在播放的归位动画会被立刻中止，转入"主窗口一动就立刻跟随"那条路径。这条规则看起来是细节，实际很关键：动画的目标位置是按"当时的主窗口"算出来的，主窗口一旦移动，那个目标就过期了；继续把动画播完，等于把一个已经作废的位置写上去，然后再纠一次。及时作废、直接跟随，是更省事也更顺的做法。

六、过渡态：最小化占位矩形为什么整轮跳过

系统里有一个几乎每个窗口程序都会踩的坑：窗口最小化时，它并不"消失"，而是被搬到一个很远的坐标去。这个坐标在横竖两个方向上都远小于 -10000（俗称 -32000 附近），同时尺寸被缩成图标大小。如果你把这个矩形当成真实位置去参与几何计算，就会算出荒唐的结果 —— 比如"被吸附窗口的主窗口在屏幕外一万像素处"，于是跟着把另一扇窗口也搬过去。

处理方法很直接：凡是读到这种"远在天边、尺寸奇小"的矩形（坐标小于 -10000，或宽高小于 100），就判定为最小化过渡态，整轮跳过 —— 不推理、不写窗口、不改任何状态，等下一轮重新读。这里的关键词是"整轮"：不是"忽略这一个矩形然后用上一轮的数据继续算"，而是这一轮什么都不做。因为最小化与还原的过程本身是异步的，中间可能读到新旧混合的尺寸，任何基于半成品数据的推算都会把窗口写到错误的位置上。宁可晚 5 毫秒，也不要写错一次。

与过渡态配套的是"最小化联动"。默认行为是：主窗口最小化时，被吸附窗口跟着最小化；主窗口还原时，它一起还原。这样你在任务栏上看到的是一个组合，点一下两扇窗口一起回来，符合"它们是一体的"这个直觉。实现上有一处细节：程序只对"因主窗口最小化而被动最小化的那一扇"做还原，用一个标记记着"这次是我让它最小化的"，避免和用户自己手动最小化右边窗口的操作互相打架。而当你没有最小化主窗口、却单独把右边那扇最小化了时，同步会把它还原成普通窗口 —— 因为吸附的前提就是"它要在场"，一扇缩在任务栏里的窗口没法并排工作。

还有两个和"什么时候该动手"直接相关的节流，一并交代：一是认领被吸附窗口的尝试最多每 400 毫秒一次，二是"它到底在不在、跑没跑"的检查（要扫盘、要枚举进程）每 1.5 秒才真查一次，中间沿用上次结论。这两处的共同理由是：它们比位置同步重得多，没有必要放进 5 毫秒的节奏里。代价是状态文字的变化最多滞后一秒多 —— 例如目标程序刚刚启动，状态栏可能还写着"正在查找"一两秒。这是刻意的取舍，把高频预算全部留给真正需要跟手的那件事。

顺带把"认领"这一步的规则说完，因为它决定了这套同步会认谁、不会认谁。认领只在窗口可见时才发生 —— 目标程序缩在系统托盘里时，它的窗口是被隐藏的，这时候吸上去没有意义，等它被弄回可见（你去点开它，或者发送需求时被叫醒）再来认领。认领成功时，如果对方窗口当时是最大化或者最小化状态，会先把它还原成普通窗口，再开始按几何关系摆放，否则"最大化窗口"和"被吸附窗口"这两个身份会一直打架。另外，判定"哪个窗口是目标"只认一件事：窗口所属进程的可执行文件路径，与配置里指定的路径逐字符相等。刻意不做"读不到路径就按进程名猜"的容错 —— 因为同名进程在真实机器上并不罕见，一旦按名字认错，后面的移动、唤醒、重启都会作用到另一个程序上，这个代价远比"这一轮没认到"严重。反过来说，这一步还有一个"提前量"设计：认领成功后会在后台把这个程序的无障碍树先"戳"一次（浏览器内核套壳的程序是懒加载的，第一次查询往往要好几秒），这样你过一会儿点「立刻修改」时，第一次查询就能命中，不用现场等。

七、调参手册：轮询间隔、静默阈值、吸回开关怎么定

这套同步暴露给用户的参数不多，但每一个都对应一种"手感"。先给一张按诉求索引的表，再逐项说清背后的取舍：

你的诉求 / 现象	调什么	建议值与说明
拖动主窗口时右边有明显的滞后	轮询间隔	默认 5 毫秒；建议区间 4~10，别低于 2（会被兜回）
老机器上 CPU 占用偏高	轮询间隔	可放宽到 10~16 毫秒，肉眼几乎无差别
慢慢拖着右边窗口想挪个位置，中途就被吸回去	静默阈值	默认 260 毫秒，可加大到 400~600；下限 60 毫秒
不想要归位时那段"滑回去"的动画	拖动回吸开关	关掉后改为直接写回；要彻底放手请用"解除吸附"
首次吸附时的归位动画太慢 / 太突兀	吸附动画时长	默认 240 毫秒；实际下限 120，距离小于 12 像素不播
主窗口最小化时，希望右边留在桌面上	最小化联动	关掉即可各管各的；打开则同进同退
想看它每一轮到底在干什么	诊断日志	打开后每次写入都带"原因"落进 dock.log

关于轮询间隔：4 到 10 毫秒是甜点区。 它的意义在于"追上鼠标"，而鼠标事件本身的采样率就在这个量级；把间隔设到 1 毫秒不会更跟手，只会让每一轮多出来的"读两个矩形、比一次大小"变成纯粹的浪费。反过来，如果设成 30 毫秒以上，拖动时你会看到右边那扇窗口像被一条橡皮筋拖着，落后半步再追上，而追上的一瞬间还可能有轻微的抖动感。

关于静默阈值：它要大于你拖动时的"停顿"。 这是使用这套机制最容易踩的坑。人手拖动不是匀速的：想对准某个位置时，手会停下来一下，几百毫秒不动。如果静默阈值设得比这个停顿短，窗口会在你手指还按着鼠标的时候被判定为"操作结束"然后弹回去 —— 体感极差，像是被谁抢走了鼠标。默认 260 毫秒对大多数人够用；如果你习惯"拖一下、停半秒看看、再拖一下"，把它加到 400 到 600 毫秒会舒服很多。

关于那几个"下限值"的用意。 轮询间隔下限 2 毫秒、静默阈值下限 60 毫秒、动画时长下限 120 毫秒，这些数字的意义不是限制你的自由，而是把"配置写飞"与"程序自激"隔开一堵墙。一个配置文件是给人手写的，写错是常态：0、负数、漏了小数点都很常见。有下限兜着，最坏的结果只是"手感不对"，不会变成"程序空转把机器拖慢"。

踩坑清单：五个"以为坏了，其实正常"的现象

1. 把右边窗口拖到别处，松手后它自己滑回来了 —— 这是设计行为，不是失控。想让它留在原地，用解除吸附。
2. 拖动主窗口时右边窗口内容闪一下 —— 多数情况是对方程序在重新排版自己的界面（浏览器内核套壳的程序尤其明显），窗口位置本身并没有掉队。
3. 状态栏文字要过一两秒才变成"已吸附" —— 目标程序的可用性检查每 1.5 秒才真查一次，这是刻意的节流。
4. 单独最小化右边那扇，它自己跳回普通窗口 —— 吸附状态下它必须在场，这是"两个窗口同一水平线"的前提。
5. 以管理员身份跑的被吸附程序"吸不动" —— 跨权限级别的窗口操作会被系统拦下，把本程序的权限提到同一级别即可，这与参数无关。

怎么验证你的调整真的生效

改完配置重启程序，打开诊断日志，然后做一遍固定动作：把主窗口左右拖动一段、再拉宽一点、最后拖到副屏。日志里对应会出现连续的"跟随主窗口"记录，以及主窗口移动时的目标矩形重算。判断标准有两个：一是拖动过程中日志的写入节奏是否连续（中间应出现"已在目标位置、无需写入"的安静段），二是每次写入的目标值是否和你的公式预期一致。把这两个对上，参数就算调对了。

八、两个自家改包实例：同步不打断，才是真的省时间

"5 毫秒同步"到底解决了什么体验问题？用两个我们自己的场景说清楚。这两个例子的共同点是：改包要等好几分钟，而等待期间你在右边窗口里是有动作的 —— 看它改到哪一步、翻需求、改下一句话。如果同步会抢焦点或打断输入，这几分钟就变成了煎熬。

实例一：自家「冷链温控」调试版改应用名，做出一个能装在一起的"内测版"。

以前的做法：为了让测试同事能一眼分辨"这是内测包不是商店里那个正式版"，得把应用名改成"冷链温控 内测版"。这一步要动到包里的字符串资源和清单文件里的显示名，改完 apktool 回编、对齐、签名，再 adb 装到测试机上确认桌面名字变了。整个流程自己要记三套命令，中间任何一步顺序错了（比如忘了对齐）都会留下隐患；更麻烦的是改的时候没法"边看边确认"，只能改完再看结果。

现在一句话：把自家调试包拖进来，在左边写"把应用名改成『冷链温控 内测版』，图标不要动"。点「立刻修改」之后，需求被送进右边那扇窗口执行，你可以在右边看着它一处处改；与此同时，左边主窗口随时能拖、能缩放，两扇窗口在 5 毫秒的节奏里保持"焊死"的关系，不存在"拖动主窗口导致右边窗口掉队、看不清它在改什么"的情况。改完，本地自动弹出打包窗口跑完回编、对齐、签名、校验四步。

怎么验证？打包完成后装上测试机，看一眼桌面上显示的名字；再用"打包后自动运行"的勾选项，装完自动拉起应用，程序还会用系统命令复核一遍前台应用是不是它，避免出现"装上了但没启动、以为改失败"的假结论。桌面名字、启动后的界面、加上打包日志里那条签名校验信息，三处对上就可以交出去了。

实例二：给自家「巡店助手」去掉自家应用的开屏广告页。

这是我们自家应用的推广页，每次启动都要停几秒再进主页，内部同事天天吐槽。以前的处理方式很"传统"：找到启动活动里跳转广告的那段逻辑，读 smali、判断哪个跳转要改、改完回编签名装机，等一次启动看是不是真的直接进主页了。整个过程最耗时的不是改，而是读代码那一步需要专注，而屏幕上来回切窗口会不断打断你。

现在一句话："去掉应用启动时的开屏广告页，启动后直接进入首页"。剩下的交给流水线：AI 改完之后自动打包，装机验证启动是否直接进主页。这里的同步机制同样在起作用 —— 读需求、写需求、翻历史都在左边那扇窗口完成，右边一直在原地显示 AI 的工作过程，两扇窗口高度相等、宽度合计占屏 3/4，视线不用跳；你在这边打字时，同步不会把焦点抢走，鼠标也不会因为窗口被搬动而落到别的地方。

这两个例子想说明的道理是一样的：高频同步的价值不在于"窗口摆得准"，而在于"摆的过程完全不打扰你"。 一个会跟你抢焦点、抢鼠标、在你打字时把窗口搬来搬去的同步，就算位置算得再准，也只会让人关掉它。克制，是这类后台机制真正难写的部分。

用户评价、合规提醒与结语

回到开头那个平衡题：跟手来自 5 毫秒的高频，友好来自对这一频率的克制。 三处防抖让循环在无事时彻底安静，稳定判定用静默时间把人手拖动与程序写入分开，两档归位与 500 毫秒冷却把互相推挤的可能性提前掐掉，最小化过渡态则整轮跳过、宁可慢一轮也不写错一次。这些规则单看都很小，合起来才让"两扇窗口像一扇"这件事既顺滑又不惹人烦。

这正是安卓修改大师智改工坊想给人的整体感受：只需说话，就能让应用变成你想要的样子。窗口怎么摆、什么时候该安静，这些琐事由程序兜住；你只需要把需求说清楚，剩下的交给流水线 —— 回编、对齐、签名、校验，以及一键装到设备上看效果。介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。