最近在Windows桌面自動(dòng)化上折騰了一個(gè)小需求從QQ客戶端的資料卡片里自動(dòng)讀取昵稱、賬號(hào)、簽名等信息。最開(kāi)始我以為這不就是遍歷一下控件樹(shù)、取幾個(gè)屬性的事結(jié)果真正上手才發(fā)現(xiàn)坑一個(gè)接一個(gè)光“元素找到了但讀不到數(shù)據(jù)”這一個(gè)問(wèn)題就卡了我兩天。如果你也打算用UIAutomation這類技術(shù)去操作QQ、微信這類深度自繪UI的程序這篇內(nèi)容建議先看完再動(dòng)手。UIAutomation確實(shí)是Windows平臺(tái)上做UI自動(dòng)化最正統(tǒng)的方案系統(tǒng)自帶的輔助功能框架不需要注入DLL也不需要勾住鼠標(biāo)鍵盤純靠控件樹(shù)就能拿到界面信息。但它的能力邊界很清晰凡是老老實(shí)實(shí)暴露了標(biāo)準(zhǔn)控件接口的程序它能干得漂亮凡是靠自繪引擎自己畫界面的程序比如QQ這種它就經(jīng)常失靈。這篇文章我用“獲取QQ資料”這個(gè)場(chǎng)景為主線把我在實(shí)際開(kāi)發(fā)中遇到的3個(gè)典型錯(cuò)誤、排查思路和最終修復(fù)方案完整記錄下來(lái)順帶把UIAutomation的幾個(gè)核心概念講透。適合正在做Windows桌面自動(dòng)化、或者準(zhǔn)備入坑但怕被控件樹(shù)折磨的開(kāi)發(fā)者參考。1. 為什么偏偏用UIAutomation來(lái)抓QQ資料1.1 UIAutomation到底能干什么UI Automation是微軟在.NET Framework 3.0時(shí)期推出的一套輔助功能接口后來(lái)系統(tǒng)級(jí)實(shí)現(xiàn)被整合進(jìn)了Windows本身。它的本質(zhì)是把屏幕上任意一個(gè)窗口里的界面元素抽象成一棵“控件樹(shù)”樹(shù)上的每個(gè)節(jié)點(diǎn)都是一個(gè)AutomationElement代表一個(gè)按鈕、一個(gè)輸入框、一個(gè)文本標(biāo)簽甚至一個(gè)自定義繪制區(qū)域。它最核心的能力有三個(gè)也是我這次需求里真正用到的查找元素按窗口標(biāo)題、控件類型、AutomationId、Name等條件去控件樹(shù)里定位目標(biāo)節(jié)點(diǎn)。讀取屬性拿到元素的Name、ControlType、BoundingRectangle屏幕坐標(biāo)范圍、IsEnabled等一堆元數(shù)據(jù)。調(diào)用模式對(duì)支持特定模式的元素執(zhí)行操作比如Invoke點(diǎn)擊、Value讀寫文本、Selection選中項(xiàng)。對(duì)做數(shù)據(jù)采集的人來(lái)說(shuō)第一和第二個(gè)能力是重點(diǎn)。因?yàn)槿绻隳芊€(wěn)定拿到一個(gè)窗口里所有元素的Name和Value你根本就不需要截圖OCR直接內(nèi)存級(jí)別精準(zhǔn)提取速度和準(zhǔn)確率都吊打視覺(jué)方案。1.2 為什么不用別的方案在正式開(kāi)搞之前我其實(shí)是把市面上的主流方案都捋了一遍因?yàn)樗鼈兏髯缘膬?yōu)劣勢(shì)直接決定了后續(xù)要踩的坑有多深。先說(shuō)我最后為什么選擇了UIAutomation而不是其他幾種常見(jiàn)路線方案原理優(yōu)點(diǎn)缺點(diǎn)UIAutomation / FlaUI通過(guò)系統(tǒng)輔助功能接口讀取控件樹(shù)無(wú)侵入、精準(zhǔn)、速度快遇到自繪界面會(huì)失靈圖像識(shí)別OpenCV模板匹配截圖后在像素層面找目標(biāo)區(qū)域通用性強(qiáng)、什么軟件都能用分辨率敏感、性能差、文字提取還得套OCR模擬鍵鼠pyautogui/win32api按固定坐標(biāo)或快捷鍵操作門檻最低、寫起來(lái)快窗口一動(dòng)全白搭、無(wú)法校驗(yàn)結(jié)果逆向協(xié)議抓包直接分析客戶端網(wǎng)絡(luò)通信或本地?cái)?shù)據(jù)庫(kù)數(shù)據(jù)最完整、最穩(wěn)定違法風(fēng)險(xiǎn)高、技術(shù)門檻極高、不推薦碰從表格能看出圖像識(shí)別和模擬鍵鼠都屬于“盲操作”你根本不知道自己拿到的數(shù)據(jù)對(duì)不對(duì)逆向協(xié)議雖然數(shù)據(jù)維度最好但它涉嫌破壞計(jì)算機(jī)信息系統(tǒng)而且對(duì)普通開(kāi)發(fā)者來(lái)說(shuō)工程量大得嚇人。UIAutomation是目前唯一兼顧“非侵入、可校驗(yàn)、實(shí)現(xiàn)成本可控”的路線所以我選它。但選它不意味著萬(wàn)事大吉。QQ的資料卡片是典型的自繪界面很多元素不暴露標(biāo)準(zhǔn)屬性這就直接引出后面那3個(gè)坑。2. 動(dòng)手前必須掌握的幾個(gè)核心概念2.1 控件樹(shù)一切UI元素的組織方式理解UIAutomation的第一步是理解控件樹(shù)。Windows會(huì)把一個(gè)窗口內(nèi)部的所有可交互元素組織成一個(gè)樹(shù)形結(jié)構(gòu)根節(jié)點(diǎn)是桌面Desktop第二層是每個(gè)頂層窗口如QQ主窗口再往下是窗口內(nèi)部的按鈕、輸入框、列表項(xiàng)等。但要注意控件樹(shù)不是你眼睛看到的那個(gè)“視覺(jué)樹(shù)”。比如QQ界面里你肉眼看到的一大塊面板在控件樹(shù)里可能只是一個(gè)ControlType為Custom的節(jié)點(diǎn)里面什么都沒(méi)有因?yàn)樗亲岳L的繪制細(xì)節(jié)完全在窗口內(nèi)部完成系統(tǒng)拿不到更細(xì)的結(jié)構(gòu)。這件事特別反直覺(jué)。我第一次用Inspect工具查看QQ窗口時(shí)以為能看到豐富的控件列表結(jié)果里面全是Custom或者Pane活像一個(gè)空殼。所以后續(xù)寫代碼時(shí)我完全沒(méi)有依賴QQ內(nèi)部控件的標(biāo)準(zhǔn)屬性而是用窗口標(biāo)題、窗口句柄、屏幕坐標(biāo)這些“外部特征”來(lái)定位。2.2 條件表達(dá)式AndCondition還是直接字符串UIAutomation定位元素最常用的是Condition本質(zhì)上是一個(gè)過(guò)濾器。你可以用PropertyCondition指定“某個(gè)屬性等于某個(gè)值”也可以用AndCondition組合多個(gè)條件。在實(shí)際寫代碼時(shí)很多新手會(huì)犯一個(gè)毛病想一步到位用多個(gè)條件同時(shí)過(guò)濾結(jié)果找不到元素。原因很簡(jiǎn)單——你要找的元素本身就沒(méi)有暴露你用作過(guò)濾條件的那幾個(gè)屬性。以QQ資料卡為例它的昵稱區(qū)域很可能Name為空、AutomationId為空你拿這些條件去匹配自然什么都匹配不到。我的建議是先用最小條件定位比如“窗口標(biāo)題包含某某QQ號(hào)”拿到整個(gè)窗口節(jié)點(diǎn)再遞歸遍歷它的子樹(shù)用ControlType和BoundingRectangle輔助判斷甚至直接打印整棵子樹(shù)來(lái)人工確認(rèn)。能把整棵樹(shù)的節(jié)點(diǎn)打印出來(lái)比你絞盡腦汁寫過(guò)濾條件有用得多。2.3 偵察工具和開(kāi)發(fā)庫(kù)選擇工欲善其事必先利其器。我做這個(gè)需求時(shí)查控件樹(shù)用的是Windows SDK自帶的Inspect工具在安裝了Windows SDK之后路徑一般在“C:\Program Files (x86)\Windows Kits\10\bin\版本號(hào)\x64\Inspect.exe”。Inspect有幾個(gè)模式要會(huì)用鼠標(biāo)跟隨模式鼠標(biāo)移到哪里就顯示那個(gè)元素的屬性快速確認(rèn)你想要的區(qū)域到底暴露了哪些屬性?？丶?shù)視圖模式左邊是樹(shù)右邊是屬性適合看整體層級(jí)。原始視圖模式Standard視圖看不到的節(jié)點(diǎn)在Raw視圖里可能會(huì)冒出來(lái)這對(duì)分析自繪控件很關(guān)鍵。開(kāi)發(fā)庫(kù)方面C#生態(tài)最成熟的是FlaUIPython生態(tài)里我一直用一個(gè)名為uiautomation的庫(kù)它內(nèi)部用comtypes包裝了COM接口比直接用ctypes自己調(diào)API舒服太多。下面的示例代碼我都以Python的uiautomation庫(kù)為例邏輯換成FlaUI也完全通用。3. 三個(gè)典型錯(cuò)誤從踩坑到修復(fù)3.1 錯(cuò)誤一控件樹(shù)遍歷不到條件根本沒(méi)寫對(duì)場(chǎng)景還原我寫的第一版代碼邏輯很簡(jiǎn)單通過(guò)窗口標(biāo)題找到QQ主窗口然后在窗口控件樹(shù)里FindControl條件設(shè)為ControlType為Text、Name包含目標(biāo)QQ號(hào)。結(jié)果程序跑起來(lái)返回空什么都不找到。當(dāng)時(shí)我第一反應(yīng)是窗口句柄沒(méi)拿對(duì)但Print一下又發(fā)現(xiàn)窗口找到了。問(wèn)題明顯出在“從窗口再往下找”這一步。排查過(guò)程我先用Inspect的鼠標(biāo)跟隨模式點(diǎn)了一下QQ資料卡上的昵稱區(qū)域。注意Inspect里顯示的是元素類型QQ資料卡的每一塊幾乎都是Pane或Custom根本沒(méi)有Text控件而且所有Name都是空字符串AutomationId也是空。這就解釋了為什么我拿“Text類型”去過(guò)濾會(huì)一無(wú)所獲。但這里有個(gè)更隱蔽的坑即使我把條件放寬到所有控件控件樹(shù)里也未必有那個(gè)節(jié)點(diǎn)。因?yàn)镼Q的資料卡本質(zhì)上是一個(gè)獨(dú)立的分層窗口Layered Window它和QQ主窗口雖然是父子關(guān)系但內(nèi)容不是通過(guò)標(biāo)準(zhǔn)控件繪制而是直接把像素貼上去的。在UIAutomation視角里這一塊區(qū)域就只是一個(gè)矩形框系統(tǒng)不知道里面畫了字。修復(fù)方案既然拿不到內(nèi)部元素那就別硬剛內(nèi)部結(jié)構(gòu)改用“窗口 位置”的組合策略。第一步用窗口標(biāo)題找到資料卡所在的頂層窗口。很多時(shí)候資料卡是一個(gè)獨(dú)立的頂層窗口句柄不同標(biāo)題里往往包含你要找的QQ號(hào)。第二步根據(jù)你已知的界面布局用BoundingRectangle計(jì)算目標(biāo)文本區(qū)域的屏幕坐標(biāo)范圍。第三步對(duì)這個(gè)坐標(biāo)范圍做文本獲取——本質(zhì)上已經(jīng)不是UIAutomation的活而是需要用到輔助功能里的TextPattern或者直接后臺(tái)截圖OCR。但好在我們只是為了拿資料不一定非要讀屏幕像素有時(shí)候直接從窗口標(biāo)題正則提取QQ號(hào)就夠了。代碼實(shí)現(xiàn)大概是這樣的import uiautomation as auto import re def find_profile_window(keyword): # 遍歷所有頂層窗口找標(biāo)題里包含指定關(guān)鍵字的 for wnd in auto.GetRootControl().GetChildren(): name wnd.Name or if 資料 in name and keyword in name: return wnd return None # 拿QQ號(hào)可以這樣直接從標(biāo)題提 win find_profile_window(目標(biāo)昵稱或QQ號(hào)) if win: print(窗口標(biāo)題:, win.Name) m re.search(rQQ號(hào)[:]?\s*(\d{5,}), win.Name) if m: print(提取到號(hào)碼:, m.group(1))別小看這個(gè)思路它繞開(kāi)了自繪控件讀不到內(nèi)部元素的死結(jié)。后面錯(cuò)誤二里讀更復(fù)雜的資料內(nèi)容也是建立在“窗口定位”這個(gè)基礎(chǔ)上的。提示無(wú)論用什么方式遍歷控件樹(shù)都不要一上來(lái)就對(duì)整個(gè)桌面做全局FindAll。桌面節(jié)點(diǎn)下的元素有幾萬(wàn)個(gè)一次全量遍歷慢到懷疑人生。正確的做法永遠(yuǎn)是“頂層窗口快速定位 - 再向下找”能攔腰截?cái)嘟^不從根搜。3.2 錯(cuò)誤二明明拿到了元素文本卻是空的場(chǎng)景還原繞開(kāi)控件樹(shù)最深處之后我改用了一種“取巧”的辦法用UIAutomation的WindowPattern控制資料卡窗口再嘗試遍歷它的直接子節(jié)點(diǎn)找到看起來(lái)像是昵稱、賬號(hào)的那幾個(gè)元素然后調(diào)用GetCurrentPropertyValue(AutomationElement.NameProperty)去讀文本。結(jié)果這次能拿到元素了但讀出來(lái)的Name還是空字符串ValuePattern也不可用調(diào)用Value的Value屬性直接拋異常。這是UIAutomation入門者最容易崩潰的階段——拿著Inspect敲定的屬性在代碼里卻拿到空值。其實(shí)原因不外乎下面幾種。排查過(guò)程我當(dāng)時(shí)用Inspect的Raw View重新審視了QQ資料卡的控件樹(shù)發(fā)現(xiàn)了一個(gè)重要現(xiàn)象很多節(jié)點(diǎn)雖然有NativeWindowHandle說(shuō)明它們承載了一個(gè)原生子窗口但Name、Value、LegacyIAccessible這些跟文本有關(guān)的屬性全是空。這意味著文本信息并沒(méi)有按標(biāo)準(zhǔn)控件屬性暴露給輔助功能而是由QQ自己在繪制窗口時(shí)直接調(diào)用GDI畫上去的。不過(guò)還有第二種可能也是很多人忽略的信息加載是異步的。QQ資料卡打開(kāi)之后昵稱、等級(jí)、簽名這些數(shù)據(jù)是慢慢刷出來(lái)的控件樹(shù)里的節(jié)點(diǎn)雖然已經(jīng)創(chuàng)建但文本內(nèi)容還沒(méi)填進(jìn)去。如果你在打開(kāi)窗口后立刻讀取拿到空值是再正常不過(guò)的事。修復(fù)方案對(duì)策分兩步一是“等待”二是“換通道”。等待很好理解就是輪詢讀取直到目標(biāo)屬性非空或者超時(shí)。注意這里要加上Time.sleep但不能用固定sleep因?yàn)椴煌W(wǎng)絡(luò)條件和機(jī)器性能加載速度差異很大。我寫了一個(gè)通用的等待函數(shù)import time def wait_for_element(wnd, condition, timeout10): start time.time() while time.time() - start timeout: el wnd.GetFirstChildControl(condition) if el and el.Name: return el time.sleep(0.3) return None“換通道”則是核心修復(fù)點(diǎn)既然標(biāo)準(zhǔn)屬性拿不到我就去試著調(diào)用LegacyIAccessible模式。這個(gè)模式是微軟為了兼容老式Win32輔助功能接口MSAA保留的通道自繪控件只要實(shí)現(xiàn)了IAccessible接口數(shù)據(jù)就能從這里拿出來(lái)。QQ很多自繪區(qū)域其實(shí)在背后實(shí)現(xiàn)了IAccessibleInspect里看是空但真去調(diào)用是能拿到內(nèi)容的。def get_text_via_legacy(el): # 嘗試獲取LegacyIAccessible模式 legacy el.GetLegacyIAccessiblePattern() if legacy: return legacy.Name or return 如果LegacyIAccessible也是空我最后的兜底方案才是截圖OCR。但實(shí)際測(cè)試下來(lái)QQ資料卡里昵稱和個(gè)性簽名有很大概率能通過(guò)LegacyIAccessible拿到并不需要走到OCR那一步。注意讀ValuePattern尤其是LegacyIAccessible時(shí)如果元素沒(méi)有實(shí)現(xiàn)對(duì)應(yīng)接口直接調(diào)用會(huì)拋異常。不要一上來(lái)就假定所有元素都支持這些Pattern先通過(guò)GetSupportedPatterns判斷一下再做分支處理。3.3 錯(cuò)誤三跨線程訪問(wèn)導(dǎo)致句柄失效和程序崩潰場(chǎng)景還原解決了“讀不到”的問(wèn)題后我開(kāi)始把代碼嵌進(jìn)一個(gè)定時(shí)任務(wù)里每隔幾秒去刷新一次資料。問(wèn)題隨之而來(lái)程序跑著跑著突然拋ElementNotAvailableException有時(shí)候干脆連句柄都被判斷成無(wú)效整個(gè)自動(dòng)化線程直接崩潰。我一開(kāi)始以為是自己代碼里資源沒(méi)釋放但排查之后發(fā)現(xiàn)根源是“線程模型”的問(wèn)題。排查過(guò)程UIAutomation的元素引用并不是全局穩(wěn)定的。當(dāng)你持有某個(gè)AutomationElement對(duì)象時(shí)內(nèi)部其實(shí)緩存了對(duì)應(yīng)的原生窗口句柄和運(yùn)行時(shí)標(biāo)識(shí)符。如果被自動(dòng)化程序QQ那邊發(fā)生了界面刷新、頁(yè)面切換、窗口重建你再拿著緩存的元素去調(diào)用它的屬性就會(huì)觸發(fā)ElementNotAvailableException。更麻煩的是COM的多線程模型。Python uiautomation庫(kù)默認(rèn)在調(diào)用線程上初始化COM如果你在后臺(tái)線程里創(chuàng)建自動(dòng)化對(duì)象然后又拿到主線程里去操作或者反過(guò)來(lái)都會(huì)出現(xiàn)RPC失敗、句柄無(wú)效這類玄學(xué)錯(cuò)誤。所以這個(gè)問(wèn)題的核心是跨線程訪問(wèn)了本該單線程使用的COM對(duì)象或者持有了過(guò)期的元素引用卻沒(méi)有重試機(jī)制。修復(fù)方案明確兩條鐵律第一所有UIAutomation調(diào)用放在同一個(gè)線程里最好是主線程或者專門抽出一個(gè)自動(dòng)化線程不要在多個(gè)線程之間來(lái)回傳AutomationElement對(duì)象。第二每次操作前重新獲取元素引用而不是緩存后反復(fù)使用?？梢杂靡粋€(gè)“獲取-操作-釋放”的模式import comtypes def safe_get_window_by_title(title): root auto.GetRootControl() for wnd in root.GetChildren(): if title in (wnd.Name or ): return wnd return None def refresh_profile(keyword): # 每次都重新獲取避免緩存句柄失效 wnd safe_get_window_by_title(keyword) if not wnd: return None try: # 在這里執(zhí)行讀取邏輯不要跨線程 return extract_profile(wnd) except comtypes.COMError: # 句柄失效最多重試三次 return None # 在線程內(nèi)循環(huán)調(diào)用 def worker(): while True: data refresh_profile(目標(biāo)QQ) if data: print(data) time.sleep(5)光這樣還不夠因?yàn)榧词鼓憔€程模型正確QQ的窗口在刷新時(shí)還是可能臨時(shí)失效。所以外層再加一個(gè)重試裝飾器遇到COMError就重新走一遍定位邏輯徹底解決偶發(fā)崩潰問(wèn)題。實(shí)戰(zhàn)心得我發(fā)現(xiàn)有個(gè)更隱蔽的坑是“先最小化窗口再讀取”。QQ資料卡窗口最小化到任務(wù)欄之后UIAutomation依然能找到元素但BoundingRectangle坐標(biāo)會(huì)變成負(fù)數(shù)或者全零導(dǎo)致你拿坐標(biāo)去換算位置時(shí)出錯(cuò)。所以讀取前務(wù)必先把窗口恢復(fù)到正常狀態(tài)或者直接判斷窗口的TransformPattern的CanMinimize/CanMaximize狀態(tài)。4. 問(wèn)題速查表 獨(dú)家避坑心得4.1 常見(jiàn)問(wèn)題五連問(wèn)速查表為了方便你后面快速定位問(wèn)題我把這次實(shí)踐中遇到的癥狀和解決方案整理成了速查表癥狀可能原因快速修復(fù)思路FindAll返回空集合目標(biāo)控件是自繪區(qū)域沒(méi)有暴露標(biāo)準(zhǔn)屬性改用窗口標(biāo)題定位或用坐標(biāo)區(qū)域圈定元素能拿到但Name為空文本屬性沒(méi)暴露或信息尚未加載完成等待輪詢 嘗試LegacyIAccessible運(yùn)行時(shí)頻繁拋ElementNotAvailableException界面刷新導(dǎo)致引用失效每次操作前重新獲取元素加重試機(jī)制跨線程調(diào)用COM異常多線程混用了AutomationElement固定線程模型禁止跨線程傳對(duì)象窗口最小化后坐標(biāo)全亂窗口狀態(tài)影響坐標(biāo)計(jì)算讀取前檢查窗口狀態(tài)并恢復(fù)4.2 我認(rèn)為很值錢的幾條經(jīng)驗(yàn)這次做完我對(duì)Windows自動(dòng)化有了幾個(gè)比較深刻的體會(huì)不一定在官方文檔里能看到但實(shí)戰(zhàn)中真的很救命。第一不要把UIAutomation當(dāng)萬(wàn)能工具。它的設(shè)計(jì)初衷是輔助功能不是爬蟲(chóng)接口。遇到自繪嚴(yán)重的程序覆蓋率就是不到半個(gè)界面。這時(shí)候不要死磕“為什么標(biāo)準(zhǔn)屬性讀不到”而是盡早切換策略比如從讀控件屬性改成讀窗口標(biāo)題、讀剪貼板或者用OCR兜底。方案切換得越早整個(gè)項(xiàng)目的落地時(shí)間就越短。第二Inspect Raw View是你最好的老師。默認(rèn)Standard視圖下很多節(jié)點(diǎn)會(huì)被合并Raw View能讓你看到完整底層結(jié)構(gòu)。所有“為什么找不到元素”的問(wèn)題都應(yīng)該先去Raw View里確認(rèn)元素到底存不存在、屬性到底是什么而不是反復(fù)改代碼里的過(guò)濾條件。第三自動(dòng)化代碼里一定要加“重試上限”。UIAutomation的接口不穩(wěn)定尤其是QQ這種經(jīng)常彈窗、動(dòng)畫、異步加載的軟件任何一步都可能因?yàn)闀r(shí)序問(wèn)題失敗。一個(gè)無(wú)限循環(huán)卡死和一個(gè)帶超時(shí)退出的循環(huán)后者的體驗(yàn)天差地別。我在等待函數(shù)里都會(huì)加timeout參數(shù)默認(rèn)10秒絕不讓程序傻等。第四對(duì)自己正在處理的程序要有敬畏心。我一度想通過(guò)強(qiáng)制向資料卡窗口發(fā)送WM_GETTEXT消息來(lái)讀取文本以為這樣能繞過(guò)控件樹(shù)的限制但對(duì)自繪窗口來(lái)說(shuō)這條路也基本走不通。這種折騰雖然浪費(fèi)了時(shí)間卻讓我更理解Windows消息機(jī)制和自繪窗口的底層邏輯后面排查問(wèn)題時(shí)反而更順了。4.3 后續(xù)還能往哪個(gè)方向擴(kuò)展如果你不滿足于只抓QQ資料其實(shí)這套方法論是可以復(fù)用的。比如同一個(gè)思路下你可以用它去做微信聊天記錄的自動(dòng)化導(dǎo)出前提是對(duì)方或者你本人擁有授權(quán)也可以用來(lái)批量處理企業(yè)微信里的客戶信息臺(tái)賬。凡是基于Chromium內(nèi)核的新版客戶端UIAutomation能暴露出來(lái)的控件樹(shù)結(jié)構(gòu)會(huì)更接近網(wǎng)頁(yè)DOM定位起來(lái)反而更舒服。再深一層你還可以把“窗口定位 坐標(biāo)區(qū)域 OCR兜底”這套組合封裝成一個(gè)通用類輸入任意程序窗口標(biāo)題就能自動(dòng)提取指定區(qū)域的文本。這樣以后再接新需求不需要從零開(kāi)始寫定位邏輯直接調(diào)庫(kù)就行。我個(gè)人在實(shí)際操作中還有一個(gè)體會(huì)UIAutomation本身并不難難的是你要理解每個(gè)Windows程序的界面到底是怎么畫出來(lái)的。標(biāo)準(zhǔn)控件畫出來(lái)的界面它像一本印刷好的書頁(yè)頁(yè)清晰自繪窗口畫出來(lái)的界面更像一張照片你要的信息都混在像素里。做自動(dòng)化的功夫一半在研究工具另一半在研究你要操作的那個(gè)程序。希望這篇文章能幫你少走幾步彎路至少把“元素找不到”“文本讀不到”“跨線程崩潰”這三個(gè)最常見(jiàn)的坎先跨過(guò)去。