在FMX中使用阻塞式ShowMessage会引发哪些问题？

本文探讨在FMX中使用阻塞式ShowMessage的影响，聚焦Android/Mac平台下强制实现阻塞式消息框引发的问题，属于偏理论性讨论。

阻塞式消息框（如Yes/No、Ok类型）在Windows平台使用起来非常便捷，但如果用以下代码实现阻塞式消息框，会引发哪些问题？

function MsgGeneric(const MessageText: string): Integer;
var
  DialogType: TMsgDlgType;
  Buttons: TMsgDlgButtons;
  DefaultButton: TMsgDlgBtn;
  Event: TEvent;
  ResultValue: Integer;
begin
  if MessageText = '' then Exit(0);

  DialogType := GetDialogTypeFromIcon(Icon);
  if (Icon and cMB_YESNO) = cMB_YESNO then    // MB_YESNO
    begin
      Buttons := [TMsgDlgBtn.mbYes, TMsgDlgBtn.mbNo];
      DefaultButton := TMsgDlgBtn.mbNo;
    end
  else
    begin
      Buttons := [TMsgDlgBtn.mbOK];
      DefaultButton := TMsgDlgBtn.mbOK;
    end;

  Event:= TEvent.Create;
  ResultValue:= 0;
    
  try
    TDialogService.MessageDialog(MessageText,
        DialogType,
        Buttons,
        DefaultButton,
        0,
        procedure(const AResult: TModalResult)
        begin
            ResultValue := AResult;
            Event.SetEvent;
        end);

    // Wait for dialog to close
    Event.WaitFor(INFINITE); 
    Result := ResultValue;
  finally
    Event.Free;
  end;
end;

核心问题分析 #

• UI线程完全阻塞：FMX的TDialogService.MessageDialog是异步实现，依赖UI线程处理用户交互。代码中用Event.WaitFor(INFINITE)会直接卡住当前UI线程，导致整个应用界面冻结，无法响应任何操作。在Android平台，这种阻塞超过一定时长会触发系统的ANR（应用无响应）机制，直接被系统强制关闭。
• 违背平台设计规范：MacOS和Android的UI框架均采用异步交互模型，这种强制阻塞的方式不符合平台原生设计逻辑，可能导致消息框无法正常渲染，或者出现界面错乱、无响应的异常情况。
• 死锁与资源泄漏风险：如果回调逻辑因线程阻塞无法触发Event.SetEvent，会导致代码进入无限等待状态；若等待过程中出现未捕获异常，事件对象可能无法正常释放，长期运行会引发内存泄漏。
• 回调执行异常：TDialogService.MessageDialog的回调函数本应在UI线程执行，但UI线程被阻塞后，回调的执行会被延迟，甚至因为线程死锁永远无法触发，最终导致程序卡死。

参考内容 #

• Delphi FMX阻塞式消息对话框
• FireMonkey中消息对话框的正确显示方式

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