簡介面向安防監(jiān)控與嵌入式開發(fā)的C工程師這份?？礑VR監(jiān)控客戶端Demo程序內(nèi)含海康官方SDK及完整可編譯的示例工程集中演示設(shè)備搜索連接、實時視頻預(yù)覽、錄像回放與云臺控制等關(guān)鍵功能可幫助開發(fā)者快速理解DVR設(shè)備通信流程縮短監(jiān)控客戶端從零搭建的時間。壓縮包總計187個文件、5.09MB主體為64個h頭文件與56個cpp源文件搭配7個dll和7個lib運行庫另有29個ico圖標與9個bmp位圖等界面資源以及doc文檔、exe示例等功能覆蓋設(shè)備管理、視頻流處理、錄像管理、報警服務(wù)等模塊結(jié)構(gòu)清晰便于直接打開工程研讀。目前已有402人學(xué)習(xí)下載。通過閱讀和二次開發(fā)這份源代碼可以掌握海康SDK中API的調(diào)用順序與參數(shù)配置方法尤其適合需要定制多畫面顯示、移動偵測報警或人臉識別等高級功能的中高級開發(fā)者作為基礎(chǔ)框架復(fù)用。1. 從「能跑通的 Demo」到「能交付的客戶端」中間隔著的不是代碼量接手過某個監(jiān)控項目的開發(fā)者多半有過這種經(jīng)歷拿到廠商提供的 SDK 壓縮包里面有一個 DVR 監(jiān)控客戶端 Demo 程序打開工程編譯、運行填上設(shè)備 IP 就能看到實時畫面看起來一切順利?？梢坏┮踊胤?、抓圖、斷線重連或者換個網(wǎng)絡(luò)環(huán)境問題就接踵而至。DVR 監(jiān)控客戶端 Demo 程序的核心價值從來不是“能演示”而是把 SDK 的幾條關(guān)鍵鏈路——登錄、取流、回放、控制——完整跑一遍讓你知道每個環(huán)節(jié)該調(diào)哪個接口、參數(shù)怎么配。這篇筆記就圍繞這個方向從看懂 Demo 到改造成可交付的客戶端把原理、步驟和文檔里不寫的坑一次講透適合正在做監(jiān)控客戶端集成、工期緊又沒人帶的從業(yè)者。2. Demo 程序到底是什么讀懂 SDK 目錄、工程結(jié)構(gòu)和三種開發(fā)路線2.1 一條主線登錄、取流、回放、控制Demo 演示的就是這四個動作不管哪個廠商的 DVR 設(shè)備客戶端 Demo 的本質(zhì)都繞不開一條主線設(shè)備登錄、實時預(yù)覽、錄像回放、云臺與參數(shù)控制。登錄負責建立會話拿到一個后續(xù)所有操作的句柄實時預(yù)覽把設(shè)備的視頻流拉到本地解碼顯示回放則基于錄像文件列表按時間區(qū)間檢索和播放控制包括云臺轉(zhuǎn)向、焦距調(diào)節(jié)、報警布防等。DVR 監(jiān)控客戶端 Demo 程序通常把這四件事做成四個頁面或四個按鈕背后就是四組對應(yīng)接口。理解這條主線很重要因為實際項目里你大概率要在這條主線上擴展。比如增加多個設(shè)備的分組管理、錄像文件下載、AI 事件聯(lián)動。Demo 的代碼結(jié)構(gòu)往往就是一張“地圖”告訴你哪個功能該去哪找接口。我通常拿到開發(fā)包后第一件事不是讀接口手冊而是先把 Demo 的界面交互和調(diào)用棧跑一遍弄清每個按鈕背后連的是哪個 API。這個習(xí)慣能省下后面兩三天翻文檔的時間。2.2 為什么業(yè)界選擇 SDK 而不是裸寫 RTSP有人會問DVR 設(shè)備不是都支持 RTSP 嗎直接用 FFmpeg 拉流不行嗎行但只覆蓋了實時預(yù)覽這一條路。真正的客戶端項目里登錄鑒權(quán)、設(shè)備能力集、錄像文件檢索、云臺控制、報警上傳、語音對講這些能力RTSP 協(xié)議要么不支持要么各家私有擴展五花八門。廠商 SDK 把這些能力封裝成統(tǒng)一接口把復(fù)雜的信令交互和私有協(xié)議差異全部藏在動態(tài)庫里對上層開發(fā)者來說就是“填參數(shù)、調(diào)函數(shù)、收回調(diào)”。舉個最典型的例子裸寫 RTSP 時設(shè)備重啟后你往往要等一段時間才能感知到斷流再去重新建立連接而 SDK 通常提供心跳保活和斷線回調(diào)登錄會話的狀態(tài)是實時可感知的。再比如錄像檢索RTSP 協(xié)議本身不提供錄像文件列表的標準化查詢各家設(shè)備返回格式都可能不同。所以我的建議很直接凡是需要登錄鑒權(quán)、回放、控制、報警的項目全部走廠商 SDKRTSP 只作為預(yù)覽的備用方案。DVR 監(jiān)控客戶端 Demo 程序就是 SDK 的“最小使用說明書”你把它跑通等于把廠商幫你踩過一遍的鏈路重新走了一遍。2.3 拿到 Demo 包后三個必讀文件和一個必跑流程開發(fā)包的目錄結(jié)構(gòu)每家廠商大同小異通常會包含頭文件、動態(tài)庫、Demo 工程、文檔四塊。具體來說常見布局如下表目錄/文件作用打開優(yōu)先級include頭文件接口聲明、結(jié)構(gòu)體定義、錯誤碼高lib/bin動態(tài)庫SDK 實現(xiàn)運行時需要拷到 exe 目錄高demo示例工程可編譯的客戶端 Demo 源碼最高doc文檔接口手冊、版本說明、FAQ中三個必讀文件我一般這樣選第一是接口手冊里的“登錄/退出”章節(jié)它決定了整個程序的入口怎么寫第二是 Demo 工程里主流程對應(yīng)的源文件通常是 Login、Preview、Playback 這幾個第三是版本說明文件里面會寫明 SDK 對應(yīng)設(shè)備固件的版本范圍這個最容易忽略一旦不匹配就會出現(xiàn)“接口存在但調(diào)用報錯”的玄學(xué)問題。必跑流程只有一條先編譯 Demo、把動態(tài)庫拷貝到運行目錄、按示例配置設(shè)備 IP 和端口、跑通登錄和預(yù)覽。這里要特別提醒不要把 Demo 工程里的輸出目錄當運行目錄直接在 IDE 里跑很多 Demo 默認把動態(tài)庫放到配置好的輸出路徑你手動拷貝時漏了某個 DLL運行就會報“找不到程序入口”。先花半小時把這個流程跑通后面所有步驟都以它為基準出了問題也好區(qū)分是環(huán)境問題還是代碼問題。2.4 Demo 工程的典型代碼組織功能模塊劃分與線程模型打開一個成熟的 DVR Demo 工程你會發(fā)現(xiàn)它很少把所有邏輯堆在一個文件里。常見做法是界面層、業(yè)務(wù)層、SDK 層三層分離界面層只管按鈕和顯示業(yè)務(wù)層封裝登錄態(tài)、通道列表、播放句柄這些中間狀態(tài)SDK 層直接調(diào)廠商接口。如果你的工程不是這樣至少也要按功能拆文件否則后面加斷線重連和日志時會非常痛苦。線程模型是 Demo 里最值得留意、也最容易被新手看走眼的部分。SDK 通常會自己起工作線程負責網(wǎng)絡(luò)收發(fā)、解碼、事件分發(fā)你的程序里至少還有界面線程和處理業(yè)務(wù)的工作線程?；卣{(diào)函數(shù)運行在 SDK 的線程里這意味著第一不要在回調(diào)里做重活否則會阻塞 SDK 的數(shù)據(jù)分發(fā)第二不要直接在新線程里操作界面控件要通過消息投遞或線程安全隊列。很多 Demo 為了示例簡潔直接在回調(diào)里刷新界面這在單路預(yù)覽時沒事多路并發(fā)時就會卡成幻燈片。后面第 5 章會專門展開這個坑。3. 先跑通最小閉環(huán)登錄設(shè)備 獲取通道信息3.1 初始化 SDK 與設(shè)置連接參數(shù)這一步做不對后面全白搭幾乎每個廠商 SDK 的第一步都是初始化做的是黑匣子式的準備網(wǎng)絡(luò)庫加載、加解密模塊初始化、日志系統(tǒng)注冊、內(nèi)部線程池創(chuàng)建。初始化不成功后面所有接口都會返回“未初始化”之類的錯誤。但很多 Demo 把初始化寫得很隱蔽放在程序啟動的某個角落里你復(fù)制代碼時容易漏掉。下面是一段初始化示例為了讓代碼不綁定具體廠商接口名做了泛化你拿到開發(fā)包后把函數(shù)名替換成頭文件里的實際接口即可// 初始化SDK返回值0表示成功非0需要查錯誤碼 int ret DVR_Init(); if (ret ! 0) { // 記錄錯誤碼并退出不要繼續(xù)往下走 printf(DVR_Init failed, error%d\n, ret); return -1; } // 設(shè)置日志級別和輸出目錄方便后期排錯 DVR_SetLogLevel(DVR_LOG_LEVEL_DEBUG, C:/dvrlogs);初始化接口一般沒有參數(shù)但“有沒有調(diào)用”和“調(diào)用了幾次”都是問題。我見過有人在每次登錄前都調(diào)一次 Init這會導(dǎo)致 SDK 內(nèi)部資源重復(fù)創(chuàng)建輕則內(nèi)存上漲重則崩潰。正確做法是進程生命周期內(nèi)只初始化一次。日志級別建議開發(fā)階段用 DEBUG交付階段改成 ERROR因為完整日志在低配機器上會拖慢回調(diào)線程。日志路徑最好用相對當前程序目錄拼出來的絕對路徑不要用寫死的 C 盤根目錄否則現(xiàn)場機器可能沒有寫入權(quán)限。3.2 DVR 監(jiān)控客戶端 Demo 程序的登錄接口IP、端口、用戶名、密碼之外還有幾個易忽略的參數(shù)登錄是 DVR 監(jiān)控客戶端 Demo 程序里最核心的一步也是新手最容易想當然的一步。填 IP、端口、用戶名、密碼誰都會但容易被忽略的是“連接超時”“加密通道”“設(shè)備端口號”這幾個細節(jié)。不少設(shè)備默認管理端口不是 80 或 443而是一個廠商自定義端口比如 8000 或 8001登錄時填錯端口表現(xiàn)就是“網(wǎng)絡(luò)超時”哪怕設(shè)備就在同網(wǎng)段。下面是一段帶關(guān)鍵參數(shù)的登錄示例DVR_LOGIN_INFO login {0}; DVR_DEVICE_INFO devInfo {0}; // 設(shè)備網(wǎng)絡(luò)參數(shù)IP、端口、賬號、密碼 snprintf(login.deviceIp, sizeof(login.deviceIp), 192.168.1.64); login.devicePort 8000; // 注意這是設(shè)備私有協(xié)議端口不是HTTP端口 snprintf(login.userName, sizeof(login.userName), admin); snprintf(login.password, sizeof(login.password), your_password); // 兩個容易被忽略的參數(shù) login.useSecureChannel 1; // 高版本設(shè)備固件默認要求加密登錄0可能被拒 login.connTimeout 5000; // 毫秒不要用默認值默認可能長達幾十秒 int userId DVR_Login(login, devInfo); if (userId 0) { int err DVR_GetLastError(); // 根據(jù)錯誤碼查頭文件-6通常是網(wǎng)絡(luò)不可達-7通常是賬號或密碼錯誤 } else { // 登錄成功userId 是后續(xù)所有操作的會話句柄 }這里的核心邏輯是登錄成功后返回的是一個整數(shù)句柄而不是設(shè)備對象指針這個句柄要全局保存后續(xù)預(yù)覽、回放、云臺控制全部依賴它。連接超時建議顯式設(shè)置不同 SDK 的默認值差異很大有的默認是 15 秒有的默認是 30 秒?，F(xiàn)場網(wǎng)絡(luò)稍差時用戶點了登錄界面卡十幾秒才有反應(yīng)體驗非常糟糕把超時設(shè)短一些可以快速失敗、快速重試。加密通道參數(shù)需要根據(jù)設(shè)備固件調(diào)整較老的設(shè)備可能不支持加密登錄需要置 0否則會一直報“協(xié)商失敗”。3.3 登錄成功不表示能取流先拉通道信息再建預(yù)覽很多 DVR 設(shè)備是多通道的比如 4 路、8 路、16 路。登錄成功之后第一件事不是急著去預(yù)覽而是先問設(shè)備“你有幾個通道哪些在線每個通道的編碼格式是什么”。Demo 程序通常會把這個信息加載到界面的通道列表里。跳過這一步的后果是你拿著通道號 5 去預(yù)覽但設(shè)備只有 4 路接口返回“通道號越界”。拉取通道信息的方式各廠商 SDK 大同小異代碼示意如下DVR_CHANNEL_INFO channels[16] {0}; int count DVR_GetChannelInfo(userId, channels, 16); for (int i 0; i count; i) { // 只把在線且編碼格式支持的通道加入界面列表 if (channels[i].isOnline) { printf(channel %d online, codec%d\n, channels[i].index, channels[i].encodeType); } }這段代碼的要點在于通道信息是一個數(shù)組元素個數(shù)可能小于設(shè)備的物理通道數(shù)判斷在線狀態(tài)要依據(jù) SDK 返回的標志位而不是自己猜測。編碼格式也很重要如果你的解碼器不支持該設(shè)備的私有編碼格式預(yù)覽畫面會花屏或黑屏。很多 Demo 在這里只顯示通道號不顯示編碼格式導(dǎo)致用戶選了一個不支持解碼的通道折騰半天。我一般會在界面列表里把通道狀態(tài)、編碼格式、分辨率一起展示每行對應(yīng)一個通道這樣既直觀又方便排查問題也算是在最小閉環(huán)里提前踩掉一個常見坑。4. 把畫面拉起來實時預(yù)覽 抓圖 本地錄像4.1 預(yù)覽的本質(zhì)解碼顯示鏈路與回調(diào)數(shù)據(jù)流實時預(yù)覽看起來是“點了按鈕就有畫面”背后其實是三條鏈路的協(xié)作。第一條是網(wǎng)絡(luò)取流鏈路SDK 從設(shè)備拉取視頻流第二條是解碼鏈路把壓縮碼流解碼成原始圖像幀第三條是渲染鏈路把圖像幀送到窗口顯示。Demo 程序通常把后兩條封裝在 SDK 內(nèi)部你只需要指定窗口句柄和碼流類型SDK 自己完成解碼和繪制。理解這條鏈路的價值在于排錯。預(yù)覽黑屏?xí)r你得判斷是網(wǎng)絡(luò)沒取到流、解碼失敗還是窗口句柄不對。SDK 一般會提供回調(diào)事件比如斷流、解碼失敗、首幀到達。很多 Demo 把這些事件打印到控制臺或調(diào)試輸出你運行時看不到就錯過了關(guān)鍵信息。預(yù)覽啟動后可以先用抓圖驗證鏈路是否正常如果抓圖能保存出一張完整畫面說明取流和解碼沒問題問題大概率在窗口渲染如果抓圖也是黑圖說明鏈路在更上游。4.2 預(yù)覽參數(shù)里 3 個必須顯式指定的參數(shù)預(yù)覽接口的參數(shù)結(jié)構(gòu)一般都很大初學(xué)者容易全部置零然后抱著僥幸心理去試。實際上有三個參數(shù)決定成敗窗口句柄、碼流類型、通道號。窗口句柄必須是真正的子窗口句柄而不是對話框或主窗口句柄否則畫面畫不出來碼流類型決定了走主碼流還是子碼流遠程低帶寬場景要提前切子碼流通道號則直接對應(yīng)設(shè)備物理通道。下面是一段預(yù)覽啟動示例DVR_PREVIEW_PARAM param {0}; param.wndHandle (DVR_HANDLE)GetDlgItem(hDlg, IDC_VIDEO_WND); // 必須是子窗口句柄 param.streamType DVR_STREAM_MAIN; // 主碼流清晰但碼率大子碼流用于多畫面 param.channel channelIndex; // 通道號從0開始不要用1開始 param.callback NULL; // 不使用數(shù)據(jù)回調(diào)由SDK直接繪制 int playHandle DVR_StartRealPlay(userId, param); if (playHandle 0) { // 從錯誤碼推斷是參數(shù)錯誤還是取流失敗 }窗口句柄這個坑我在實際項目里見過不止一次。有人直接把登錄窗口的句柄傳進去結(jié)果是畫面覆蓋了整個界面控件全部被擋住還有人傳了一個還沒創(chuàng)建的窗口句柄運行時不報錯但畫面就是不出來。正確做法是在界面創(chuàng)建完子窗口之后用子窗口的句柄去啟停預(yù)覽。碼流類型的選型也有講究本地調(diào)試用主碼流沒問題跨公網(wǎng)遠程訪問時主碼流可能帶寬不夠畫面卡頓這時候可以在界面加一個“流暢/高清”切換本質(zhì)上就是在重啟用不同碼流類型。4.3 抓圖和錄像Demo 里最容易抄錯的兩處抓圖和錄像在邏輯上有一個共同點它們依賴的是預(yù)覽句柄而不是登錄句柄。很多人在這里抄錯拿 userId 去抓圖接口返回成功但文件內(nèi)容不對。抓圖的正確姿勢是先啟動預(yù)覽拿到 playHandle然后基于這個句柄再調(diào)抓圖接口。下面是一段抓圖示例DVR_CAPTURE_PARAM cap {0}; cap.wndHandle playHandle; // 注意這里是預(yù)覽句柄不是登錄句柄 cap.savePath D:/capture/20241121_153000.jpg; // 路徑必須存在且?guī)U展名 cap.format DVR_CAPTURE_JPG; // 指定編碼格式不要依賴默認值 cap.quality 90; // JPEG質(zhì)量90是常用值 int ret DVR_CapturePicture(playHandle, cap); if (ret ! 0) { // 檢查目錄權(quán)限、路徑是否帶擴展名 }抓圖的關(guān)鍵坑有兩個一是路徑目錄不存在接口可能直接失敗二是連續(xù)抓圖時文件名必須不同用時間戳命名可以避免覆蓋。錄像和抓圖的區(qū)別在于錄像是一個持續(xù)過程需要主動停止DVR_RECORD_PARAM rec {0}; rec.wndHandle playHandle; // 同樣基于預(yù)覽句柄 rec.filePath D:/record; // 錄像文件保存目錄 rec.splitDuration 600; // 每個文件時長單位秒10分鐘一個 DVR_StartRecord(playHandle, rec); // ... 用戶點擊停止按鈕時 DVR_StopRecord(playHandle);錄像文件切分時長是一個容易被忽略的參數(shù)。如果設(shè)成 0有些 SDK 會一直寫同一個文件一旦客戶端異常退出錄像文件可能損壞。我通常設(shè)成 600 秒到 1800 秒這樣即使程序崩潰損失最多是最后一個切片。另外錄像和抓圖不要在同一瞬間操作某些設(shè)備固件在同時收到抓圖和錄像請求時會有一個請求被靜默丟棄這是固件限制程序里要做好失敗重試。5. 避坑DVR 客戶端 Demo 最常見的 5 個翻車點5.1 登錄就返回錯誤碼日志全是“網(wǎng)絡(luò)超時”現(xiàn)象設(shè)備 IP 能 ping 通端口看起來也對但登錄接口就是報網(wǎng)絡(luò)超時重試多次依然失敗。原因最常見的是端口號填錯。很多 DVR 設(shè)備的私有協(xié)議端口和管理頁面端口不是同一個管理頁面走 80/443私有協(xié)議可能走 8000 或 8001。另一個隱藏原因是登錄失敗次數(shù)過多觸發(fā)了設(shè)備賬號鎖定有些固件連續(xù)失敗 5 次會鎖定 30 分鐘期間即使密碼正確也會超時。還有本地防火墻把 UDP 或自定義端口攔截了。解決先用廠商提供的設(shè)備搜索工具確認設(shè)備實際端口不要相信配置截圖。登錄失敗后不要馬上高頻重試先看錯誤碼再決定策略。局域網(wǎng)環(huán)境調(diào)試時可以臨時關(guān)閉防火墻排除網(wǎng)絡(luò)層攔截。如果設(shè)備固件較老嘗試把登錄接口里的加密通道參數(shù)置 0部分老設(shè)備不支持加密協(xié)商。5.2 預(yù)覽窗口黑屏但登錄成功現(xiàn)象登錄成功啟動預(yù)覽也返回了正常的句柄但畫面區(qū)域一片黑沒有任何報錯。原因窗口句柄傳錯了最常見的是傳成主對話框句柄或者窗口還沒顯示出來就啟動了預(yù)覽或者碼流類型與設(shè)備能力不匹配。有時候是顯示模式問題SDK 默認使用硬件加速渲染而目標機器顯卡驅(qū)動太老畫面就渲染不出來。解決創(chuàng)建一個專門的子窗口用于視頻顯示啟動預(yù)覽前先 ShowWindow 讓窗口可見再傳入子窗口句柄。先嘗試切回主碼流確認不是子碼流解碼問題。如果還是黑屏把 SDK 的顯示模式參數(shù)從硬件加速切到軟件渲染這一步往往能解決老顯卡機器上的黑屏。判斷鏈路是否正?？梢杂?4.3 里的抓圖功能驗證。5.3 回調(diào)線程排隊多路畫面卡成幻燈片現(xiàn)象單路預(yù)覽非常流暢加到 4 路以上開始卡頓CPU 占用不高但畫面掉幀嚴重。原因預(yù)覽數(shù)據(jù)回調(diào)函數(shù)里做了耗時操作比如把視頻幀轉(zhuǎn)成 Bitmap、寫日志、甚至直接把網(wǎng)絡(luò)流寫入磁盤。SDK 的工作線程是共享的一路回調(diào)卡住其他路的回調(diào)全部排隊等待。另一個常見原因是每路預(yù)覽共用了同一個渲染窗口SDK 內(nèi)部需要在同一窗口上反復(fù)切換繪制目標導(dǎo)致效率急劇下降。解決回調(diào)函數(shù)里只做兩件事拷貝數(shù)據(jù)或投遞消息不要做任何解碼、編碼、文件寫入。一路預(yù)覽對應(yīng)一個獨立顯示窗口不要共用。如果需要保存視頻流在回調(diào)里把原始碼流快速寫入內(nèi)存隊列由獨立的寫盤線程處理。開發(fā)階段不要把 SDK 的調(diào)試日志級別設(shè)成 DEBUG日志輸出本身就會拖慢回調(diào)。5.4 抓圖保存的文件打不開現(xiàn)象抓圖接口返回成功目標目錄里也有文件但文件大小為 0 字節(jié)或者用看圖軟件打不開。原因目錄權(quán)限不足程序沒有寫入權(quán)限文件名沒有擴展名系統(tǒng)不知道用什么格式打開抓圖動作發(fā)起太快設(shè)備還沒送出第一幀圖像SDK 抓了個空或者抓圖與錄像同時發(fā)起被設(shè)備固件靜默忽略。解決先手動創(chuàng)建目錄并檢查寫權(quán)限。文件名用時間戳加 .jpg 后綴不要用無擴展名的方式。在預(yù)覽啟動后等待“首幀到達”事件再允許用戶點擊抓圖按鈕。抓圖和錄像按鈕之間做互斥同一時刻只允許一個操作。5.5 Demo 在調(diào)試器里正常雙擊運行就崩現(xiàn)象在 IDE 里 F5 運行一切正常但雙擊 exe 運行時直接崩潰或者提示缺少動態(tài)庫。原因工作目錄不同。IDE 運行時的工作目錄通常是工程目錄動態(tài)庫和配置文件放在那里能找到雙擊 exe 時工作目錄可能是系統(tǒng)目錄或桌面相對路徑全部失效。另一個原因是依賴的運行時庫或 DLL 沒有拷貝到 exe 同目錄。解決把所有 SDK 動態(tài)庫和第三方依賴庫統(tǒng)一放在 exe 同目錄。程序里不要使用裸的相對路徑基于當前 exe 所在路徑拼接日志和配置文件路徑。目標交付機器上如果還提示缺少運行庫把對應(yīng)的 VC 運行庫安裝包一并帶上。我自己的習(xí)慣是打完包之后在一臺干凈的虛擬機里雙擊運行一次能過才算交付。6. 讓 Demo 走向能交付網(wǎng)絡(luò)異常重連、時間同步和日志三件事Demo 能跑通只是起點真正交付使用時現(xiàn)場網(wǎng)絡(luò)抖動、設(shè)備斷電重啟、NVR 時間不準都是常態(tài)。我自己的經(jīng)驗是把下面三件事做好客戶端才能從“能用”變成“好用”。第一件事是網(wǎng)絡(luò)異常重連。SDK 通常會有斷線回調(diào)你要在這個回調(diào)里做“自動重新登錄 重新啟動預(yù)覽”而不是把錯誤彈給用戶讓他手動重啟程序。重連要加去抖邏輯第一次失敗等 2 秒第二次等 5 秒最多 30 秒避免設(shè)備還沒起來你就一直高頻重試。重連期間界面要保持可操作按鈕顯示“連接中”。另外重連成功后要把之前所有通道的預(yù)覽狀態(tài)恢復(fù)這一點最容易漏。第二件事是設(shè)備時間同步。DVR 錄像回放依賴設(shè)備時間軸如果設(shè)備時間不對回放時間段怎么都檢索不到錄像。客戶端啟動登錄成功后把本地時間寫入設(shè)備這一步在 Demo 里通常沒有但現(xiàn)場幾乎必用。注意有些設(shè)備允許校時的窗口很小只接受誤差在幾分鐘內(nèi)的校時可以先獲取設(shè)備時間再決定是否寫入。第三件事是日志系統(tǒng)。Demo 里常見的 printf 到控制臺的做法交付現(xiàn)場根本不可用。我在工程里加了一個簡單的分級日志模塊按時間自動分文件保留最近 7 天。所有 SDK 錯誤碼、登錄結(jié)果、預(yù)覽啟停、重連動作都寫進日志?，F(xiàn)場反饋“連不上”的時候第一件事就是翻日志看錯誤碼和重連記錄往往一分鐘就能定位問題。這幾件事做完客戶端才具備基本的可維護性。說到這想提一個我自己的教訓(xùn)早期做某跨平臺系統(tǒng)的監(jiān)控客戶端時重連邏輯做了但沒做重連次數(shù)限制結(jié)果設(shè)備停電檢修期間客戶端每 3 秒重連一次把現(xiàn)場網(wǎng)絡(luò)打滿了最后我只能現(xiàn)場改代碼、重新打包。從那以后凡是涉及自動重連的代碼我一定會加退避機制和最大重試次數(shù)。這個習(xí)慣也推薦給你。希望幫到你。本文還有配套的精品資源點擊獲取