关闭手机蓝牙,你的手表 App 还剩什么

先问你一个问题。

你现在手上的手表 App，把手机蓝牙关掉、手机放桌上，人走到另一个房间，它还能干什么？

如果你的答案是"基本上什么都干不了"，那这篇就是写给你看的。

一、先承认一件事：手表早就独立了，是软件没跟上

我做穿戴端需求的时候，脑子里有句话搁了很久没说出口：

我们一直在把一块独立的设备，当成手机的一个远程界面来做。

而且这个念头特别自然。因为做久了会发现，几乎所有讨论都是这么起来的：

「手表上要显示这个数据，从手机上同步过去。」「手表这边操作完，让手机发一下请求。」

每一句都合理，加起来就变成了一个默认前提：手表是手机的配件。

但硬件那边根本不是这么回事。

二、硬件这条路，其实走了十年

我查了一下公开资料，这条线比我印象里清楚得多：

2015 年，华为第一款智能手表（HUAWEI WATCH）跑的是 Android Wear，靠蓝牙跟着手机走。

2017 年，Watch 2 出了 LTE 版本。这是华为手表第一次能脱离手机打电话、用移动数据。

2021 年，Watch 3 系列开始内置 eSIM，独立联网成了旗舰标配。

到今天，WATCH 6 这类设备支持 eSIM 独立通话，有一号双终端和独立号码两种模式。官方说明里明确写着，即使省电模式下也能接打电话；手表上还有智慧生活 App 手表版，不需要手机就能远程控制家里的设备。

十年。硬件从"跟着手机走"，做成了"离开手机也在线"。

所以问题从来不是「手表能不能独立」。

是我们这些写 App 的人，还没跟上。

三、这个错，会以什么方式暴露

我把它拆成四个具体后果。你可以对照一下自己的项目。

1. 手表端没有独立的网络能力

不带手机的时候，手表上的功能大面积失效。

但硬件早就支持了。WATCH 5、WATCH 6 这类设备开 eSIM 之后，断掉蓝牙它会自动切到蜂窝。能力在，是我们没用。

2. 手表端的鉴权是"借用"来的

手表登录态从手机同步过来，或者干脆用手机下发的 token。

独立链路一旦立起来，这条借用来的凭证就成了安全模型的缺口。因为它绕开了手机端的登录态校验，自己却没有完整的一套。

3. 手表端不处理"手机不在"

所有异常处理都假设手机在附近。

可用户最需要手表的时候，恰恰就是手机不在的时候。跑步、游泳、开会、下楼取快递，这些场景里手表是唯一在场的设备。

4. 手机端状态被当成唯一真相源

手表操作完，等手机来同步。

手表一旦独立发起操作，手机端就没有事件来源。你在手表上锁了车，手机界面还停在"已解锁"。

四、一个不花钱的自检

不用改代码，先做这个测试。

把手表连着的手机蓝牙关掉，手机放远，然后你用手表把 App 里每个主要功能点一遍。记录三类：

1. 哪些功能直接灰掉或报错。说明它根本没做独立路径。

2. 哪些功能能点但一直转圈。说明它在等一个永远不会回来的响应。

3. 哪些功能正常。这些才是真的独立。

第 2 类最危险。因为它看起来像"网络慢"，实际上是架构问题——它连"该走哪条路"都没想过。

五、正确的形态

一句话：手机和手表，是两条并列的链路，各自连云端，各自连车。

这两条链路各自要有独立的登录态、独立的指令通道、独立的状态刷新。

这三样如果从手机端"借用"，独立之后一定出问题。

六、说句实话

我得承认，我最初画架构图的时候，画的也是"手表 → 手机 → 云端"。

不是没想过独立，是那个版本画下去很顺，所有需求都能满足，评审也没人提。

后来有一次被人问了一句：

「手表没带手机的时候怎么办？」

那一刻我才发现，我们做了那么久的手表功能，从来没测过"手机不在"这个场景。

七、这句话不是技术判断，是产品判断

手表不是手机的第二块屏。

一旦你承认它是独立设备，很多设计就得重做：

· 不能再用"手机登录后同步给手表"

· 不能再用"手机收到推送再转给手表"

· 不能再用"手表这边先记着，等手机来同步"

这三条每一条都省事，每一条都会在"手机不在"的那一天一起失效。

而那一天，一定会来。

最后

如果你也在做穿戴端，我想知道一件事：

你们测试的时候，测过"手机不在"吗？

如果测过，是怎么测的？真机断蓝牙，还是模拟的？

如果没测过，那这篇可能来得正是时候。

留言告我一声，我下一篇想写这个。

我是汪闲僧，在车企写鸿蒙，业余看球、偶尔写字。

这个号周更，只写三件事：车上的 App 和穿戴、鸿蒙两端：App 和设备、把活干快。

写得慢，但每篇都想清楚了才发。