托盤圖標(biāo)出現(xiàn)在任務(wù)欄右下角右鍵菜單響應(yīng)正常雙擊也能喚出主窗口唯獨調(diào)Shell_NotifyIcon發(fā)出去的那個氣球通知屏幕上一點動靜都沒有——而且返回值還是TRUE。這個現(xiàn)象我前后遇到過三四回每次根因都不一樣有一次是uFlags漏了NIF_INFO有一次是程序被改成后臺常駐方式導(dǎo)致圖標(biāo)壓根沒掛到 explorer 上還有一次是測試機上把通知和操作的總開關(guān)關(guān)掉了。所以看到氣球通知無效這種描述先別急著翻代碼得先把無效這兩個字拆開判斷它到底屬于哪一類。這篇是寫給正在做 Windows 桌面端常駐托盤程序的人看的以 CWin32為主順帶把 C#WinForms和 WPF 封裝層上的等價坑一起擺出來。讀完至少能做到兩件事一是清楚Shell_NotifyIcon發(fā)氣泡時到底是哪幾個字段在起作用二是手上有一套能自己往下查的鏈路而不是對著屏幕干瞪眼改參數(shù)。氣球通知這東西看著只有幾行 API實際上牽扯到結(jié)構(gòu)體版本、字符集、窗口消息循環(huán)、系統(tǒng)通知策略、會話隔離五個層面任何一層出問題表現(xiàn)都是沒反應(yīng)所以分層定位比試錯重要得多。1. 三種不彈故障點完全不同1.1 圖標(biāo)壓根沒進(jìn)托盤區(qū)這是最容易被跳過的一步。很多人在排查氣泡的時候默認(rèn)圖標(biāo)都在那兒了肯定是氣泡的問題但實際情況里圖標(biāo)顯示正常并不代表NIM_ADD成功過——有一種情況是圖標(biāo)顯示出來了但那是上一次進(jìn)程殘留的僵尸圖標(biāo)鼠標(biāo)劃過就消失點它也沒反應(yīng)。真正判斷圖標(biāo)是否屬于當(dāng)前進(jìn)程最簡單的辦法是把鼠標(biāo)懸停在圖標(biāo)上看szTip里設(shè)置的提示文字有沒有出現(xiàn)如果提示文字是空白的或者顯示的是別的程序的文字那基本可以確定當(dāng)前進(jìn)程根本沒加上圖標(biāo)氣泡自然無從談起。NIM_ADD失敗的原因里hIcon為空是最常見的一個。Win32 里常見寫法是先LoadIcon或者LoadImage拿一個HICON再填進(jìn)nid.hIcon。這里有個真實存在的坑如果這個HICON是通過CreateIconIndirect、CopyIcon這類函數(shù)動態(tài)生成的而代碼里又在NIM_ADD之后順手調(diào)了DestroyIcon托盤圖標(biāo)會立刻變成一塊空白或者花屏。原因是 shell 并沒有把圖標(biāo)數(shù)據(jù)拷貝走它只是持有了這個句柄你銷毀了它那邊就指向了一塊已經(jīng)失效的內(nèi)存。正確的釋放時機是NIM_DELETE之后再DestroyIcon順序不能反。還有一種更隱蔽的程序被注冊成了服務(wù)或者用計劃任務(wù)以不管用戶是否登錄都運行的方式啟動。這種進(jìn)程運行在會話 0Session 0而會話 0 是沒有交互式桌面的Shell_NotifyIcon可能返回成功圖標(biāo)卻永遠(yuǎn)不可能出現(xiàn)在用戶眼前。判斷方法很簡單任務(wù)管理器里看這個進(jìn)程屬于哪個會話如果不是當(dāng)前登錄用戶的會話號那所有 UI 相關(guān)的 API 都是白搭。另外提一句Windows 11 的托盤區(qū)把默認(rèn)圖標(biāo)折疊進(jìn)了溢出面板用戶不點開小箭頭是看不到的。這不是故障但排查時容易被誤判成圖標(biāo)沒加進(jìn)去先確認(rèn)一下托盤設(shè)置里的隱藏的圖標(biāo)菜單。1.2 圖標(biāo)在氣泡死活不出來這一類才是標(biāo)題里說的情況。此時NIM_ADD是成功的szTip能正常顯示右鍵菜單也能彈唯獨氣泡不出來。常見原因按出現(xiàn)頻率排下來大概是uFlags沒帶NIF_INFO、NIM_MODIFY之前圖標(biāo)狀態(tài)已經(jīng)丟了、szInfo為空字符串、系統(tǒng)通知開關(guān)被關(guān)閉、發(fā)送氣泡時消息循環(huán)處于阻塞狀態(tài)。uFlags這個問題我在代碼評審里見過不止一次。有人寫了一個UpdateTrayIcon()函數(shù)把NIF_ICON | NIF_MESSAGE | NIF_TIP全填上然后在這個函數(shù)末尾順手填了szInfo和szInfoTitle以為這樣氣泡就會跟著圖標(biāo)一起更新。實際上Shell_NotifyIcon是嚴(yán)格按uFlags位掩碼來決定讀哪些字段的沒置NIF_INFO位szInfo那一段內(nèi)存它連看都不看。同理dwInfoFlags的圖標(biāo)類型、NIIF_NOSOUND這類標(biāo)志也都只在NIF_INFO置位時才生效。還有一種是先刪后沒加。某些程序在響應(yīng)WM_ENDSESSION或者顯示器的WM_DISPLAYCHANGE時會先NIM_DELETE再重新NIM_ADD如果中間某次NIM_ADD因為窗口句柄無效而失敗后續(xù)的NIM_MODIFY就會一直返回失敗氣泡當(dāng)然也發(fā)不出來。所以我習(xí)慣把是否已添加做成一個顯式的狀態(tài)位任何一次NIM_ADD失敗都要記錄下來后續(xù)發(fā)氣泡前先檢查這個狀態(tài)。1.3 氣泡彈了但標(biāo)題是空的或者全是亂碼嚴(yán)格來說這不算無效但它經(jīng)常和無效混為一談因為用戶看到一片方塊或者空白會直接反饋通知沒顯示。亂碼的根因幾乎只有一個結(jié)構(gòu)體用了 ANSI 版本而字符串傳的是寬字符或者反過來。NOTIFYICONDATA在 SDK 頭文件里是通過UNICODE宏展開成NOTIFYICONDATAW或NOTIFYICONDATAA的如果工程屬性里的字符集是使用多字節(jié)字符集而你代碼里寫的是L...編譯器要么報錯要么悄悄截斷最終szInfo里只有一個字符加個結(jié)尾。這個坑在遷移老項目時特別容易踩到。老工程當(dāng)年是 MBCS后來為了支持多語言整體改成 Unicode結(jié)果某個自己封裝的托盤類里還留著char緩沖區(qū)和新結(jié)構(gòu)體拼接編譯能過跑起來就是亂碼。定位辦法是直接看sizeof(NOTIFYICONDATA)的值Unicode 版本在 x64 下大概是 976 字節(jié)這個量級如果在調(diào)試器里看到cbSize明顯偏小那基本就是字符集或者結(jié)構(gòu)體定義對不上。2. NOTIFYICONDATA 里決定氣泡生死的字段2.1 uFlags、szInfo、szInfoTitle 三者的聯(lián)動關(guān)系先把一段能用的代碼擺出來后面所有的討論都圍繞它展開。下面這段是添加圖標(biāo)的初始化注意uFlags里沒有NIF_INFO因為添加階段不需要氣泡NOTIFYICONDATA nid { 0 }; nid.cbSize sizeof(NOTIFYICONDATA); nid.hWnd hMainWnd; nid.uID IDI_TRAY; nid.uFlags NIF_ICON | NIF_MESSAGE | NIF_TIP; nid.uCallbackMessage WM_TRAY_CALLBACK; nid.hIcon hTrayIcon; StringCchCopy(nid.szTip, ARRAYSIZE(nid.szTip), L常駐托盤工具); if (!Shell_NotifyIcon(NIM_ADD, nid)) { // 這里一定要留日志后面排查全靠它 }發(fā)氣泡是另一段獨立邏輯uFlags只保留NIF_INFObool ShowBalloon(HWND hWnd, UINT id, const wchar_t* title, const wchar_t* text, DWORD infoFlags) { NOTIFYICONDATA nid { 0 }; nid.cbSize sizeof(NOTIFYICONDATA); nid.hWnd hWnd; nid.uID id; nid.uFlags NIF_INFO; nid.dwInfoFlags infoFlags; StringCchCopy(nid.szInfoTitle, ARRAYSIZE(nid.szInfoTitle), title); StringCchCopy(nid.szInfo, ARRAYSIZE(nid.szInfo), text); return Shell_NotifyIcon(NIM_MODIFY, nid) ! FALSE; }這里有兩個細(xì)節(jié)值得說。第一NIM_MODIFY階段uFlags只寫NIF_INFO是完全正確的語義是這次我只改氣泡部分其它字段別動不需要把NIF_ICON再寫一遍。第二szInfo傳空字符串注意不是空指針是長度為 0 的字符串的語義是移除當(dāng)前顯示的氣泡不是什么都不做。有些代碼在錯誤分支里填了個空字符串當(dāng)兜底結(jié)果就是看起來什么都沒發(fā)生。字段長度也有硬上限szInfo是 256 個WCHARszInfoTitle是 64 個WCHAR都包含結(jié)尾的空字符。超長會被截斷用StringCchCopy這類安全函數(shù)能保證不出界但內(nèi)容確實會丟。我見過標(biāo)題寫了一長串路徑導(dǎo)致后面全被切掉的看起來像標(biāo)題顯示不全其實是長度超限。2.2 cbSize、uVersion 與那個共用體的歷史包袱cbSize是所有NOTIFYICONDATA故障里最隱蔽的一個。這個字段的用途是讓 shell 知道調(diào)用方用的是哪個版本的結(jié)構(gòu)體因為從 Windows 2000 到現(xiàn)在這個結(jié)構(gòu)體加過好幾輪字段。寫sizeof(NOTIFYICONDATA)在正常情況下永遠(yuǎn)是對的問題出在兩種場景一是工程引用了很老的第三方 SDK 頭文件結(jié)構(gòu)體定義本身就缺字段sizeof算出來偏小二是用 C# 或其它語言手工定義StructLayout時字段漏了或者順序錯了。第二種場景我踩過。C# 里為了不依賴 WinForms 的NotifyIcon有人會自己DllImport一個Shell_NotifyIcon然后手寫一個NOTIFYICONDATA結(jié)構(gòu)體。少寫一個guidItem或者把uTimeout的位置寫錯編譯一點問題沒有運行起來cbSize對不上NIM_ADD直接返回FALSE。這種情況在調(diào)試器里看一眼cbSize和預(yù)期值差多少基本就能定位。再說uVersion。NOTIFYICONDATA里uTimeout和uVersion是共用同一塊內(nèi)存的union { UINT uTimeout; UINT uVersion; };也就是說你不能在同一次調(diào)用里既設(shè)超時又設(shè)版本號。設(shè)置版本要用NIM_SETVERSION把uVersion填成NOTIFYICON_VERSION_4這個動作會改變后續(xù)回調(diào)消息的編碼方式——lParam的低字是消息 ID高字是圖標(biāo) ID。很多人加了NIM_SETVERSION之后發(fā)現(xiàn)右鍵菜單不彈了就是因為回調(diào)處理還在按老格式解析lParam。所以這條命令不是加了更好而是加了就得改回調(diào)。NOTIFYICON_VERSION_4還有另一個副作用uTimeout被徹底忽略氣泡停留時長完全由系統(tǒng)的輔助功能設(shè)置決定。如果你有代碼依賴精確控制氣泡顯示 3 秒還是 10 秒那在 v4 下是做不到的。2.3 dwInfoFlags 里幾個會反向生效的標(biāo)志dwInfoFlags決定氣泡左側(cè)那個小圖標(biāo)的樣式常見取值是NIIF_NONE、NIIF_INFO、NIIF_WARNING、NIIF_ERROR、NIIF_USER。前四個都是系統(tǒng)內(nèi)置圖標(biāo)直接寫就行NIIF_USER則需要額外配合hBalloonIcon字段。這里有個真實的坑NIIF_USER置位但hBalloonIcon留空時不同 Windows 版本的處理不一致有的版本回退到hIcon有的版本干脆畫一個默認(rèn)圖標(biāo)還有的版本會導(dǎo)致整個氣泡不顯示。我現(xiàn)在的做法是要么不用NIIF_USER用就老老實實把hBalloonIcon填上別指望系統(tǒng)幫你兜底。另一個有意思的標(biāo)志是NIIF_RESPECT_QUIET_TIMEWindows 7 引入的。置位之后如果系統(tǒng)處于安靜時間現(xiàn)在叫專注助手這條氣泡會被直接丟棄不是延遲顯示是丟棄。這個標(biāo)志的設(shè)計初衷是尊重用戶不想被打擾的意愿但如果你的程序發(fā)的是關(guān)鍵提醒置了這個位就等于主動放棄了顯示機會。反過來如果你不置這個位系統(tǒng)在某些版本上仍然會按全局策略抑制橫幅——這一點各版本行為不完全一致所以不要用它來做能不能顯示的開關(guān)。NIIF_NOSOUND相對簡單加上就不響提示音。有個細(xì)節(jié)是它不影響氣泡本身的顯示只影響聲音所以別把它和靜音模式下氣泡不顯示混為一談。3. 代碼沒問題但屏幕沒反應(yīng)系統(tǒng)層攔在哪3.1 通知總開關(guān)、專注助手與安靜時間這是排查時最容易漏掉的一層因為它不在你的代碼里而在用戶的機器上。Windows 10 之后系統(tǒng)設(shè)置里有一個通知和操作的總開關(guān)關(guān)掉之后所有應(yīng)用的通知全部靜默下面還有按應(yīng)用細(xì)分的開關(guān)以及專注助手的幾種模式關(guān)閉、僅優(yōu)先通知、僅鬧鐘。Shell_NotifyIcon發(fā)出的氣泡在 Windows 8 之后已經(jīng)被系統(tǒng)當(dāng)作通知來管理了所以它會完整地受這些開關(guān)影響。表現(xiàn)是Shell_NotifyIcon返回TRUE氣泡不出現(xiàn)通知中心里也找不到。這種情況你改一萬行代碼都沒用。排查手段是讓測試機恢復(fù)到默認(rèn)狀態(tài)通知總開關(guān)打開、專注助手關(guān)閉、當(dāng)前應(yīng)用在通知列表里處于允許狀態(tài)。還有一點如果程序以管理員權(quán)限運行而系統(tǒng)設(shè)置里的通知是按應(yīng)用配置的某些版本下管理員進(jìn)程的通知配置和普通進(jìn)程不是同一份表現(xiàn)就是普通權(quán)限下能彈、提權(quán)后不彈。這個差異在不同系統(tǒng)版本上表現(xiàn)不一致我的做法是測試矩陣?yán)锕潭ò胀?quán)限和管理員權(quán)限兩行別只測一種。老系統(tǒng)上還有一個注冊表開關(guān)HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced下的EnableBalloonTips值為 0 時禁用氣球提示。這個鍵在新系統(tǒng)上是否仍然生效取決于版本但在 Windows 7 時代它是標(biāo)準(zhǔn)的關(guān)閉方式排查老環(huán)境時值得看一眼。組策略里也有對應(yīng)的關(guān)閉通知氣球提示項域環(huán)境下的機器可能被統(tǒng)一下發(fā)。3.2 會話與用戶身份Session 0 和 RunAs 的死角前面提過會話 0 的問題這里展開說。Windows 的服務(wù)宿主機制決定了服務(wù)進(jìn)程運行在會話 0那是一個沒有交互式桌面的獨立會話。任何在會話 0 里調(diào)用的 UI 相關(guān) API包括Shell_NotifyIcon、MessageBox、CreateWindow要么失敗要么創(chuàng)建一個用戶永遠(yuǎn)看不到的窗口。這個問題在實際項目里通常表現(xiàn)為開發(fā)機上好好的裝到客戶機上就沒通知。區(qū)別在于開發(fā)機是雙擊 exe 運行的客戶機上是通過服務(wù)或者計劃任務(wù)啟動的。定位方法是在任務(wù)管理器里加一列會話 ID看進(jìn)程對應(yīng)的數(shù)字是不是和當(dāng)前登錄用戶一致。如果不一致那問題不在代碼在于部署方式——要么改成用戶登錄后自啟動要么用會話隔離機制把 UI 部分拆成一個運行在用戶會話里的獨立進(jìn)程。還有一種情況是以另一個用戶身份運行比如右鍵以其他用戶身份運行或者用憑據(jù)管理器啟動。這時圖標(biāo)會加到那個用戶的托盤里當(dāng)前登錄用戶看不到但那個用戶如果同時在線快速用戶切換在他自己的桌面里是能看到圖標(biāo)的。現(xiàn)象就是我這邊沒圖標(biāo)但換個賬號登錄就有了很容易被誤判成偶發(fā) bug。3.3 Windows 8 之后氣球改頭換面成 Toast這條屬于知道就行不知道會繞遠(yuǎn)路的范疇。從 Windows 8 開始Shell_NotifyIcon發(fā)出的氣球通知在視覺上已經(jīng)變成了 toast 樣式——從屏幕右下角滑入、停留幾秒、然后收進(jìn)通知中心。接口沒變樣式變了。這個變化帶來兩個實際影響。第一通知中心會成為這些氣泡的歸檔地用戶在通知中心里能看到歷史消息這意味著重復(fù)發(fā)同一條消息的行為和老系統(tǒng)不一樣了老系統(tǒng)上重復(fù)發(fā)會不斷彈新的新系統(tǒng)上可能出現(xiàn)合并或者覆蓋。第二某些系統(tǒng)版本上如果程序沒有設(shè)置AppUserModelID通知在系統(tǒng)里的歸屬會是一個默認(rèn)的宿主表現(xiàn)是通知列表里看不到你的應(yīng)用名用戶在設(shè)置里想允許你的通知都找不到對應(yīng)條目。設(shè)置AppUserModelID的 API 是SetCurrentProcessExplicitAppUserModelID在進(jìn)程啟動早期調(diào)用。如果對通知的可靠性要求比較高其實可以考慮直接走 Toast 通知那套接口代價是需要注冊快捷方式、需要處理激活回調(diào)工程復(fù)雜度上一個臺階。托盤氣球勝在簡單二十行代碼就能跑Toast 勝在可控能拿到點擊、能進(jìn)通知中心歸檔、能被用戶精細(xì)管理。選哪個取決于你的通知是順手提示一下還是業(yè)務(wù)流程的一環(huán)。4. 一條能自己走完的排查鏈路4.1 用三十行最小工程把業(yè)務(wù)代碼摘出去我處理這類問題的固定第一步是新建一個空的 Win32 工程只保留一個隱藏主窗口、一個托盤圖標(biāo)、一個定時器定時器每三秒發(fā)一次氣泡。這個工程大概三十行寫完不超過十分鐘。之所以要先做這一步是因為在真實項目里氣泡不顯示可能是業(yè)務(wù)邏輯、線程調(diào)度、窗口生命周期三者疊加出來的你直接在里面改參數(shù)改一次跑一次變量太多判斷不了哪個改動起了作用。最小工程的骨架大致是這樣LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_CREATE: AddTrayIcon(hWnd); SetTimer(hWnd, TIMER_BALLOON, 3000, nullptr); return 0; case WM_TIMER: if (wParam TIMER_BALLOON) { ShowBalloon(hWnd, IDI_TRAY, L測試標(biāo)題, L這是一條測試氣泡, NIIF_INFO); } return 0; case WM_DESTROY: RemoveTrayIcon(hWnd); PostQuitMessage(0); return 0; } return DefWindowProc(hWnd, msg, wParam, lParam); }如果這個最小工程能彈氣泡說明 API 用法和系統(tǒng)環(huán)境都沒問題問題在你的業(yè)務(wù)代碼里如果彈不出來說明問題在環(huán)境或者調(diào)用方式上接下來往系統(tǒng)層查。這一步能省掉一半的排查時間。4.2 返回值、窗口消息、監(jiān)視工具三處取證最小工程也不彈的時候取證要分三路走。第一路看返回值。Shell_NotifyIcon返回FALSE說明 shell 明確拒絕了這時基本可以鎖定字段錯誤cbSize不對、hWnd無效、uID沖突。返回TRUE但無顯示說明接收端沒問題問題在展示端系統(tǒng)策略、會話、桌面可見性。這兩條分支的排查方向完全相反所以返回值必須看。第二路看窗口消息。如果要做氣泡點擊響應(yīng)uCallbackMessage指定的消息會在氣泡被點擊時發(fā)到你的窗口。用一個能抓窗口消息的工具掛在目標(biāo)窗口上觀察發(fā)氣泡前后有沒有WM_USER范圍內(nèi)的消息流動。這一步主要是確認(rèn) shell 到底有沒有收到請求。第三路看系統(tǒng)狀態(tài)。通知設(shè)置、專注助手、會話 ID、是否提權(quán)這四項各花一分鐘確認(rèn)比讀一天文檔有用。我現(xiàn)在的習(xí)慣是在程序的關(guān)于頁面里放一個隱藏的診斷入口一鍵打印這幾項狀態(tài)客戶反饋問題時讓他截個圖能省掉好幾輪來回?，F(xiàn)象優(yōu)先懷疑驗證方式NIM_ADD返回 FALSEcbSize、hIcon為空、窗口句柄無效調(diào)試器里看cbSize與sizeof是否一致圖標(biāo)在氣泡無返回值 TRUEuFlags漏NIF_INFO斷點檢查發(fā)送時的uFlags值圖標(biāo)不在氣泡無會話 0、圖標(biāo)句柄被提前釋放任務(wù)管理器看會話 ID檢查DestroyIcon時機氣泡出但標(biāo)題空白字符集不匹配看sizeof(NOTIFYICONDATA)與工程字符集設(shè)置時好時壞消息循環(huán)被阻塞、定時器被搶占檢查主線程是否有長耗時同步操作特定機器必現(xiàn)通知開關(guān)、專注助手、組策略重置通知設(shè)置為默認(rèn)后復(fù)測4.3 把什么時候不彈記錄成日志這一點聽起來平淡但它決定了后續(xù)排查是幾天還是幾小時。我在托盤模塊里加了一組固定的日志點NIM_ADD的結(jié)果、NIM_DELETE的結(jié)果、每次發(fā)氣泡前的uFlags和dwInfoFlags值、發(fā)氣泡的返回值、當(dāng)前進(jìn)程的會話 ID 和是否提權(quán)。這些信息加起來不到二十行代碼但客戶現(xiàn)場出問題時看一眼日志就能把范圍縮小到一兩個方向。有個細(xì)節(jié)日志里不要把szInfo全文打進(jìn)去用戶數(shù)據(jù)可能很長也可能包含不該落盤的內(nèi)容打個長度和標(biāo)題就夠了。5. 托管封裝層WinForms 與 WPF 的等價坑5.1 NotifyIcon.ShowBalloonTip 的前置條件C# 的 WinForms 里NotifyIcon類把Shell_NotifyIcon包了一層接口看著簡單坑一樣不少。ShowBalloonTip(int timeout)要能生效至少得滿足三個條件Visible為true、Icon不為null、圖標(biāo)已經(jīng)被系統(tǒng)接受。第一個條件是硬性的Visible false時調(diào)ShowBalloonTip不拋異常也不顯示最容易漏。第二個條件很多人以為只要給Icon賦值就行實際上如果你是從資源文件動態(tài)加載圖標(biāo)流用完順手把StreamDispose掉了Icon對象的內(nèi)部句柄可能已經(jīng)失效表現(xiàn)就是托盤圖標(biāo)顯示成一塊空白氣泡也跟著不顯示。第三個條件在窗體生命周期早期容易出問題。在Form_Load里立刻調(diào)ShowBalloonTip有些機器上不生效因為這時窗口句柄剛創(chuàng)建托盤圖標(biāo)還沒真正掛上去。穩(wěn)妥做法是Load之后用BeginInvoke推遲到消息隊列下一輪再調(diào)或者在Shown事件里調(diào)。timeout參數(shù)在 Vista 之后基本被忽略了實際時長由系統(tǒng)的輔助功能設(shè)置決定。這一點和老系統(tǒng)不一樣如果產(chǎn)品文檔里寫了氣泡顯示 5 秒最好改成約 5 秒實際由系統(tǒng)設(shè)置決定免得后面被當(dāng)成 bug 提。5.2 消息泵被堵住時氣泡會遲到Shell_NotifyIcon內(nèi)部是通過窗口消息和任務(wù)欄通信的這意味著它依賴調(diào)用線程的消息循環(huán)。如果主線程正在跑一個長耗時同步任務(wù)比如讀一個大文件、等一個網(wǎng)絡(luò)請求、跑一段密集計算那么即使你在另一個線程里調(diào)ShowBalloonTip調(diào)用也可能被卡住直到主線程的消息泵重新轉(zhuǎn)起來?，F(xiàn)象很有迷惑性日志顯示已發(fā)送氣泡但用戶是在幾秒甚至幾十秒之后才看到或者干脆看不到因為已經(jīng)過了時效。這類問題在后臺任務(wù)完成時彈通知的場景里特別常見因為后臺任務(wù)完成的時刻主線程往往正在刷新界面。處理辦法是有的把耗時任務(wù)放到后臺線程主線程只負(fù)責(zé) UI或者在不依賴NotifyIcon對象的場景下用一個獨立的隱藏窗口在自己的線程里跑消息循環(huán)來處理托盤消息。后者工程量大些但如果托盤邏輯要脫離主窗口獨立存活比如主窗口可以關(guān)閉但程序不退出這個結(jié)構(gòu)反而更清晰。WPF 這邊沒有內(nèi)置的托盤圖標(biāo)控件社區(qū)里常見的做法是引用 WinForms 的NotifyIcon或者用第三方庫。第三方庫如果自己實現(xiàn)了Shell_NotifyIcon的互操作那前面說的cbSize、uFlags、字符集三件事依然適用換語言不換原理。選庫的時候可以看一眼它有沒有處理NOTIFYICON_VERSION_4沒處理的話右鍵菜單的坐標(biāo)計算在某些機器上會偏。6. 把這套東西做成不容易再出問題的結(jié)構(gòu)6.1 用一個帶狀態(tài)位的發(fā)送函數(shù)收口在項目里我最后的做法是把托盤的添加刪除發(fā)氣泡三個動作集中在一個小模塊里模塊內(nèi)部維護一個bool added狀態(tài)位任何一次NIM_ADD成功才置位NIM_DELETE后清零。發(fā)氣泡的入口函數(shù)第一件事就是檢查這個狀態(tài)位沒置位就先嘗試添加一次。這樣不管上層怎么調(diào)用都不會出現(xiàn)圖標(biāo)沒了還在發(fā)氣泡的靜默失敗。同時這個模塊對外只暴露一個ShowBalloon(title, text, level)函數(shù)level是個枚舉映射到NIIF_INFO、NIIF_WARNING、NIIF_ERROR。這樣上層不需要知道dwInfoFlags的存在后面如果要換實現(xiàn)比如換成 Toast 通知改動面只在一個文件里。還有一個小設(shè)計發(fā)氣泡函數(shù)返回一個枚舉區(qū)分發(fā)送成功、發(fā)送失敗、系統(tǒng)策略可能抑制三種結(jié)果。第三種判斷不了那么準(zhǔn)可以根據(jù)會話 ID 和通知開關(guān)做個粗略推斷。有這個返回值上層在做關(guān)鍵提醒時就能選擇走別的通道比如閃爍任務(wù)欄、改托盤圖標(biāo)顏色而不是把所有希望都押在氣泡上。6.2 退出時的清理和僵尸圖標(biāo)NIM_DELETE一定要在窗口銷毀之前調(diào)而且要用和NIM_ADD完全相同的hWnd和uID。我見過填錯uID導(dǎo)致圖標(biāo)刪不掉的情況表現(xiàn)是程序退出后圖標(biāo)還掛在那兒鼠標(biāo)劃過才消失。這不僅僅是觀感問題——殘留的圖標(biāo)會占用那個uID下次啟動如果復(fù)用同一個 ID行為可能不可預(yù)期。另一個清理時機是WM_ENDSESSION系統(tǒng)關(guān)機或者注銷時程序不一定能走完正常的退出流程。在這個消息里補一次NIM_DELETE能減少殘留。還有崩潰場景進(jìn)程直接掛掉不會執(zhí)行任何清理代碼圖標(biāo)一定殘留這個沒辦法只能靠系統(tǒng)自己回收。如果程序支持多實例uID的分配要小心。兩個實例用同一個hWnd和uID是不可能的hWnd天然不同但如果用了自己生成的guidItem標(biāo)識兩個實例可能會互相覆蓋。多實例場景建議用單實例機制直接禁掉或者在guidItem里加入進(jìn)程相關(guān)的區(qū)分信息。6.3 版本差異下的降級策略不同 Windows 版本對氣泡的處理差異實際項目里沒必要逐一適配但有三條底線值得守住。第一條不要在NIM_ADD的時候一次性把NIF_INFO也帶上試圖順便彈個氣泡添加和修改分成兩次調(diào)用邏輯清晰出問題也好定位。第二條NIM_SETVERSION只在確實需要 v4 的回調(diào)格式時才調(diào)調(diào)了就同步改回調(diào)解析邏輯兩者必須一起改。第三條uTimeout不要依賴需要多停留一會兒的需求用重復(fù)發(fā)送或者改成帶交互的通知來實現(xiàn)更好別指望這個字段。我在實際項目里的體會是托盤氣泡這個功能的問題密度和代碼量完全不成比例——二十行代碼的功能可能需要幾百行的排查經(jīng)驗來兜底。所以能把它封裝干凈就封裝干凈別讓業(yè)務(wù)邏輯直接碰NOTIFYICONDATA后面換人維護或者系統(tǒng)升級改一個文件就夠了。