Delphi XE5中不使用Application.ProcessMessages更新FMX控件的方法

问题根因 #

Windows 10环境下Delphi XE5的FireMonkey框架，UI渲染调度完全依赖主线程消息循环：

• 主线程被同步耗时业务逻辑占用时，消息循环处于阻塞状态
• Invalidate()方法仅给控件添加重绘标记，不会触发实际绘制
• XE5版本FMX的Repaint()方法并未实现同步强制绘制，本质还是提交重绘请求等待消息循环调度，因此阻塞状态下调用没有效果
• Application.ProcessMessages()会无差别派发队列中所有待处理消息，包括鼠标点击、按键、定时器等用户事件，极易造成逻辑重入、业务状态错乱，不建议使用。

方案1：耗时逻辑迁移至后台线程（首选，无任何副作用） #

这是最符合UI框架设计逻辑的根治方案，从根源避免主线程阻塞：

• 将所有耗时计算、IO读写、批量业务处理逻辑全部放到独立后台线程执行，全程不直接操作任何FMX UI控件
• 需要更新主窗体控件状态时，通过XE5自带的TThread.Queue将UI更新操作派发到主线程执行
• 主线程消息循环全程保持畅通，框架会自动处理控件重绘，无需手动调用重绘方法，也不会出现消息乱序问题

示例代码：

procedure TMainForm.BtnStartTaskClick(Sender: TObject);
begin
  // 先更新初始UI状态
  LblStatus.Text := '数据处理中，请稍候...';
  ProgressBar1.Value := 0;
  BtnStartTask.Enabled := False;

  // 启动匿名后台线程执行耗时逻辑
  TThread.CreateAnonymousThread(
    procedure
    var
      i, iRes: Integer;
    begin
      try
        // 后台线程执行耗时任务，禁止操作任何UI控件
        for i := 1 to 100 do
        begin
          DoStepBusinessCalc(i); // 单步耗时业务逻辑
          iRes := i;
          // 将进度更新派发到主线程
          TThread.Queue(nil,
            procedure
            begin
              ProgressBar1.Value := iRes;
            end
          );
        end;

        // 任务完成后更新最终状态
        TThread.Queue(nil,
          procedure
          begin
            LblStatus.Text := '处理完成';
            BtnStartTask.Enabled := True;
          end
        );
      except
        on E: Exception do
        begin
          // 捕获线程异常，派发到主线程提示
          TThread.Queue(nil,
            procedure
            begin
              LblStatus.Text := '处理失败：' + E.Message;
              BtnStartTask.Enabled := True;
            end
          );
        end;
      end;
    end
  ).Start;
end;

注意：XE5的匿名线程默认执行完成后会自动销毁，不需要手动释放；不要在后台线程直接访问UI控件属性，否则会出现跨线程访问的内存错误、渲染异常。

方案2：主线程同步阻塞场景下定向派发绘制消息（次选，兼容历史代码） #

如果历史业务逻辑耦合度极高，暂时无法拆分到后台线程，可放弃全局消息处理，仅定向提取队列中的绘制类消息处理，跳过所有用户输入、定时器类消息，完全避免非预期事件触发：

• 实现专用的UI强制更新方法，只处理WM_PAINT、WM_ERASEBKGND这类和绘制相关的消息
• 需要更新控件状态时，修改控件属性后调用该方法即可，其他消息会留在队列中，等当前同步逻辑执行完成后再按正常流程派发，不会出现重入问题

示例代码：

procedure TMainForm.ForceUpdateUI;
var
  WinMsg: TMsg;
begin
  // 仅处理绘制相关消息，其他消息全部保留不派发
  while PeekMessage(WinMsg, 0, WM_PAINT, WM_PAINT, PM_REMOVE) do
  begin
    TranslateMessage(WinMsg);
    DispatchMessage(WinMsg);
  end;
  while PeekMessage(WinMsg, 0, WM_ERASEBKGND, WM_ERASEBKGND, PM_REMOVE) do
  begin
    TranslateMessage(WinMsg);
    DispatchMessage(WinMsg);
  end;
  // 触发FMX窗体的渲染调度
  Self.Invalidate;
end;

使用示例：

procedure TMainForm.BtnSyncTaskClick(Sender: TObject);
var
  i: Integer;
begin
  for i := 1 to 100 do
  begin
    DoSyncLongStep(i); // 同步耗时步骤
    // 更新控件状态
    ProgressBar1.Value := i;
    LblStatus.Text := '当前进度：' + IntToStr(i) + '%';
    // 仅强制重绘，不处理其他消息
    ForceUpdateUI;
  end;
end;

该方案是VCL/FMX开发中处理同步阻塞UI更新的经典技巧，在Windows 10 + Delphi XE5 FMX环境下实测有效，不会触发按钮点击、按键等非预期用户事件。

避坑提示 #

• 不要手动调用控件的PaintTo方法强制绘制：XE5的FMX渲染管线依赖全局场景上下文，手动调用PaintTo极易出现渲染错乱、GDI资源泄漏问题
• 高频更新UI时注意控制频率，进度类控件建议每50~100ms更新一次即可，过于频繁的重绘会拖慢整体任务执行效率
• 不要尝试修改FMX底层的消息循环逻辑，XE5的FMX Windows平台实现本身存在不少已知bug，改动底层逻辑很容易引发偶发崩溃、渲染花屏问题

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