视频监控设备二次开发那些事儿（一）
从2012年从事IT行业，一进来就开始做视频相关的开发，到目前已经有五年多了。从使用第三方视频监控平台，到后来自己写设备接入网关，一路起来，踩过许多坑。现在公司正在运行的代码已经是补丁摞补丁，惨不忍睹。很想花几个月时间重新做一套，旧项目的维护工作，以及新项目又拿这套平台去部署，感觉已经尾大不掉了。但还是希望有机会推翻重做，更好的方案已经在头脑中，有机会就开始实施，没机会也要创造机会实施。今天就先说一下视频设备开发中遇到的那些坑。
1、最大的坑，二次开发SDK的耗时接口。其实不管是windows平台还是linux平台下，总会存在耗时函数，比如网络通信的connect，不设置套接字为非阻塞，windows平台有做过测试，可达5分钟。下面开始说视频设备的耗时接口。首先，设备登录接口。部分厂家SDK还算友好，提供异步接口，登录成功或失败都通过回调函数输出。但部分设备不支持异步登录，如果设备不在线，其登录接口阻塞长达10s+。你可能会说，可以开线程登录啊，一个线程不够使用线程池啊。我们也确实这样处理的，带来的代价就是，开线程数量一定要控制好，如果不在线的设备多了，线程开少了，一次重登录轮询，可能还登录不完所有设备。当然也可对单个不在线设备创建定时器控制登录，不过复杂度也会相应增加，这就需要对项目成本、周期等因素做一下平衡了。
切记，使用线程锁千万别把耗时接口锁进来，不解释了，估计大家也懂。
案例：宇视IMOS_SDK的登录接口、查询录像/录像回放接口（部分异常情况下会阻塞）。
2、异步消息不返回上下文指针或者指针无效。我想说的是，异步消息回调务必一开始就做测试，如果我说的问题正好存在，将会影响你的架构。一般情况下，C++传递回调函数，一般是将类的静态成员函数做为回调函数传到SDK接口中，顺带把类的this指针传递进去。有异步消息输出时，把this指针再传递回来，这样可以使用/修改类的成员变量。记得第一次遇到这种情况时，另一个同事写了设备管理类，我负责实现单个设备操作类。可代码写好测试的时候，发现传递进去的指针跟回调输出出来的不对，这尼玛当时就懵了。当时跟设备厂商存在竞争关系，对方当然不愿意改，另一方面，消息回调传出的设备登录ID是有效的，可做区分。于是，活生生的把一个instance类写成了manager，用了单例模式，总比全局变量要好些吧。由于当时同事写的管理类已经与其他模块对接好，最后变成了manager管理多个item，而这多个item的instance指针其实是尼玛同一个。后来在使用宇视IMOS_SDK时，也发现同样的问题。
注意：使用第三方SDK异步接口时，请检查设备回调接口中有没有上下文指针（或叫做用户数据指针），如果有，检查一下是不是正确的（如果不正确，一般可以找设备厂商修改，特殊情况就不说了）。
案例：不再叙述。
未完待续...