安卓电视的交互困境几乎每个深度用过电视盒子的人都有一肚子话想说。遥控器的方向键在网格化界面上挪来挪去还算顺手可一旦碰上那些为手机触屏设计的应用——滑动列表、长按拖拽、双指缩放——方向键立刻变成一根不听话的拐杖点一下挪一格想滑到底部得按到手酸。更别提那些藏在屏幕边缘的按钮方向键的焦点逻辑根本够不着。我最初折腾这个需求就是因为家里那台电视上装了个漫画阅读器翻页要横向滑动遥控器按了十分钟才翻过三话体验极其割裂。安卓电视虚拟鼠标这个思路本质上是在遥控器的按键事件和屏幕的触控事件之间架一座桥把方向键的离散移动映射成光标的连续位移把确认键映射成点击把返回键或者长按映射成拖拽和滑动。听起来简单但真正落地时会撞上一堆细节——光标移动的加速度曲线怎么设计、点击和拖拽怎么区分、不同应用的触控事件坐标系怎么对齐、系统层和用户层两种实现路径各自的天花板在哪里。这篇内容就把我在这条路上踩过的坑、试过的方案、最后跑通的配置完整摊开讲适合手里有安卓电视或者电视盒子、想让遥控器干更多事的人参考也适合想理解安卓输入事件分发机制的开发者当个案例看。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毫秒避免误触。参数推荐值影响调整建议速度衰减系数0.85~0.92松手后光标惯性大屏取高值短按步长屏宽0.5%微调精度阅读场景可减小长按加速上限屏宽2%/帧大范围移动速度4K屏适当降低点击触控半径2~4像素点击识别率低端盒子取大值拖拽触发阈值250~400毫秒点击/拖拽区分按应用类型调这些参数单独看都是小数字组合起来对手感的影响是决定性的。我建议在工具里做一个参数面板让用户能实时调、实时感受比预设几套固定方案实用得多。4.1 低性能盒子上的帧率妥协不是所有电视盒子都跑得动60帧的插值定时器。我手头有一台老盒子插值定时器跑16毫秒周期时CPU占用明显上升光标移动反而出现卡顿。这种情况下把插值周期放宽到33毫秒30帧配合稍微加大的单步位移观感上的连续性损失不大但流畅度稳定很多。判断标准很简单如果Choreographer回调里发现掉帧严重就降周期。这个自适应逻辑值得写进去因为电视硬件的性能跨度实在太大了。4.2 与系统焦点导航的冲突处理最后一个坑来自系统本身。安卓电视的方向键默认承担焦点导航职责你的虚拟鼠标拦截了方向键之后系统级的焦点移动就失效了。这在需要键盘导航的场景比如输入法选字、系统设置菜单里会造成困扰。我的处理是加一个模式切换虚拟鼠标模式和焦点导航模式用某个组合键比如长按返回键切换或者在检测到输入法弹出时自动临时切回焦点导航。这个细节不做用户会在某些界面里彻底失去操作能力体验直接崩盘。5. 实际部署时绕不开的权限与兼容性清单把上面这些逻辑拼成一个能装的工具还有几道部署关卡要过。无障碍服务的声明需要在AndroidManifest.xml里注册BIND_ACCESSIBILITY_SERVICE权限并提供一个accessibility-service配置的XML里面声明canRequestFilterKeyEventstrue和canPerformGesturestrue。少了任何一个按键监听或者手势注入就会静默失效而且系统不会给明确报错只能靠日志排查。不同厂商的系统对无障碍注入的限制程度不一样。有的系统会在省电模式下限制后台无障碍服务的手势注入频率有的会在应用切换时短暂断开服务连接。应对办法是在服务里监听onInterrupt回调断开后自动重连并在重连期间给用户一个轻提示。另外部分系统把无障碍快捷方式做成了独立开关用户开了服务但没开快捷方式服务可能不生效引导页里要把这两步都写清楚。注意调试阶段务必用adb logcat过滤自己服务的TAG无障碍相关的异常大多不会弹窗只会打在日志里。我遇到过服务明明显示已开启、但onKeyEvent就是不回调的情况最后发现是配置文件里漏了flagDefault加上就好了。兼容性方面安卓版本跨度也要考虑。dispatchGesture是API 24引入的低于这个版本只能退回应用层方案。AccessibilityWindowInfo.getBoundsInScreen在部分低版本上返回空需要做空值兜底。这些分支逻辑写起来烦但电视设备的系统版本分布比手机更分散不处理就会在特定设备上直接崩。6. 这套东西还能往哪些方向延伸跑通基础功能之后我试过几个延伸方向有的效果不错有的纯属折腾。比较有价值的是手势录制与回放把一串方向键操作录成一个宏绑定到某个快捷键上一键执行。比如看漫画时录一个下滑翻页的宏按一下翻一页比每次手动滑省事。实现上就是把注入的手势序列存成带时间戳的列表回放时按时间轴重放注意回放期间要屏蔽真实按键输入避免事件打架。另一个方向是光标吸附。电视应用里的可点击元素通常比较大光标移动到附近时自动吸附到元素中心能显著降低精确瞄准的难度。实现需要读取无障碍节点树遍历AccessibilityNodeInfo找isClickable()为true的节点算光标到节点中心的距离小于阈值就吸附。这个功能在列表类应用里体验提升明显但在节点树复杂的应用里遍历开销不小要做节流。至于用语音或者手机当遥控器来控制光标我也试过延迟和精度都不如物理方向键暂时没继续深挖。虚拟鼠标这个方向真正的价值在于它把电视上那些为触屏设计、却被迫用遥控器操作的应用重新盘活了这个需求在电视应用生态里长期存在值得花时间打磨手感。我个人在实际部署中的体会是这类工具的核心竞争力不在功能多少而在那几十毫秒的手感差异和几个像素的坐标精度上。参数面板、坐标校准、模式切换这些看起来是附加功能的东西恰恰决定了用户是把它当主力工具还是装完就忘。先把移动和点击这两件事做到跟手再谈扩展顺序反了会走很多弯路。 
长河君 · 2026/11/4 10:33:53 · 阅读 1.2k 安卓电视虚拟鼠标：遥控器模拟触控的平滑算法与无障碍注入实践
安卓电视的交互困境几乎每个深度用过电视盒子的人都有一肚子话想说。遥控器的方向键在网格化界面上挪来挪去还算顺手可一旦碰上那些为手机触屏设计的应用——滑动列表、长按拖拽、双指缩放——方向键立刻变成一根不听话的拐杖点一下挪一格想滑到底部得按到手酸。更别提那些藏在屏幕边缘的按钮方向键的焦点逻辑根本够不着。我最初折腾这个需求就是因为家里那台电视上装了个漫画阅读器翻页要横向滑动遥控器按了十分钟才翻过三话体验极其割裂。安卓电视虚拟鼠标这个思路本质上是在遥控器的按键事件和屏幕的触控事件之间架一座桥把方向键的离散移动映射成光标的连续位移把确认键映射成点击把返回键或者长按映射成拖拽和滑动。听起来简单但真正落地时会撞上一堆细节——光标移动的加速度曲线怎么设计、点击和拖拽怎么区分、不同应用的触控事件坐标系怎么对齐、系统层和用户层两种实现路径各自的天花板在哪里。这篇内容就把我在这条路上踩过的坑、试过的方案、最后跑通的配置完整摊开讲适合手里有安卓电视或者电视盒子、想让遥控器干更多事的人参考也适合想理解安卓输入事件分发机制的开发者当个案例看。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毫秒避免误触。参数推荐值影响调整建议速度衰减系数0.85~0.92松手后光标惯性大屏取高值短按步长屏宽0.5%微调精度阅读场景可减小长按加速上限屏宽2%/帧大范围移动速度4K屏适当降低点击触控半径2~4像素点击识别率低端盒子取大值拖拽触发阈值250~400毫秒点击/拖拽区分按应用类型调这些参数单独看都是小数字组合起来对手感的影响是决定性的。我建议在工具里做一个参数面板让用户能实时调、实时感受比预设几套固定方案实用得多。4.1 低性能盒子上的帧率妥协不是所有电视盒子都跑得动60帧的插值定时器。我手头有一台老盒子插值定时器跑16毫秒周期时CPU占用明显上升光标移动反而出现卡顿。这种情况下把插值周期放宽到33毫秒30帧配合稍微加大的单步位移观感上的连续性损失不大但流畅度稳定很多。判断标准很简单如果Choreographer回调里发现掉帧严重就降周期。这个自适应逻辑值得写进去因为电视硬件的性能跨度实在太大了。4.2 与系统焦点导航的冲突处理最后一个坑来自系统本身。安卓电视的方向键默认承担焦点导航职责你的虚拟鼠标拦截了方向键之后系统级的焦点移动就失效了。这在需要键盘导航的场景比如输入法选字、系统设置菜单里会造成困扰。我的处理是加一个模式切换虚拟鼠标模式和焦点导航模式用某个组合键比如长按返回键切换或者在检测到输入法弹出时自动临时切回焦点导航。这个细节不做用户会在某些界面里彻底失去操作能力体验直接崩盘。5. 实际部署时绕不开的权限与兼容性清单把上面这些逻辑拼成一个能装的工具还有几道部署关卡要过。无障碍服务的声明需要在AndroidManifest.xml里注册BIND_ACCESSIBILITY_SERVICE权限并提供一个accessibility-service配置的XML里面声明canRequestFilterKeyEventstrue和canPerformGesturestrue。少了任何一个按键监听或者手势注入就会静默失效而且系统不会给明确报错只能靠日志排查。不同厂商的系统对无障碍注入的限制程度不一样。有的系统会在省电模式下限制后台无障碍服务的手势注入频率有的会在应用切换时短暂断开服务连接。应对办法是在服务里监听onInterrupt回调断开后自动重连并在重连期间给用户一个轻提示。另外部分系统把无障碍快捷方式做成了独立开关用户开了服务但没开快捷方式服务可能不生效引导页里要把这两步都写清楚。注意调试阶段务必用adb logcat过滤自己服务的TAG无障碍相关的异常大多不会弹窗只会打在日志里。我遇到过服务明明显示已开启、但onKeyEvent就是不回调的情况最后发现是配置文件里漏了flagDefault加上就好了。兼容性方面安卓版本跨度也要考虑。dispatchGesture是API 24引入的低于这个版本只能退回应用层方案。AccessibilityWindowInfo.getBoundsInScreen在部分低版本上返回空需要做空值兜底。这些分支逻辑写起来烦但电视设备的系统版本分布比手机更分散不处理就会在特定设备上直接崩。6. 这套东西还能往哪些方向延伸跑通基础功能之后我试过几个延伸方向有的效果不错有的纯属折腾。比较有价值的是手势录制与回放把一串方向键操作录成一个宏绑定到某个快捷键上一键执行。比如看漫画时录一个下滑翻页的宏按一下翻一页比每次手动滑省事。实现上就是把注入的手势序列存成带时间戳的列表回放时按时间轴重放注意回放期间要屏蔽真实按键输入避免事件打架。另一个方向是光标吸附。电视应用里的可点击元素通常比较大光标移动到附近时自动吸附到元素中心能显著降低精确瞄准的难度。实现需要读取无障碍节点树遍历AccessibilityNodeInfo找isClickable()为true的节点算光标到节点中心的距离小于阈值就吸附。这个功能在列表类应用里体验提升明显但在节点树复杂的应用里遍历开销不小要做节流。至于用语音或者手机当遥控器来控制光标我也试过延迟和精度都不如物理方向键暂时没继续深挖。虚拟鼠标这个方向真正的价值在于它把电视上那些为触屏设计、却被迫用遥控器操作的应用重新盘活了这个需求在电视应用生态里长期存在值得花时间打磨手感。我个人在实际部署中的体会是这类工具的核心竞争力不在功能多少而在那几十毫秒的手感差异和几个像素的坐标精度上。参数面板、坐标校准、模式切换这些看起来是附加功能的东西恰恰决定了用户是把它当主力工具还是装完就忘。先把移动和点击这两件事做到跟手再谈扩展顺序反了会走很多弯路。