自从共享单车火了以后物联网应用开发就比较热门了， 甚至一些非物联网的公司也开始切入物联网项目中去，结果用传统的互联网技术和团队开发出来的项目问题多多。核心原因是物联网应用开发本身有一些特殊性需要关注，正好本人从事了多年的物联网软件设计和管理工作，说一说物联网应用开发时应该特别注意的地方。
要知道物联网应用开发的特殊性首先要了解物联网应用与传统互联网项目的使用场景有什么不同。从技术上讲物联网应用与传统项目最大的不同是点是数据产生来源的不同。传统软件或者普通互联网软件的数据都是由人输入的，服务端都要对接收到的数据进行预处理，凡是数据不符合要求时都会返回让用户重新输入数据。举个例子：以用户使用银行APP在线转账为例，如果用户输错了不存在的收款账户或者在转账金额中输入了字母（一般客户端都会对金额输入做控制防止金额栏输入字母这种事发生）那么服务端就会捕捉到这个入参错误并且发回客户端要求重新输入，甚至为了提高开发效率好多开发框架已经把入参合规性检测整合到开发框架中了。
但是物联网的数据基本上都不是靠人工输入产生的，而且好多物联网应用设备长期在高温高湿的环境下使用，只能使用比较低端的操作系统和编程语言，更容易因终端程序错误及网络问题产生数据错乱问题。我把常见问题归类以下下三类并给出解决办法：
1.网络不稳定导致数据包错乱，原因是目前大多数物联网设备采用的是低级操作系统，使用的较底层的通讯协议（主要是TCP和UDP）导致。这里又分两个问题数据包粘包和数据错乱。
(1)数据包粘包指的是终端程序发起的多个数据包被网络层合并起来一起送到服务端，导致服务端无法正确解析数据。
解决办法是约定数据包的包头和包尾，例如以“OX”作为每一个数据包的头和尾
服务端即使收到"OX12345OXOX67890OX"这样的数据也很容易就能把数据还原成"OX12345OX" 和 "OX67890OX"并进行后续处理。
(2)数据错乱指数据在传输过程中被改变了，导致服务端收到的数据是错误的。
解决办法是在发送每一包的数据都增加一个校验位X
服务端每次收到数据先计算校验位X是否正确，如果校验位不正确说明传输过程中数据已不可信，告诉设备重新发送数据即可。
2.通讯超时问题：这里主要指的时终端的数据已经送到服务端，服务端接收数据后通知终端时网络阻塞导致的，
这里的主要问题是终端与服务器状态不一致（终端以为数据没有发送成功，而服务器已经执行了该数据）。
解决办法是服务端要有重复数据处理机制，这里也分两种情况。
(1)不改变业务状态的过程数据：比如共享单车要定时向服务端发送自己所在的位置坐标，当服务器接收到的坐标发现跟之前已经接收过的数据是重复数据时只要丢弃这包数据并告诉终端“接收成功，继续发送下一包数据“即可。
(2)需要改变业务状态的数据：比如学员在学车时先要在教练车的终端设备上做签到，如果9:00分终端向服务器发起签到请求，服务端处理了签到请求并发还给终端设备告知允许签到，这时网络阻塞终端设备没有收到允许签到的回复。这一时刻设备终端学员是非签到状态而在服务端学员已经是签到状态（终端设备的学员状态与服务器端的学员状态产生了不一致）。等到9:01分学员再次尝试签到，这个时候服务端又接收到了签到请求，服务端就需要把学员的签到时间改成9：01分并返回给设备签到成功（这里的处理逻辑与传统程序的处理逻辑不一样了），如果第二次没有产生网路阻塞，终端设备接收到服务端发送过来的允许签到结果后把自己的状态改为学员9：01分签到。最终终端设备和服务器的状态是一致的。
3.终端产生的异常数据：主要原因是大部分物联网终端的应用场景（要求终端体积要小，在室外高温高热环境长期工作）采用的是低级操作系统及开发语言做应用开发，这就需要开发人员人工管理内存（目前的高级开发语言比如JAVA就是系统自动管理内存，不需要开发人员干预），很容易因为内存越界等问题导致数据错乱(例如转账金额变成字母)。这种问题是最麻烦的，因为发回设备重新交互也不会产生正确的结果，只能在服务端把异常数据另外保存起来并记录下终端编号及发生时间，供后续人员排查问题并手工处理异常记录。