安卓电视虚拟鼠标：遥控器模拟触控的平滑算法与无障碍注入实践

安卓电视的交互困境，几乎每个深度用过电视盒子的人都有一肚子话想说。遥控器的方向键在网格化界面上挪来挪去还算顺手，可一旦碰上那些为手机触屏设计的应用——滑动列表、长按拖拽、双指缩放——方向键立刻变成一根不听话的拐杖，点一下挪一格，想滑到底部得按到手酸。更别提那些藏在屏幕边缘的按钮，方向键的焦点逻辑根本够不着。我最初折腾这个需求，就是因为家里那台电视上装了个漫画阅读器，翻页要横向滑动，遥控器按了十分钟才翻过三话，体验极其割裂。

安卓电视虚拟鼠标这个思路，本质上是在遥控器的按键事件和屏幕的触控事件之间架一座桥：把方向键的离散移动映射成光标的连续位移，把确认键映射成点击，把返回键或者长按映射成拖拽和滑动。听起来简单，但真正落地时会撞上一堆细节——光标移动的加速度曲线怎么设计、点击和拖拽怎么区分、不同应用的触控事件坐标系怎么对齐、系统层和用户层两种实现路径各自的天花板在哪里。这篇内容就把我在这条路上踩过的坑、试过的方案、最后跑通的配置完整摊开讲，适合手里有安卓电视或者电视盒子、想让遥控器干更多事的人参考，也适合想理解安卓输入事件分发机制的开发者当个案例看。

1. 先搞清楚电视遥控器到底能发出什么信号

动手之前必须把输入源摸清楚，否则后面所有映射设计都是空中楼阁。安卓电视的遥控器走的是标准输入子系统，按键事件通过/dev/input/eventX节点上报，键值定义在linux/input-event-codes.h里。常见的电视遥控器会发出这几类键值：方向键KEY_UP/KEY_DOWN/KEY_LEFT/KEY_RIGHT、确认键KEY_ENTER或KEY_DPAD_CENTER、返回键KEY_BACK、主页键KEY_HOME，部分遥控器还带音量键和菜单键。这些键值在安卓框架层会被InputReader读取，再经InputDispatcher分发给当前焦点窗口。

关键点在于：方向键产生的是离散的按下和抬起事件，而触控屏产生的是带坐标的连续MotionEvent。虚拟鼠标要做的转换，就是把前者翻译成后者。这里有个容易被忽略的细节——遥控器方向键在长按时，系统会以一定的重复速率持续上报按下事件，这个速率由内核的input子系统控制，通常在几十毫秒到一百多毫秒之间。如果你直接拿这个重复事件去驱动光标，光标会一顿一顿地跳，完全谈不上"连续"。所以第一层设计就必须引入自己的定时器或者动画插值，把离散事件平滑成连续位移。

我在实测中对比过两种取事件的方式。一种是应用层通过dispatchKeyEvent拦截方向键，这种方式最省事，但有个硬伤：一旦你的应用失去焦点，事件就断了，而且系统级的方向键焦点移动逻辑会和你抢事件。另一种是走无障碍服务（AccessibilityService），通过onKeyEvent拿到全局按键，再配合AccessibilityService的dispatchGesture注入手势。后者的覆盖面大得多，能在任意应用上层工作，代价是需要用户手动开启无障碍权限，且注入手势有延迟。两条路我都跑过，下面会分别说清楚各自的边界。

提示：不同厂商的遥控器键值可能有差异，动手前先用getevent命令在终端里把按键原始码打出来看一眼，别照着通用文档硬套。

1.1 用getevent把遥控器的底牌翻开

这一步是很多教程跳过的，但它是后面所有调试的基准。在电视上开一个终端（adb shell进去也行），执行：

getevent -l

然后逐个按遥控器按键，终端会打印出类似这样的内容：

/dev/input/event3: EV_KEY KEY_DPAD_UP DOWN /dev/input/event3: EV_SYN SYN_REPORT 00000000 /dev/input/event3: EV_KEY KEY_DPAD_UP UP

记下每个物理按键对应的event节点和KEY_名称。有些遥控器走的是蓝牙HID协议，节点可能是event4或event5，键值名称也可能出现KEY_HOMEPAGE这种非标准写法。把这些记在一张表里，后面写映射逻辑时直接查表，比反复试错高效得多。我自己的那张表里还额外标注了每个键长按时的重复间隔，用getevent -lt带上时间戳就能算出来，这个数值直接决定光标平滑算法的参数。

1.2 离散按键到连续位移的平滑处理

拿到重复间隔之后，平滑方案就有了依据。假设实测长按方向键的重复间隔是80毫秒，那么每收到一个按下事件，光标理论上应该移动"80毫秒对应的距离"。如果直接按固定像素跳，比如每次跳20像素，快速连按和长按的手感会完全不一样。我的做法是维护一个速度变量：每次收到按下事件时给速度累加一个增量，同时启动一个16毫秒周期的插值定时器（对齐60帧刷新），定时器里按当前速度移动光标，速度再按一个衰减系数缓慢回落。这样短按是精确的小步移动，长按则速度逐渐爬升，手感接近真实鼠标的加速。

衰减系数的取值很讲究。系数太接近1，光标会一直飘，松手后还在滑；系数太小，长按加速感出不来。我试下来0.85到0.92之间比较舒服，具体值跟电视的屏幕尺寸和分辨率有关——1080p的电视上0.88左右，4K屏因为像素密度高，同样的物理位移对应更多像素，系数要往0.92调。这个参数没有标准答案，建议做成可配置项，让用户自己微调。

2. 应用层拦截与无障碍注入，两条路的天花板在哪

前面提到取事件有两条路，这里展开说清楚，因为选错路会让后面的工作量翻倍。应用层拦截指的是在你自己的App里重写dispatchKeyEvent或者onKeyDown，把方向键事件吃掉，转成自己维护的光标坐标，再通过MotionEvent的构造和dispatchTouchEvent回灌给界面。这条路的好处是零权限、延迟极低、调试方便，缺点是只能在自己的应用内生效。如果你的目标是让整个电视系统上所有应用都能用虚拟鼠标，这条路走不通。

无障碍注入则是另一回事。AccessibilityService可以监听全局按键（需要在配置里声明canRequestFilterKeyEvents），拿到按键后用dispatchGesture构造一个GestureDescription，里面放一条从当前位置到目标位置的Path，再配一个极短的持续时间，系统就会把它当成真实触控事件注入到当前前台应用。这条路能覆盖所有应用，包括那些没有为遥控器做适配的触屏应用。代价有三：一是用户必须手动去设置里开无障碍，二是注入手势有几十毫秒的固有延迟，三是部分定制系统对无障碍注入做了限制，需要额外处理。

我最终的方案是两条路都保留：应用内用拦截方式保证自家场景的丝滑手感，全局用无障碍注入兜底。如果你的需求只是让某个特定应用好用，别上无障碍，直接拦截就够了，省掉一堆权限引导的麻烦。

2.1 无障碍注入的手势构造细节

dispatchGesture的入参是一个GestureDescription，核心是StrokeDescription。构造一条从A点到B点的滑动，代码大致是这样：

Path path = new Path(); path.moveTo(startX, startY); path.lineTo(endX, endY); GestureDescription.StrokeDescription stroke = new GestureDescription.StrokeDescription(path, 0, 16); GestureDescription gesture = new GestureDescription.Builder().addStroke(stroke).build(); dispatchGesture(gesture, null, null);

这里的16是持续时间，单位毫秒。持续时间太短，系统可能判定为点击而非滑动；太长，光标移动会有拖影感。实测16到30毫秒之间比较合适，具体看目标应用的触控采样率。还有一个坑：连续快速注入多个手势时，前一个手势没结束就注入下一个，系统会丢弃后面的。所以注入逻辑必须串行化，用一个队列管理，等回调onCompleted再发下一个。我一开始没做队列，快速连按方向键时光标直接卡住不动，排查了半天才发现是手势被吞了。

2.2 点击与拖拽的区分逻辑

虚拟鼠标光有移动不够，还得能点、能拖。点击好办，确认键按下时在光标位置注入一个短促的点击手势即可。拖拽麻烦一些，需要区分"长按进入拖拽"和"普通点击"。我的做法是：确认键按下时启动一个计时器，300毫秒内抬起算点击，超过300毫秒则进入拖拽模式，此后方向键的移动不再移动光标本身，而是生成一条从拖拽起点到当前点的滑动路径持续注入。这个300毫秒的阈值参考了安卓系统长按的默认值，用户肌肉记忆比较一致。

拖拽模式下的注入频率要控制。每个方向键事件都注入一条完整滑动路径的话，路径会碎成很多段，目标应用可能识别成多次独立滑动而不是一次连续拖拽。更稳的做法是维护拖拽起点，每次移动时注入一条"从起点到当前点"的完整路径，让系统自己插值。这样虽然单次注入的数据量大一点，但目标应用看到的是连贯的拖拽轨迹。

3. 光标坐标系对齐，最容易翻车的一环

光标画在屏幕上，注入的触控坐标却要落到目标应用的窗口坐标系里，这两者之间的换算是最容易出问题的地方。电视上常见的情况是：系统UI有自己的坐标系，应用窗口有自己的坐标系，如果应用开了分屏或者画中画，坐标系还会再嵌套一层。你按屏幕绝对坐标注入，事件可能落到错误的窗口上，表现为"光标在这里，点击却点到了别处"。

解决思路是先拿到当前前台窗口的边界。无障碍服务里可以通过getWindows()拿到AccessibilityWindowInfo列表，取isActive()为true的那个，读它的getBoundsInScreen()。注入坐标时，把光标的屏幕坐标减去窗口左上角偏移，得到窗口内坐标。这一步在单窗口全屏时看起来多余，但一旦遇到带侧边栏的系统UI或者分屏场景，不做这个换算必然出错。

还有一个隐蔽的坑：部分应用的触控区域和显示区域不一致。比如某些视频应用全屏播放时，画面是16:9但窗口是16:10，上下有黑边，触控坐标系却按窗口算。这时候光标画在黑边上，注入的坐标落在窗口内，点击位置和视觉位置就对不上。我的处理办法是在光标渲染层加一个可视化的坐标指示，调试阶段把注入坐标和光标坐标同时打印出来对比，发现偏差就手动加偏移量校正。这个偏移量没法通用，只能针对具体应用配置，所以工具里最好留一个"坐标校准"入口。

3.1 多分辨率下的坐标缩放

电视的分辨率五花八门，1080p、4K、甚至一些带鱼屏比例的投影。光标移动的像素步长如果写死，在不同分辨率上手感差异巨大。我的做法是把步长定义成屏幕宽度的百分比，比如短按一步移动屏幕宽度的0.5%，长按加速到2%。这样在1080p上一步约10像素，在4K上约20像素，物理观感基本一致。注入坐标时同样要做缩放：如果光标渲染层用的是逻辑坐标，注入前要乘以DisplayMetrics.density换算成物理像素，否则在高密度屏上点击位置会整体偏移。

3.2 焦点丢失与光标隐藏的联动

虚拟鼠标有个体验细节：什么时候显示光标，什么时候隐藏。一直显示会挡住内容，完全不显示用户又不知道光标在哪。我的策略是方向键有输入时显示光标并启动一个3秒的隐藏倒计时，倒计时内无输入则淡出。同时监听窗口变化事件，前台应用切换时立即隐藏光标并重置位置到屏幕中心，避免光标残留在上一个应用的坐标系里造成误点。这个联动逻辑看着琐碎，但少了它，用起来会有一种"光标不受控"的别扭感。

4. 从能用到好用，手感调优的几个关键参数

功能跑通只是及格线，虚拟鼠标这种东西，手感差一点用户立刻能感知到。我在自己家和几个朋友的电视上反复调过一轮，总结出几个对体验影响最大的参数，列出来供参考。

第一个是光标移动的加速度曲线。线性加速（速度随时间匀速增长）在短按和长按之间过渡生硬，我改成了先慢后快的二次曲线，前200毫秒加速平缓，之后加速变陡。这样微调位置时精确，大范围移动时又不至于按到手酸。第二个是点击的触控半径。注入点击时如果只给一个点，部分应用会判定为无效触控，给一个半径2到4像素的微小路径更稳。第三个是拖拽的起始延迟，前面说的300毫秒可以微调，阅读类应用调到250毫秒更跟手，绘图类应用调到400毫秒避免误触。

这些参数单独看都是小数字，组合起来对手感的影响是决定性的。我建议在工具里做一个参数面板，让用户能实时调、实时感受，比预设几套固定方案实用得多。

4.1 低性能盒子上的帧率妥协

不是所有电视盒子都跑得动60帧的插值定时器。我手头有一台老盒子，插值定时器跑16毫秒周期时CPU占用明显上升，光标移动反而出现卡顿。这种情况下把插值周期放宽到33毫秒（30帧），配合稍微加大的单步位移，观感上的连续性损失不大，但流畅度稳定很多。判断标准很简单：如果Choreographer回调里发现掉帧严重，就降周期。这个自适应逻辑值得写进去，因为电视硬件的性能跨度实在太大了。

4.2 与系统焦点导航的冲突处理

最后一个坑来自系统本身。安卓电视的方向键默认承担焦点导航职责，你的虚拟鼠标拦截了方向键之后，系统级的焦点移动就失效了。这在需要键盘导航的场景（比如输入法选字、系统设置菜单）里会造成困扰。我的处理是加一个模式切换：虚拟鼠标模式和焦点导航模式用某个组合键（比如长按返回键）切换，或者在检测到输入法弹出时自动临时切回焦点导航。这个细节不做，用户会在某些界面里彻底失去操作能力，体验直接崩盘。

5. 实际部署时绕不开的权限与兼容性清单

把上面这些逻辑拼成一个能装的工具，还有几道部署关卡要过。无障碍服务的声明需要在AndroidManifest.xml里注册BIND_ACCESSIBILITY_SERVICE权限，并提供一个accessibility-service配置的XML，里面声明canRequestFilterKeyEvents="true"和canPerformGestures="true"。少了任何一个，按键监听或者手势注入就会静默失效，而且系统不会给明确报错，只能靠日志排查。

不同厂商的系统对无障碍注入的限制程度不一样。有的系统会在省电模式下限制后台无障碍服务的手势注入频率，有的会在应用切换时短暂断开服务连接。应对办法是在服务里监听onInterrupt回调，断开后自动重连，并在重连期间给用户一个轻提示。另外，部分系统把"无障碍快捷方式"做成了独立开关，用户开了服务但没开快捷方式，服务可能不生效，引导页里要把这两步都写清楚。

注意：调试阶段务必用adb logcat过滤自己服务的TAG，无障碍相关的异常大多不会弹窗，只会打在日志里。我遇到过服务明明显示已开启、但onKeyEvent就是不回调的情况，最后发现是配置文件里漏了flagDefault，加上就好了。

兼容性方面，安卓版本跨度也要考虑。dispatchGesture是API 24引入的，低于这个版本只能退回应用层方案。AccessibilityWindowInfo.getBoundsInScreen在部分低版本上返回空，需要做空值兜底。这些分支逻辑写起来烦，但电视设备的系统版本分布比手机更分散，不处理就会在特定设备上直接崩。

6. 这套东西还能往哪些方向延伸

跑通基础功能之后，我试过几个延伸方向，有的效果不错，有的纯属折腾。比较有价值的是手势录制与回放：把一串方向键操作录成一个宏，绑定到某个快捷键上，一键执行。比如看漫画时录一个"下滑翻页"的宏，按一下翻一页，比每次手动滑省事。实现上就是把注入的手势序列存成带时间戳的列表，回放时按时间轴重放，注意回放期间要屏蔽真实按键输入，避免事件打架。

另一个方向是光标吸附。电视应用里的可点击元素通常比较大，光标移动到附近时自动吸附到元素中心，能显著降低精确瞄准的难度。实现需要读取无障碍节点树，遍历AccessibilityNodeInfo找isClickable()为true的节点，算光标到节点中心的距离，小于阈值就吸附。这个功能在列表类应用里体验提升明显，但在节点树复杂的应用里遍历开销不小，要做节流。

至于用语音或者手机当遥控器来控制光标，我也试过，延迟和精度都不如物理方向键，暂时没继续深挖。虚拟鼠标这个方向真正的价值，在于它把电视上那些"为触屏设计、却被迫用遥控器操作"的应用重新盘活了，这个需求在电视应用生态里长期存在，值得花时间打磨手感。

我个人在实际部署中的体会是，这类工具的核心竞争力不在功能多少，而在那几十毫秒的手感差异和几个像素的坐标精度上。参数面板、坐标校准、模式切换这些看起来是"附加功能"的东西，恰恰决定了用户是把它当主力工具还是装完就忘。先把移动和点击这两件事做到跟手，再谈扩展，顺序反了会走很多弯路。