1. 項(xiàng)目概述從零到一構(gòu)建一個(gè)MFC聊天程序最近在整理舊項(xiàng)目時(shí)翻出了一個(gè)多年前用VC和MFC寫(xiě)的聊天程序。雖然現(xiàn)在各種即時(shí)通訊框架和庫(kù)層出不窮但回過(guò)頭來(lái)看用MFC這種經(jīng)典的桌面開(kāi)發(fā)技術(shù)來(lái)實(shí)現(xiàn)一個(gè)完整的聊天應(yīng)用依然是一個(gè)非常扎實(shí)的學(xué)習(xí)路徑。它能讓你深刻理解Windows消息機(jī)制、網(wǎng)絡(luò)編程、界面線(xiàn)程同步這些核心概念而不是僅僅停留在調(diào)用API的層面。這個(gè)項(xiàng)目標(biāo)題“VC實(shí)現(xiàn)MFC聊天程序完整教程”聽(tīng)起來(lái)像是一個(gè)老派的挑戰(zhàn)但它涵蓋的知識(shí)點(diǎn)——從界面布局到網(wǎng)絡(luò)通信從事件處理到數(shù)據(jù)序列化——對(duì)于想深入理解Windows桌面開(kāi)發(fā)本質(zhì)的開(kāi)發(fā)者來(lái)說(shuō)價(jià)值一點(diǎn)都沒(méi)過(guò)時(shí)。這個(gè)程序本質(zhì)上是一個(gè)C/S架構(gòu)的桌面應(yīng)用包含服務(wù)器端和客戶(hù)端。服務(wù)器負(fù)責(zé)管理連接和轉(zhuǎn)發(fā)消息客戶(hù)端則提供用戶(hù)交互界面。我們將使用MFC的文檔/視圖架構(gòu)作為基礎(chǔ)利用Windows Socket進(jìn)行網(wǎng)絡(luò)通信。整個(gè)過(guò)程會(huì)涉及到MFC對(duì)話(huà)框編程、控件使用、自定義消息、多線(xiàn)程處理以及基礎(chǔ)的TCP套接字編程。即使你之前只用過(guò)Qt或WinForms跟著這個(gè)流程走一遍也能對(duì)Windows原生開(kāi)發(fā)有全新的認(rèn)識(shí)。我將會(huì)把當(dāng)年踩過(guò)的坑、調(diào)試的心得以及如何讓程序更健壯的經(jīng)驗(yàn)都揉進(jìn)這個(gè)教程里。2. 核心需求解析與技術(shù)選型考量2.1 功能需求拆解一個(gè)聊天程序無(wú)論簡(jiǎn)單還是復(fù)雜其核心需求是穩(wěn)定的。我們需要實(shí)現(xiàn)以下幾個(gè)基本功能模塊用戶(hù)界面這是用戶(hù)直接交互的部分。需要一個(gè)主窗口顯示聊天記錄一個(gè)輸入框用于編輯消息發(fā)送按鈕以及連接服務(wù)器的配置區(qū)域如服務(wù)器IP地址和端口輸入框、連接/斷開(kāi)按鈕?？赡苓€需要一個(gè)在線(xiàn)用戶(hù)列表。網(wǎng)絡(luò)通信這是程序的心臟。必須實(shí)現(xiàn)基于TCP或UDP協(xié)議的套接字通信。TCP能保證消息可靠、有序地送達(dá)更適合聊天場(chǎng)景。我們需要處理連接建立、數(shù)據(jù)收發(fā)、連接斷開(kāi)以及錯(cuò)誤處理。消息協(xié)議網(wǎng)絡(luò)上傳送的是二進(jìn)制字節(jié)流。我們需要定義一種簡(jiǎn)單的應(yīng)用層協(xié)議讓客戶(hù)端和服務(wù)器能理解彼此發(fā)送的數(shù)據(jù)。例如一條消息可以包含“發(fā)送者”、“接收者”、“消息內(nèi)容”、“時(shí)間戳”等字段。并發(fā)處理服務(wù)器需要同時(shí)處理多個(gè)客戶(hù)端的連接。這意味著必須使用多線(xiàn)程或異步I/O模型。在客戶(hù)端為了不阻塞UI網(wǎng)絡(luò)接收操作也最好放在單獨(dú)的線(xiàn)程中。數(shù)據(jù)持久化雖然不是最核心的但一個(gè)實(shí)用的聊天程序通常需要保存聊天記錄。我們可以選擇將記錄保存到本地文件或數(shù)據(jù)庫(kù)中。2.2 為什么選擇VC與MFC看到“VC”和“MFC”很多新入行的朋友可能會(huì)覺(jué)得這是“上古”技術(shù)。確實(shí)它不是當(dāng)下最時(shí)髦的選擇但對(duì)于這個(gè)特定項(xiàng)目和學(xué)習(xí)目的而言它有不可替代的優(yōu)勢(shì)深入理解Windows編程模型MFC是對(duì)Win32 API的一層面向?qū)ο蠓庋b。通過(guò)它你能更直觀地理解窗口、消息循環(huán)、設(shè)備上下文、GDI對(duì)象等Windows核心概念。很多現(xiàn)代框架如Qt、WinUI底層依然繞不開(kāi)這些。資源與生態(tài)Visual Studio對(duì)MFC的支持非常成熟資源編輯器對(duì)話(huà)框、菜單、圖標(biāo)編輯器用起來(lái)非常高效。大量的遺留系統(tǒng)、工業(yè)控制軟件仍在使用MFC掌握它意味著你能維護(hù)和開(kāi)發(fā)這類(lèi)應(yīng)用。輕量級(jí)與可控性相比.NET Framework或一些大型UI庫(kù)純粹的MFC程序依賴(lài)少體積小運(yùn)行效率高。你對(duì)程序的行為有完全的控制權(quán)從內(nèi)存分配到消息處理一切盡在掌握。學(xué)習(xí)曲線(xiàn)與成就感MFC的學(xué)習(xí)曲線(xiàn)確實(shí)陡峭但一旦你征服了它再去學(xué)習(xí)其他GUI框架會(huì)感覺(jué)容易很多。完整實(shí)現(xiàn)一個(gè)網(wǎng)絡(luò)聊天程序帶來(lái)的成就感是單純調(diào)用一個(gè)現(xiàn)成IM SDK無(wú)法比擬的。注意本教程基于Visual Studio 2019/2022進(jìn)行它們?nèi)匀煌昝乐С諱FC開(kāi)發(fā)。如果你遇到“vs2019創(chuàng)建mfc項(xiàng)目沒(méi)有窗體”的問(wèn)題請(qǐng)確保在安裝Visual Studio時(shí)勾選了“使用C的桌面開(kāi)發(fā)”工作負(fù)載下的“MFC和ATL支持”組件。2.3 網(wǎng)絡(luò)協(xié)議選擇TCP vs UDP這是一個(gè)關(guān)鍵決策。對(duì)于聊天程序我們強(qiáng)烈推薦使用TCP。TCP面向連接、可靠、有序的字節(jié)流。建立連接需要三次握手能保證數(shù)據(jù)包不丟失、不重復(fù)、按序到達(dá)。這正是聊天消息傳輸所需要的特性——你肯定不希望“你好”和“再見(jiàn)”兩條消息的順序顛倒或丟失其中一條。UDP無(wú)連接、不可靠、盡最大努力交付。它速度快、開(kāi)銷(xiāo)小但不保證送達(dá)和順序。適合視頻流、語(yǔ)音聊天或?qū)崟r(shí)游戲這種可以容忍少量丟包的場(chǎng)景。在我們的項(xiàng)目中我們將采用TCP協(xié)議。服務(wù)器將監(jiān)聽(tīng)一個(gè)端口客戶(hù)端通過(guò)該端口與服務(wù)器建立連接。服務(wù)器作為消息中轉(zhuǎn)站接收一個(gè)客戶(hù)端的消息然后轉(zhuǎn)發(fā)給目標(biāo)客戶(hù)端或所有其他客戶(hù)端。3. 開(kāi)發(fā)環(huán)境搭建與項(xiàng)目創(chuàng)建3.1 安裝必要的運(yùn)行庫(kù)與組件在開(kāi)始編碼之前確保你的開(kāi)發(fā)環(huán)境齊全。正如網(wǎng)絡(luò)熱詞中提到的“微軟 vc 2015-2022 x64 運(yùn)行庫(kù)”你的程序最終需要在用戶(hù)機(jī)器上運(yùn)行而用戶(hù)可能沒(méi)有安裝相應(yīng)的VC運(yùn)行庫(kù)。你有兩個(gè)選擇靜態(tài)鏈接在項(xiàng)目屬性中將“運(yùn)行時(shí)庫(kù)”設(shè)置為“多線(xiàn)程(/MT)”或“多線(xiàn)程調(diào)試(/MTd)”。這樣會(huì)將必要的C運(yùn)行庫(kù)代碼編譯進(jìn)你的EXE文件中生成的文件會(huì)變大但部署簡(jiǎn)單用戶(hù)無(wú)需額外安裝運(yùn)行庫(kù)。動(dòng)態(tài)鏈接并分發(fā)使用“多線(xiàn)程DLL(/MD)”模式。你需要將對(duì)應(yīng)的MSVCPxxx.dll和VCRUNTIMExxx.dll等文件隨你的程序一起分發(fā)或者引導(dǎo)用戶(hù)安裝“Microsoft Visual C Redistributable”運(yùn)行庫(kù)合集。對(duì)于新手我建議先使用靜態(tài)鏈接以簡(jiǎn)化部署和調(diào)試。在Visual Studio Installer中請(qǐng)確認(rèn)已安裝“使用C的桌面開(kāi)發(fā)”工作負(fù)載并勾選了“用于x86和x64的Visual C MFC”和“Windows 10 SDK”或最新版Windows SDK。3.2 創(chuàng)建MFC應(yīng)用程序項(xiàng)目打開(kāi)Visual Studio選擇“創(chuàng)建新項(xiàng)目”。搜索“MFC”選擇“MFC應(yīng)用程序”點(diǎn)擊“下一步”。給項(xiàng)目起個(gè)名字比如MFCChat選擇合適的位置。在“應(yīng)用程序類(lèi)型”頁(yè)面做如下關(guān)鍵選擇應(yīng)用程序類(lèi)型選擇“基于對(duì)話(huà)框”。對(duì)于聊天客戶(hù)端這種主界面是一個(gè)對(duì)話(huà)框的程序來(lái)說(shuō)這比“單文檔”或“多文檔”更簡(jiǎn)單直接。服務(wù)器端如果不需要復(fù)雜界面甚至可以用控制臺(tái)程序但這里為了教學(xué)統(tǒng)一我們也用基于對(duì)話(huà)框的MFC程序來(lái)創(chuàng)建服務(wù)器。項(xiàng)目樣式選擇“MFC標(biāo)準(zhǔn)”。使用共享DLL中的MFC這里根據(jù)你之前的決定選擇。為了部署方便教程示例選擇“在靜態(tài)庫(kù)中使用MFC”。文檔/視圖結(jié)構(gòu)支持因?yàn)槲覀冇玫氖腔趯?duì)話(huà)框的程序這個(gè)選項(xiàng)不可用或無(wú)需勾選。點(diǎn)擊“完成”VS會(huì)為你生成一個(gè)帶有基礎(chǔ)對(duì)話(huà)框和標(biāo)準(zhǔn)MFC類(lèi)骨架的項(xiàng)目。3.3 界面設(shè)計(jì)初步使用對(duì)話(huà)框編輯器項(xiàng)目創(chuàng)建后你會(huì)看到資源視圖里有一個(gè)IDD_MFCCHAT_DIALOG的對(duì)話(huà)框資源。雙擊打開(kāi)對(duì)話(huà)框編輯器。對(duì)于客戶(hù)端我們需要拖放以下控件List Box或List Control用于顯示聊天記錄。IDC_CHAT_LIST。Edit Control用于輸入消息。設(shè)置為多行、垂直滾動(dòng)。IDC_MSG_EDIT。Button發(fā)送消息按鈕。IDC_SEND_BTN標(biāo)題為“發(fā)送(S)”。Edit Control用于輸入服務(wù)器IP。IDC_IP_EDIT。Edit Control用于輸入服務(wù)器端口。IDC_PORT_EDIT。Button連接服務(wù)器按鈕。IDC_CONNECT_BTN標(biāo)題為“連接”。Button斷開(kāi)連接按鈕。IDC_DISCONNECT_BTN標(biāo)題為“斷開(kāi)”初始狀態(tài)為禁用(Disabled)。對(duì)于服務(wù)器端界面可以更簡(jiǎn)單List Box顯示服務(wù)器日志如客戶(hù)端連接、斷開(kāi)、消息轉(zhuǎn)發(fā)記錄。IDC_LOG_LIST。Button啟動(dòng)服務(wù)器按鈕。IDC_START_BTN。Button停止服務(wù)器按鈕。IDC_STOP_BTN初始狀態(tài)為禁用。使用編輯器調(diào)整控件布局使其美觀易用。記住每個(gè)控件的ID我們稍后需要為它們關(guān)聯(lián)變量和事件處理程序。4. 網(wǎng)絡(luò)通信核心Windows Sockets編程4.1 MFC對(duì)Socket的封裝CAsyncSocket與CSocketMFC提供了兩個(gè)主要的套接字類(lèi)CAsyncSocket和CSocket。CAsyncSocket是對(duì)Winsock API的低層封裝提供了基于事件回調(diào)的異步模型控制靈活但需要自己處理更多細(xì)節(jié)。CSocket派生自CAsyncSocket它提供了更高級(jí)的、與MFC歸檔序列化機(jī)制集成的同步操作并且是線(xiàn)程安全的簡(jiǎn)化了編程。對(duì)于我們的聊天程序服務(wù)器端由于要處理多個(gè)客戶(hù)端連接我們采用每個(gè)客戶(hù)端連接一個(gè)獨(dú)立工作線(xiàn)程的模式。在這個(gè)工作線(xiàn)程中我們可以使用CSocket進(jìn)行同步的Receive和Send操作邏輯清晰。監(jiān)聽(tīng)Socket在主線(xiàn)程使用異步事件?？蛻?hù)端通常只有一個(gè)連接Socket。我們可以選擇在UI線(xiàn)程中使用CAsyncSocket的異步模型通過(guò)重寫(xiě)OnReceive等虛函數(shù)或者單獨(dú)創(chuàng)建一個(gè)工作者線(xiàn)程使用CSocket進(jìn)行同步通信。為了避免接收數(shù)據(jù)阻塞UI我推薦為客戶(hù)端也創(chuàng)建一個(gè)獨(dú)立的網(wǎng)絡(luò)通信線(xiàn)程。本教程將采用多線(xiàn)程 CSocket的方案因?yàn)樗壿嫺卑赘菀滋幚碜枞僮骱途€(xiàn)程同步。4.2 定義簡(jiǎn)單的應(yīng)用層消息協(xié)議在網(wǎng)絡(luò)上我們不能直接發(fā)送C對(duì)象。我們需要將消息結(jié)構(gòu)體序列化成字節(jié)流。我們定義一個(gè)簡(jiǎn)單的協(xié)議// 定義消息類(lèi)型 enum MsgType { MSG_TYPE_TEXT 1, // 文本消息 MSG_TYPE_LOGIN, // 登錄/加入聊天室 MSG_TYPE_LOGOUT, // 登出/離開(kāi) MSG_TYPE_USERLIST // 用戶(hù)列表更新 }; // 消息頭固定長(zhǎng)度 struct ChatMsgHeader { int msgType; // 消息類(lèi)型 int msgLen; // 消息體長(zhǎng)度不包括頭部 char sender[32]; // 發(fā)送者昵稱(chēng) char receiver[32]; // 接收者昵稱(chēng)廣播消息可為空或特定標(biāo)識(shí) }; // 文本消息體可變長(zhǎng)度由msgLen指定 // 緊跟在Header后面的是實(shí)際的文本內(nèi)容char數(shù)組發(fā)送一條消息的流程在發(fā)送端填充ChatMsgHeader結(jié)構(gòu)體計(jì)算消息體長(zhǎng)度msgLen。先發(fā)送ChatMsgHeadersizeof(ChatMsgHeader)字節(jié)。再發(fā)送消息體msgLen字節(jié)。接收一條消息的流程先嘗試接收固定大小的ChatMsgHeader。必須循環(huán)接收直到收滿(mǎn)sizeof(header)字節(jié)因?yàn)門(mén)CP是流式協(xié)議可能分多次到達(dá)。解析header.msgLen。根據(jù)msgLen循環(huán)接收消息體數(shù)據(jù)直到收滿(mǎn)。根據(jù)header.msgType處理不同類(lèi)型的消息。這個(gè)“長(zhǎng)度前綴”的方法是處理TCP粘包/拆包問(wèn)題的常見(jiàn)手段。4.3 服務(wù)器端核心實(shí)現(xiàn)監(jiān)聽(tīng)與客戶(hù)端管理服務(wù)器需要做以下幾件事創(chuàng)建監(jiān)聽(tīng)Socket在主線(xiàn)程通常是對(duì)話(huà)框類(lèi)中創(chuàng)建一個(gè)CSocket對(duì)象如m_listenSocket調(diào)用Create和Bind指定端口然后調(diào)用Listen開(kāi)始監(jiān)聽(tīng)。接受連接我們需要一種機(jī)制來(lái)接受新連接?？梢栽谝粋€(gè)單獨(dú)的“接受線(xiàn)程”中循環(huán)調(diào)用m_listenSocket.Accept(m_clientSocket)或者使用CAsyncSocket的OnAccept事件。為了簡(jiǎn)單我們可以在一個(gè)工作者線(xiàn)程中做同步Accept。為每個(gè)客戶(hù)端創(chuàng)建線(xiàn)程一旦Accept成功得到一個(gè)新的CSocket對(duì)象代表與該客戶(hù)端的連接立即創(chuàng)建一個(gè)新的工作者線(xiàn)程CWinThread將這個(gè)Socket對(duì)象通常需要傳遞其句柄或指針注意線(xiàn)程安全交給該線(xiàn)程處理。客戶(hù)端線(xiàn)程工作循環(huán)在線(xiàn)程函數(shù)中循環(huán)執(zhí)行Receive消息頭。Receive消息體。解析消息。根據(jù)消息類(lèi)型處理如廣播文本消息、更新用戶(hù)列表。將消息轉(zhuǎn)發(fā)給其他在線(xiàn)的客戶(hù)端遍歷客戶(hù)端連接列表調(diào)用每個(gè)客戶(hù)端Socket的Send方法。管理客戶(hù)端列表服務(wù)器需要維護(hù)一個(gè)當(dāng)前在線(xiàn)客戶(hù)端的列表包含Socket指針、用戶(hù)昵稱(chēng)等信息。這個(gè)列表會(huì)被多個(gè)客戶(hù)端線(xiàn)程讀寫(xiě)因此必須使用線(xiàn)程同步機(jī)制如臨界區(qū)CCriticalSection或互斥量CMutex來(lái)保護(hù)。一個(gè)常見(jiàn)的坑是直接在不同線(xiàn)程間傳遞或使用MFC對(duì)象如CSocket。MFC對(duì)象通常與創(chuàng)建它的線(xiàn)程關(guān)聯(lián)。解決方案是在主線(xiàn)程創(chuàng)建Socket然后將其句柄SOCKET類(lèi)型傳遞給工作者線(xiàn)程在線(xiàn)程中再通過(guò)CSocket::FromHandle或Attach來(lái)關(guān)聯(lián)一個(gè)棧上的CSocket對(duì)象進(jìn)行操作。更安全的方式是直接在線(xiàn)程中使用Winsock API。4.4 客戶(hù)端核心實(shí)現(xiàn)連接、發(fā)送與接收客戶(hù)端相對(duì)簡(jiǎn)單連接服務(wù)器用戶(hù)點(diǎn)擊“連接”按鈕在按鈕事件處理函數(shù)中獲取IP和端口創(chuàng)建一個(gè)CSocket對(duì)象如m_clientSocket調(diào)用Create()和Connect(serverIp, port)。啟動(dòng)接收線(xiàn)程連接成功后立即創(chuàng)建一個(gè)獨(dú)立的接收線(xiàn)程。將m_clientSocket的句柄傳遞給這個(gè)線(xiàn)程。UI線(xiàn)程不應(yīng)該進(jìn)行阻塞的Receive調(diào)用否則界面會(huì)卡死。接收線(xiàn)程工作循環(huán)與服務(wù)器端的客戶(hù)端線(xiàn)程類(lèi)似循環(huán)接收消息頭和消息體。收到完整消息后需要將其傳遞回UI線(xiàn)程進(jìn)行顯示例如將消息內(nèi)容添加到聊天記錄List Box中。切記不能在工作線(xiàn)程中直接操作UI控件這會(huì)導(dǎo)致程序不穩(wěn)定或崩潰?？缇€(xiàn)程更新UIMFC中從工作線(xiàn)程安全更新UI的標(biāo)準(zhǔn)方法是使用自定義消息WM_USER xxx或PostMessage。工作線(xiàn)程將收到的消息數(shù)據(jù)打包通過(guò)PostMessage發(fā)送到主對(duì)話(huà)框窗口。主對(duì)話(huà)框的WindowProc或消息映射中處理該自定義消息從中解包數(shù)據(jù)并更新控件。發(fā)送消息用戶(hù)在編輯框中輸入內(nèi)容點(diǎn)擊“發(fā)送”。在“發(fā)送”按鈕事件處理函數(shù)中獲取文本按照協(xié)議格式打包成字節(jié)流。然后調(diào)用m_clientSocket.Send()發(fā)送。這里Send是同步的但因?yàn)樗芸煸赨I線(xiàn)程中直接調(diào)用通?？梢越邮?。如果擔(dān)心阻塞也可以將發(fā)送操作放到另一個(gè)線(xiàn)程或使用異步Socket。5. 關(guān)鍵難點(diǎn)與實(shí)戰(zhàn)技巧5.1 多線(xiàn)程同步與資源管理這是MFC網(wǎng)絡(luò)編程中最容易出錯(cuò)的地方。Socket傳遞如前所述不要跨線(xiàn)程直接使用同一個(gè)CSocket對(duì)象。推薦模式是主線(xiàn)程創(chuàng)建Socket并連接后將其Detach()把原始的SOCKET句柄一個(gè)整數(shù)值傳遞給工作線(xiàn)程。工作線(xiàn)程內(nèi)創(chuàng)建一個(gè)局部的CSocket對(duì)象調(diào)用Attach(hSocket)將其與句柄關(guān)聯(lián)然后進(jìn)行通信。線(xiàn)程結(jié)束時(shí)確保在局部CSocket對(duì)象析構(gòu)前不要Close或者先Detach再關(guān)閉句柄。UI更新必須通過(guò)消息機(jī)制。例如// 定義自定義消息 #define WM_UPDATE_CHAT_MSG (WM_USER 100) // 在工作線(xiàn)程中 CString* pMsg new CString(_T(Hello from thread!)); ::PostMessage(hWndMain, WM_UPDATE_CHAT_MSG, (WPARAM)pMsg, 0); // 在主對(duì)話(huà)框消息映射中 ON_MESSAGE(WM_UPDATE_CHAT_MSG, OnUpdateChatMsg) LRESULT CMFCChatDlg::OnUpdateChatMsg(WPARAM wParam, LPARAM lParam) { CString* pMsg (CString*)wParam; m_listChat.AddString(*pMsg); delete pMsg; // 務(wù)必記得刪除避免內(nèi)存泄漏 return 0; }資源泄漏確保每個(gè)new/malloc都有對(duì)應(yīng)的delete/free。對(duì)于Socket確保在程序退出或連接斷開(kāi)時(shí)正確關(guān)閉。對(duì)于線(xiàn)程確保在對(duì)話(huà)框銷(xiāo)毀時(shí)能正常通知工作線(xiàn)程退出例如設(shè)置一個(gè)退出標(biāo)志volatile bool m_bStop并等待線(xiàn)程結(jié)束WaitForSingleObject。5.2 TCP粘包/拆包處理這是網(wǎng)絡(luò)編程的經(jīng)典問(wèn)題。由于TCP是字節(jié)流沒(méi)有消息邊界一次Send的數(shù)據(jù)可能被分成多個(gè)包到達(dá)拆包或者多次Send的小數(shù)據(jù)可能被合并成一個(gè)包到達(dá)粘包。我們的“長(zhǎng)度前綴法”就是為了解決這個(gè)問(wèn)題。在接收端必須嚴(yán)格按照“先收固定頭解析長(zhǎng)度再收對(duì)應(yīng)長(zhǎng)度體”的流程并且要用循環(huán)來(lái)收因?yàn)橐淮蜶eceive調(diào)用可能只收到部分?jǐn)?shù)據(jù)。// 偽代碼接收固定長(zhǎng)度數(shù)據(jù)的函數(shù) int ReceiveExact(CSocket sock, char* buf, int len) { int totalReceived 0; while (totalReceived len) { int ret sock.Receive(buf totalReceived, len - totalReceived); if (ret 0) { // 連接錯(cuò)誤或關(guān)閉 return -1; } totalReceived ret; } return totalReceived; // 應(yīng)該等于len } // 在接收線(xiàn)程中 ChatMsgHeader header; if (ReceiveExact(clientSocket, (char*)header, sizeof(header)) 0) break; char* pBody new char[header.msgLen 1]; // 多一個(gè)字節(jié)放字符串結(jié)束符 if (ReceiveExact(clientSocket, pBody, header.msgLen) 0) { delete[] pBody; break; } pBody[header.msgLen] \0; // 處理header和pBody... delete[] pBody;5.3 程序穩(wěn)定性與異常處理網(wǎng)絡(luò)程序必須健壯能處理各種異常情況。心跳機(jī)制長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)通信TCP連接可能因?yàn)橹虚g網(wǎng)絡(luò)設(shè)備超時(shí)而被斷開(kāi)但應(yīng)用程序感知不到?？梢栽O(shè)計(jì)一個(gè)簡(jiǎn)單的心跳包MsgType為MSG_TYPE_PING/PONG定期發(fā)送以保持連接活躍并檢測(cè)死連接。超時(shí)設(shè)置CSocket可以調(diào)用SetSockOpt設(shè)置發(fā)送和接收超時(shí)避免在網(wǎng)絡(luò)異常時(shí)無(wú)限期阻塞。錯(cuò)誤處理每次Socket操作Connect,Accept,Send,Receive后都應(yīng)檢查返回值或調(diào)用GetLastError。對(duì)于Receive返回0表示對(duì)方優(yōu)雅地關(guān)閉了連接。線(xiàn)程安全退出對(duì)話(huà)框關(guān)閉時(shí)向所有工作線(xiàn)程發(fā)送退出信號(hào)并等待它們結(jié)束。避免線(xiàn)程還在訪(fǎng)問(wèn)已被銷(xiāo)毀的對(duì)話(huà)框成員變量。6. 界面優(yōu)化與功能增強(qiáng)6.1 聊天記錄顯示的優(yōu)化使用簡(jiǎn)單的List Box顯示聊天記錄當(dāng)消息多時(shí)會(huì)很簡(jiǎn)陋。我們可以使用List Control換成CListCtrl可以設(shè)置多列分別顯示時(shí)間、發(fā)送者、消息內(nèi)容看起來(lái)更專(zhuān)業(yè)。富文本顯示如果想支持表情、圖片或字體顏色可以考慮使用CRichEditCtrl。但這會(huì)復(fù)雜很多需要處理RTF格式或自定義繪制。自動(dòng)滾動(dòng)添加新消息后自動(dòng)滾動(dòng)到底部。對(duì)于CListBox可以調(diào)用SetTopIndex(GetCount() - 1)。時(shí)間戳在打包消息時(shí)加入時(shí)間戳在顯示時(shí)格式化輸出。6.2 實(shí)現(xiàn)用戶(hù)列表與私聊功能目前我們實(shí)現(xiàn)的是廣播聊天室。要支持用戶(hù)列表和私聊需要登錄協(xié)議客戶(hù)端連接后發(fā)送一個(gè)MSG_TYPE_LOGIN消息攜帶用戶(hù)昵稱(chēng)。服務(wù)器將其加入在線(xiàn)用戶(hù)列表。維護(hù)用戶(hù)列表服務(wù)器端維護(hù)一個(gè)std::mapSOCKET, UserInfo其中UserInfo包含昵稱(chēng)、狀態(tài)等。廣播用戶(hù)列表更新當(dāng)有用戶(hù)加入或離開(kāi)時(shí)服務(wù)器構(gòu)造一個(gè)MSG_TYPE_USERLIST消息將當(dāng)前在線(xiàn)用戶(hù)列表可以只發(fā)昵稱(chēng)發(fā)送給所有客戶(hù)端。客戶(hù)端顯示列表客戶(hù)端收到用戶(hù)列表消息后更新一個(gè)List Box控件。私聊協(xié)議在消息頭ChatMsgHeader中我們已經(jīng)定義了receiver字段。發(fā)送私聊消息時(shí)客戶(hù)端將receiver字段設(shè)置為目標(biāo)用戶(hù)的昵稱(chēng)。服務(wù)器收到后不是廣播而是查找昵稱(chēng)對(duì)應(yīng)的Socket單獨(dú)發(fā)送給該接收者。6.3 文件傳輸與圖片發(fā)送這是一個(gè)高級(jí)功能?；舅悸肥嵌x新的消息類(lèi)型如MSG_TYPE_FILE_INFO和MSG_TYPE_FILE_DATA。MSG_TYPE_FILE_INFO包含文件名、文件大小等信息。接收方確認(rèn)后發(fā)送方將文件分塊通過(guò)多個(gè)MSG_TYPE_FILE_DATA消息發(fā)送。接收方按順序接收并重組文件。需要注意的是大文件傳輸不能阻塞主消息循環(huán)需要單獨(dú)的任務(wù)隊(duì)列或線(xiàn)程處理。圖片可以當(dāng)作二進(jìn)制文件傳輸也可以在客戶(hù)端先壓縮如轉(zhuǎn)為Base64再以文本消息形式發(fā)送但后者效率低。7. 調(diào)試、部署與常見(jiàn)問(wèn)題7.1 VC程序崩潰調(diào)試網(wǎng)絡(luò)熱詞中提到了“vc 崩潰生成調(diào)試文件”。當(dāng)程序在用戶(hù)機(jī)器上崩潰時(shí)獲取崩潰現(xiàn)場(chǎng)信息至關(guān)重要。生成調(diào)試符號(hào)PDB文件在項(xiàng)目屬性 - “鏈接器” - “調(diào)試”中確?！吧烧{(diào)試信息”設(shè)置為“是(/DEBUG)”。發(fā)布版本也可以生成PDB這不會(huì)影響性能。設(shè)置異常處理與生成Dump文件可以使用SetUnhandledExceptionFilter函數(shù)設(shè)置頂層的未處理異常過(guò)濾器。當(dāng)崩潰發(fā)生時(shí)在這個(gè)過(guò)濾器函數(shù)中調(diào)用MiniDumpWriteDump函數(shù)將進(jìn)程的內(nèi)存狀態(tài)寫(xiě)入一個(gè).dmp文件。將這個(gè).dmp文件和對(duì)應(yīng)的PDB文件拿回開(kāi)發(fā)機(jī)用Visual Studio打開(kāi)就能看到崩潰時(shí)的調(diào)用棧和變量信息極大方便了定位問(wèn)題。日志系統(tǒng)在關(guān)鍵路徑添加日志輸出輸出到文件或調(diào)試器記錄程序狀態(tài)、網(wǎng)絡(luò)數(shù)據(jù)等是排查線(xiàn)上問(wèn)題的利器。7.2 64位與32位兼容性問(wèn)題熱詞中提到了“mfc的64位的exe不能調(diào)用32位的dll嗎?”。是的絕對(duì)不能混用。一個(gè)進(jìn)程的地址空間是統(tǒng)一的如果進(jìn)程是64位的它加載的所有DLL也必須是64位的32位進(jìn)程只能加載32位DLL。這是由CPU指令集和操作系統(tǒng)加載器決定的。如果你的程序需要調(diào)用一個(gè)只有32位版本且沒(méi)有源碼的DLL那么你的主程序也必須編譯成32位即x86平臺(tái)。在Visual Studio的項(xiàng)目屬性 - “配置管理器”中將活動(dòng)解決方案平臺(tái)設(shè)置為“Win32”。如果你的程序是64位的而DLL是32位的唯一的辦法是創(chuàng)建一個(gè)單獨(dú)的32位進(jìn)程代理進(jìn)程來(lái)加載那個(gè)DLL然后通過(guò)進(jìn)程間通信IPC來(lái)調(diào)用功能這非常復(fù)雜。7.3 程序打包與依賴(lài)檢查使用靜態(tài)鏈接MFC和運(yùn)行時(shí)庫(kù)是最簡(jiǎn)單的部署方式生成的單個(gè)EXE文件可以在大多數(shù)Windows系統(tǒng)上直接運(yùn)行。如果使用動(dòng)態(tài)鏈接你需要確保目標(biāo)機(jī)器上有相應(yīng)的庫(kù)。可以使用Visual Studio自帶的“發(fā)布”功能或者使用第三方安裝包制作工具如Inno Setup, NSIS將必要的MSVCPxxx.dll,MFCxxx.dll,VCRUNTIMExxx.dll等文件打包進(jìn)安裝程序。在開(kāi)發(fā)機(jī)上測(cè)試通過(guò)后務(wù)必在一臺(tái)干凈的、沒(méi)有安裝Visual Studio的虛擬機(jī)或電腦上測(cè)試確認(rèn)所有依賴(lài)都已就位。7.4 常見(jiàn)編譯與運(yùn)行錯(cuò)誤“f:\dd\vctools\vc7libs\ship\atimfc\src\mfc\afxshellmanager.cpp line: 30”這類(lèi)錯(cuò)誤通常指向MFC內(nèi)部源碼往往是因?yàn)橘Y源ID定義沖突、在錯(cuò)誤的線(xiàn)程中調(diào)用了MFC函數(shù)、或者M(jìn)FC對(duì)象如CWnd使用不當(dāng)如訪(fǎng)問(wèn)了已銷(xiāo)毀的窗口。仔細(xì)檢查你的消息映射、線(xiàn)程間對(duì)象傳遞和控件訪(fǎng)問(wèn)。鏈接錯(cuò)誤“無(wú)法解析的外部符號(hào)”檢查你是否在stdafx.h或項(xiàng)目設(shè)置中包含了必要的頭文件如afxsock.h用于Socket支持以及是否鏈接了對(duì)應(yīng)的庫(kù)如Socket庫(kù)ws2_32.lib是自動(dòng)鏈接的但如果你用了其他庫(kù)則需要手動(dòng)添加。運(yùn)行時(shí)Socket錯(cuò)誤10038在一個(gè)已關(guān)閉或未初始化的Socket上操作。檢查你的Socket對(duì)象生命周期確保在調(diào)用Send/Receive前Socket是有效的。界面卡死或無(wú)響應(yīng)這幾乎肯定是因?yàn)樵赨I線(xiàn)程中執(zhí)行了阻塞操作如長(zhǎng)時(shí)間循環(huán)、同步網(wǎng)絡(luò)接收。牢記所有可能阻塞的操作都應(yīng)放到工作線(xiàn)程中。實(shí)現(xiàn)一個(gè)完整的MFC聊天程序是一次對(duì)Windows桌面開(kāi)發(fā)核心技術(shù)的全面演練。從消息循環(huán)到網(wǎng)絡(luò)I/O從多線(xiàn)程同步到資源管理每一步都需要仔細(xì)考量。雖然過(guò)程會(huì)遇到不少挑戰(zhàn)但當(dāng)你最終看到兩個(gè)自己編寫(xiě)的程序成功互發(fā)消息時(shí)那種對(duì)系統(tǒng)底層運(yùn)作機(jī)制的理解和掌控感是使用高級(jí)框架快速搭出應(yīng)用所無(wú)法比擬的。這個(gè)項(xiàng)目代碼量不大但涉及的知識(shí)點(diǎn)很密集非常適合作為深入C Windows編程的練手項(xiàng)目。