BLE 读书笔记(一)

最近正好在做跟蓝牙这块有关的开发, 但是一直就是 CoreBluetooth 的几个代理跳来跳去, 老感觉隔了一层纱, 正好发现了一本不错的书, 于是在学习的同时顺便做了点简单的笔记

低功耗蓝牙开发权威指南阅读笔记

1. 自适应跳频: 一种使用某个频率子集的技术, 使设备可以避免其他非自适应技术使用该频率
2. 跳频: 两个设备之间使用多个频率进行通信. 某一个时刻只用一个频率, 各频率之间按照确定的顺序依次使用
3. 蓝牙技术的设计目标: 全球操作(2.45G Hz, 全球免费, 都能够使用, 但是使用该频段的技术太多, 拥挤, 干扰), 低成本(没有设计网络拓扑学), 鲁棒性(预防干扰, 自适应跳频, 长 CRC或者短 CRC), 短距离(个人局域网), 低功耗(BLE)
4. 时间即能量: 贯穿整个低功耗的一个概念. 操作 = 消耗能量 >> 减少必要操作的执行时间
5. 电池: 合适温度, 过高过低减少电量甚至损耗电池寿命; 超电流使用, 超出上限容易损坏电池(俗称”电池烧了”), 长时间使用也会减少电池的总体可用量. 设计设备时需要考虑到: 在长时间的使用电池供电以后能有一段时间给电池恢复. 电池本身漏电问题: 如果电池只是偶尔使用, 那么电池本身漏电就是电池损耗的重要一环.
6. 鲁棒的发现其他设备: 减少活动所需时间 >> 能耗减少 >> 延长电池寿命 >> 延长设备使用时间.
7. BLE 中, 一个设备如果向北发现就必须每个几秒发送三次短消息, 如果想发现打算与之通信的设备, 在广播短消息之后该设备应立即进行侦听. 寻找其他设备时, 设备将打开接收器并侦听其他设备的传输(广播?)
8. 三次短消息的传输分别是三个不同的频率 >> 提高鲁棒性. 三是在鲁棒性和功耗之间的一个平衡.
9. 发现设备这种工作应该交给能量储备更多的设备进行(手机, Central 端, 外设, peripheral 端就只负责执行接收).
10. 短消息短的原因: 短消息消耗的能量更少. 短报文消除了控制器在一次数据传输中需要不断校准无线电的需求(传输数据 >> 传输能量 >> 芯片发热 >> 改变传输频率). 短报文略微降低了芯片的峰值功率. 短期, 间歇性的取电对电池更加友好.
11. 内存需要动态刷新 >> 刷新就需要能量 >> 内存越多刷新需要的能量越多 >> BLE 设计在每一层都考虑了降低内存的数量: 链路层保持较短分组 >> 较少无线电发送和接收数据包时对内存的要求; 属性协议层不需要处理任何长度大于23字节的数据报文; 状态转换时也不要求存储任何状态信息.
12. 设备需要做的事情越多 >> 需要激活的协议越多 >> 对存储器的需求越大 >> BLE 仅有一个协议 >> 减少开销
13. BLE 的每层都使用了非对称设计 >> 为了让能源更少的设备负担更小
    • 物理层: 发射器(peripheral)和接收器(Central), 一个只有发射器和一个只有接收器的设备构成的网络 >> 非对称网络 << 所有其他设备必须为资源最有限的设备进行优化
    • 链路层: 广播者(peripheral)和扫描者(Central), 从设备(peripheral)和主设备(central), 从设备无法发起任何复杂的操作, 主设备负责微微网的定时, 自适应跳频集合设置, 加密以及一些其他的复杂操作 >> 从设备可以非常简单, 实现了低成本, 低内存和及可能低的功耗.
    • 属性协议层: 客户端( Central)和服务器(peripheral, GATT?). 服务器保存数据, 客户端向其发送数据请求以获得该数据.
    • 安全架构: 非对称密钥分配方案, 从设备负责提供密钥, 并交给主设备由后者保存. >> 主设备担负起保存链路绑定信息的重任. >> 从设备上实现安全特性很简单 >> 主设备要麻烦一点.
14. 总结: BLE, 尽可能的减少自身开销, 将所有开销大的活动转移到资源更为丰富的设备上去.
15. notify >> Central 不需要想 peripheral 执行轮询, 而是在值 change 的时候 peripheral 主动发送给 Central
16. BLE 基于状态的模型(read-write-notify)构建了一个典型的 C/S 架构, 同时减少了设备需要包含的代码数量以及用来保存代码的存储器数量 >> 降低功耗 && 更少的代码 >> 更少的错误 && 越简单 >> 越便宜 >> 开发更迅速, 更强健, 更容易维护 less is more
17. IP 协议没有集成在 BLE 设备上的原因: 内存, 能量消耗不能满足要求 >> 不允许将 IP 数据包直接路由到从设备 >> 智能网关: peripheral 数据存储, 不需要关心Central 是谁, Central 可以直连, 也可以远程通过互联网网关连接
18. 无连接模型: BLE 的基本理念就是连接是瞬态的(大约是3ms 内就能建立连接, 发送数据并断开连接).
19. 面向服务的架构:
    • C/S 之上的进一步抽象, 是一个将服务器中的信息组织成服务的模型. 该服务可以被防线, 进行交互或用做已知的语义. 意味着该服务具有确定的行为, 在给定相同的条件时, 总会产生同样的结果.
    • 正式合约: 一个服务之所以被视为服务, 是因为其在公开的功能以及如何工作两个方面提供了正规的描述. >> 正式合约. 好处在于: 一个服务的实例很容易被另一个服务的实例所代替. 只要两个服务的实力具有相同的功能和行为, 这种情况就有可能发生
    • 松耦合: 将依赖关系减少到最低限度, 使修改服务的实现时不会带来意想不到的边界效应, 从而降低风险 >> 应当将正式合约及其实现这二者分离开来 >> 只要正式合约不被破坏或者修改, 实现就可以根据需要随意变换.
    • 服务抽象: 服务公开的状态应当尽可能少, 只应规定服务行为的外在表现.
    • 可重用性: 真正意义上的可重用性是令服务适用于多种不同应用的一种能力, 良好的设计方案中, 服务可以与具体的实现过程相互独立 >> 该服务能够在其他应用程序中快速, 轻松地获得重用.
    • 无状态: 服务器不能保存任何客户端的状态数据 >> 让众多客户端支持服务扩展. 无状态的设计目标是删除客户端和服务器之间的所有交互状态, 一般最多存的是服务器状态. >> 无论任何客户端在任何时间发送任何请求, 服务器都将以完全相同的方式相应相同的请求, 而不管请求来自哪个客户端.
    • 可组合性: 服务应该被设计的小而简单 >> 实际上并不会这样 >> 面向服务的体系结构鼓励聚合较小的服务(服务之间的相互组合) >> 实现更高级的服务接口
    • 自治: 服务本身必须是可靠的 >> 这样才能重用和组合服务 >> 自治的服务可以独立执行任务, 而不管在其周边发生的情况. 非自治服务可能会带来许多额外的支撑服务, 并且可能与其他服务相冲突.
    • 可发现性: 要想使用服务就必须使得服务能够被发现. 可发现性通常是通过一个单独的, 与服务交互的协议来实现的. 而 BLE 采用的是: 使用同一个协议实现服务发现以及服务交互 >> 属性协议 >> 可发现性被称之为通用属性规范.

转载于:https://www.cnblogs.com/SquirrelStock/p/5774252.html