导语丨作为离用户和物联网设备最近的前端，在物联网三部曲中扮演什么样的角色呢？这两年来腾讯云物联网探索出了“腾讯连连”小程序，提供了一系列开源的开放能力，和更多的物联网开发商和爱好者一起打造生态。本文是对腾讯云专家工程师陈慧中在云+社区沙龙online的分享整理，希望与大家一同交流。

一、物联网设备及腾讯连连简介

物联网的基础概念就是人与物相连、物与物相连的基础设施，跟互联网一样，都是基础设施。物就是物联网设备，说到物联网设备大家脑子里可能就会浮现那张增长很迅速的物联网设备增势图，到了 2020 年预估可以达到百亿元的规模。

这说明了物联网设备是呈指数级增长的，是以一种井喷的方式在增长，这也体现了物联网的前景是非常广阔的。

主题里面提到的连接智能就是指智能设备，大方向是结合本地或者云端 AI 能力的物联网设备。参与一些论坛的时候大家会把 AI 和 IoT 一起来讲，缩写为 AIoT。今天我们先从基础的设备讲起，这样也有利于大多数的听众接受。

物联网设备的分类有很多维度，第一个维度是设备上云的方式。因为物联网就是设备和人的连接，连接肯定是通过互联网完成的，而设备怎么上云呢？

基本有两种方式，一是设备直连，直接和云端通讯。另一种是子设备通过网关跟云端建立连接。这里比较特殊是蓝牙设备，需要通过手机、蓝牙网关的蓝牙通信再进行云端连接。

网关和子设备的连接方式，它的拓扑图可以是星状的、网状的、树状的，可以适用于很多场景的子设备和网关的连接。

云端连接都是双向通知，云端需要控制设备，设备端也要去云端推送消息。这里涉及到物联网的基础协议 MQTT 协议，它其实就是发布订阅者模式的一种网络架构，有兴趣的同学可以查阅资料了解。在手机端，websocket 也可以提供相应的功能，达到同样的效果。

大家可以看到图片中的网关既有无线信号，又有一些串口是有线的，这就体现了另外一个设备划分维度：以通信方式为维度。通信划分的大类很简单：有线和无线。

有线设备中一是光缆，通过家里的网口和 USB 连接，家里有搭建过家庭视频监控体系的话，有线视频监控体系就是通过 USB 或者网口连接到中央硬盘录像机的。二是串口通信，它在工业领域用得比较多，好处是它可以通过 C++ 和其他一些语言进行编程。

无线通讯领域分成局域网和广域网，最贴近我们生活的局域网领域的设备分类就是 Wi-Fi 设备，通过连接家里的路由器和云端通信，还有蓝牙设备，它可以和设备之间组成网状的网络拓扑，可以达到设备间的通信。

另外一部分无线通讯中的广域网的领域，一是运营商网络，比如3G、4G、5G。还有一部分是广域网单独拎出来的低功耗广域网，这类设备的功耗比较低，有两大分类，一是 NB-IoT，二是 Lora。NB-IoT 是基于运营商网络搭建的低功耗网络，目前普及率比较高，针对每种设备也有自己的优势和劣势，这里不做赘述。

有些设备具备两到三种通信方式，这样的结合可以扬长避短。举三个例子，一是 Wi-Fi 和蓝牙的结合，因为 Wi-Fi 功耗比较高比较耗电，蓝牙功耗比较低，它的连接是可靠的，而且抗干扰性比较强，它们俩的结合在 Wi-Fi 设备配网的时候可以提高成功率和便捷度。

二是蓝牙和 3G 网络的结合，以 Apple Watch 3G 版为例。第三是和NB-IoT 的结合，蓝牙可以做到短距离间的物体和物体的通信和精准定位，可以兼顾到远距离的数据传输，虽然设备的大类并不多，但是它们各个在自己领域发挥优势和它们的结合可以适用很多应用场景。

首先，要开发一个物联网设备的时候，主要要兼顾到端对端的安全，要确保设备后面跟云端通信的时候，数据通信是安全的。一般会用到证书或者密钥认证，调试功能对开发的效率提升也很明显。

第二步是设备量产之后用户怎么连接，连接就涉及到蓝牙或者是配网方式，让设备上云，还有一个维度是设备要在云端注册。

第三步是设备的控制，云端需要对设备进行控制，在一些与人强交互的设备领域也需要 C 端有一个强大的控制面板，针对设备的某些属性进行精准控制，还有设备的上下线的处理。

另一个维度设备和设备间的联动，有些时候是需要云端去分析控制的，比如家里的温度传感器，温度达到 30 度以上，需要去开启家里的空调，这样的场景联动维度。

第四步是开发者需要监控设备的健康度，去搜集它的日志，也要对其数据进行分析，辅助商业上的决策或者其他的用途。

随着产品的迭代，还需要更新固件，不可能让用户买了设备后有产品更新就要再买一个，这不是一锤子买卖。

最后一步是设备不用了、下线了，需要做云端的删除和清理数据。

虽然有六步，但是其中的连接、控制和监控是设备最活跃的一段时间，对应到人的生命是像我们的中年阶段。从技术方面讲，这个三个阶段涉及技术点和难度也比较大。

产品方面，腾讯云 IoT 致力于帮助广大的物联网开发者做好设备生命周期管理中的基础设施建设，保证功能的易用性、完整性和性能高可用性，让开发者只需要关注自己业务逻辑即可，这样以最短时间发布产品抢占先机。

在整个物联网产品开发平台架构图如下：

如图所示，开发者可以在物联网开发者平台去开发调试这个设备，在控制台去看这个设备的监控日志、数据分析等等。同时，腾讯也推出了 C 端的应用腾讯连连，去帮助用户做设备管理，设备管理包括设备的连接、交互、更新、删除等等，可以进一步的缩短开发厂商设备量产的 C 端产品开发流程。

腾讯连连当初为什么要做小程序呢？大家对小程序也有所了解，小程序的优势在于安装便捷、给一个二维码就可以打开了，不像 APP 的安装那么繁琐，它跟微信里面的关系链是强绑定的。

物联网设备也是跟人强绑定的，家居领域、企业领域都是需要跟一群人交互的，它的优势在于这里。而对于开发商来说，小程序可以用一种语法在两端运行，不需要处理安卓、IOS 端的兼容性问题，可以大大的减少缩短开发周期，而且可以精简开发智能角色一个前端就可以搞定以前要两个端的开发人员做的工作。

如果基于用户来讲，腾讯连连也是 2B 的，开发商用户都有的诉求点肯定是要去实现的。腾讯连连在做之前也去采访调研过，发现业界对于小程序端做设备的控制管理是有很多顾虑的，因为认为微信小程序提供的底层接口并不够强大稳定。

但是我们仍然觉得没有做不成的事情，只有做不成事情的人，所以预研了现有的能力基本上可以支持。微信内部也很支持 IoT 领域的功能建设和性能优化，所以腾讯连连就开始做了，事实证明我们也做到了，为了适用更多场景，比如国外用户或者是其他的场景，我们也提供了连连的 APP 版本和相关 SDK。

二、腾讯连连在设备连接的能力与建设优化

首先是 Wi-Fi 类设备，Wi-Fi 类设备上云需要有 5 个步骤，因为 Wi-Fi 设备刚开始是什么都不知道的，它是被买到家中，需要别人告诉它家里路由器的密码和 SSID。所以第一步是手机端需要把 SSID 和密码告诉设备，设备端知道后连接路由器的 Wi-Fi。

设备和手机都在路由器的局域网里面，它们通过局域网通信设备端可以告知APP当前的设备三元组信息（设备基础信息），设备可以直接去云端注册这个设备，注册成功后手机端就可以云端把设备绑定到自己的名下。

解释两个概念，一是狭义配网的概念，第一步就是传输 SSID 和密码，为了达到这一步有蛮多的配网方案，我们把它叫成狭义的配网。二是广义的配网，广义的配网是绑定设备成功，这样设备才能具备跟云端通信的能力，这是广义配网的概念。

小程序端的连接遇到的挑战，主要是手机在狭义配网怎么将路由器的 Wi-Fi 信息告知设备，后面的绑定操作直接调一个接口就可以了。

Wi-Fi 对设备的适用场景和普及率非常高，在一些不便有线连接的环境，物理空间也有限制的环境用 Wi-Fi 设备就可以很简单的进行设备上云。需要和其他设备进行通信的情况下，因为设备都在一个局域网里面，可以通过TCP或者UDC进行通信。

Wi-Fi适合适合兼容性比较高的场景。而兼容性有两个维度，一是设备需要在世界任何一个 Wi-Fi 里面都可以正常连接，这一点是 Wi-Fi 联盟去保证的，因为 Wi-Fi 认证是向下兼容的而且指定了全球统一的标准。

另一个维度是：在配网时候任何一台有 Wi-Fi 功能的手机都可以正常进行配网，这不用担心。就我们的认知而言，智能机从 iPhone 4 开始就有 Wi-Fi 能力了，当然它也有问题和弱点，就是其功耗非常高。它是基于2.4G频段的，抗干扰能力比较弱，所以目前的市场是逐步在缩减的，当然，这里只是给大家一个大致的概念。

我们可以看看 Wi-Fi 的狭义配网，设备端获取 SSID 和密码主要分两个方面，一方面是标准配网方式，另一方面是一键配网方式。

标准配网是兼容性比较高的配网方案，现在的模组厂商一般都会支持。一键配网是各个厂商为了提高用户体验，提供的一套具有私有协议又有安全性考量的配网协议，包括微信的 AirKiss 协议。

目前我们已经从微信接管了这套协议的后期维护。乐鑫 esptouch 的 smartconfi 协议，realtek 的 simpleconfig 协议等等，其他还有很多，我们这里只列出来腾讯连连现在支持的配网协议如图：

低功耗和 Wi-Fi 结合的场景、双模配网的场景也被列在一键配网的维度里面，这些我们也是支持的。

有了狭义配网的基础后，下一步就是去调研微信小程序有没有这样的技术能力。目前基本上都是基于这三个能力进行开发的，一是连接 Wi-Fi 的能力，二是 UDP 通信能力，三是蓝牙通信的能力。腾讯连连也基于这个技术能力展开了开发。

简单介绍一下配网的协议：设备端生成一个热点，手机端去加入这个热点，加入热点之后小程序和设备就可以进行 UDP 通信，小程序把 Wi-Fi 信息和配网信息发给设备，设备就可以正常连接到路由器。这时候小程序也需要把自己网切换到路由器。设备有上云的能力后就去注册这个设备，当然，这里面肯定还会涉及到一些安全的考量。

注册设备后，手机端去轮询这个设备注册状态，成功之后绑定这个设备。那么为什么不直接由设备端告诉小程序端设备的注册状态？

这是刚开始的流程，因为小程序的基础接口 connectWi-Fi、UDP 通信是有失败率的，所以导致如果设备端直接告知小程序端注册状态的话，会有一些失败率。

而且 UDP 是面向非连接的，有一定的丢包率，所以导致告知小程序端注册状态的时间会比较长。根据这个成功率和时间的考量，我们就改了一下流程，由小程序端自己轮询后面的状态，对成功率和耗时都有帮助。

SoftAP效果展示，设备端的日志贴出来，在 Wi-Fi 配网开发过程中设备端日志很重要，这会大大节约开发的时间，对后期问题的定位也很有帮助。目前我是在 SecureCRT进行设备端的连接和日志的抓取，也可以打 AT 指令来切换 SoftAP，效果也很直观。

这个整体流程有四步，对用户体验有些影响，小程序端接口端需要调用两次 Wi-Fi，但因为是兼容性比较强的协议，所以目前普及率也非常高。

一键配网的基础原理都是类似的，先是设备需要切换到混杂模式，可以抓取到附近的路由器转发出来所有的广播包信息，手机端同时创建一个 UDP Client发包，创建UDP Server抓取包。之后就开始广播 Wi-Fi 信息，设备端抓取到了以后，因为设备没有加入路由器没有密钥，只能解析包头，从包头里面解析到 Wi-Fi 信息后就连接路由器。

这时候又涉及到小程序端比较特殊的地方，就是小程序端没有接口可以获取到本机的 IP，所以设备端是无法直接给小程序端回包的。

这里有两种方式可以做，设备端连接完路由器后继续监听小程序端发的广播包，因为都在一个局域网里面，所以就可以拿到源 IP。

另外一种方式设备端广播回包，小程序端也正常可以收到回包。小程序端收到回包后会去验证这个包的合法性，验证通过后去注册设备、轮询设备状况等等。

这中间有一些比较难理解的点，首先是混杂模式，它可以接收附近环境中所有的 802.11 的报文。针对一个报文而言，因为没有在局域网通信，设备端也没有加入到路由器，收到的包都是加密的，如果没有得到路由器的密钥是无法解包的，所以Body部分无法解析，只能解析包头和报文长度这两个信息，Wi-Fi 信息只能放在这两个里面。

广播地址是4个255，组播地址是保留的D类地址，可以映射到目标MAC地址里面，也是固定的头+IP地址的 23位。

通过网卡抓包和工具打印出来包的信息可以看下面的表格，目标MAC地址上面是广播地址，下面是组播地址。可以承载信息还有包大小。

目前腾讯连连小程序支持的一键配网协议用的发包方式和承载信息方式，SmartConfig是组播和广播都支持。但是是把信息放在包体的长度里面，组播广播方式只是用来规避一些 5G 和 2.4G 路由器兼容的情况下的成功率问题。

SimpleConfig是使用组播的方式，信息编码放在了组播目标Mac地址里面，Airkiss是使用广播的方式，信息放在包体长度里面。

说下最后两列，目前在我调研下，业界只有连连小程序支持这三种一键配网的方式，这个也是我们当初做这个事情的动力，可以在这里实现差异化。展示一下一键配网的效果，可以看到最直观的感受它的交互流程比刚才的少了一步，只需要填写 Wi-Fi 路由器的 SSID 和密码就可以发起连接。

刚才两种配网方式并不是互斥的关系，很多应用场景里面它们是并存的，这样能够提高整体的成功率。

下面实现的这个部分并不是很容易，遇到了很多很多挑战，我们截取三个方面来一一说明。

刚才也有提到，UDP 通信接口的稳定性兼容性强依赖于小程序底层的，有些时候作为上层很无奈，因为它不可控制。但是并不是什么也不能做，针对相应的错误是可以做包括但不限于以下三种处理方式：

• 规避性的自动处理方案；

  
  

• 可以做提醒让用户操作；

  
  

• 反馈给微信让其不断改进。

  
  

这三步都有做也有成功案例，说这么多有些抽象，举一些例子，比如:

在一键配网的时候定时发广播包，频率很密集，要求在 5 到 10 毫秒之间，这样设备端混杂模式监听切换频道才能正常解析。但是在一些安卓手机发包的时候，发现有些频率可以达到一秒以上，造成设备解析不了，成功率很低。

在连接设备热点的时候有些安卓手机底层判断这个热点没有 Wi-Fi 连接的时候，不会使用这个热点，但是上层发 UDP 包的时候并不会报错，不过这个包会被丢掉。

在发UDP包的时候如果中途退出微信再打开微信配网的时候就会报错。

第二个挑战是：针对于一键配网的协议实现的时候，这些厂商并没有提供小程序端的 SDK 和源码。因为他们开发的时间比较久了，也没有相关的配网文档，在自身团队而言也比较缺乏小程序端二进制流处理和加密的经验。

针对这样的困境，我们和产品同学一起找了厂商授权，厂商提供了 APP 端的 SDK 和源代码或者是安装包我们可以进行解读和翻译，过程也很麻烦，调试的时候需要把 APP 跑起来，这样对小程序的转换结果进行比对，会有一些 APP 支持的接口、小程序不支持的，比如小程序得不到手机端的 IP 等等，我们都结合设备端把这些问题解决掉了，也体现在整体配网流程方案里面。

第三个挑战是定位问题，因为 Wi-Fi 配网是很长的流程，涉及到小程序端、路由器、设备端，而且流程也很长，哪一步出错了，设备端出错还是小程序端出错都需要有很强的监控能力。这样开发厂商或者是 C 端用户反馈问题的时候也可以精准和快速的定位到问题。

因为开发调试的时候意识到设备端日志的重要性，光靠小程序的日志或者是后台日志并不能很快的定位问题。那么如何去搜集设备端的日志，有没有通用的方案呢？

面对这些挑战，我们优化了整体的设备端 Wi-Fi 类配网的流程，也会涉及到刚才的挑战的解决方案。

开始配网时，因为 Wi-Fi 失败率比较高，会有 2% 到 3% 的失败率，失败也是需要可以让用户在系统设置页手动连接的，如果有了手动设置连接后面配网流程仍然可以继续，这样增高了一定的成功率。

成功后就要开始创建 UDP 通信，这个时候又涉及到 IOS 端和安卓端发包的区别。现在在开发小程序的时候会用ES6，ES6支持同步写法，但是小程序端混合微任务（Promise）和宏任务（SetTimeout）写法会有 bug，会造成频率会一秒以上，不会达到 5 毫秒到 10 毫秒。

所以我们在安卓端异步写法发起配网包，IOS 还是用优雅的同步写法发起配网包，得到设备端回包地址后发设备的配网，通过 UDP 通信来做。当时这里要提到的是微信在新版本里面已经修复了这个问题。

因为 UDP 通信是面向非连接的，有一定的丢包的可能性，所以设计了重试的逻辑之后绑定设备整个流程结束，所有的流程有错误事件的监听，记录整个操作轨迹、报错的详细信息。

当出现出错的时候可以去判断错误的类型，针对有些错误类似去做错误处理，比如在实际配网的时候 Wi-Fi 如果被切换的话，可以去识别到再把它重新加到正确的 Wi-Fi 面自动进行配网，这样也可以增大成功率。

另一方面，如果出错了，还有一个通用的设备端日志搜集的逻辑，原理也不复杂，就是在设备端起一个热点，手机端连接这个热点简单的验证通过了后设备端会把日志发给小程序端。小程序端搜集了以后集体上报，后台、前端和设备端的全息日志都会被存在日志后台，这个日志除了有定位的功能也有帮辅助分析成功率、耗时的重要信息。

辅助配网的流程，设备端会起一个蓝牙的广播服务，手机端、小程序端可以连接这个蓝牙，在这个蓝牙通信的过程中把刚才的 Wi-Fi 和 UDP 通信的信息都可以交换完成。

因为蓝牙服务底层 ATT 所有命令都是必达的，会让整个数据传输可靠性非常高，现在运用这种辅助配网的模组也越来越多。但是它的弱点在于其成本比较高，比纯 Wi-Fi 设备配网高一倍。

BleCombo 多了一步连接设备蓝牙步骤，刚才说到整个配网流程会记录日志从而分析成功率和耗时，从而不断的提升连接体验。

蓝牙设备的上云交互流程很简单，手机端或者是网关连接蓝牙设备后，蓝牙设备可以交换三元组信息，手机端搜集了之后可以云端绑定这个设备。

蓝牙设备适用于一些低功耗短距离的应用场景，也可以支持多对多通信的场景，位置服务和设备网络应用比较适用，但问题在于其兼容性比较低，随着终端设备的不断快速升级，兼容性也会越来越好。

低功耗蓝牙兼容性上很不错，但是经典蓝牙一般。蓝牙也正在逐渐占据物联网通信协议的主要地位。

蓝牙设备遇到的挑战，一是代码架构设计上的，因为蓝牙方面开放形态有蓝牙连连插件、应用端SDK、和自定义的 H5 SDK，直接蓝牙设备的连接因为蓝牙设备是很多的，但是每一个设备并没有通用的蓝牙传输协议，都是每家自己定义的，腾讯连连也不可能一家家的支持，给到自定义 H5 的开放方式，让开发商自己解析蓝牙协议。

那么怎么去达到复用呢？腾讯连连把蓝牙解析的逻辑放在了每一种蓝牙设备的适配器里面，把一些底层的逻辑，比如设备管理、处理设备绑定一些云端逻辑和设备蓝牙连接和蓝牙状态管理的逻辑作为一个底层 的SDK，这样右侧就是底层的 SDK，三个开放形态直接去安装就可以了，可以按需引用蓝牙解析的协议适配器。

挑战二在于蓝牙通信的过程底层会交换 MTU 值，但是小程序端并没有现成接口获取这个设备端的 MTU，造成传输数据大小无法确定，设备端可以分片传过来解析，但是小程序不知道 ，造成发包数据过大设备端接收失败。

针对这一点，腾讯连连在设备端增加了协商 MTU 大小的服务，这样小程序端就可以拿到 MTU 进行手动分片。

第三个挑战是调试，因为解析协议有很多逻辑，还有二进制流的处理如果都需要放在真机上调试，这个效率非常低，我们最基础能够做到的是改变代码习惯，代码检查暴露问题等等，但是后面会讲到的自定义 H5 是可以辅助在浏览器调试的，以提升效率。

三、腾讯连连设备在交互的能力建设与优化

腾讯连连的控制面板主要分为三类：标准面板、H5 个性化面板和免开发面板。H5 个性化面板可以让开发商自己在设计规范里提供自己编写的业务逻辑去渲染整个面板。免开发面板针对比较通用的模型做自开发面板，用户自己直接使用。

自定义 H5 架构底层是基于一个 H5 的框架，在小程序内嵌 webview 里面打开，从下往上看，我们提供有限的应用端 API 给到上层调用，中间一层通过蓝牙的 webview 转发和微信的 JSSDK 提供微信支持 webview 里面的 JSSDK 调用，比如扫码等等。上层提供了自定义 H5 开发的 SDK，就可以跑厂商生成的 JS、CSS。

自定义 H5 架构提供了三大类 H5，设备控制 H5、标准/自定义蓝牙设备搜索 H5 和 标准/自定义蓝牙控制 H5。自定义蓝牙搜索的H5，搜索页实现设备绑定，标准和自定义蓝牙的设备控制去做远程控制和事件上报。

那么怎么实现蓝牙通讯呢？因为 webview 里面 H5 不能直接蓝牙通信，所以我们设计了 websocket 层进行了蓝牙消息的转发，性能达到毫秒级别。厂商的 JS 和 CSS 可以接受任何技术栈，整个流程是先在第一位调试、发布、之后后台审核，之后外网可见，还可以进行升级和回滚。

重点说下调试模式，因为对于开发者而言，开发时调试很重要。连连小程序内开放了一个调试的入口，这样可以生成 H5 的调试地址，调试地址可以在微信公众号和浏览器打开，会验证控制台、登录台，从而验证当前的 ID 的权限，生成一个调试设备 ID，代理本地用厂商自己生成的 JS，这样就可以渲染出页面，也支持热更新，这是整个的调试模式。

作为自定义 H5 的框架，很多东西也需要保证，比如稳定性。自定义 H5 的框架是使用SCF，它支持监控和自动扩缩容，也做了 ES 全系日志实时分析告警。

安全性方面在开发调试时候要限制用户的白名单，这样开发调试时候厂商的页面也是不能被外网用户看到的，这样可以保证代码和功能的安全。

应用端API也有权限限制，只能控制该ProductID所属厂商下的设备管理的接口。发布也有审核，也会针对厂商上传的 JS 做安全扫描，整个框架也有 xss、csrf 的技术防护。

四、腾讯连连开源能力介绍

腾讯连连提供了三个方式的开源能力，一是应用端开发的SDK，二是小程序插件，三是自定义 H5SDK。

应用端开发的 SDK 厂商可以基于这个 SDK 进行自有品牌小程序的开发，腾讯连连已经把技术的配网、设备管理的 API 开放出来了。

开源的意义是帮大家提升效率降低成本，前面介绍的整个设备连接能力建设和设备控制能力建设中，有很多很难很繁琐的部分。

难的部分可能大部分的开发都能搞定，但繁琐的部分则需要很多时间打磨，用很多的时间去测试和优化。把繁琐的部分和难的部分我们都搞定并且开源出去就能够为用户提升很大的效率，从而降低成本。

物联网是很特殊的领域，我们需要的并不仅仅是某个产品的成功，而更应该是整个生态的成功。腾讯连连希望通过开源希望跟整个业界都协同起来共建一个生态。

张建林先生说过一句话：“可能过去的五年，你玩的物联网和智慧城市根本就不是物联网思维，而是局域网思维，是画地为牢的死城思维，你的先发优势，很可能是先出发的烈士”。

腾讯云物联网一直用这种忧患思维做自我反思，希望跟大家一起合作，搜集大家的需求并把需求通用化来实现补齐功能，打磨性能、提升体验，从而降低开发者接入门槛，也会帮助定位客户问题，积极响应。

腾讯云接触的很多客户中，包括物联网的开发厂商他们都是没有前端的背景，有些是单片机开发转前端的，我们针对这样的场景也可以开放一些前端能力辅导。

Q&A

Q：腾讯连连后续会出“一碰即连”么，类似 NFC 贴那种？

A：类似于二维码那种配网，我们是有计划支持的，最后提到的是未来的规划，也会紧紧围绕开发厂商的业务需求去开展能力建设，如果你们有这样的需求，我们也会优先的响应。

Q：请问，腾讯连连如何保证大规模介入呢？

A：因为腾讯连连目前是 C 端的应用，每个 C 端用户设备数并不多，问题应该指的是腾讯云的消息通信是不是支持大规模接入？其实现有的物联网设备规模是很大的，但是具体的数字我不公开了，目前我们支持QoS0和QoS1保证，而且并发 qps 也是很大，并且也有多地容灾。

Q：腾讯连连主要是智能家居使用吗？

A：刚开始没有针对适用场景谈设备分类，适用场景是不挑的，支持的是各种通信协议设备的接入，至于这个设备是应用于哪种业务场景是智能家居、智慧城市等等都可以，也推出了腾讯连连的企业板，帮助企业用户管理它的比如智慧楼宇这样的设备连接。

Q：腾讯连连的性能怎么样？

A：刚才说了几个维度，有设备连接、设备交互的维度，每一个性能指标也不一样，如果想知道什么样的性能是可以私下跟我聊的。如果有更深入的分享也会把性能数据比如成功率和耗时同步出来，因为今天的篇幅有限，我就不贴出来了。做事情肯定是以精品的态度去做的，因为支持配网协议也是业界领先的，希望设备连接的性能也是业界领先的，但是这个领先也是需要跟大家一起合作来达成的。

Q：苹果和安卓蓝牙都能打通了吗？

A：微信是提供了这样的已经抹平平台差异的低功耗蓝牙接口，性能也很可靠，我们已经接入了蓝牙设备也有了佐证，在于经典蓝牙的支持，小程序论坛也看得到，经典蓝牙是有计划安卓端支持，IOS 端系统限制还无法支持，但是目前经典蓝牙适用于音频通信和耳机，物联网领域的应用并没有很多。

我说说自己的看法，web3.0与物联网的关系，前端在web里面承担了重要的角色，web1.0 是人与信息的交互，2.0 是人与人的交互，3.0 就是没有定论的。在我的想法里面 3.0 应该跟物联网相关的，就是人与物的交互。

目前物联网领域前端还是不多的，物联网很需要C端场景的前端同事加入一起来打磨 C 端连接设备、控制设备的体验，希望今天听了分享的前端同学如果对物联网领域有兴趣的可以加我微信一起交流。