如何解决业务处理过程中界面“呆滞”的问题？
zhhzxl
2004-12-08
问题的提出：
在windows窗口（例如：对话框）上触发一个业务时，经常会遇到这样一种情况：整个窗口瞬间变得呆滞，无法拖动、切换和刷新；即使另外创建非模态的窗口来反映业务处理的过程，也无济于事。下面是某个项目中出现的情形。
处理业务前：
点击“汇总”按钮后：
由上图很明显可以看到，在业务处理的过程中，界面既无法响应也无法刷新。造成这种情形的原因是什么？
问题的原因：
上述问题出现的原因是：业务处理、界面响应刷新等被放置在同一个线程中了。因此，当整个线程的运行时间都用去处理业务时，界面自然无法响应和刷新，也就出现了“呆滞”的问题。当然大部分的情况下，业务可以在瞬间处理，用户感觉不出各种消息处理的先后顺序，误以为所有的事情都是同时做的。
在这里，我不想去讨论操作系统的消息处理机制，而是针对上述问题给出两种解决的方案，并且限制：任何时刻程序进程中仅允许存在一个业务处理过程。注：方案中出现的代码使用类vc形式。
解决的方案：
首先，为了问题说明的简单，作者给出界面程序处理的简化模式：
其中：（注：未给出接口参数）
class IForm{
virtual bool GetSetting() = 0; //获取设置
}
class IUiControl{
virtual void RunTask() = 0; //触发业务
}
virtual IEntity{
virtual bool Process() = 0; //业务处理
}
顺序图如下：
方案1：显示调用消息API
这种方案使用的场合是，业务的处理过程可以划分成众多微小的子处理过程，而子过程的处理仅花费微小的时间片。假定子过程处理函数由IEntity接口给出，描述为：MiniProcess。
则IUiControl::RunTask的实现可以改为：
void IUiControl::RunTask()
{
if(IForm::GetSetting())
{
CWaitCursor wait; //处理过程中，阻止用户操作，但不阻止系统消息
MSG message;
while(是否结束？)
{
IEntity::MiniProcess();
//接收和分发消息
If(::PeekMessage(&message,NULL,0,0,PM_REMOVE)){
::TranslateMessage(&message);
::DispatchMessage(&message);
}
}
}
}
从实现代码可以看出，这种方式并没有增加线程的数量，而是在业务处理的过程中，安插了消息接收和分发的函数，间歇性的响应了消息。
方案2：增加业务处理线程
这种方案使用的场合是业务过程无法细分，或者子过程本身也需要较长时间花费的情形。方案中增加了一个反馈窗口，以便用户在业务处理的过程中能够看到一些反馈信息。该窗口可以采用非模态的对话框实现，在界面的初始化函数中创建。
改进的类图如下：
改进的顺序图如下：
在界面控制中增加私有的线程函数：
static bool WINAPI ThreadProc(LPVOID lpParam)
{
IEntity* lpEntity = (IEntity*)lpParam;
return lpParam->Process();
}
将IUiControl::RunTask的实现改为：
void IUiControl::RunTask()
{
if(IForm::GetSetting())
{
DWORD id;
AfxBeginThread(ThreadProc,(LPVOID)业务类指针);
}
}
从实现代码可以看出，业务处理由单独的线程负责，因此不会阻塞界面上的消息，从而解决了界面“呆滞”的问题。
结束语：
本文提出两种方案，解决了业务处理过程中界面“呆滞”的问题。方案简单清晰，便于使用，同时也适于已有代码的改造。但是，方案只提供了解决问题的框架，遇到具体问题时，还需改进和补充。在使用方案时需要考虑代码重入的问题，以免出现莫名其妙的错误。该方案没有考虑多业务处理并发的情形，留待用户自行处理。
