Android UI线程繁忙时是否会跳过或限流ACTION_MOVE触摸事件？

没错，Android确实会在UI线程繁忙的时候对ACTION_MOVE事件做合并限流，这就是你看到大量中间MOVE事件消失的核心原因。

背后的系统逻辑是这样的： #

• Android的触摸事件由系统的InputManagerService（IMS）负责收集和分发，所有触摸事件最终都会被投递到UI线程的消息队列中等待处理。
• 当UI线程被耗时任务占满（比如长时间的计算、复杂的绘制操作），消息队列开始堆积时，IMS不会无限制地往队列里塞连续的ACTION_MOVE事件。系统认为，连续的MOVE事件本质是在报告手指位置的连续变化，最新的那个位置才是最有价值的——用户的手指已经滑到新位置了，之前的旧位置事件再处理已经没有实际意义，反而会加重UI线程的负担。
• 所以IMS会自动合并连续的ACTION_MOVE事件：它会丢弃中间的大部分事件，只保留最新的1-2个，等UI线程有空的时候一次性分发出去。这就导致你原本能收到十几个MOVE事件，现在只剩寥寥几个。

关于你关心的「延迟可以接受，但事件丢失不能理解」： #

系统的这个设计是优先保证触摸事件的时效性而非完整性。对于大多数普通滑动场景（比如列表滚动、页面切换），用户只需要最终的滑动结果，中间的每一步位置其实无关紧要；但如果你的场景是精细手势识别、实时绘图这类必须依赖全量MOVE事件的功能，这种合并就会带来问题。

如果确实需要全量事件，有两个思路可以尝试：

• 用View#postOnAnimation()或者Choreographer来绑定触摸事件的处理逻辑，让它和系统的绘制帧同步，减少UI线程的阻塞概率；
• 极端情况下可以考虑监听原始输入事件（需要系统级权限，普通应用不推荐）。

当然，正如你所说，UI线程不应该繁忙是基本原则，但既然你聚焦在事件本身，那核心原因就是系统的这个事件合并限流策略。

内容的提问来源于stack exchange，提问作者Lukasz Indyk