视频监控设备二次开发那些事儿（一）

    从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异步接口时，请检查设备回调接口中有没有上下文指针（或叫作用户数据指针），若是有，检查一下是否是正确的（若是不正确，通常能够找设备厂商修改，特殊状况就不说了）。

        案例：再也不叙述。

      

        未完待续...