視頻監控設備二次開發那些事兒（一）

    從2012年從事IT行業，一進來就開始作視頻相關的開發，到目前已經有五年多了。從使用第三方視頻監控平臺，到後來本身寫設備接入網關，一路起來，踩過許多坑。如今公司正在運行的代碼已是補丁摞補丁，慘不忍睹。很想花幾個月時間從新作一套，舊項目的維護工做，以及新項目又拿這套平臺去部署，感受已經尾大不掉了。但仍是但願有機會推翻重作，更好的方案已經在頭腦中，有機會就開始實施，沒機會也要創造機會實施。今天就先說一下視頻設備開發中遇到的那些坑。

    一、最大的坑，二次開發SDK的耗時接口。其實不論是windows平臺仍是linux平臺下，總會存在耗時函數，好比網絡通訊的connect，不設置套接字爲非阻塞，windows平臺有作過測試，可達5分鐘。下面開始說視頻設備的耗時接口。首先，設備登陸接口。部分廠家SDK還算友好，提供異步接口，登陸成功或失敗都經過回調函數輸出。但部分設備不支持異步登陸，若是設備不在線，其登陸接口阻塞長達10s+。你可能會說，能夠開線程登陸啊，一個線程不夠使用線程池啊。咱們也確實這樣處理的，帶來的代價就是，開線程數量必定要控制好，若是不在線的設備多了，線程開少了，一次重登陸輪詢，可能還登陸不完全部設備。固然也可對單個不在線設備建立定時器控制登陸，不過複雜度也會相應增長，這就須要對項目成本、週期等因素作一下平衡了。

        切記，使用線程鎖千萬別把耗時接口鎖進來，不解釋了，估計你們也懂。

        案例：宇視IMOS_SDK的登陸接口、查詢錄像/錄像回放接口（部分異常狀況下會阻塞）。

 

    二、異步消息不返回上下文指針或者指針無效。我想說的是，異步消息回調務必一開始就作測試，若是我說的問題正好存在，將會影響你的架構。通常狀況下，C++傳遞迴調函數，通常是將類的靜態成員函數作爲回調函數傳到SDK接口中，順帶把類的this指針傳遞進去。有異步消息輸出時，把this指針再傳遞回來，這樣可使用/修改類的成員變量。記得第一次遇到這種狀況時，另外一個同事寫了設備管理類，我負責實現單個設備操做類。可代碼寫好測試的時候，發現傳遞進去的指針跟回調輸出出來的不對，這尼瑪當時就懵了。當時跟設備廠商存在競爭關係，對方固然不肯意改，另外一方面，消息回調傳出的設備登陸ID是有效的，可作區分。因而，活生生的把一個instance類寫成了manager，用了單例模式，總比全局變量要好些吧。因爲當時同事寫的管理類已經與其餘模塊對接好，最後變成了manager管理多個item，而這多個item的instance指針實際上是尼瑪同一個。後來在使用宇視IMOS_SDK時，也發現一樣的問題。

        注意：使用第三方SDK異步接口時，請檢查設備回調接口中有沒有上下文指針（或叫作用戶數據指針），若是有，檢查一下是否是正確的（若是不正確，通常能夠找設備廠商修改，特殊狀況就不說了）。

        案例：再也不敘述。

      

        未完待續...