直接说结论这个项目是真的能把吃灰的旧手机变成一套能干活的多设备键鼠套装而且用的是Serverless这套后端逻辑来处理规则映射和指令下发不是那种打开App点两下就没有下文的玩具Demo。我前阵子刚好把手里一台Android 9的旧手机翻出来配合一个云函数服务做了一套完整的手机蓝牙键鼠方案。实现之后我可以用手机直接控制旁边的Windows笔记本、客厅的安卓电视盒子甚至临时接管一下没配键鼠的ARM开发板。这套链路跑通之后我才意识到Serverless在里面的作用其实比大多数人想象的要大它不只是挂一个云函数等着被调而是把整个键鼠方案的配置中心、规则引擎和安全边界全部拎了出来。这篇内容就把我实操验证过的整体设计、协议细节、代码实现思路、遇到的问题和排查方式全部写出来。如果你手边正好有一台闲置Android手机又想省下买无线键鼠的钱或是有开发者想了解蓝牙HID 无服务器架构怎么组合成实际产品这篇内容应该能帮你少走不少弯路。1. 整体设计与技术选型思路1.1 为什么选择手机 蓝牙HID这条路把手机变成键鼠本质上是要让手机在被控设备面前伪装成一个标准的蓝牙键盘和鼠标。蓝牙HIDHuman Interface Device协议是蓝牙协议栈中专门描述人机交互设备的规范键盘、鼠标、游戏手柄走的都是这套东西。只要手机按照HID规则向对端设备声明自己的描述符然后周期性上报按键或坐标数据对端设备就会把手机当作一个普通外设来对待完全不需要安装额外驱动。这种做法的价值在几个场景里体现得特别明显一是台式机和迷你主机经常遇到键鼠临时失灵或不够用的窘境二是客厅电视盒子遥控器打字输入实在太痛苦蓝牙键鼠又是刚需三是开发板上不想常驻一套键鼠偶尔连上去调试又需要输入命令。手机是现成的智能设备既有蓝牙模块又有锂电池拿来当键鼠简直是零成本硬件复用。1.2 Serverless在这个方案里到底承担什么职能很多人一听Serverless键鼠就觉得奇怪键鼠明明是本地设备跟云函数有什么关系。这个疑问我非常理解因为最开始我也没有直接把Serverless放进链路里而是简单地把手机模拟成蓝牙键鼠直接控制电脑。但是真用起来之后问题马上就暴露了。我原本的设想是电脑这边跑一个Agent程序根据手机按下的物理按键执行对应操作比如音量键映射成F5刷新、长按主页键打开浏览器。问题在于这些映射规则散落在每台被控设备的本地配置文件里我换一台电脑又得重新配置一遍快捷键规则我在手机上想快速切换办公电脑和电视盒子两套映射方案时本地配置根本来不及切换灵活性太差。而把这些规则放上Serverless之后手机和Agent都变成了无状态客户端规则统一从云端拉取改一条映射规则之后所有设备同时生效再也不用逐个改配置文件。Serverless在这里承担的是规则中心、宏指令编排中心和多设备认证中心的角色。手机端只负责蓝牙HID协议的注入Agent端只负责执行上层的映射动作中间最核心的按键含义全部由云函数来决定。这样做还有一个额外的好处如果某天被控设备已经被入侵攻击者拿到设备本地权限也只能看到缓存的规则抄本拿不到完整的云端控制策略。1.3 和传统云主机方案相比优势在哪在做技术选型的时候我专门对比过自己买一台云主机来跑这套规则的方案。传统云主机的优势是环境完全可控数据库、Redis、消息队列随便装缺点是成本高、运维重。我这套键鼠方案的规则体量撑死也就几百KB放在一台云主机上纯属浪费而且为了保活还得处理一堆系统维护问题。用Serverless函数来实现之后收益是直接的按调用次数计费基本属于免费额度绰绰有余无需关心底层操作系统补丁和运行环境函数实例在被控设备触发时才会启动天然适合低频、突发性的指令请求模式。实际上键鼠的映射规则请求本身就符合典型的短时突发、低频持续特征这正是Serverless最擅长的负载形态。对比维度传统云主机Serverless函数成本构成按月/按年买断闲时也得付费按调用次数资源使用量计费闲置几乎零成本运维负担系统补丁、环境配置、进程守护全得管只需关心业务代码运行时平台托管弹性能力需要自己规划容量扩缩容麻烦自动弹性冷启动时仅需短暂等待适合体量有状态服务、大数据量、长时间运行轻量API、规则分发、事件触发型逻辑选型下来我心里是有底的这台手机蓝牙键鼠项目里Serverless不是噱头而是真正把这套方案从单机玩具升级成多设备智能外设平台的关键拼图。2. 核心协议原理与关键细节2.1 蓝牙HID协议里需要先搞懂的几个概念想要让手机被识别成蓝牙键鼠不能仅仅把手机蓝牙打开就行而是需要在手机端实现完整的HID设备角色。这个过程牵扯到三个核心概念HID描述符、SDP记录和报告报文。HID描述符是一份二进制数据它向主机声明这个设备有哪些用法、按键怎么编码、鼠标坐标怎么表示。比如键盘描述符里需要声明键盘的按键页、修饰键页鼠标描述符里需要声明X轴、Y轴和滚轮。描述符写错的话被控设备能识别到蓝牙连接但不会把它当成标准键鼠表现就是设备管理器里多了一个未知蓝牙外设。SDPService Discovery Protocol记录是蓝牙服务发现的关键信息手机要广播自己支持Human Interface Device Service并把HID描述符和协议版本信息放进SDP响应里。到这一步对端设备才能看到手机上挂着一个蓝牙键盘或蓝牙鼠标的服务。报告报文则是实际交互时的数据单元。键盘报告是8字节定长数据第1字节是修饰键位第2字节是保留位后面6字节记录同时按下的按键鼠标报告则紧凑得多用字节位表示按钮状态和坐标增量。我一句话总结描述符决定我能干什么、怎么解释我的数据报告决定我此刻做了什么动作。官方资料里把这一整套流程称为HID Device RoleAndroid从PieAndroid 9开始才在公开API里支持蓝牙HID Device所以不是所有手机都能玩这套方案系统版本要卡在Android 9及以上的机型才稳。2.2 Serverless函数该怎么拆分设计在设计云函数的时候我一开始犯过把逻辑全部塞进一个函数的错误结果后期修改特别痛苦。拆分清楚之后函数的职责边界很清晰我建议你按下面三个服务来划分。第一个是设备注册与鉴权函数。它的作用是处理手机和Agent的首次接入请求完成设备信息的录入和token发放。手机端连接Serverless时会携带设备序列号和一次性装机码函数校验通过后返回一个短期有效的访问令牌后续所有请求都携带这个令牌。这样既避免了明文设备信息漫天飞也方便随时吊销某台设备的访问权限。第二个是映射规则查询函数。这是整个系统里被调用最多的接口手机端和Agent端都会在启动时、切换被控设备时请求它。函数的输入是被控设备的类型和设备分组ID输出是经过解析后的按键映射JSON、宏指令定义和应用白名单。这个函数讲究的是响应速度和缓存策略我在实际部署时给它开了加速配置并把规则结果做了一层本地缓存避免每次按键都去访问远程服务。第三个是宏指令编排函数。当手机按下某个组合键触发打开浏览器并输入地址这类复杂动作时Agent会把这个动作描述发到函数里由函数解析成一步步的内部指令序列再返回给Agent执行。这样做的原因是宏指令往往涉及多条子操作如果逻辑全写在Agent端多台Agent的版本不同就可能出现行为不一致统一由云端编排能保证所有设备动作完全同步。三个函数各管一段组合起来就是一条完整的手机按键 - HID注入 - Agent事件上报 - 云端规则决策 - 本地宏执行闭环。2.3 安全边界和权限控制不能省把键鼠控制和云服务连在一起之后安全问题就不是小事情了。按键数据里掺杂着用户输入的内容和快捷键动作如果云端接口被人扫描爆破轻则设备误操作重则规则被恶意篡改。我在这套方案里把权限控制拆成了三层。第一层是传输层身份认证。所有接口都要求在请求头里携带Bearer TokenToken由注册接口发放有效期默认24小时期满后需要刷新。这样即使某台设备的Token被截获也不会永久暴露整个系统。第二层是设备级访问控制。每一台手机和Agent在首次注册时都会绑定一个唯一的设备ID云函数在处理映射规则请求时会校验请求方设备ID与规则所属的分组是否匹配。比如两台手机分别控制客厅和书房那么客厅手机的Token永远无法读取书房设备的规则配置。第三层是操作审计。我在关键动作里加了日志埋点每次宏指令编排请求都会记录设备ID、动作类型和时间戳。这样出了问题可以快速追溯是哪台设备、在什么时间、执行了什么操作排障效率会高很多。诚实地讲这三层安全设计肯定不是金融级别的防护但对家庭和中小型工作室场景已经足够。如果未来要放到公网环境给陌生设备用我还会考虑加上IP白名单和设备指纹校验不过那就属于另一个量级的工程了。3. 端到端实操从零搭一套可用方案3.1 准备清单在动手之前先把需要的软硬件全部列出来避免中途发现缺东少西。硬件方面你需要一台Android 9的备用手机作为键鼠本体我测试用的是厂商系统定制较少的机型兼容性比较省心一台被控目标设备可以是Windows电脑、Mac、Linux主机、安卓电视盒子我实测覆盖了Windows 10、Ubuntu 20.04和安卓9电视盒子三种类型另外准备一根数据线用于前期调试手机端日志无线调试虽然方便但看日志还是得数据线靠谱。软件方面手机端需要一个能创建蓝牙HID设备的App官方Demo有参考价值但功能太原始我是自己简单封装了一层调用被控端Agent我选用了Python来写用pynput库监听系统输入事件用requests库调用云函数接口Serverless平台我建议直接用你熟悉的云厂商函数计算产品代码是通用Node.js HTTP风格迁移成本很低。3.2 手机端实现BLE HID键鼠的关键代码Android官方从API 28开始在BluetoothAdapter里增加了getProfileProxy方法我们可以通过BluetoothHidDevice这个Profile来创建一个HID设备。核心实现步骤分为三步注册Profile代理、配置HID描述符、上报报告数据。第一步获取BluetoothHidDevice实例并注册回调。代码结构大致如下BluetoothManager bluetoothManager getSystemService(BluetoothManager.class); BluetoothAdapter bluetoothAdapter bluetoothManager.getAdapter(); bluetoothAdapter.getProfileProxy( context, mProfileListener, BluetoothHidDevice.PROFILE_ID );这里的mProfileListener会回调onProfileProxyReady返回一个BluetoothHidDevice实例我们后续的注册、上报都通过它来完成。第二步注册HID设备。这是最容易踩坑的地方必须把描述符数据写得准确无误。我以键盘为例贴一段描述符定义private static final byte[] KEYBOARD_DESCRIPTOR new byte[]{ (byte) 0x05, 0x01, // Usage Page (Generic Desktop) (byte) 0x09, 0x06, // Usage (Keyboard) (byte) 0xA1, 0x01, // Collection (Application) (byte) 0x05, 0x07, // Usage Page (Key Codes) (byte) 0x19, 0xE0, // Usage Minimum (224) (byte) 0x29, 0xE7, // Usage Maximum (231) (byte) 0x15, 0x00, // Logical Minimum (0) (byte) 0x25, 0x01, // Logical Maximum (1) (byte) 0x75, 0x01, // Report Size (1) (byte) 0x95, 0x08, // Report Count (8) (byte) 0x81, 0x02, // Input (Data, Variable, Absolute) // ... 省略中间的按键页和输出报告描述 (byte) 0xC0 // End Collection };这段描述符的核心意思就是向主机声明我这个设备是一个键盘我上报的数据格式是修饰键位普通按键列表。如果这里写错主机会误解你的数据含义表现出的症状就是按下A键却输出了B字符或者干脆完全没反应。描述符的具体字节含义可以参考USB HID标准蓝牙HID直接复用了USB HID的用法定义这一点可以直接照搬。注册调用如下BluetoothHidDevice hidDevice ...; hidDevice.registerApp( com.example.virtualkb, Virtual Keyboard, KEYBOARD_DESCRIPTOR, null, null, BLUETOOTH_HID_DEVICE_SUBCLASS1_KEYBOARD, new BluetoothHidDevice.Callback() { // 在这里处理连接状态变化和报告发送回调 } );注册完成之后手机就会在蓝牙扫描中暴露一个名为Virtual Keyboard的HID设备。这时候用目标设备去扫描蓝牙就能搜到这个新设备并完成配对。第三步在需要输出按键时发送报告。键盘报告是固定8个字节第0字节是修饰键Ctrl/Shift/Alt的标志位第2到第7字节是标准按键码比如A键的按键码是0x04发送代码大致如下byte[] report new byte[8]; report[2] (byte) 0x04; // 按下 A 键 hidDevice.sendReport(BluetoothHidDevice.REPORT_TYPE_INPUT, report);发送完之后不要忘记发送一份全零报告表示按键释放否则目标计算机会认为这个按键一直被按住表现就是字母持续重复输入。鼠标方向我也顺手写了一份鼠标描述符需要声明有X轴、Y轴和按钮页上报时用4字节报告第0字节是按钮状态第1字节是X轴相对位移第2字节是Y轴相对位移第3字节是滚轮增量。手机触摸板区域滑动时把位移量按照固定比例转换成相对坐标增量填进报告目标端的光标就会跟着动起来。3.3 被控设备Agent的职责与实现被控设备上跑Agent是整套链路里不可或缺的一环。有人会问手机都已经是蓝牙键鼠了为什么还要在被控设备上装软件原因在于纯蓝牙键鼠只能实现普通的按键和鼠标移动无法实现按音量键打开浏览器这类智能映射因为这种动作的意图不在HID协议的语义范畴里需要一个本地进程来理解并执行。Agent的工作流程分三步。第一步是监听系统输入事件。我选了Python的pynput库它跨平台支持Windows、Linux和macOS监听键盘和鼠标移动的代码非常简单from pynput import keyboard from pynput import mouse def on_press(key): try: print(fkey {key.char} pressed) except AttributeError: print(fspecial key {key} pressed) with keyboard.Listener(on_presson_press) as listener: listener.join()注意pynput在Linux下需要root权限Windows和macOS则没有这个问题。如果你在树莓派上跑Agent记得用sudo启动。第二步是把输入事件上报给Serverless函数。为了减少网络开销我做了事件聚合普通按键不逐次上报只在命中规则映射时上报命中映射的事件会带上设备ID、按键码、修饰键状态和时间戳。云端函数返回该按键对应的动作指令比如REFRESH_PAGE、OPEN_APPbrowser、MACROsavetomarkdown等。第三步是根据云端返回的指令执行动作。执行模块我封装了一个简单的cmd执行器import subprocess def execute_action(action, params): if action OPEN_APP: subprocess.Popen(params[cmd].split()) elif action MACRO: key_sequence params[sequence] # 调用pynput的Controller执行组合键 for key in key_sequence: keyboard.Controller().press(key) keyboard.Controller().release(key) else: log.warning(funknown action: {action})这里最需要注意的问题是执行动作不能阻塞监听线程否则连续按键时系统输入监听会被卡住。我在自己的实现里用了一个线程池来调度动作执行监听线程只管上报动作执行线程池负责干活两者解耦之后稳定性提升非常明显。3.4 Serverless函数设计与部署样例Serverless侧我用的Node.js运行时HTTP触发方式这样手机端和Agent端都可以用最普通的HTTP客户端访问。函数代码量不大核心是处理两类请求映射规则查询和宏指令编排。下面贴一个简化版但不失完整性的示例// index.js const rules { office_pc: { KEY_VOLUME_UP: { action: REFRESH_PAGE, desc: 刷新页面 }, KEY_HOME: { action: OPEN_APP, params: { cmd: code } }, SWIPE_TWO_FINGERS: { action: MACRO, params: { sequence: [ctrl, tab] } } }, tv_box: { KEY_VOLUME_UP: { action: KEYEVENT, params: { keycode: 24 } }, KEY_VOLUME_DOWN: { action: KEYEVENT, params: { keycode: 25 } } } }; function authCheck(request) { const token request.headers.get(x-device-token) || ; if (!token.startsWith(valid_)) { return { status: false, code: 401, message: unauthorized }; } return { status: true }; } export async function handleRequest(request) { const url new URL(request.url); const path url.pathname; if (path /api/mapping) { // GET /api/mapping?targetoffice_pc const auth authCheck(request); if (!auth.status) return json(auth, 401); const target url.searchParams.get(target) || office_pc; const ruleSet rules[target] || {}; return json({ code: 0, data: ruleSet }); } if (path /api/macro) { const auth authCheck(request); if (!auth.status) return json(auth, 401); const payload await request.json(); const sequence payload.sequence || [ctrl, s]; return json({ code: 0, data: { execute: sequence } }); } return json({ code: 404, message: not found }, 404); } function json(data, status 200) { return new Response(JSON.stringify(data), { status, headers: { Content-Type: application/json } }); }这个函数有几个细节值得你注意。第一规则配置直接写在函数代码里只是演示方便工程上更合理的做法是把规则存到对象存储或表格数据库里函数启动时拉取并缓存我在生产版本里就是这样做的。第二函数对Token的校验逻辑只是一个示例真正的实现里要校验Token签名和设备ID的绑定关系避免仿造头信息绕过鉴权。部署的时候我建议打开平台的日志查询和监控告警功能这样一旦出现大面积的鉴权失败或者函数调用超时能第一时间感知到。函数的内存配置不需要太大128MB足够应对文本规则查询超时时间设30秒是因为宏编排偶尔需要等待下游响应。3.5 完整联调流程与效果验证做完整链路联调的时候我给自己定了一个循序渐进的测试计划每一步都验证通过后再进入下一步这样可以精准定位问题到底出在哪一端。第一步验证手机蓝牙HID是否生效。手机端登录注册App后切换到蓝牙设置页面让手机处于可被发现状态然后在目标设备上发起蓝牙扫描。如果目标设备能搜到名为Virtual Keyboard的HID设备并成功配对说明第一步已经通了。这一步最容易翻车因为Android对HID设备的广播有一定延迟有时候需要扫描两三次才能看到。第二步测试基础键鼠输入。配对完成后在电脑的文本编辑器里点一下输入框然后在手机上按下映射好的A键观察编辑器里是否出现字母a。鼠标方向则是在手机屏幕上滑动触摸区域观察电脑光标是否跟着移动。此时不需要启动Agent因为基础键鼠事件是蓝牙HID协议直接上报的Agent只负责高级动作映射。第三步启动Agent并绑定Serverless。在目标设备上运行Agent脚本首次运行会要求输入Serverless函数的地址和设备的Token。Agent启动后会向后端注册自己然后从云端拉取目标设备的映射规则。这时候再按下手机上熟悉的快捷键Agent应该能根据云端规则执行对应的动作比如打开代码编辑器或提交组合键宏。第四步做断线重连和长时间稳定性测试。我把手机的蓝牙关闭再开启观察目标设备能否自动重新配对Agent能否在几秒内恢复工作。我还连续跑了8小时期间每小时执行一次宏指令检查云函数的触发和响应是否正常。这轮测试下来我对整套方案的稳定性算是有了底。整个联调过程最耗时间的不是代码编写而是排查各种设备兼容性问题下面一章就把我踩过的坑和排查思路都记录下来。4. 常见问题排查与性能优化实录4.1 问题速查表我把自己在实现和后续维护中遇到的典型问题整理成了一张速查表先给你一个全局的排查视角。症状可能原因排查方法解决方案目标设备搜不到手机蓝牙设备Android未开启允许被扫描检查手机蓝牙设置切换到可被发现的页面多扫几次搜到但配对失败蓝牙HID描述符或SDP记录异常查看目标设备蓝牙错误码检查HID描述符字节是否完整重新注册配对成功但按键无输出键盘报告格式或按键码错误用蓝牙调试工具抓包确认报告字节长度和按键码映射表光标不动但按键正常鼠标描述符未生效或坐标增量为零检查鼠标描述符和代码确认X/Y轴增量字段正确填充按键延迟严重300msServerless冷启动或网络RTT高查看函数日志耗时开启预留实例客户端缓存规则使用几分钟后自动断开手机系统蓝牙省电策略观察系统日志前台保活关闭蓝牙省电优化Agent执行宏指令时无反应本地执行器线程阻塞查看Agent日志用线程池调度避免阻塞监听4.2 延迟优化冷启动、网络与本地缓存键鼠操作是强交互场景人对延迟特别敏感100毫秒以内的变化基本察觉不到超过300毫秒就会明显感觉到肉。这套方案里延迟主要来自三个环节蓝牙HID上报本身、Agent到Serverless的网络往返、以及Serverless函数的计算时间。蓝牙链路的延迟我没法完全消除但我通过调整手机的蓝牙连接参数做到了比默认更快的响应。在BluetoothHidDevice注册时可以传入QoS参数合理配置连接间隔后蓝牙事件上报延迟能控制在十到三十毫秒左右这个优化空间对于感知体验的改善非常明显。Serverless冷启动是最大的延迟隐患。函数平台在长时间无请求后回收实例下一次请求进来要重新拉起运行环境冷启动时间轻则几百毫秒重则超过一秒这直接导致第一下按键卡住、后面的按键才顺畅体验。我的解决办法分两部分一是在Serverless控制台配置预留实例数让至少一个实例长期在线冷启动问题基本消失二是让Agent在启动时预取规则并缓存到本地文件后续按键动作走本地逻辑只有宏指令这种复杂操作才必须访问云端。实测下来普通按键映射的响应延迟稳定在50毫秒以内宏指令的执行延迟在120到180毫秒之间感官上已经完全可用。4.3 稳定性优化保活、重连与看门狗整套系统在长时间运行时稳定性最大的敌人是手机系统把蓝牙干掉了和Agent自己挂了。Android系统对后台进程的管控非常激进如果手机锁屏后长时间没有交互系统可能会暂停App的后台服务蓝牙HID的连接也会跟着断开。我的对策是让手机端App启动一个前台服务并申请忽略电池优化权限。前台服务会在通知栏常驻系统对它的优先级更高不会轻易被杀掉。同时我把蓝牙连接参数里设置了自动重连一旦系统蓝牙模块被重启App会在几秒内检测到连接断开并主动重新注册。Agent端我写了一个简单的看门狗每隔三十秒检查一次Agent进程是否存在如果发现进程未运行就通过系统服务方式重新拉起它。另外Agent内部也加入了断线重连逻辑调用函数失败时会进入指数退避重试不会因为一次网络抖动就把整个进程搞崩溃。这些优化做完之后我有一段时间把手机放在架子上连续运行了三天期间没有碰过它电视盒子上的键鼠输入一直保持正常。这个结果让我确信这套方案不是只能玩一玩的Demo而是能当真正的日常工具来用的。4.4 多设备场景扩展一套云端服务管全家单台手机控制单台设备只是基础能力Serverless真正的优势在于多设备组合时的集中管理。我目前家里有三台被控设备分别是书房Windows电脑、客厅安卓电视盒子和一部用来做字幕校对的Linux笔记本。三台设备对应的规则完全不同但我共用同一个Serverless服务只在函数内部按target参数区分规则集。这样做的好处是明显的手机端逻辑完全不用变切换被控设备时只是更换规则的获取对象Agent端也只是在启动时多传一个目标设备标识。如果你想继续扩展还有两个方向可以做一是把规则配置做成可视化页面让普通人也能在网页上编辑按键映射和宏指令这对目前只能用代码配置文件的方式是很大的体验提升二是引入动态设备发现让手机在靠近某台被控设备时自动切换配置省去手动选择的麻烦。Serverless这种架构天然适合这些扩展因为新增的逻辑只是增加函数接口不需要改动已经跑通的设备端程序。最后再分享一个我在实际使用中的经验如果你也想尝试这个方案不用一上来就把所有功能做完整先从最基础的蓝牙HID键鼠配对开始跑通手机控制电脑打字这个小目标再一步步加入云函数规则、宏指令和多设备管理。我最初就是因为想着一步到位结果调试的复杂度一下子拉高走了不少弯路。把这套链路当作一个渐进式项目来做你会发现越往后越顺手那种手机随手放在哪里都能当键鼠用的体验真的会让人上瘾。