结合Windows GetMessage事件循环与UI动画循环实现低CPU占用

现有方案可行性分析 #

1. 自定义消息触发SetTimer #

可行性：高，推荐作为基础方案
这是WinAPI实现UI动画的常规做法，完全兼容原有GetMessage循环的低CPU特性：

• 动画启动时发送自定义消息，在WndProc中调用SetTimer生成约16ms（1/60秒）一次的WM_TIMER消息；
• 无动画时没有额外消息，主线程依然通过GetMessage休眠，CPU占用极低；
• 注意点：默认Windows定时器精度约10-15ms，若需要更接近60帧的精度，可调用timeBeginPeriod(1)提升精度，动画结束后用timeEndPeriod(1)恢复，避免影响系统全局定时器；WM_TIMER是低优先级消息，若主线程被高优先级消息阻塞，动画可能出现轻微卡顿，但对绝大多数UI场景足够。

2. 动画逻辑放在独立线程 #

可行性：低，不推荐
UI操作必须在窗口创建的主线程执行，动画线程仅能计算动画参数，再通过PostMessage等方式通知主线程重绘，反而增加了线程通信的复杂度，还容易出现UI状态同步问题。线程休眠调度若处理不当，资源占用甚至会高于Timer方案，完全没必要为UI动画单独开线程。

3. 直接改用PeekMessage循环 #

可行性：高，但不推荐
如果采用while(PeekMessage(...))的空循环，即使没有消息也会持续轮询，CPU占用会直接拉满；若添加Sleep降低占用，又会导致UI响应延迟，反而不如GetMessage+Timer的组合高效。仅在需要极端实时性的场景（如游戏级渲染）才考虑，普通UI动画完全没必要。

4. 自研类似Chromium的消息队列系统 #

可行性：极低，成本过高
Chromium的消息队列是为跨平台、复杂任务调度设计的，自研需要整合原生消息、动画帧调度、优先级管理等大量逻辑，工作量巨大。WinAPI原生消息机制已经能满足UI动画的需求，除非你的UI框架有跨平台或超复杂调度的硬性要求，否则完全没必要重复造轮子。

推荐替代方案 #

优化版Timer方案（GetMessage+高精度Timer+GPU加速重绘） #

基于方案1优化，兼顾低CPU和流畅动画：

// 动画启动时
timeBeginPeriod(1); // 提升定时器精度
SetTimer(hwnd, TIMER_ANIM_ID, 16, NULL); // 约60帧/秒

// WndProc中处理WM_TIMER
case WM_TIMER:
    if (wParam == TIMER_ANIM_ID) {
        // 计算动画进度，更新UI状态
        updateAnimationState();
        // 标记动画区域需要重绘，触发GPU加速重绘
        InvalidateRect(hwnd, &animationRect, FALSE);
        UpdateWindow(hwnd); // 立即触发WM_PAINT（可选，根据刷新需求）
    }
    break;

// 动画结束时
KillTimer(hwnd, TIMER_ANIM_ID);
timeEndPeriod(1); // 恢复系统定时器精度

系统级GPU动画方案（DirectComposition/DWM） #

如果你的UI已经采用GPU加速，推荐使用Windows原生的DirectComposition或DWM动画接口：

• 这些是系统级的动画支持，由系统负责帧调度和硬件加速，无需自己处理Timer和重绘逻辑；
• 可直接绑定UI元素的属性（位置、透明度、缩放等）到动画曲线，系统会自动优化资源占用，动画更流畅；
• 避免了手动计算帧进度和重绘的繁琐，还能支持阴影、模糊等硬件加速特效。

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