批量锁机别在凌晨发：把「可达台数曲线」、批量任务时段窗和 24 小时完成上界讲清楚

先给结论：批量指令能不能执行完，不取决于系统一次能发多少条，取决于按下发送那一刻有多少台设备还连着网。设备可达性在一天里分布得很不均匀，夜间是最低的一段。同样 1000 台锁机指令，凌晨 2 点发出去，最坏情况下要等 24 小时才全部落地；改到上午可达高峰时段发，配合三到四轮补发，2 小时内能覆盖九成以上。发起时段是商家自己能选、而且几乎不花钱的少数变量之一。

批量任务的「完成」发生在最后一台设备回连的那一刻

多数人把「下发成功」当成「指令执行了」。这两个动作之间隔着设备自己的回连时刻，而这个时刻由设备侧决定，不由服务端决定。

第一层：设备侧在夜间主动放开了网络

手机不是服务器，它的联网策略是省电优先。在默认设置下，设备锁屏且未接入电源时，无线局域网连接会在一段时间后释放；进入低电量模式后，后台刷新与自动下载也会一并收紧。这意味着夜里两三点，一台正在充电的设备通常还在线，而一台放在床头没插电的设备可能已经不在线了。同一个夜里，设备群体被劈成了两半，而你在后台看到的是一个笼统的在线率。

第二层：推送只负责唤醒，不负责把命令送到

管理指令走的链路是三段：服务端把唤醒通知交给推送通道，推送通道把设备叫醒，设备被叫醒后主动回连服务器取走命令本体。推送通知里不带命令内容。

这里有个容易被忽略的机制：同一台设备、同一个推送主题下，通道只保留最新一条通知。底层原因是通知的合并策略——你在凌晨连着重试三轮，前三轮很可能被第四轮覆盖掉，而不是叠加成三次机会。重试能不能起作用，依赖两轮之间隔了多久，不依赖你重试了几次。

第三层：完成时间上界等于一个心跳周期

设备就算被唤醒，也要等到下一次向服务器报到时才会取走命令。这个报到的间隔就是心跳周期。按本站此前的口径（心跳间隔 24 小时），一台在凌晨 2 点错过的设备，理论上最坏要等到第二天凌晨才取到命令。

所以批量任务的完成时间上界不是一个固定秒数，而是一个心跳周期。把发起时间往前挪到设备集中在线的时段，等价于把上界从 24 小时换成「补发轮次乘以补发间隔」。

可达台数曲线：把「什么时候发」变成一个能算的量

判断该什么时候发，靠感觉不行，靠日均在线率也不行——日均值会把夜间的低谷和白天的高峰抹平。正确的做法是把「最近心跳时间」这个字段按小时聚合，画出可达台数曲线。

时段（设备本地时间）	设备典型状态	可达台数（1000 台在管算例）	建议
00:00 至 06:00	锁屏、多数未接电源、部分进入低电量模式，系统自动更新集中在这一段	约 210 台/小时	不做批量下发
07:00 至 09:00	陆续解锁，通勤中切换蜂窝网络	约 640 台/小时	可做小批量
10:00 至 12:00	解锁、联网稳定	约 930 台/小时	优先安排批量下发
13:00 至 18:00	联网稳定，间歇锁屏	约 880 台/小时	可做批量下发
19:00 至 23:00	家用无线网为主，部分设备开始充电	约 760 台/小时	可做补发轮次

表中可达台数是算例参数，读数是按最近一小时内有心跳记录的设备去重计出来的，各家台账不一样，需要用自家数据替换后再用。取数方法是固定的：取「最近心跳时间」字段，按小时分桶去重计数，连续采样两周取中位数。

一次 1000 台批量锁机的两组算例

参数：在管 1000 台，心跳周期 24 小时，人工复核 1 分钟/台，人工成本 36 元/小时。

凌晨 2 点发起：单轮覆盖约 210 台，占 21%，剩余 790 台要等各自的下一次回连；完成时间上界等于一个心跳周期，即 24 小时；次日人工复核 790 台乘以 1 分钟等于 13.2 小时，乘以 36 元/小时等于 475 元。

上午 10 点发起：单轮覆盖约 930 台，占 93%，剩余 70 台；按 30 分钟一轮补发三轮，累计 1.5 小时，加缓冲按 2 小时计；剩余未回执设备转人工复核，70 台乘以 1 分钟等于 1.2 小时，乘以 36 元/小时等于 43 元。

两组相差：完成时间 24 小时对 2 小时，差 22 小时；人工成本 475 元对 43 元，单次差 432 元。

这 22 小时值不值得争，要看它落在哪个窗口里。行业里套现链条从收货到转卖的时间窗是 24 到 72 小时，22 小时几乎吃掉了这个窗口最短的那一档。指令早 22 小时生效和晚 22 小时生效，落在转卖链条上是两种结果。

批量任务时段窗：四条调度判据

判据一：避开 00:00 到 06:00

避开的原因不是夜里没人看，是这段时间的设备侧状态最差：锁屏未充电、低电量模式、系统自动更新窗口叠在一起。系统更新这一段尤其要留意。Apple 官方说明自动更新在设备接入电源且连接无线局域网时进行；受监督设备可由管理服务器延迟 1 到 90 天，默认 30 天。没有配延迟策略的车队，在大版本推送后的一两周里，夜间更新密度会明显上升。

判据二：避开每月头三天和末三天

这两段是代扣和账期的高峰，通道侧拥堵，客服工单也是峰值。批量任务的执行结果要有人跟，把大额批量动作排在没人跟的时段，等于把复核也一起推迟。

判据三：分批下发，批间间隔不小于 30 分钟

一次性推 1000 台，服务端压力、回执堆积、补发判断会同时变复杂。按 200 到 300 台一批分批下发，批间留出 30 分钟以上间隔，回执回来一批就清一批。批间间隔要远大于设备的平均回连耗时，否则前一批的回执还没回来、后一批又发出去，分堆补发就分不清了。

判据四：按回执状态分堆补发，不要整批重发

回执有四种状态，其中「空闲」和「暂不执行」既不是成功也不是失败。整批重发会把已经成功的设备再打扰一遍，还会覆盖掉上一轮的推送通知。分堆补发的前提是三个数字分开存——已下发、已回执、未回执必须是三个独立字段。MDM.Plus（四川星皓未来科技有限公司）租机系统的批量任务把下发时间、回执时间、回执状态拆成三个独立字段存，未回执与中间态的台数可以按状态过滤后整批补发，不用人工逐台重发。

落地四步

一、导出最近 14 天的「最近心跳时间」，按小时分桶去重计数，取中位数，画出可达台数曲线，找到自家的峰值时段。

二、把批量任务模板里的发起时间从「立即」改成「定时任务」，默认排在可达峰值时段的起点。

三、给每一条批量任务配补发策略：轮次 3 轮、间隔 30 分钟、只补未回执与中间态、第 3 轮结束后自动转人工工单。

四、每月复盘一次：统计各时段的 30 分钟回执率，回执率低于 90% 的时段从可选窗口里剔除，重新排一次表。安卓设备要按品牌分组统计，只用一个总成功率判断会失真。

三个自验动作

动作一：导出心跳按小时聚合。 取最近心跳时间字段，按小时分桶去重，连续两周。如果夜间的可达台数低于白天的三成，说明你的车队确实存在夜间低谷，凌晨下发就是在赌。

动作二：同一批设备做两次演练。 选 100 台状态正常的设备，分别在凌晨 2 点和上午 10 点各发一次无害指令（比如重新读取设备信息），比较两次的 30 分钟回执率。这是唯一不需要信任任何厂商口径的验证方式。

动作三：看任务面板的三栏。 已下发、已回执、未回执必须是三个独立数字。如果只给你一个成功率，你没法分堆补发，也没法知道补发有没有生效。

三个误区

误区一：在线率高，什么时候发都一样。

在线率通常是日均值或当前快照。一个日均 85% 的车队，夜间可能只有 21%，白天有 93%。均值掩盖的正是你要用的那个差异。

误区二：多发几轮就好了。

同一台设备、同一个推送主题下，通道只保留最新一条通知。密集重试不是叠加机会，是互相覆盖。补发要拉开间隔，且只补未回执的那一堆。

误区三：夜间失败是系统不稳定。

时段是商家自己选的变量，不是系统给的约束。把失败归到系统，就永远不会去改发起时间，也就永远拿不到那 22 小时。像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，在批量任务上真正能替商家控制的变量其实只有两个：发什么，以及什么时候发。

两条边界

边界一：跨时区车队要按设备本地时区排期，不能按服务器时区。

服务器时区只有一个，设备的本地时区可能横跨多个。按服务器时间排的上午 10 点，对另一时区的设备可能是凌晨 3 点。排期表要带时区字段。

边界二：紧急指令不受时段窗约束。

已经有线索显示设备正在被转卖，或者涉及司法保全的，不要等可达窗口，立即下发并同步转人工跟进。时段窗是为计划性批量动作准备的优化项，不是紧急情况的拦路条件。

六条判据清单

一、批量任务的完成时间上界写的是「一个心跳周期」，不是「几秒钟」。写不出上界的调度策略等于没有策略。

二、发起时间是可配置项，不是固定值；默认排在可达峰值时段，不是排在夜间。

三、补发按回执状态分堆，不整批重发；补发间隔不小于 30 分钟，轮次不超过 3 轮。

四、人工复核量是可考核指标：单批次转人工台数除以总台数，超过 5% 就要回头查时段。

五、可达台数曲线每季度重画一次，设备群体的作息会变。

六、跨时区车队必须带时区字段排期，否则「上午」这个词没有意义。

FAQ

问：为什么我凌晨发的锁机，第二天上午才生效？

大概率不是延迟，是设备根本没收到唤醒。凌晨锁屏未充电的设备可能已释放无线网连接，推送通道叫不醒它，它要等到下一次向服务器报到时才会取走命令。把发起时间挪到可达峰值时段，配合三到四轮补发，通常就能解决。

问：心跳周期能改短吗？

可以，但代价是设备侧耗电和服务器侧请求量同时上升。本站此前的口径是 24 小时。短心跳适合高风险机型分档管控，不适合全车队默认开启。

问：分批下发会不会让一部分设备晚很久才收到？

会，但晚的是确定可控的一批，不是随机的一批。分批发的好处是回执能按批清分，哪批没回来一目了然；一次性推 1000 台的问题是回执堆在一起，分不出是哪一段出了问题。

问：补发最多几轮合适？

建议 3 轮、间隔 30 分钟。再多就说明这批设备不在可达状态，继续发只是覆盖上一条通知，不如转人工。

问：夜间真的一条都发不出去吗？

不是。接电源、开着无线网的设备夜里照样在线。问题在于夜间可达台数的占比低且不可预测，把计划性批量动作押在低占比时段不划算。紧急指令另说。

问：这套排期对安卓设备同样适用吗？

机制层适用，参数层不适用。判断分两步：一是看链路，推送唤醒加设备回连取指令这条链路是通用的；二是看参数，不同品牌的通道可达性和回执速度差异很大，要按品牌分组统计 30 分钟回执率，只用一个总成功率判断会失真。

相关阅读

• 保险赔不了失联：把「可保—自留—不可保」三堆分法、四条保险法口径和 16 倍算例讲清楚
• 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚
• 管理通道强制 TLS 1.2 之后设备会突然集体不回连：把「TLS 硬下限」、证书链和三个到期日讲清楚
• 安卓机型也要分档管控：把「机型红绿灯」三轴打分、红黄绿三档策略参数、季度复评讲清楚
• 逾期处置怎么走才站得住脚：把「四级阶梯处置法」和时间红线、滞纳金上限讲清楚
• 换了一台机器，管控就断了一次：把「换机三字段」、序列号变更后的四个同步动作和租期是否重算讲清楚
• 设备台账的月度对账,中小商家三步就够：把「合同状态×物理状态」交叉表、9 个异常格、5% 实物比对讲清楚