iOS HomeKit Frameworks 介绍
HAP 的通信机制和安全性
在之前的图例中，我们已经展示了 iOS 设备上的 iOS HomeKit Frameworks是如何工作的，而其中的 HAP 子框架和 HAP 设备之间通信的「语言」正是 HAP 协议。HAP 协议包含了为基于 IP 的设备和基于低功耗蓝牙（Bluetooth LE，以下简称 BLE）的设备设计的两套安全的通信协议。我们可以通过了解 HAP 通信协议一窥iOS HomeKit Frameworks 设备与终端（指 iPhone 等控制端设备）设备日常通信的方式。
image.png
对于基于 BLE 的设备，iCloud 将跨设备同步配对信息，因此可以直接用 BLE 建立设备间的点对点通信。为满足 BLE 的数据包大小限制，HAP 协议还规定了数据包拆分发送的规则。对于基于 IP 的设备，HAP 则充分利用了自家的 Bonjour 协议进行广播和发现，并利用 HTTP 进行通信。iOS HomeKit Frameworks 请求都是由终端设备向 HomeKit 设备发起，然后 iOS HomeKit Frameworks 设备将按要求更新状态并向终端设备返回信息。HomeKit 还规定了包括加密流（stream）传输在内的其他连接形式，但应用较少，我们就不多介绍了。
终端设备每发现一台已配对的 iOS HomeKit Frameworks 设备，就会尝试与之建立会话（session）。iOS HomeKit Frameworks 设备在初始配置时会生成一对永久密钥。二者会根据交换的随机数据和已记录的永久密钥生成一对临时密钥，其有效期仅维持到当前会话结束为止。所有通信均采用带数据校验的对称加密，因此可以保证可靠性和安全性。任何解码错误或连接断开都会结束当前会话，从而最大程度地防范攻击风险。
iOS HomeKit Frameworks 本地运行机制详解
iOS HomeKit Frameworks 设备列表、永久密钥和房间分组等信息由 iCloud 负责管理与同步，而实际的设备控制等操作全部在本地完成。为了保障安全性，终端通过 HAP 控制 iOS HomeKit Frameworks设备的过程相比其它智能家居平台要繁琐不少——当然，这些差异对用户几乎是无感知的。
对于基于 IP 的 iOS HomeKit Frameworks 设备，它们将根据 mDNS（多播 DNS，Multicast DNS）协议在局域网中广播自己的 .local 本地域名（编注：说明自己是谁）和 IP 地址（编注：说明自己在哪里）。mDNS 的原理就好比是在一个随机入住的酒店里，房客可以时不时向所有房间广播自己的名字和房间号，认识他的其他房客会将他当前的房间号保存下来。根据本地缓存的 mDNS 信息，终端设备就可以用固定的域名访问到局域网中的某个 iOS HomeKit Frameworks 设备，而无需担心其 IP 地址发生变化。
image.png
Bonjour 是苹果在十几年前基于 mDNS 和 DNS-SD（DNS 服务发现，DNS Service Discovery）开发的一套软件，它在二者的基础上提供了更高级的接口。iOS HomeKit 框架 设备会使用 Bonjour 注册一个专属服务，iOS HomeKit Frameworks 则通过查询服务信息来判断该设备是否属于当前「家庭」。终端设备同样会与基于 IP 的 iOS HomeKit 框架 设备自动建立会话。如果终端设备有监视 iOS HomeKit Frameworks 设备状态的需求（例如传感器的状态变化通知，或家庭中枢的自动化触发等），它将通过 HTTP 维持一个 TCP 长连接来接收实时消息。
▍iOS HomeKit Frameworks 体验的两大杀手
大量 mDNS 节点、瞬发 HTTP 请求、长连接，这些 iOS HomeKit Frameworks 的行为对路由器产生了巨大的压力，使路由器成为 iOS HomeKit Frameworks体验的最大瓶颈和头号杀手。传统的智能家居平台只需要在每台 IP 设备和服务器间维持一个 TCP 长连接，终端设备的所有控制指令和状态获取都直接向服务器进行请求，再由服务器下发到设备上。而 iOS HomeKit Frameworks 的点对点特性则规定任何指令都需要独立的本地 HTTP 请求，对路由器的瞬时交换能力提出了不小的挑战。
iOS HomeKit Frameworks 创新性地采用了「家居中枢」作为自动化设备。家居中枢位于同一局域网内，HTTP 请求仅有毫秒级延迟。即使是数年前的 A8 芯片，相比其他智能家居设备所使用的芯片依旧拥有碾压级的性能，完全不用担心并行和复杂逻辑问题。由于操作系统「师出同门」，iOS HomeKit Frameworks 家居中枢甚至支持「快捷指令」这样高度自由的自动化方案。曾经有朋友吐槽过同样的自动化逻辑使用 iOS HomeKit Frameworks 这样的「外挂」执行速度竟然快于米家的网关自动化，这正暴露出网关设备的性能不足。iOS HomeKit Frameworks 自动化「纾解」了网关设备的「非网关功能」，反倒提升了整个智能家居系统的性能。
除此之外，iOS HomeKit Frameworks 家居中枢还承担着多重意义上的「网关」职能。家居中枢可以作为「代理」执行 iOS HomeKit Frameworks 指令，并且将非 IP 设备桥接到局域网中。由家居中枢代理的 iOS HomeKit Frameworks 请求和终端设备直接发出的请求 几乎没有差异。
对于蓝牙设备来说，它是将蓝牙设备桥接到局域网的网关。蓝牙设备只需要和家居中枢保持连接，HomeKit 就可以通过 HTTP 访问家居中枢进行代理操作，而无需每个终端设备都进行连接。这样以来既减轻了蓝牙设备的压力，又通过「信号择优」的方式提高了蓝牙的设备的响应性能。
image.png
以上方案充分扩展了蓝牙设备的连接范围，但还没有彻底解决传输速率不足和延迟高的问题。HomePod mini 上首先引入的基于 Thread 的 HAP 协议作为对蓝牙 BLE 的补充，不仅大大提高了响应性，还利用Thread 稳定、低延迟的 mesh 组网进一步扩大了 iOS HomeKit Frameworks 设备的「朋友圈」。在接入 HomeKit 后，支持 Thread 的蓝牙 HomeKit 设备可以被家居中枢所识别，然后自动加入包含家居中枢的 Thread 网络。如此一来，家居中枢就成为了设备的 Thread 网关，接收到相关请求后会通过 Thread 而不是蓝牙来进行通信，由此解决了延迟问题。
image.png
▍理解 iOS HomeKit Frameworks 抽象模型
在上文中，我们介绍了 iOS HomeKit Frameworks 的底层通信机制，它根据设备采用的通信协议分为两种不同的类型。在这些协议的基础上，iOS HomeKit Frameworks 建立了统一的抽象模型来描述它的智能逻辑。相比为了安全性而不惜将问题「复杂化」的通信协议，iOS HomeKit Frameworks 的抽象模型设计十分简洁。它只包含三个不同层次的核心概念：
设备（accessory）
服务（service）
属性（characteristic）
「服务」是对某一类设备功能的抽象。除了名为「设备信息」，用于展示制造商、序列号、固件版本等信息的一个必须的服务外，大部分设备只包含一个服务，和自己的功能相匹配。为了最大程度的抽象和复用，部分服务类型会可能「附加」其它服务。例如「空气净化器」就可以附加「风扇」服务；如果一个设备同时包含「空气净化器」和「风扇」服务，HomeKit 会推断出这是一台空气净化器，「风扇」控制的是空气净化器的风速，并且二者的开关状态应当同步。
每个服务都规定有可选和必选属性，例如「设备信息」服务中制造商、型号等属性都是必须提供的。属性反映设备的某个特征或者状态，例如开关状态、传感器数据等。属性支持多种不同的权限组合：设备制造商信息是只读（paired read）的，开关既可读（paired read）又可写（paired write），传感器数据等可以用于触发自动化的则必须具备通知（notify）权限。支持推送消息的关键属性则需要在通知的基础上实现事件（event）。除此之外，还有立即写（timed write）、写返回（write with response）、广播（broadcast）、隐藏（hidden）等权限。设备还可以定义私有属性，这些属性在「家庭」app 中将向一般用户隐藏，但可以被 iOS HomeKit Frameworks 用于控制以及自动化等操作。
iOS HomeKit Frameworks 设备入网与初始化
作为「iOS HomeKit Frameworks 原理」的最后一块拼图，我们需要谈谈 iOS HomeKit Frameworks 设备的入网和初始设置流程。为了在本地完成设备的配置和认证，iOS HomeKit Frameworks 不像米家等平台那样提供「支持设备列表」和操作指南，而是完全依靠蓝牙和 Bonjour 发现（discover）附近的设备。这样反倒创造出了更一致的设备添加流程，成为了 HomeKit 的一大标志性体验。
对于 BLE 设备来说，未经注册的设备会不?！腹悴ァ挂桓鎏厥獾摹窰AP 配对」服务，iOS HomeKit Frameworks 将监听这类广播消息，从而识别附近正在等待配对的设备。Wi-Fi 设备的入网则实际上使用了 MFi 无线设备配置功能；这一功能只对 MFi 计划的认证硬件开放，并且需要专用 BLE 蓝牙芯进行服务广播片以被 iOS 设备发现?；褂幸焕?IP 设备并不通过 iOS HomeKit Frameworks 的配对流程接入局域网。它们可能使用有线连接，或者拥有更复杂的功能（例如电视机），因此这类设备将直接通过 Bonjour 被发现。
个人终端设备将结合设置码来自动发现对应的 iOS HomeKit Frameworks 设备，确认它还未添加到 HomeKit，然后为设备配网。绝大多数 iOS HomeKit Frameworks 设备采用的静态设置码会以贴纸的形式出现在机身或者说明书等位置，目前主要有二维码贴纸和 NFC 贴纸两种。使用 iOS 或 iPadOS 设备的摄像头或 iPhone 的 NFC 扫描对应贴纸都可以激活配对流程。使用动态设置码的带屏幕设备需要在屏幕上展示二维码供扫描，例如电视机和机顶盒。
已经正确配对或接入后后，下一步需要进行初始设置。整个流程采用安全远程密码交换协议（Secure Remote Password protocol），需要进行三个来回的信息传递，期间将验证设置码的有效性，并为 HomeKit 设备生成一个长期密钥。这一密钥在还原出厂设置前都将保持不变。设置完成后，HomeKit 就会尝试和该设备建立会话，以上流程全部无错误则设备添加成功。
image.png
链接
智能家采用两种方式连接
wifi通讯或者蓝牙通讯
第一种wifi：
拿wifi的ip地址 建立socket，udp tcp socket 工具 “ AsyncSocket ”
第二种蓝牙：
蓝牙协议是公司提供的
image.png
按照协议的规则把数据发给蓝牙
image.png
比较长的数据 用的是把数据切开 分段传
蓝牙数据长度有系限制，好像就是 十几二十个字节，需要做数据完整性检查，还要校验；
可以用结构体，可读性强些
image.png
蓝牙我做过一个无人机协议，好像也是定好的结构体，做大好像也就20个字节左右
Socket会不会有链接不稳定的问题：与硬件有关，近距离通信很稳定
蓝牙配网,MQTT通讯
智联硬件，大部分场景也就配网的时候需要跟手机通信，设备控制的时候也需要呀
设备端起的服务，手机连设备的服务进行交互
使用WebRTC
特别解释:HomeKit是苹果官方开发框架,不是类似广告营销
image.png
