手机秒变蓝牙键鼠：基于Serverless的跨设备远程控制方案

前阵子调试智能家居的时候，天天要在终端里敲命令，手上又懒得拿笔记本，就顺手做了个用手机当蓝牙键盘鼠标的方案。做完之后发现这套思路挺有意思：手机没装任何桌面端，却通过蓝牙HID协议把自己伪装成标准键鼠设备，指令中转和状态编排全部交给Serverless平台处理，整个方案跑下来几乎零成本，也基本不占手机资源。

这个项目解决的痛点很实际：演示PPT时想用手机当翻页笔、电脑在客厅不想起身去按键盘、临时要往单位电脑贴一段文字却懒得开QQ微信，这些场景下，一部手机就够了。适合谁看呢？如果你想在自己的项目里做“跨设备控制”又不想引入常驻服务器，或者想在移动端玩蓝牙HID外设模拟，这篇内容应该能省你不少弯路。

先说清楚这个方案到底在干什么：手机把自己注册成一个蓝牙键盘和鼠标（也就是HID设备，Human Interface Device），电脑、平板、电视盒子这些标准蓝牙主机不需要装任何特殊驱动就能识别它。然后，手机端App把触屏操作、语音输入、甚至云平台下发的指令，翻译成标准HID报文发出去。这里面的“云平台下发的指令”就是Serverless登场的地方——它负责管理设备连接状态、转换指令格式、记录操作日志，但不跑任何常驻进程，按调用次数计费。

下面我把整个项目的拆解思路、底层原理、实现细节和踩坑记录整理出来，尽量做到拿着这篇文章可以直接上手复现。

1. 整体设计思路拆解：这套方案到底在拼什么

1.1 两个核心问题：蓝牙链路和指令编排

这个项目表面上是“手机变成键鼠”，本质上要解决两个彼此独立的问题。

第一个是蓝牙链路的身份伪装。手机要跟电脑通信，不能再走传统的蓝牙音频或者文件传输通道，而要走蓝牙经典（BR/EDR）里的HID通道。蓝牙组织专门定义了HID Profile（HID over GATT和传统HID Profile是两条路线，这里用的是后者），目的是让耳机、手柄、键鼠这类设备能跟PC、游戏机互认。手机要加入这条链路，需要系统API支持把自己注册成HID设备。Android从4.2开始其实就有BluetoothHidDevice相关的框架，但直到Android 9左右才开放了比较完整的API给普通应用（部分厂商ROM仍有限制），iOS则因为系统封闭，基本只能靠MFi外设方案，这条路暂时走不通。

第二个是跨端指令的编排。手机App直接连电脑，可以做单机版键鼠；但如果想实现“手机不在同一房间也能控制”“把手机当成一套可编程宏键盘”“多个手机轮流连同一台电脑”这类进阶效果，就需要一个中间层来管理连接状态和指令路由。这个中间层不用很重，但需要能稳定处理短时高频请求，Serverless函数计算正好是这种负载的典型匹配对象。

1.2 为什么选Serverless而不是常驻服务器

我个人在早期版本里其实先用了云服务器上常驻的WebSocket服务，后来才切到Serverless。对比之后结论很明确：这类“指令中转+状态同步”场景，常驻服务器90%的时间是空闲的，但你必须为它的存在买单，还要处理进程守护、证书续期、SSH维护等一系列麻烦事。

Serverless天然适配：一来，键鼠事件本质是短小、高频、有突发性的离散消息。用户按一下音量键、点一下屏幕、划一下触控板，后端需要做的只是“收到事件→查一下这个设备绑定的目标→转成HID报文或者下发指令给对端”这样轻量级的动作，没有长连接需求，没有大流量吞吐需求。二来，Serverless平台的自动扩缩容对这种突发负载很友好，高峰期一瞬间来几百个事件请求时，平台自动拉起多个实例；半夜没人用时缩到零，账单也跟着归零。再加上函数计算本身支持多种触发方式，可以与API网关深度绑定，天然适合手机App通过HTTPS上报指令这种模式。

1.3 和常见替代方案的对比

做这个项目之前，我对比过市面上常见的几类做法：

• 专用蓝牙键鼠/翻页笔：几十块钱就能买到，但功能固定，没法定制，也没法实现跨网络的远程指令。
• 远程桌面类软件（如RD Client、VNC）：能远程操作电脑上的界面，但依赖网络质量，且只是“看屏幕”，不是原生键鼠输入，跟某些软件兼容不好。
• 网络KVM类硬件：企业级方案，稳定但价格高，不适合个人玩。
• 本方案（手机蓝牙HID + Serverless编排）：手机端负责HID设备模拟，Serverless负责云端指令汇聚和管理，兼顾了“物理层零成本”和“逻辑层可编程”两个优点。

选型时还有一个隐性考量：蓝牙HID链路一旦建立，手机和电脑之间的通信完全不依赖互联网。这就意味着即使云端服务临时不可用，只要本地App带有一份离线指令表，照样可以当普通蓝牙键鼠用。Serverless只是给这套系统增加了“远程指挥”和“状态编排”能力，属于锦上添花，不构成单点故障。这一点从工程架构上看非常舒服。

2. 蓝牙HID底层原理：手机伪装键鼠的关键

2.1 HID是什么，为什么系统只认HID

HID全称Human Interface Device，人机交互设备。鼠标、键盘、手柄、触控笔，本质上都是HID设备。操作系统跟这些设备通信，不关心你的硬件里面跑了什么芯片、用了什么传感器，只认一套标准化的描述符协议。这套协议定义了设备是什么（键盘、鼠标还是两者兼具）、能上报什么数据（按键码、坐标、滚轮）、数据包的格式长什么样。

这套标准化的好处非常明显：一个蓝牙键盘，不管是什么牌子、什么固件、在哪个国家买的，连上新电脑都能直接打字。手机想“伪装”成键鼠，本质就是让手机向电脑发送符合HID标准的描述符和事件报文，电脑端会像对待任何正常外设一样对待它，不需要安装任何手机厂商的驱动。

2.2 HID Report Descriptor的写法与含义

描述符是整个伪装过程的“身份证明”。我用一个简化的键盘鼠标复合设备描述符来说明：

0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x02, // Usage (Mouse) 0xA1, 0x01, // Collection (Application) 0x09, 0x01, // Usage (Pointer) 0xA1, 0x00, // Collection (Physical) 0x05, 0x09, // Usage Page (Button) 0x19, 0x01, // Usage Minimum (1) 0x29, 0x03, // Usage Maximum (3) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x95, 0x03, // Report Count (3) 0x75, 0x01, // Report Size (1) 0x81, 0x02, // Input (Variable) 0x95, 0x01, // Report Count (1) 0x75, 0x05, // Report Size (5) 0x81, 0x01, // Input (Constant) 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x30, // Usage (X) 0x09, 0x31, // Usage (Y) 0x15, 0x81, // Logical Minimum (-127) 0x25, 0x7F, // Logical Maximum (127) 0x75, 0x08, // Report Size (8) 0x95, 0x02, // Report Count (2) 0x81, 0x06, // Input (Variable, Relative) 0xC0, // End Collection 0xC0, // End Collection

这段描述符定义了鼠标的按钮状态（3个按键位）和相对坐标位移（X/Y两个轴）。后面如果再加上键盘的Usage Page（0x07）和键盘报告结构，就可以做成复合设备，让电脑以为插入的是一个“键盘鼠标一体式外设”。写描述符的时候最容易犯的错是Report Count和Report Size算错位数，导致整个报文长度对不上，蓝牙连接成功但设备就是没反应，后面排查起来很费劲。

2.3 手机端API与权限限制

Android端实现HID设备模拟，核心API是BluetoothHidDevice。基础的用法是先通过BluetoothAdapter.getProfileProxy()拿到HID服务代理，然后注册一个BluetoothHidDevice.Callback回调，再调用registerApp()把应用注册为HID设备。注册成功后，用sendReport()或sendGetReport()向已连接的主机发送HID报文。

这个API有个非常坑的地方：大多数设备要求应用持有BLUETOOTH_PRIVILEGED权限，这是系统级权限，普通应用拿不到。这就导致了一个很现实的情况：用AOSP编译的ROM或者刷了Magisk的环境里，可以很轻松地调用这个API；但如果你用的是小米、华为、三星这类出厂ROM，直接调用大概率会被权限拦截，或者能注册但连不上电脑。

绕过方案有三个：一是尽量选用支持该能力且放开权限的ROM（比如某些类原生系统）；二是用adb shell appops set或者Magisk模块给应用额外授权；三是放弃BluetoothHidDevice，改用低功耗蓝牙HID over GATT（BLE HID），Android从8.0开始支持BLE外设模式，BLUETOOTH_CONNECT权限比系统特权权限宽松不少，而且新版电脑普遍支持BLE键盘鼠标。我在实际项目中最后就是走BLE HID路线，虽然延迟略高于经典蓝牙，但在办公和演示场景完全够用，最大的好处是免去了系统权限的折磨。

3. 服务端编排：Serverless在这套方案里的角色

3.1 Serverless架构设计：三个核心函数

整个Serverless部分我拆成了三个云函数，按职责划分，互不耦合：

• session-manager：负责设备会话管理。手机首次连上蓝牙后调用一次，向服务端登记设备信息（设备唯一ID、目标主机别名、当前会话状态）；断开时再调用一次释放会话。数据存在云数据库里，每条记录只保存“设备ID-目标主机对应关系”和最近心跳时间。
• command-relay：负责指令转换与下发。手机把“按下了音量+”事件上报上来，这个函数查一下会话表，确认这台手机当前可以控制哪个目标，然后把事件转换成标准HID键值或自定义宏指令，推送到目标端（比如通过WebSocket给电脑端驻留的代理程序，或者直接写入消息队列）。
• event-logger：负责操作日志。每次键鼠事件写一条日志，用来做后续的统计分析（比如统计哪个时间段使用频率高、哪些按键误触率高）。日志写完后异步处理，不影响主链路延迟。

这样的拆分逻辑很清楚：会话管理和指令转发是两种完全不同的负载特征，前者低频但需要有状态，后者高频但无状态，混在一个函数里会互相拖累。比如commond-relay被突发流量打爆时，不能影响session-manager的正常查询。

3.2 指令协议设计：JSON格式与状态机

因为键鼠事件大多是短消息，用JSON做传输格式成本很低，又方便调试。我设计了一套精简协议，核心事件结构大致如下：

{ "type": "key", "action": "press", "keyCode": 0x15, "modifiers": { "ctrl": false, "alt": false, "shift": false }, "timestamp": 1712996400000, "deviceId": "phone-a1" }

鼠标事件则将会是可以变为：

{ "type": "mouse", "action": "move", "dx": 30, "dy": -15, "buttons": 0, "timestamp": 1712996401000 }

协议设计时有几个细节值得注意：

• keyCode统一使用USB HID键值（比如Enter键是0x28，字母A是0x04），不要用ASCII码，因为HID键值和ASCII不是一一对应关系，一旦用错，云端序列化再反序列化时特别容易出乱码。
• 所有报文必须带deviceId。同一账号下可能有手机、平板、备用机同时在线，且它们可能控制不同的目标主机，不带设备ID会导致指令被路由到错误的电脑。
• timestamp用于按时间戳排序。蓝牙HID事件本身是有序的，但上报到云端走HTTPS后，请求到达顺序可能不一致。目标端应该根据timestamp做一次缓冲排序，避免按键顺序错乱。

3.3 为什么用Serverless部署，冷启动如何规避

说到“serverless部署”，不少人的第一反应是冷启动延迟。对于键鼠这种要求低延迟的场景，冷启动确实是个隐患。但实际用下来，有几种方法可以把它压到可接受范围：

• 函数预热：在管理后台设置定时触发器，每5分钟用心跳请求唤醒函数一次。这个方法最简单，缺点是会造成少量闲时计费。对免费额度来说，几乎可以忽略。
• 并发实例保持：部分云函数平台支持配置最小实例数，比如保持1个热实例。这样第一次请求进来时不会经历冷启动，代价是相当于又有了一个“低配常驻进程”，费用比完全弹性略高。
• 协议层面降级：如果极端情况真遇到冷启动（比如平台波动导致实例回收），手机App端有一份本地指令缓存表和一个“降级模式”。手机和目标主机若在同一个局域网内，可以走局域网直连通道，完全绕开云端。Serverless在这里只是“首选通道”，不是“唯一通道”。

我实际采用的策略是“定时预热+协议降级”双保险。实测下来p99延迟在200毫秒以内，p50在80毫秒左右。这个数字对键盘输入来说略高，但对绝大多数控制类操作——比如播放下一页、调音量、发快捷键组合——人是感知不到延迟的。

4. 端到端实战：从设备配对到远程控制的完整链路

4.1 准备工作与硬件选型

先说硬件，这个项目对手机的要求不高，Android 9以上的主流手机即可，只要是带蓝牙硬件的都行。如果是iOS设备，最多只能做成局域网内的虚拟触控板，走不了蓝牙HID伪装，这点要提前想清楚。目标主机（被控制的电脑）Win10/macOS/Linux都支持标准蓝牙键鼠，没有额外兼容要求。

开发环境方面，手机端用Android Studio，Kotlin语言，目标SDK 33左右即可。云函数我一开始用Node.js写的，后来换成Python版本（个人更熟悉Python的日志和字典处理），选型因素主要是团队维护习惯，两者在函数计算平台上差别不大。

4.2 Serverless部署步骤：以函数计算平台为例

下面用常见的函数计算平台为例，演示一个最小可用的command-relay函数从创建到上线的过程。

第一步，在控制台创建服务，运行环境选Python 3.9或者Node.js 16，函数入口填index.handler。创建成功后，在代码编辑区粘贴核心逻辑：

import json def handler(event, context): # 从API网关传过来的body解析事件 body = json.loads(event.get('body', '{}')) device_id = body.get('deviceId') event_type = body.get('type') action = body.get('action') # 这里替换成真实的数据库查询逻辑 target_host = query_target_host(device_id) if not target_host: return { 'statusCode': 404, 'body': json.dumps({'error': 'host not bound'}) } # 构造下行指令，投递到目标主机对应的消息通道 dispatch_to_target(target_host, body) return { 'statusCode': 200, 'body': json.dumps({'ok': True, 'routedTo': target_host}) }

第二步，绑定API网关触发器，创建一条路径规则。比如POSThttps://your-service.com/api/v1/command，HTTP方法和路径选好后，网关会自动把进来的请求转成上面handler能处理的event格式。建议在网关层开一个访问密钥，避免任何人拿到地址就能给你的电脑发指令。密钥放在请求头里，服务端用环境变量保存并校验。

第三步，设置环境变量和依赖。函数代码里用到的云数据库连接信息、密钥、队列topic，统一放进环境变量，不要写死在代码里。依赖安装方面，函数计算平台都支持在线安装依赖，直接把requirements.txt填进去，或使用控制台提供的“层”功能。

第四步，配置触发器策略。默认所有请求都会触发函数执行，最好加上一个频率限制，比如单个设备每分钟最多600次调用，防止误操作或恶意刷量导致费用异常。

这个流程跑通之后，你用curl模拟一条鼠标事件请求，函数返回200且目标端收到消息，就说明服务端编排这一层已经完成。

4.3 手机端实现要点：HID设备注册与报文发送

手机端的核心代码分两部分，第一步是注册HID设备。以BLE HID方案为例，核心逻辑大致是这样：

val bluetoothManager = getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager val bluetoothAdapter = bluetoothManager.adapter // 通过 BluetoothHidDevice 注册（部分ROM需要系统权限） val hidDeviceProfile = bluetoothAdapter.getProfileManager() .getProfileProxy(context, hidDeviceCallback, BluetoothHidDevice::class.java) // 注册应用 hidDeviceProfile.registerApp( "com.example.virtualkb", "Virtual Keyboard & Mouse", "Example Inc.", hidDeviceCallback )

第二步是发送鼠标移动报文。HID鼠标报文一般是4字节：第一个字节是按键状态，第二、三字节是X和Y的相对位移（有符号），第四个字节是滚轮。如果要模拟平滑移动，需要把一次大的位移拆成多个小步长，每步之间加极短延时（比如2~5毫秒），否则电脑端的光标会像瞬移，很难精准定位。

fun sendMouseMove(dx: Int, dy: Int) { // 将坐标转换为单字节有符号整数 val report = byteArrayOf( 0x00, dx.coerceIn(-127, 127).toByte(), dy.coerceIn(-127, 127).toByte(), 0x00 ) hidDeviceProfile.sendReport(connectedDevice, 0, report) }

这里有一个经验之谈：手机屏幕上的滑动距离和电脑光标的移动距离之间存在一个“灵敏度系数”，我一般取2.0~2.5倍，也就是手指在手机上滑1厘米，电脑光标移动2厘米多。系数太大光标飘，太小手要反复滑，建议做成设置项让用户自己调。

4.4 指令流转链路与端云协同

把整套链路的请求路径串起来看：

手机用户点击触控板或键盘按键，App生成结构化JSON事件，带上设备ID和事件时间戳；事件先走HTTP（或HTTPS）上报到API网关；网关鉴权后把事件转给command-relay云函数；command-relay查询会话表，确认这台手机绑定的目标主机；函数将事件推送到目标主机上的驻留代理程序（通常通过WebSocket长连维持）；代理程序解析JSON，调用操作系统API或者通过HID内核模块注入键鼠事件。至此，一次完整的跨设备操作闭环就完成了。

如果目标主机上没有驻留代理程序，还有一个纯硬件方案可以平滑替代：再准备一块支持HID的蓝牙开发板（比如ESP32），开发板本身就注册成HID键鼠并连接电脑，同时以低功耗蓝牙或Wi-Fi方式接收手机指令。这样手机发给云端的指令最终由开发板执行，开发板跟电脑之间仍然走标准蓝牙HID。这个方案把“云端编排”和“本地注入”之间的鸿沟补上了，适合不想在电脑上装任何软件的读者。

5. 常见问题与排查技巧：实战中踩过的坑

5.1 设备能配对但电脑没反应

这个现象非常典型，出现概率也最高。最常见的原因是HID描述符的Report Map没有发送成功或格式错误。检查思路是：先用官方自带的蓝牙日志工具（或Android的adb shell dumpsys bluetooth_manager）确认HID设备是否已经注册成功，再查看电脑端“设备管理器”或“系统信息”里是否识别到了键盘鼠标设备。如果识别到但没反应，大概率是Report Descriptor里报告长度和发送的报文字节数不一致。比如描述符声明报告长度为6字节，实际发送只有2字节，电脑就会丢弃整个报文。

还有一个容易被忽略的点：很多手机ROM在锁屏或息屏后会自动挂起HID服务，这时候电脑端设备显示正常，但报文发不出去。解决办法是给App申请前台服务权限，并在通知栏驻留一个常驻通知，同时请求电池优化白名单，确保App进程不被系统杀掉。

5.2 键盘输入乱码或重复输入

键盘乱码基本都是键码映射表的问题。USB HID键值跟电脑上的实际字符是两层映射：HID键值传上去后，操作系统会根据当前键盘布局（比如美式、德语输入法）做一次翻译。你用手机发送HID键值0x04，操作系统会把它翻译成字母“a”，但如果当前输入法处于中文状态，可能变成某个中文符号或快捷键，看起来就像乱码。

解决办法有两个：一个是App内做可配置的键码映射表，允许用户在设置里调整；另一个更省事的办法是尽量减少字符级输入，把常用的“打字”操作预置成“文本粘贴”模式——在电脑端驻留代理程序里接收一段字符串，然后模拟快捷键Ctrl+V把剪贴板内容粘贴出去。文本粘贴比逐键敲字符稳定得多，延迟也更低。

重复输入多半是按键按下和抬起事件之间间隔太短，或者一次按上报了两次。在App端做一个简单的去抖：同一个键码在500毫秒内最多上报一次按下事件；或者在上报时附带一个按下-抬起状态机，目标端严格按“按下-抬起”的配对关系处理。

5.3 延迟过高或偶发断连

延迟问题分两类。如果整体延迟偏高，优先检查指令链路里是否有不必要的串行处理或日志写库操作。实际测试中，一个最容易被忽略的性能陷阱是：每次键鼠事件都触发一次数据库写入，导致云函数被迫等待IO。解决办法是把日志写入改为异步队列，或者直接在函数内只打印日志，由平台日志系统统一采集，不单独写业务库。

偶发断连的原因很多，蓝牙信号干扰、目标主机休眠、手机蓝牙驱动异常都可能触发。排查时先看蓝牙信号强度，如果手机和电脑距离超过5米或者中间有金属障碍物，断连概率陡增。其次看目标主机是否开启了省电模式——Windows的蓝牙设备节能选项默认开启，会在设备空闲一段时间后断开链接，需要在设备管理器里把“允许计算机关闭此设备以节约电源”取消勾选。最后，手机端要在HID连接丢失后自动尝试重连，并配合前台服务保证重连逻辑不被系统终止。

5.4 关键问题速查表

6. 实操心得：这套方案还能怎么扩展

6.1 把手机打造成可编程宏键盘

做完了基础键鼠功能之后，我马上加了一个宏命令面板。手机屏幕上预先定义多个按钮，每个按钮对应一组按键序列。比如“复制整行并粘贴到下一行”对应Ctrl+C、End、Enter、Ctrl+V，一条宏指令里可以包含几十个按键动作。这个宏命令在Serverless端就是一个标准化的宏定义表，手机端只需要同步宏列表并渲染成按键即可。

这个扩展之所以有价值，是因为普通键盘的按键组合有限，但宏键盘可以组合出任意操作序列。我现在调试代码时常用的一个宏是“格式化代码并运行”（Ctrl+S、Ctrl+Shift+I、F5），一键触发，比在键盘上按三个组合键舒服得多。

6.2 多人共享同一台电脑的授权机制

Serverless编排层天然适合做多设备管理。我在会话表里增加了一个角色字段：owner可以绑定控制权，guest只能发起协助请求。owner在手机端点“同意”后，guest的手机才能开始输入。这个机制用在远程协助、临时共用一台电脑的场景下特别实用，并且不需要OpenSSH服务器或者第三方远程控制软件。

6.3 从“键鼠控制”升级为“IoT控制面板”

再进一步想，这套方案的底层匹配到的目标是标准化输入设备，但再往上一层，它完全可以扩展成通用的跨设备控制中枢。手机通过蓝牙HID控制电脑是第一步，通过Wi-Fi或者BLE控制智能家居网关是第二步。Serverless编排层对于指令的转换和路由能力是通用的，换一个目标类型的配置，就是一套新的控制面板。

如果你也喜欢折腾这类东西，建议在做完键鼠之后，不要急着收工。把控制目标抽象成一套通用的“设备-指令-动作”模型，后续接新设备会快很多。我个人现在的做法是，所有指令事件统一走同一个云函数入口，这个函数只负责路由和鉴权，真正的动作执行逻辑全部由目标端（电脑代理、ESP32固件、语音助手等）负责。这样一来，添加新设备时中心服务几乎不用改代码，所有扩展都在端侧完成，这个教训也是我在连续踩了几次“中心化改造”的坑之后才总结出来的。