场景需求：
小爱音响、Wifi灯泡、WIfi插座等物联设备在未联网之前使用Udp广播的方式来配置其连上云端。
Smartconfig智能配网:
在未连上网时，设备会在其支持的信道上轮询，监听周围发出的广播或者组播报文。这里会有一种叫“导向码”的东西，这是开发人员约好的一种“敲门砖”，设备一开始并不是监听全部的数据，而是只监听约定长度的导向吗，当设备监听到的Udp报文与其约好的“导向码”相匹配时，设备会接着解析接下来的Udp数据。
鉴于UDP包长度可控的优势，设备配网的广播包由以下组成：
密文长度 = 20 + 8 + 应用层数据长度 + 算法相关的常量C，
就App端的工作而言，除了与硬件工程师定义好的算法相关常量，其余的就是smartconfig的主要工作，即将设备需要的信息（wifi、密码）转换成指定长度的由“1”构成的字节，往数据层中填充，让设备端解析。这个比较抽象，大致就是告诉设备我们传输的数据的方式不是报文内容，而是报文的长度，我想告诉你的是5，那么我就给你发5个1，因为我的数据长度是5。这个时候设备可以反劈（开玩笑的））
需要注意的是，UDP中需要减去IPV4 20个字节的头及8个长度的UDP头
算法常量是20。手机APP要传输888这个数据，则在UDP报文内容中填充88-20(Ipv4头)-8(UDP报头)-20（算法常量）个字节
前导码：前导码是为了让手机告诉设备，我要开始了！
一般会让我们的蓝牙循环播放一组前导码，并且持续一段时间（这段时间是经过硬件工程师和前端的反复调试，得出的前硬件模块导码发现和分析的时间而定），因为我们是无法得知设备在哪一步。
数据码：
我们的wifi名称为miwifi,密码为1234，这就需要和我们的硬件工程师大佬定义流程，告诉他哪些字段是名称哪些是密码，如下：
- APP连续发送N个UDP广播包，前导码。
- APP发送1个UDP广播包，IP报文数据长度为’n’-8。（8我们自己定义的常量，硬件设备会在此上+8）
- APP发送1个UDP广播包，IP报文数据长度为’a’-8。
- APP发送1个UDP广播包，IP报文数据长度为’m’-8。
- APP发送1个UDP广播包，IP报文数据长度为’-’-8。
- 传输wifi名称
- APP发送1个UDP广播包，IP报文数据长度为’p’-8。-
- APP发送1个UDP广播包，IP报文数据长度为’w’-8。
- APP发送1个UDP广播包，IP报文数据长度为’d’-8。
- 传输wifi密码
- 发送终止符
- 再次发送前导码
- 循环
这些工作使我这个切图仔压力山大，做花里胡哨的界面，还得会计算机原理运算了解OSI七层模型，这好像是大学大二的课程。
同学们并不需要焦虑，如果真的对数据帧、高低位、或与非了如指掌，那为什么来做前端🐶🐶🐶
配网成功，走上正轨
在发送UDP的过程，我们的设备也没有闲着，需要向服务器轮训请求设备状态（ajax请求），那么我们前端怎么知道新添加的设备是眼前的设备，而不在遥远地方的其他设备呢？这就需要我们眼前的设备配对完成后，将他的sku，设备的型号，配对的wifi名称存进云端服务器，服务器会告知前端。所以，我们设备配网的时候，会要求APP接入wifi，这也是原因之一
注意事项iOS,不少H5+ APP的iOS APP发不出广播主要因为用户权限设置，除了需要使用Wifi的权限，还需要用户添加扫描本地连接设备的权限。某些设备设置不会弹出让用户添加本地设备的授权框，因此需要在发广播包之前最好进行下相应的权限检验。
