在 TSMaster 里寫腳本這件事寫得越深越早晚會(huì)撞上一堵墻手上有一堆現(xiàn)成的 dll里面有算法、有加密、有設(shè)備廠商給的驅(qū)動(dòng)接口可腳本這邊就是夠不著。TSMaster 自帶的腳本 API 覆蓋的是總線收發(fā)、仿真、診斷、標(biāo)定這些常規(guī)動(dòng)作一旦要接第三方庫腳本訪問 dll 就成了繞不開的基本功。這篇按我自己的實(shí)操順序把 Python 腳本、C/C 小程序、C# 小程序三條訪問 dll 的路子從頭捋一遍重點(diǎn)講那些文檔里不寫、但一定會(huì)讓你卡半天的細(xì)節(jié)位數(shù)匹配、調(diào)用約定、依賴鏈、回調(diào)對(duì)象的生命周期、字符串編碼、dll 沖突。不管你是剛裝完 TSMaster 想跑第一個(gè)腳本的新手還是已經(jīng)在做臺(tái)架自動(dòng)化、想把老代碼搬進(jìn)來的老手都能直接抄配置、抄代碼。1. 先想清楚腳本為什么要去訪問 dll1.1 TSMaster 里三個(gè)能寫腳本的入口這三個(gè)入口能碰 dll 的方式完全不同這也是很多人第一次踩坑的根本原因——拿著 Python 的思路去寫 C 小程序或者拿 C 小程序的寫法去套 C#結(jié)果編譯能過、運(yùn)行就崩。Python 腳本是上手最快的入口在腳本編輯器、全局腳本、測(cè)試用例的腳本步驟里都能寫。它的優(yōu)勢(shì)是改一行跑一行不用編譯特別適合算法驗(yàn)證、報(bào)文解析、數(shù)據(jù)后處理這類活兒。它訪問 dll 靠的是 Python 自帶的ctypes模塊本質(zhì)是動(dòng)態(tài)加載 運(yùn)行時(shí)查符號(hào)不需要任何頭文件和 lib 文件。C/C 小程序是編譯型的跑在軟件進(jìn)程內(nèi)部適合高頻、實(shí)時(shí)性要求高、需要貼著底層接口做的場(chǎng)合。TSMaster 的定時(shí)器回調(diào)、報(bào)文事件回調(diào)基本都在這個(gè)小程序里落地。它訪問 dll 走的是標(biāo)準(zhǔn) Windows 的鏈接/加載機(jī)制需要 dll、lib、頭文件三件套齊活。C# 小程序介于兩者之間.NET 生態(tài)里現(xiàn)成的東西拿來就用寫串口、寫數(shù)據(jù)庫、調(diào) HTTP 接口都很舒服。它訪問 dll 靠的是DllImport這個(gè)平臺(tái)調(diào)用特性簽名聲明寫對(duì)了就能直接調(diào)。1.2 什么情況下非碰 dll 不可我把這些年遇到的場(chǎng)景歸成四類基本能覆蓋九成以上的需求。第一類是公司內(nèi)部已有的算法庫比如 CRC 校驗(yàn)、信號(hào)濾波、標(biāo)定算法、故障診斷邏輯這些代碼往往跑了很多年只有 dll 沒有源碼重寫的風(fēng)險(xiǎn)比復(fù)用大得多。第二類是硬件廠商給的接口電源、程控電阻、示波器、數(shù)據(jù)采集卡、加密狗廠商一般只給 dll 加一份頭文件和一份 PDF你沒有別的選擇。第三類是老的測(cè)試代碼本身就是 C/C 寫的邏輯復(fù)雜且經(jīng)過長期驗(yàn)證直接包成 dll 復(fù)用比翻譯成 Python 劃算。第四類是需要被 TSMaster 驅(qū)動(dòng)的 .NET 程序集設(shè)備這時(shí)候 C# 小程序反而是最順的路。1.3 三條路線怎么選選路線的核心判斷依據(jù)只有三個(gè)調(diào)用頻率、實(shí)時(shí)性要求、以及你手上的資源形態(tài)有源碼還是只有 dll。下面這張表是我自己總結(jié)的對(duì)照可以直接照著挑。判斷維度Python ctypesC/C 小程序C# DllImport上手速度最快改完就跑最慢要配工程中等要編譯調(diào)用頻率上限幾千次/秒有解釋器開銷幾十萬次/秒量級(jí)幾萬次/秒量級(jí)實(shí)時(shí)性差有 GC 和解釋器抖動(dòng)最好可控一般需要頭文件/lib不需要需要不需要處理結(jié)構(gòu)體/指針要手寫類型映射直接用要寫封送特性回調(diào)支持可以但有坑最自然可以委托要保引用適合的場(chǎng)景驗(yàn)證、后處理、低頻控制實(shí)時(shí)回調(diào)、高頻算法.NET 生態(tài)集成我的習(xí)慣是先用 Python 把 dll 調(diào)通確認(rèn)導(dǎo)出名、參數(shù)、返回值、編碼全對(duì)再?zèng)Q定要不要搬到 C 小程序。這個(gè)順序能省掉大量時(shí)間因?yàn)?Python 側(cè)報(bào)錯(cuò)清晰、改起來快而 C 小程序一旦加載失敗往往連個(gè)像樣的錯(cuò)誤信息都看不到。2. 動(dòng)手前的三道硬門檻位數(shù)、調(diào)用約定、依賴鏈這三道門檻不跨過去后面寫多少代碼都是白費(fèi)。它們的共同特點(diǎn)是報(bào)錯(cuò)信息極其模糊看起來像是代碼寫錯(cuò)了實(shí)際上是環(huán)境問題。2.1 位數(shù)必須嚴(yán)格對(duì)上現(xiàn)在的 TSMaster 基本是 64 位程序這意味著三件事。Python 腳本跑在 TSMaster 主進(jìn)程里解釋器跟著主進(jìn)程走所以是 64 位C/C 小程序編譯時(shí)必須選 x64 平臺(tái)選了 Win32 會(huì)直接加載失敗C# 小程序要看清目標(biāo)平臺(tái)是 Any CPU 還是 x64Any CPU 在 64 位宿主下會(huì)以 64 位運(yùn)行通常沒問題但如果引用了 32 位的托管程序集就會(huì)炸。典型癥狀是OSError: [WinError 193] %1 不是有效的 Win32 應(yīng)用程序或者 C 小程序加載時(shí)提示模塊無效。這個(gè)錯(cuò)誤碼看著像文件損壞實(shí)際九成是位數(shù)不匹配。怎么確認(rèn)一個(gè) dll 是幾位用 Visual Studio 開發(fā)者命令行的dumpbindumpbin /headers CalcLib.dll | findstr machine輸出8664是 x64輸出14C是 x86。沒有 VS 的話用任意一個(gè) PE 查看工具或依賴分析工具看頭信息也行。提示不要試圖用32 位兼容的思路硬扛。32 位進(jìn)程沒法把 64 位 dll 加載到自己地址空間里跨位調(diào)用只能走進(jìn)程外方案——起一個(gè) 32 位中轉(zhuǎn)進(jìn)程用命名管道或共享內(nèi)存通信。這套東西的成本和復(fù)雜度完全是另一個(gè)量級(jí)除非萬不得已不要碰。2.2 調(diào)用約定stdcall 和 cdecl 差的那一下棧平衡調(diào)用約定說白了就是函數(shù)返回時(shí)誰來清理?xiàng)Ｉ系膮?shù)。Windows API 用的是__stdcall參數(shù)由被調(diào)用方清理很多第三方 C 庫默認(rèn)是__cdecl參數(shù)由調(diào)用方清理。如果調(diào)用方和被調(diào)用方的理解不一致棧指針就會(huì)錯(cuò)位后果是返回值全是垃圾、參數(shù)看起來被吃掉了、或者直接崩潰。Python 側(cè)的區(qū)分方式很直接ctypes.CDLL(path)加載默認(rèn)按cdecl調(diào)用ctypes.WinDLL(path)加載默認(rèn)按stdcall調(diào)用。選錯(cuò)的表現(xiàn)非常典型函數(shù)明明返回 0你拿到的是個(gè)七位數(shù)或者第一次調(diào)用沒事第二次調(diào)用直接進(jìn)程消失。C 小程序側(cè)更嚴(yán)格頭文件里寫的是__stdcall你的聲明就必須寫__stdcall一個(gè)字都不能少。否則編譯鏈接都能過運(yùn)行必崩。怎么確認(rèn)一個(gè) dll 的導(dǎo)出函數(shù)用的哪種約定看導(dǎo)出名的裝飾形式dumpbin /exports CalcLib.dll如果看到_Calc_Add8這種帶字節(jié)數(shù)后綴的是stdcall看到_Calc_Add這種只有前導(dǎo)下劃線的是cdecl如果看到一長串帶?和的亂碼名字那是 C 編譯器做了名稱修飾說明 dll 作者沒加extern C。最后這種情況最麻煩因?yàn)槊謺?huì)隨編譯器版本變化只能靠GetProcAddress拿到修飾名去調(diào)或者找廠商要一個(gè) C 接口的導(dǎo)出。2.3 依賴鏈真正的兇手往往是 dll 自己的 dllWinError 126找不到指定的模塊是最常見的加載失敗。絕大多數(shù)人的第一反應(yīng)是路徑寫錯(cuò)了于是反復(fù)檢查路徑檢查半天沒問題。實(shí)際上八成的 126 不是目標(biāo) dll 不在而是目標(biāo) dll 依賴的某個(gè) dll 不在。常見依賴有三類VC 運(yùn)行庫msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll廠商的底層驅(qū)動(dòng)以及某個(gè)被其他模塊搶先加載的同名不同版本 dll——這就是大家常說的 dll 沖突。排查三板斧按順序來用依賴分析工具打開目標(biāo) dll看哪幾個(gè)節(jié)點(diǎn)標(biāo)紅裝對(duì)應(yīng)版本的 VC 運(yùn)行庫注意要裝x64版裝成 x86 版解決不了問題把目標(biāo) dll 和它所有依賴 dll 全部丟進(jìn)同一個(gè)目錄然后用絕對(duì)路徑加載。關(guān)于 dll 沖突原理值得說清楚Windows 在同一個(gè)進(jìn)程里同名 dll 只會(huì)加載一份。如果某個(gè)模塊先把老版本的xxx.dll加載進(jìn)來了你后面請(qǐng)求加載新版本時(shí)系統(tǒng)發(fā)現(xiàn)這個(gè)名字已經(jīng)加載過了就會(huì)直接把老版本的句柄給你。你調(diào)用的一切都正常但行為就是不對(duì)。規(guī)避辦法有兩個(gè)。C 側(cè)用LoadLibraryEx加LOAD_WITH_ALTERED_SEARCH_PATH標(biāo)志讓系統(tǒng)到 dll 自己所在的目錄去找它的依賴而不是從主程序目錄開始找。Python 側(cè)用os.add_dll_directory()把依賴目錄加進(jìn)搜索路徑這個(gè)在 Python 3.8 之后是必須的因?yàn)槟菚r(shí)起 Windows 上加載 dll 不再默認(rèn)搜 PATH。3. Python 腳本用 ctypes 訪問 dll 全流程Python 是我最推薦的起點(diǎn)因?yàn)樗腻e(cuò)誤反饋?zhàn)钋逦?。這一章按實(shí)際操作順序走一遍。3.1 環(huán)境確認(rèn)與 dll 放置策略第一件事是確認(rèn) TSMaster 內(nèi)置 Python 的版本。在腳本里跑一句import sys print(sys.version)注意內(nèi)置的 Python 環(huán)境只保證標(biāo)準(zhǔn)庫可用numpy、pandas這類第三方包要看你的安裝包版本里帶沒帶。如果你打算在腳本里做大量數(shù)組運(yùn)算先在腳本里import numpy試一下不行就得換個(gè)思路——要么自己在 C 側(cè)把運(yùn)算做完要么用ctypes配合原生數(shù)組手寫循環(huán)。第二件事是 dll 放哪。我的習(xí)慣是在 TSMaster 工程目錄下建一個(gè)libs子目錄把 dll 和它的所有依賴一起丟進(jìn)去然后腳本里用絕對(duì)路徑拼出來。不要依賴系統(tǒng) PATH也不要指望放到主程序目錄就行——那會(huì)污染安裝目錄換個(gè)工程就亂套。import os DLL_DIR rD:\Project\TSMaster\Demo\libs if hasattr(os, add_dll_directory): os.add_dll_directory(DLL_DIR) # Python 3.8 必須 DLL_PATH os.path.join(DLL_DIR, CalcLib.dll)如果你的腳本需要跨機(jī)器部署別把絕對(duì)路徑寫死?？梢宰x一個(gè)同目錄的配置文件或者用工程根目錄加子路徑拼出來。有些執(zhí)行方式下的 TSMaster 腳本拿不到__file__這種時(shí)候老老實(shí)實(shí)從工程配置里讀路徑比猜要靠譜。3.2 參數(shù)類型映射表與結(jié)構(gòu)體對(duì)齊ctypes有一套自己的類型系統(tǒng)和 C 類型不是一一對(duì)應(yīng)。下面這張表是我平時(shí)貼在顯示器邊上的照著填基本不會(huì)錯(cuò)。C 側(cè)聲明ctypes 寫法關(guān)鍵備注intctypes.c_int固定 32 位unsigned intctypes.c_uintshortctypes.c_short16 位unsigned charctypes.c_ubytecharctypes.c_char單字節(jié)字符const char*ctypes.c_char_p傳bytes不是strvoid*ctypes.c_void_p萬能指針float/doublectypes.c_float/c_double別混用BOOLWin32ctypes.c_int4 字節(jié)boolCctypes.c_bool1 字節(jié)和 BOOL 不是一回事unsigned char[N](ctypes.c_ubyte * N)定長數(shù)組struct自定義Structure子類_pack_必須對(duì)齊字符串編碼是另一個(gè)高頻坑。C 側(cè)的char*絕大多數(shù)情況下是 ANSI 編碼在中文 Windows 上就是 GBK而 Python 側(cè)字符串是 Unicode。傳參的時(shí)候要顯式編碼取回來的時(shí)候要顯式解碼name 左前輪速 calc.Calc_SetName.argtypes [ctypes.c_char_p] calc.Calc_SetName.restype ctypes.c_int calc.Calc_SetName(name.encode(gbk))踩過的坑記錄一下有一次我順手寫了encode(utf-8)傳過去 C 側(cè)按 GBK 解結(jié)果所有中文全變亂碼但英文和數(shù)字完全正常排查了半天才想起來是編碼問題。所以規(guī)矩就這么定死——對(duì)外傳參一律 GBK除非頭文件里明確寫了寬字符接口。結(jié)構(gòu)體的對(duì)齊更隱蔽。C 側(cè)結(jié)構(gòu)體如果有#pragma pack(1)Python 側(cè)就必須寫_pack_ 1否則字段偏移會(huì)差幾個(gè)字節(jié)你會(huì)讀到看起來完全隨機(jī)的值。class CanFrame(ctypes.Structure): _pack_ 1 _fields_ [ (id, ctypes.c_uint), (dlc, ctypes.c_ubyte), (data, ctypes.c_ubyte * 8), (timestamp, ctypes.c_ulonglong), ]3.3 一個(gè)能跑通的完整例子假設(shè)廠商給了我們一個(gè)CalcLib.dll導(dǎo)出三個(gè)函數(shù)int Calc_Add(int, int)、int Calc_CRC16(const unsigned char*, int, unsigned short*)、void Calc_SetLogCallback(void(*)(int, const char*))全部是stdcall。完整腳本如下。import ctypes import os DLL_DIR rD:\Project\TSMaster\Demo\libs if hasattr(os, add_dll_directory): os.add_dll_directory(DLL_DIR) DLL_PATH os.path.join(DLL_DIR, CalcLib.dll) # stdcall 用 WinDLL若是 cdecl 則換成 CDLL calc ctypes.WinDLL(DLL_PATH) # 1) 簡單函數(shù) calc.Calc_Add.argtypes [ctypes.c_int, ctypes.c_int] calc.Calc_Add.restype ctypes.c_int print(Calc_Add(3,4) , calc.Calc_Add(3, 4)) # 2) 帶輸出緩沖區(qū)的函數(shù) calc.Calc_CRC16.argtypes [ ctypes.c_void_p, ctypes.c_int, ctypes.POINTER(ctypes.c_ushort), ] calc.Calc_CRC16.restype ctypes.c_int def crc16(data: bytes) - int: buf (ctypes.c_ubyte * len(data)).from_buffer_copy(data) out ctypes.c_ushort(0) rc calc.Calc_CRC16( ctypes.cast(buf, ctypes.c_void_p), len(data), ctypes.byref(out) ) if rc ! 0: raise RuntimeError(Calc_CRC16 failed, rc%d % rc) return out.value print(CRC16 0x%04X % crc16(b\x01\x02\x03\x04\x05\x06\x07\x08))幾個(gè)細(xì)節(jié)值得單獨(dú)說。第一argtypes和restype一定要寫。不寫的話 ctypes 會(huì)按默認(rèn)規(guī)則猜指針會(huì)被截?cái)喑?32 位在 64 位進(jìn)程里直接崩。第二輸出參數(shù)用ctypes.byref(out)比ctypes.pointer(out)更輕量也更快。第三from_buffer_copy會(huì)復(fù)制一份數(shù)據(jù)避免你后續(xù)改動(dòng)原 bytes 影響 dllbytes 本身不可變但換成bytearray時(shí)就有這個(gè)風(fēng)險(xiǎn)了。讀寫一個(gè)結(jié)構(gòu)體數(shù)組也順手給出來做批量報(bào)文處理時(shí)用得上frames (CanFrame * 64)() calc.Calc_ReadFrames.argtypes [ctypes.POINTER(CanFrame), ctypes.c_int] calc.Calc_ReadFrames.restype ctypes.c_int n calc.Calc_ReadFrames(frames, 64) for i in range(n): print(hex(frames[i].id), frames[i].dlc, bytes(frames[i].data[:frames[i].dlc]))3.4 回調(diào)函數(shù)最容易閃退的地方回調(diào)是 Python 調(diào) dll 里最危險(xiǎn)的一環(huán)。寫法本身很簡單CALLBACK ctypes.CFUNCTYPE(None, ctypes.c_int, ctypes.c_char_p) def _on_log(level, msg): text msg.decode(gbk, errorsignore) if msg else print([dll][%d] %s % (level, text)) _cb CALLBACK(_on_log) # 存成模塊級(jí)變量 calc.Calc_SetLogCallback.argtypes [CALLBACK] calc.Calc_SetLogCallback.restype None calc.Calc_SetLogCallback(_cb)大坑在這里如果你偷懶寫成calc.Calc_SetLogCallback(CALLBACK(_on_log))Python 側(cè)沒有任何變量持有這個(gè)回調(diào)對(duì)象垃圾回收一觸發(fā)就把它回收了。dll 下一次回調(diào)時(shí)跳到已經(jīng)釋放的地址整個(gè)進(jìn)程瞬間消失。這種崩潰的惡心之處在于——它不在注冊(cè)的那一刻發(fā)生而是在幾秒或幾十秒之后看起來毫無規(guī)律特別難定位。第二個(gè)要注意的點(diǎn)是線程?；卣{(diào)是在 dll 自己的線程里進(jìn)來的跟你的腳本主線程不是一回事。在回調(diào)里直接動(dòng)手操作 TSMaster 的界面對(duì)象或發(fā)報(bào)文接口很容易出現(xiàn)競(jìng)態(tài)。我的做法是在回調(diào)里只做一件事把數(shù)據(jù)塞進(jìn)一個(gè)線程安全的隊(duì)列然后在腳本的主循環(huán)或定時(shí)器里取出來處理。第三個(gè)點(diǎn)是異常?；卣{(diào)函數(shù)里拋出的 Python 異常不會(huì)優(yōu)雅地傳回 dll跨語言邊界的行為是未定義的。所以回調(diào)體里必須自己包一層try/except出錯(cuò)就記日志絕不讓異常逃出去。4. C/C 小程序直接鏈接 dll 的做法C 小程序的調(diào)用開銷最小實(shí)時(shí)性最好代價(jià)是配置麻煩、出錯(cuò)難查。這一章講配置和兩種調(diào)用方式。4.1 工程配置的三件套與輸出目錄在 TSMaster 里寫 C/C 小程序需要在工程設(shè)置里配好三樣?xùn)|西頭文件搜索路徑、lib 文件搜索路徑、附加依賴項(xiàng)。配完之后編譯鏈接能過但運(yùn)行還會(huì)掛——因?yàn)樾〕绦蚓幾g出來的 dll 是要被主程序加載的它所在的目錄和你配的路徑?jīng)]關(guān)系。關(guān)鍵動(dòng)作是把第三方 dll 復(fù)制到小程序輸出 dll 的同一個(gè)目錄里。如果你在小程序工程設(shè)置里找到了附加依賴項(xiàng)或DLL 搜索路徑這類配置項(xiàng)優(yōu)先用它沒有的話就靠同目錄擺放 絕對(duì)路徑加載兩條腿走路穩(wěn)。還有兩個(gè)編譯選項(xiàng)必須注意。平臺(tái)選x64和 TSMaster 保持一致。運(yùn)行時(shí)庫選/MD多線程 DLL不要選 /MT。原因是 dll 之間的內(nèi)存分配和釋放必須共用同一份 CRT如果你用 /MT第三方 dll 用 /MD就會(huì)出現(xiàn)在我這邊 new、在你那邊 delete的災(zāi)難癥狀是隨機(jī)崩潰或者內(nèi)存泄漏極難查。4.2 隱式調(diào)用與顯式調(diào)用的取舍隱式調(diào)用就是編譯期鏈接代碼干凈#pragma comment(lib, CalcLib.lib) extern C __declspec(dllimport) int __stdcall Calc_Add(int a, int b); void demo_implicit() { int r Calc_Add(3, 4); printf(Calc_Add %d\n, r); }優(yōu)點(diǎn)是寫起來清爽IDE 能補(bǔ)全。缺點(diǎn)也很致命程序啟動(dòng)時(shí)就必須能找到這個(gè) dll找不到的話整個(gè)小程序加載失敗而 TSMaster 那邊給出的提示往往只是一句小程序加載失敗你完全不知道是哪個(gè) dll 的問題。顯式調(diào)用多寫幾行但可控性完全不一樣#include windows.h #include cstdio typedef int (__stdcall *PFN_ADD)(int, int); static PFN_ADD g_pfn_add nullptr; static HMODULE g_hmod nullptr; int ensure_calclib_loaded() { if (g_hmod g_pfn_add) return 0; g_hmod ::LoadLibraryExW( LD:\\Project\\Demo\\libs\\CalcLib.dll, nullptr, LOAD_WITH_ALTERED_SEARCH_PATH); if (!g_hmod) { DWORD err ::GetLastError(); printf([CalcLib] LoadLibrary failed, err%lu\n, err); return (int)err; } g_pfn_add (PFN_ADD)::GetProcAddress(g_hmod, Calc_Add); if (!g_pfn_add) { printf([CalcLib] GetProcAddress failed, err%lu\n, ::GetLastError()); return -1; } return 0; }LOAD_WITH_ALTERED_SEARCH_PATH這個(gè)標(biāo)志的作用前面提過——讓系統(tǒng)從 dll 自己所在的目錄去找它的依賴。當(dāng)你把依賴 dll 全放在libs目錄里時(shí)這個(gè)標(biāo)志幾乎是必須的否則系統(tǒng)會(huì)從主程序目錄開始找找不到就報(bào) 126。我的建議很明確調(diào)試期一律用顯式調(diào)用把所有錯(cuò)誤碼都打出來。等接口穩(wěn)定、部署環(huán)境固定了再?zèng)Q定要不要換成隱式。很多時(shí)候根本換回來——顯式調(diào)用的那點(diǎn)代碼量換來的可診斷性太值了。4.3 在定時(shí)器回調(diào)里調(diào) dll 的注意事項(xiàng)TSMaster 的定時(shí)器回調(diào)跑在實(shí)時(shí)線程上在這個(gè)上下文里調(diào)外部 dll有幾條線不能碰。首先不要在回調(diào)里做大塊內(nèi)存分配、磁盤 IO 或Sleep。這些操作會(huì)阻塞實(shí)時(shí)線程表現(xiàn)出來就是定時(shí)不準(zhǔn)、界面卡頓、報(bào)文丟幀。實(shí)測(cè)過一個(gè)案例dll 單次調(diào)用耗時(shí) 3 毫秒定時(shí)器周期設(shè)成 1 毫秒界面上肉眼可見地卡報(bào)文時(shí)間戳也開始漂。其次一定要搞清楚 dll 是不是線程安全的。很多廠商的 dll 內(nèi)部有全局緩沖區(qū)多個(gè)線程同時(shí)調(diào)用會(huì)互相踩。判斷方法很簡單——看頭文件里有沒有提到線程安全或者不可重入含糊不清的就當(dāng)它不安全處理。做法是自己加一把臨界區(qū)static CRITICAL_SECTION g_cs; static bool g_cs_inited false; int safe_calc_add(int a, int b) { if (!g_cs_inited) { ::InitializeCriticalSection(g_cs); g_cs_inited true; } ::EnterCriticalSection(g_cs); int r g_pfn_add ? g_pfn_add(a, b) : -1; ::LeaveCriticalSection(g_cs); return r; }第三絕對(duì)不要讓 C 異常穿過 dll 邊界。如果你的 dll 和主程序的 CRT 版本不一致異常穿越邊界時(shí)會(huì)直接終止進(jìn)程連日志都沒有。規(guī)矩就是dll 內(nèi)部自己try/catch對(duì)外只返回錯(cuò)誤碼一個(gè)異常都不許漏出來。第四如果你在回調(diào)里同時(shí)用 TSMaster 自身的接口TSApp命名空間那一套和外部 dll功能上沒問題但要注意別在兩邊都做阻塞操作。我一般把外部 dll 的耗時(shí)調(diào)用抽到一個(gè)獨(dú)立工作線程回調(diào)里只投遞任務(wù)這樣實(shí)時(shí)線程永遠(yuǎn)輕裝。5. C# 小程序用 DllImport 引入外部接口C# 小程序的平臺(tái)調(diào)用寫起來最像聲明一下就能用但封送處理有它自己的坑。5.1 簽名聲明與封送處理using System; using System.Runtime.InteropServices; public static class CalcLib { [DllImport(CalcLib.dll, CallingConvention CallingConvention.StdCall, CharSet CharSet.Ansi)] public static extern int Calc_Add(int a, int b); [DllImport(CalcLib.dll, CallingConvention CallingConvention.Cdecl)] public static extern int Calc_CRC16(byte[] data, int len, out ushort crc); }幾個(gè)要點(diǎn)。CallingConvention的默認(rèn)值是StdCall對(duì)應(yīng)Winapi但很多 C 庫是Cdecl必須顯式寫清楚。雖然現(xiàn)在 64 位下 Windows 的調(diào)用約定已經(jīng)統(tǒng)一了寫清楚的好處是將來萬一要切 32 位不會(huì)莫名其妙地崩。out ushort會(huì)被自動(dòng)封送成指針比在 C 里手寫指針舒服得多。結(jié)構(gòu)體要顯式標(biāo)注布局和對(duì)齊[StructLayout(LayoutKind.Sequential, Pack 1)] public struct CanFrame { public uint Id; public byte Dlc; [MarshalAs(UnmanagedType.ByValArray, SizeConst 8)] public byte[] Data; public ulong Timestamp; }Pack要和 C 側(cè)的#pragma pack一致。結(jié)構(gòu)體里有定長字符串時(shí)用[MarshalAs(UnmanagedType.ByValTStr, SizeConst 32)]配CharSet.Ansi能自動(dòng)幫你做 ANSI 和 Unicode 的轉(zhuǎn)換。dll 的加載路徑是另一個(gè)坑。C# 小程序的 dll 搜索路徑和主進(jìn)程有關(guān)最穩(wěn)的辦法是顯式設(shè)置搜索目錄[DllImport(kernel32.dll, CharSet CharSet.Unicode, SetLastError true)] private static extern bool SetDllDirectory(string lpPathName); SetDllDirectory(D:\Project\Demo\libs);不要圖省事把 dll 復(fù)制到 TSMaster 主程序目錄那會(huì)讓安裝目錄越來越亂而且換臺(tái)機(jī)器就失效。5.2 內(nèi)存生命周期與托管對(duì)象釘住數(shù)組傳給非托管代碼時(shí)有個(gè)隱蔽陷阱如果 dll 把這個(gè)指針存起來了、稍后再用那么 GC 一旦壓縮堆數(shù)組就被移動(dòng)了dll 手里那個(gè)指針就變成了野指針。這種場(chǎng)景必須把托管對(duì)象釘住var buffer new byte[4096]; var handle GCHandle.Alloc(buffer, GCHandleType.Pinned); try { IntPtr ptr handle.AddrOfPinnedObject(); // 把 ptr 傳給 dll } finally { handle.Free(); // 必須釋放否則句柄泄漏 }回調(diào)這塊和 Python 是同一類問題。委托必須有人持有引用否則 GC 回收之后非托管側(cè)的回調(diào)就跳飛了。做法是把委托存成靜態(tài)字段或者在調(diào)用完之后加一句GC.KeepAlive(callback)。還有一條規(guī)矩要記牢誰分配的內(nèi)存誰釋放。dll 里分配的內(nèi)存一定要用 dll 自己導(dǎo)出的釋放函數(shù)去釋放絕對(duì)不要在 C# 里調(diào)Marshal.FreeHGlobal去放掉——兩邊的堆管理器不一樣這么干必崩。6. 報(bào)錯(cuò)排查速查表與實(shí)測(cè)踩坑記錄6.1 加載失敗類報(bào)錯(cuò)速查報(bào)錯(cuò)含義最可能的原因處理辦法WinError 126找不到模塊依賴缺失少了 VC 運(yùn)行庫或依賴 dll依賴分析工具查紅色節(jié)點(diǎn)補(bǔ)齊依賴WinError 193不是有效 Win32 程序位數(shù)不匹配64 位宿主加載 32 位 dlldumpbin /headers確認(rèn)位數(shù)WinError 127找不到指定程序?qū)С雒环中揎棥⑵磳戝e(cuò)誤、大小寫dumpbin /exports核對(duì)導(dǎo)出名WinError 1114DLL 初始化例程失敗DllMain 出錯(cuò)dll 在 DllMain 里加載別的 dll 或建線程找廠商確認(rèn)或用顯式延遲加載繞開加載成功但行為不對(duì)dll 沖突同名老版本已被搶先加載絕對(duì)路徑 獨(dú)立目錄隔離WinError 1114這個(gè)特別值得說一句。它出現(xiàn)的時(shí)候通常意味著 dll 的DllMain里干了不該干的事——比如在DLL_PROCESS_ATTACH階段去調(diào)用LoadLibrary加載另一個(gè) dll、創(chuàng)建線程、或者調(diào)用會(huì)阻塞的同步 API。Windows 的加載鎖還在持有狀態(tài)這些操作就會(huì)死鎖或者失敗。如果廠商不給你源碼唯一的辦法是繞開把 dll 的加載推遲到實(shí)際調(diào)用的時(shí)候顯式LoadLibrary而不是在進(jìn)程啟動(dòng)階段就讓它被隱式加載。6.2 調(diào)用即崩潰類問題調(diào)用一次就崩和調(diào)用兩次才崩是兩種完全不同的問題不要混在一起查。調(diào)用一次就崩八成是參數(shù)類型或調(diào)用約定錯(cuò)了。檢查順序先確認(rèn)stdcall還是cdecl再確認(rèn)參數(shù)寬度int和long在 64 位下都是 4 字節(jié)但size_t是 8 字節(jié)unsigned long在 Windows 上也是 4 字節(jié)unsigned long long是 8 字節(jié)最后確認(rèn)結(jié)構(gòu)體對(duì)齊。Python 側(cè)特別容易犯的錯(cuò)是沒寫argtypes導(dǎo)致指針被當(dāng)成int截?cái)唷Ｕ{(diào)用兩次才崩基本就是回調(diào)對(duì)象被 GC 回收了或者某個(gè)緩沖區(qū)被寫越界、破壞了相鄰內(nèi)存?；卣{(diào)的問題前面講過了解決辦法就是把回調(diào)對(duì)象存成長生命周期變量。緩沖區(qū)越界的問題可以在 Python 側(cè)把緩沖區(qū)開大一圈前后各留 32 字節(jié)的哨兵調(diào)完之后檢查哨兵有沒有被改寫能快速判斷是不是越界寫。6.3 結(jié)果不對(duì)但不崩的問題這一類最難查因?yàn)闆]有任何報(bào)錯(cuò)。常見的三種情況我按出現(xiàn)頻率排一下。排第一的是字符串編碼。前面說過char*在中文 Windows 上基本都是 GBK你按 UTF-8 編過去就會(huì)亂碼。排查辦法很簡單——傳一個(gè)純英文串過去如果正常基本就是編碼問題。排第二的是結(jié)構(gòu)體對(duì)齊。C 側(cè)用了#pragma pack(1)Python 側(cè)沒寫_pack_ 1字段偏移全錯(cuò)你會(huì)看到 ID 和 DLC 好像對(duì)得上但時(shí)間戳完全離譜。這種部分字段正確的現(xiàn)象是對(duì)齊問題的典型特征。排第三的是返回值語義理解錯(cuò)了。有些 dll 返回的是實(shí)際寫入的字節(jié)數(shù)有些返回的是錯(cuò)誤碼有些返回 0 表示成功、有些返回 0 表示失敗。這種事只能翻文檔或者做實(shí)驗(yàn)確認(rèn)——給一組已知輸入看返回值是不是符合你的預(yù)期。6.4 一套固定的排查流程踩了足夠多次之后我固化下來一套排查順序從下往上打基本能在二十分鐘內(nèi)定位到問題用dumpbin /headers確認(rèn)位數(shù)和宿主進(jìn)程一致用dumpbin /exports把導(dǎo)出名原樣抄下來別憑記憶拼用依賴分析工具打開 dll把紅色節(jié)點(diǎn)全部解決掉改成絕對(duì)路徑加載加上LOAD_WITH_ALTERED_SEARCH_PATH先在 Python 里最小化復(fù)現(xiàn)把參數(shù)、返回值、編碼全部驗(yàn)證正確再把驗(yàn)證過的調(diào)用原樣搬到 C 小程序或 C#全程打日志——加載結(jié)果、每次調(diào)用的參數(shù)和返回值、錯(cuò)誤碼一個(gè)都不省。第 5 步是我最想強(qiáng)調(diào)的。很多人上來就在 C 小程序里硬剛編譯半天加載失敗只會(huì)給一句模糊提示來回折騰幾個(gè)小時(shí)。同樣的邏輯用 Python 寫十行代碼報(bào)錯(cuò)清清楚楚十幾分鐘就能確認(rèn) dll 本身有沒有問題。確認(rèn)沒問題了再搬效率差好幾倍。7. 一些不成體系但很值錢的經(jīng)驗(yàn)cts里加載 dll 的時(shí)候WinDLL和CDLL的選擇可以現(xiàn)場(chǎng)驗(yàn)證。如果你不確定調(diào)用約定可以兩個(gè)都試一次哪個(gè)不崩就是哪個(gè)——這個(gè)方法土但有效前提是崩的是 Python 進(jìn)程而不是整個(gè) TSMaster。所以務(wù)必先在獨(dú)立的 Python 環(huán)境里做這個(gè)實(shí)驗(yàn)別在 TSMaster 里試。dll 目錄隔離這件事我的做法是每個(gè)第三方庫單獨(dú)一個(gè)子目錄目錄名帶上版本號(hào)。這樣做的直接好處是同名不同版本的 dll 永遠(yuǎn)不會(huì)互相干擾出問題的時(shí)候也知道該退回到哪個(gè)版本。代價(jià)是磁盤上多幾份文件這個(gè)代價(jià)值得付。關(guān)于調(diào)試有個(gè)小技巧特別管用在 Python 側(cè)寫一個(gè)probe.py腳本內(nèi)容就是把 dll 加載一遍、把每個(gè)導(dǎo)出符號(hào)打印出來、用一組固定輸入跑一遍調(diào)用。換機(jī)器、換版本、換編譯器的時(shí)候先跑這個(gè)腳本二十秒就能判斷環(huán)境是不是健康的。這個(gè)腳本我改過七八個(gè)版本現(xiàn)在是每次接手新 dll 的第一件事。最后一個(gè)經(jīng)驗(yàn)是關(guān)于文檔的。廠商給的 PDF 里參數(shù)表和返回值說明通常寫得像謎語。真正靠譜的做法是拿 dll 去打邊界值——傳 0、傳負(fù)數(shù)、傳超大值看它返回什么、會(huì)不會(huì)崩。打完之后你對(duì)這個(gè) dll 的脾氣就有底了比讀十頁文檔管用。當(dāng)然這個(gè)實(shí)驗(yàn)必須在隔離的 Python 環(huán)境里做崩了也不影響 TSMaster 主進(jìn)程。