瞭解執行緒問題
本主題描述 Microsoft 消費者介面自動化用戶端實作的常見執行緒案例,並說明如何避免用戶端使用執行緒不正確時可能發生的問題。
本主題包含下列幾節:
消費者介面自動化和 UI 執行緒
由於消費者介面自動化使用 Windows 訊息的方式,當用戶端應用程式嘗試與 UI 執行緒上自己的 UI 互動時,就會發生衝突。 這些衝突可能會導致效能非常慢,甚至會導致應用程式停止回應。
如果您的用戶端應用程式是要與桌面上的所有元素互動,包括自己的 UI,您應該從個別執行緒進行所有消費者介面自動化呼叫。 這包括使用 IUIAutomationTreeWalker 或 IUIAutomationElement::FindAll 方法和使用控制項模式來尋找元素。 此執行緒不應該擁有任何視窗,而且應該是元件物件模型 (COM) Multithreaded Apartment (MTA) 模型執行緒, (一個使用COINIT_MULTITHREADED flag.) 呼叫CoInitializeEx來初始化 COM 的執行緒。)
在消費者介面自動化事件處理常式中進行消費者介面自動化呼叫是安全的,因為事件處理常式一律會在非 UI 執行緒上呼叫。 不過,訂閱可能來自用戶端應用程式 UI 的事件時,您必須在非 UI 執行緒上呼叫 IUIAutomation::AddAutomationEventHandler或相關的方法, (這也應該是 MTA 執行緒) 。 在相同執行緒上移除事件處理常式。
消費者介面自動化用戶端不應該使用多個執行緒來新增或移除事件處理常式。 如果在相同用戶端進程中新增或移除另一個事件處理常式,則發生非預期的行為。
事件處理常式的執行緒模型
消費者介面自動化用戶端應該針對實作事件處理常式的執行緒使用 COM MTA 執行緒模型。 使用單一線程 Apartment (STA) 模型可能會導致問題,例如防止用戶端從執行緒移除事件處理常式。
64 位 Windows 上的 COM Apartment Affinity
根據 COM 規格,遠端物件的存留期是由 呼叫 CoCreateInstance 函式來建立物件的 Apartment 存留期所控管。 當原始 Apartment 關閉時,也會釋放遠端物件。
對於消費者介面自動化用戶端,此 COM 行為可能表示 32/64 協助程式的存留期 (是由 32 位元素所使用之UIAutomationCore.dll) 所建立的執行緒 Apartment 存留期所控管。 如果消費者介面自動化用戶端會將元素封送處理到另一個執行緒,當原始 Apartment 關閉時,元素可能會失效。 消費者介面自動化用戶端應該在使用封送處理自動化元素時攔截錯誤,以正常方式處理這些問題。
具有 64 位元素的 32 位消費者介面自動化用戶端可能會發生相同的問題。
相關主題
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應