如果我的理解是正确的，specification中分配了大量的UUID，但之后还有this。
由于可以自定义iBeacon的UUID，UUID是否会与现有代码冲突并产生不良后果？
如果我的理解是正确的，则服务UUID位于BLE分组的字节30和31处，其与iBeacon的UUID重叠。服务UUID只有2个字节，因此不会发生冲突。
答案 0 :(得分：1)
重要的是要了解有两种类型的蓝牙广告：
广告必须是一种或另一种，而不是两种。
仅服务广告使用服务UUID（16位或128位）。制造商广告没有。制造商广告仅具有向Bluetooth SIG注册的双字节公司代码。制造商广告中的其他所有内容都是任意数据。
AltBeacon和iBeacon等信标类型是制造商广告，因此它们不包含服务UUID。因此，ProximityUUID和服务UUID之间不存在可能的重叠，这是完全不同的事情。
Eddystone和Gimbal等其他信标类型确实使用可能导致混淆的服务广告。
答案 1 :(得分：0)
您可能会将iBeacon UUID与16位服务UUID混淆。
iBeacon UUID长度为16字节（字节，非位），这意味着有2^(16 * 8)种可能的组合。
那是3.4 * 10^38，这很多。甚至比Avogadro的常数还要大。所以永远不应该发生碰撞。
另一方面，服务UUID只有2^16 = 65,536个组合。但蓝牙SIG管理那些以防止冲突。
答案 2 :(得分：0)
当然可以，但是嘿，128位。 2个人通过随机程序生成相同的UUID会很难。
如果您希望在uuidgen终端上随机生成一个OS X命令。
答案 3 :(得分：0)
iBeacon广告和可发现服务广告的格式和内容完全不同。因此，即使数据包末尾可能有一些字节具有相同的值，但数据包头中的差异意味着对这些字节的含义没有混淆