主循环与线程泵模型

桌面应用的主循环是为键盘鼠标的慢节奏设计的，搬到触摸设备上，事件频率与渲染节奏都换了量级。主循环与线程泵的模型选择，直接决定应用的响应与功耗。这篇讲模型与改造要点。

▍三种循环模型
模型一，原始循环加轮询：循环里挨个查各输入源（经典桌面模式）。省内存但忙等浪费电，移动端不友好，必须改造。模型二，事件驱动加阻塞等待：无事件时阻塞（epoll 类等待），有事唤醒。功耗友好，是移动端正解。模型三，分层泵：系统层事件泵（接收触摸、生命周期）加框架层主循环（框架自己的事件分发），两层经线程边界衔接——桌面移植的实际形态，关键是两层的唤醒路径要打通（系统事件到达要能唤醒框架循环）。

▍分层泵的接线
系统侧回调（触摸、窗口变化）发生在系统线程，框架循环在框架线程。标准接线：回调里只做入队（无锁队列或互斥队列）加唤醒（写事件管道或条件变量），框架线程醒来出队处理。铁律：回调热路径零 IO——不做文件与日志写盘，只做内存操作；需要记录的状态用原子计数器攒着，慢速线程轮询转储。违反这条的直接症状是偶发全输入冻结（队列线程被 IO 卡住，看起来像设备死了）。

▍节拍与合并
触摸移动事件频率高（每秒上百次），逐事件全量处理会过载。两级优化：合并（同帧内的移动事件只处理最新位置）与节拍（处理频率对齐显示刷新率）。框架的重绘请求同样要合并（脏区合并），别每个输入都触发一次全量重绘。

▍空转检测
模型改完要验证无空转：应用静止时 CPU 占用应近零。检测方法：性能工具看线程 CPU 时间分布，发现常驻活跃线程逐个排查（常见嫌疑：忙等循环、超频定时器、日志轮询）。真实案例：某工程静止时一个线程持续百分之几的占用，追查是调试日志的轮询转储间隔过密，改事件触发后归零。

▍验收
静止功耗、触摸跟手性、长时间使用发热三项一起看——三者是同一套循环模型的三面。

免费无广告的安装包可以在官网下载体验。