蓝牙低功耗广告功能一直以来都是开发者们“直接使用”的一项技术，直到它开始以一些隐蔽而麻烦的方式引发问题。你只需设置一个名称、添加一个UUID，或许再加入一些制造商相关的数据，然后就希望一切都能正常运行。多年来，人们默认的规则很简单：如果信息无法被压缩到31个字节以内，那就是你的问题了。而扩展广告功能正是蓝牙规范对这一现状的迟来认可——现代设备在建立连接之前确实需要传递更多信息。
这篇文章将深入、实际地探讨目前在Android开源项目中实现的扩展蓝牙广告功能。我们会解释这项功能存在的必要性、它在实际通信过程中的工作原理、Android系统提供了哪些相关接口以及隐藏了哪些信息，还会说明如何使用这项功能而不至于无意中影响电池寿命或设备的兼容性。此外，我们还会讨论开发团队在实际生产过程中常会犯的一些错误、那些在文档中并未被提及的注意事项，以及如何以系统工程师的角度来设计广告数据包，而不是仅仅从数据包的数量角度来考虑问题。
如果你曾经疑惑为什么有时某个设备能正常接收扩展广告信息，而另一个设备却无法接收；或者为什么你精心设计的广告数据包在扫描结果中根本显示不出来，那么这篇文章非常适合你阅读。
目录
我们都曾接受的那个31字节的谎言
很长一段时间里，蓝牙低功耗广告机制让我们接受了这样一个在事后看来显得相当荒谬的概念：整个设备的识别信息竟然可以被压缩到31个字节中。不是31个字符，也不是31个“逻辑字段”，仅仅是31个原始字节而已。这些字节包含了设备的标志、服务UUID、设备名称、制造商信息，以及产品团队认为必须让他人在未建立连接的情况下就能获取的各类数据。最终，每一位蓝牙低功耗技术的工程师都像人们习惯接受糟糕的网络延迟或慢速的Wi-Fi一样，将这一限制视为理所当然的事情。
因此，我们只能设法应对这种限制。我们将设备名称缩写成只有内部人员才能理解的含义；把多种信息压缩到单个字节中，就像在20世纪80年代编写汇编代码一样；我们还发明了一些二进制协议，将这些信息嵌入到制造商数据字段中，只希望永远没有人需要在原始开发者不在场的情况下去调试这些协议。而当其他方法都失败时，我们就会采取最糟糕的做法：仅仅为了读取一些基本信息，就建立连接，这样不仅会浪费电量、增加延迟，还会让整个系统变得混乱，只是为了回答那个“你是什么设备？”的问题。
事实是，传统的蓝牙广告机制根本不是为现代的蓝牙低功耗设备设计的。它最初是为那些简单的信标设备、心率监测器等设计的，这类设备在公共场合可以不需要具备复杂功能，只有在建立连接后才会启动高级功能。但几年后，蓝牙低功耗设备已经不再是单纯的配件了，它们变成了可穿戴设备、音频播放器、追踪器、智能眼镜、锁具等等。这些设备需要在建立连接之前就广播自己的功能信息、兼容性数据、当前状态，有时甚至还需要表达自己的意图。31字节的限制不仅显得过于有限，而且确实导致了系统设计的缺陷。
这就是“31字节谎言”的真正危害所在。问题并不在于这31个字节的存在本身，而在于它们根本不足以满足各种需求——无论是设备识别、兼容性检测，还是实现多个设备在未配对的情况下进行交互。蓝牙技术社区多年来都清楚这一点，因此才会有这么多产品违反规则，滥用扫描响应机制，或者在原本设计就不适合承载大量信息的基础上，再添加自定义的协议。
扩展广告机制的出现，正是因为整个行业终于意识到：设备识别已经不再是一个简单的“是或否”的问题了。设备识别需要结合具体的上下文来进行判断——这设备是谁、它能做什么、人们应该如何与它交互，甚至是否真的有必要与它进行通信。试图用31个字节来表达所有这些信息，根本不是什么高明的工程设计，而只是为了生存而采取的权宜之计。扩展广告机制其实就是蓝牙技术在说：“现在你们可以好好解释一下自己是谁了。”
当你理解了这一背后的原因，就会发现扩展广告机制并不是一种高级的可选功能，而更像是一种必要的补救措施。它并不是对系统的一次升级，而是对多年来那些创造性妥协、尴尬的权衡以及潜藏在无数生产系统中的错误假设的一种修正。一旦你这样看待它，那么关于它的运作原理、Android系统是如何利用它的，以及如何正确使用它，这些内容就会变得容易理解多了。
广告基础知识（但你可能已经忘记的那些细节）
大多数开发者认为蓝牙广告只是“在后台自动进行的操作”，但这种模糊的理解恰恰会导致人们在面对扩展广告功能时产生困惑。实际上，广告并不是随意向空气中发送数据，而是一种基于无线电传输时间、功耗限制以及碰撞避免机制而设计的、经过精心优化的发现机制。如果你不重新审视这些限制条件，扩展广告功能可能会显得神秘甚至不可靠，但事实上它的运行方式完全符合设计初衷。
在经典的BLE广告模式下，所有通信都通过37、38和39这三个专用频道进行。这些频道的存在唯一目的就是实现快速设备发现。它们被刻意设置在2.4 GHz频段中较为分散的位置，并经过优化，以便扫描设备能够快速扫描这些频道而不会消耗过多电量。正是这种设计使得广告功能在低功耗设备上能够高效运行，但同时也导致数据传输量受到了严重限制——每多一个字节的数据，所有接收设备的通信时间、碰撞概率以及功耗都会相应增加。
许多人还会忽略另一个细节：广告通信并不是对称的。广告发送方可以控制数据包的发送时间和频率，但扫描设备最终接收到什么内容则由它们自己决定。由于轮询机制、干扰因素或操作系统的调度安排，扫描设备可能会错过一些数据包。因此，广告信息被设计得具有冗余性和重复性；同时，广告数据也被要求具备无状态、自包含的特点。如果你的数据包需要依赖前一个数据包才能完整理解其含义，那么这种设计就已经存在缺陷了。
“扫描响应”机制是人们在不破坏原有广告模型框架的前提下尝试进行扩展的首个方法。它允许广告发送方选择在何时以及以何种频率发送数据包，但具体接收内容仍由扫描设备决定。不过，这一改进并没有从根本上解决数据传输量的限制问题——每个数据包的大小仍然被限制在31字节以内，通信依然依赖专用频道进行，且通信机制也依然是以设备发现为核心设计的。扫描响应机制虽然增加了系统的复杂性，但并未真正提升数据传输效率。
扩展广告功能正是建立在这些基础机制之上的。它依然坚持“快速、低成本的设备发现”这一原则，但将信息描述与设备识别过程分离开来。专用广告频道仍然用于宣告设备的存在，但不再需要承载所有详细信息。一旦扫描设备确认了某台设备的存在，后续的数据传输工作就可以通过其他方式完成。正是这种设计理念的突破，使得扩展广告功能显得更加强大，而不仅仅是一种“规模更大的传统广告形式”而已。
如果读完这段内容后你能记住一个关键点，那就是：广告的目的并不是为了最大化数据传输量，而是为了将被发现的成本降到最低。扩展广告功能并没有改变这一目标，它只是为我们提供了更有效的工具来实现这一目标，同时让我们不再对“31字节的数据量到底能传递多少信息”这种问题产生误解罢了。
扩展广告存在的原因
扩展广告的出现，是因为蓝牙低功耗生态系统已经超出了最初设计时所基于的假设。早期的蓝牙低功耗设备都是简单、单一用途的外设，它们只需要宣告自己的存在，或许还需要提供一个服务UUID即可。而现代的蓝牙低功耗设备本身就已经构成了一个完整的生态系统。在任何连接建立之前，这些设备都需要表达自身的功能、版本信息、角色定位、兼容性限制，有时甚至还需要说明自身的临时状态。旧有的设计模式迫使开发者要么将这些信息隐藏在连接过程之后，要么将它们压缩成难以理解的数据格式。而扩展广告机制正是蓝牙规范对这种变化的一种认可——因为设备的发现过程已经变得更加智能和复杂了。
推动扩展广告发展的一个重要因素是避免不必要的连接。建立连接会消耗大量的系统资源：会唤醒CPU、占用内存、触发安全认证流程，同时还可能引发用户能够察觉到的副作用，比如权限提示或界面切换等。许多系统其实并不愿意进行连接，除非它们已经确定该设备与自身的需求相关。扩展广告使得设备能够在连接之前就提供足够的信息，让用户判断是否值得与该设备建立连接。这一功能极大地改变了系统的设计方式，尤其是在可穿戴设备、音频生态系统以及基于距离的交互场景中。
另一个推动扩展广告发展的关键因素是可扩展性。在设备数量较少的情况下，传统的广告机制表现良好，但当设备密度增加时，这种机制就会变得效率低下。当所有设备都试图通过相同的主要通道来发送广告信息时，数据冲突会增多，设备的发现效率也会下降。扩展广告通过将大量数据转移到次要通道上，减轻了主要通道的负担。主要通道仍然用于发送简短、快速的信息，而更详细的数据则通过次要通道仅传递给那些需要这些信息的设备。这种分离机制有助于大型生态系统在拥挤的无线环境中更加稳定地运行。
扩展广告的出现还有助于在传输范围、速度和功耗之间实现更好的平衡。传统的广告机制依赖于LE 1M物理层协议，这种协议虽然实用，但并不总是最佳选择。扩展广告允许设备使用LE 2M物理层协议来提高数据传输速度，或者使用LE编码物理层协议来延长传输距离。这意味着设备可以根据自身的实际需求来调整广告信息的发送方式，而不再被迫采用统一的解决方案。例如，追踪器、耳机和智能锁等设备都可以采用不同的广告机制进行通信，但它们仍然可以在同一个蓝牙生态系统中被其他设备识别到。
最后，扩展广告的存在也是因为仅仅保证向后兼容性并不足以满足现代技术发展的需求。蓝牙技术联盟历来都非常谨慎地对待破坏旧设备的行为，有时甚至会因此而牺牲一些创新机会。扩展广告机制通过与传统广告机制共存的方式，解决了这一矛盾——设备既可以使用扩展广告机制，也可以继续使用传统广告机制；它们可以根据实际需要动态地选择使用哪种机制，或者在必要时优雅地切换回传统方式。这种设计使得新系统可以在发展的过程中不会让旧硬件陷入困境，而在当今这个蓝牙设备的使用寿命往往比与其连接的手机更长的时代，这一点尤为重要。
从根本上来说，扩展广告的功能并不在于发送更多的数据字节，而在于在交互的早期阶段就明确表达出设备的意图。这种机制使得设备能够在任何人建立连接之前，更真实地展现出自身的身份及需求。一旦从这个角度去理解扩展广告的作用，就会发现它其实并非可选功能，而是不可或缺的一部分。
蓝牙规范中发生了哪些变化
当人们听说扩展广告是随着蓝牙5.0版本出现的时，他们往往会认为这只是些细微的改动，比如缓冲区大小的增加，或者协议层中某些限制的放宽。但实际上，扩展广告要求人们对蓝牙规范中广告信息的呈现方式进行彻底的重新设计。其中最重要的变化并不在于数字“255”，而在于将广告信息明确划分为发现阶段和数据传输阶段，并在协议层面对这些流程进行规范，而不是依靠一些临时性的解决方案来处理这些问题。
在旧的蓝牙规范中，所有广告信息都存储在主要的广告通道中。这些通道既用于通知其他设备该设备的存在，也用于传递描述该设备的所有详细信息。但由于主要广告通道会被范围内所有设备共享，因此蓝牙规范对这种设计方式进行了严格的限制。而扩展广告则打破了这种束缚。新规范引入了“辅助广告链”的概念：主要广告信息中只包含指向携带实际数据包的辅助通道的指针，这个指针被称为“辅助指针”，它是整个扩展广告机制的核心。
另一个重要的变化是，广告信息不再被假设为单一的数据包。在扩展广告模式下，数据包可以被拆分成多个辅助数据包，并通过特定的链接方式组合在一起，这样扫描设备就可以重新组装这些数据包来获取完整的信息。这种设计使得广告数据包的体积可以大大增加，而无需进行一次耗时较长的传输操作，从而避免占用过多的通信资源。蓝牙规范明确规定了这些数据包链的调度方式、时间同步机制以及扫描设备应如何遵循这些规则。正因如此，扩展广告相比那些旧有的技术手段来说，显得更加可靠。
此外，蓝牙规范还将广告功能与固定的物理层传输机制分离了。在旧的广告模式下，广告信息总是通过LE 1M物理层进行传输，这种机制虽然能够平衡通信范围和数据传输速度，但并不总是最理想的方案。而扩展广告允许辅助数据包使用不同的物理层传输机制，例如LE 2M物理层可以加快数据传输速度，而LE编码物理层则能扩大通信范围。这一变化虽然看似细微，但却具有很大的实用性，因为它让设备设计者能够根据实际需求自主选择合适的传输方式，而不必被固定的默认设置所限制。
还有一个重要的变化在于，扫描能力和连接能力不再被绑定在相同的机制上。在旧的广告模式下，这两种能力是与特定的数据包类型紧密关联的，因此灵活性较差。而扩展广告则将这些属性明确地定义为可配置的参数。一个扩展广告信息可能具有可扫描性但不可连接性，也可能具有可连接性但不可扫描性，甚至两者都不具备。对于现代系统而言，发现设备、交换功能信息和建立连接这三个环节是相互独立的过程，它们各自涉及到不同的安全性和功耗要求，因此这种灵活性显得尤为重要。
最后，该规范引入了新的人机交互命令，以便在控制器层面控制扩展广告功能。过去只有一种命令用于设置广告数据，而现在则有了专门用于设置参数、提供数据以及启用或禁用广告功能的独立命令。这种变化体现了将广告视为具有生命周期和状态的管理对象，而非静态配置项的思维方式。Android的API也反映了这一转变，因此AOSP系统中的扩展广告功能虽然看起来更为复杂，但同时也具备更强的灵活性。
综合来看，这些变化说明扩展广告并非一种简单的附加功能，而是一种全新的广告模式，它只是与原有的广告机制共存而已。蓝牙规范并没有仅仅提高某些限制，而是重新定义了哪些广告内容是被允许存在的。正因如此，扩展广告功能能够推动新的系统设计诞生，而不仅仅是让旧有的系统运行得稍微顺畅一些。
传统广告与扩展广告：客观的对比分析
人们很容易认为扩展广告是对传统广告功能的升级，但这种观点会导致不良的设计决策。传统广告并没有过时，而扩展广告也并非在所有情况下都更优越。它们其实是两种为应对不同需求而优化的工具，了解每种技术的适用场景比死记硬背它们的功能列表更为重要。蓝牙规范之所以同时支持这两种广告方式，是因为现实世界中的产品确实需要这种灵活性。
传统广告的优势在于其简单性、可预测性以及广泛的兼容性。所有支持BLE协议的手机和控制器都能理解这种广告格式，而且它的运行表现也在多年的生产实践中得到了充分验证。由于它仅使用主要的广告通道和固定的物理层协议，因此在低端硬件上也能保持稳定的性能。因此，对于那些需要简单标识、适用于基本外设或必须被多种扫描设备识别的设备来说，传统广告是一个非常合适的选择。如果你的广告需求可以通过名称、UUID以及少量元数据来表达，那么传统广告往往是最安全、风险最低的选择。
而扩展广告则更注重表达能力和选择性。它允许设备提前传递更多信息，但这种设计的前提是使用者拥有性能更强的扫描设备和控制器。在现代的Android生态系统中，这一前提通常是成立的，但毕竟仍是一种假设。此外，扩展广告还引入了许多额外的复杂性因素：次要广告通道、辅助数据指针、物理层协议的选择以及更大的数据负载量。这些因素都会带来功耗、时序控制及兼容性方面的挑战，而传统广告则完全没有这些问题。
这两种广告模式在扩展能力方面也存在显著差异。传统广告的所有数据传输压力都集中在所有设备共用的主要通道上，当环境中的设备数量增多时，这些通道就会变得拥挤，从而导致设备的发现效率下降。而扩展广告通过将主要广告信息保持在较小规模，并将较大的数据负载量转移到仅在必要时使用的次要通道上，从而缓解了这一压力。在设备密集的环境中，这种设计使得扩展广告不仅具有更强的表达能力，其稳定性也更高。
另一个关键区别在于，不同的广告模型对系统设计的引导方式不同。传统的广告模式往往会促使开发者尽早建立设备之间的连接，因为在这种模式下，前期并没有足够的空间来表达设备的功能意图或兼容性要求。而扩展型广告模式则鼓励开发者采取相反的做法：多进行广告宣传，但减少设备之间的实际连接。这种转变能够显著降低能耗并提升用户体验，尤其是在那些设备是通过随机方式被发现、且只有部分设备需要建立连接的生态系统中。
不过，扩展型广告模式并非没有代价。较大的数据包传输所需的时间更长，次级通道的调度也会导致传输时序出现不确定性，而且，并非所有控制器在频繁使用扩展型广告功能时都能表现出良好的性能。在某些情况下，尤其是对于超低功耗设备或那些对向后兼容性有严格要求的 produk 来说，传统广告模式仍然是更好的选择。真正的错误并不在于选择传统广告模式，而在于仅仅因为扩展型广告模式的存在就盲目选择它。
最有效的蓝牙系统会将传统广告模式与扩展型广告模式视为互补的关系。它们会利用传统广告模式来最大化设备的可发现性和兼容性，而在生态系统条件允许的情况下，则使用扩展型广告模式来进一步丰富设备发现的机制。只要合理运用这种混合策略，就能同时获得两种模式的优点，而不会在不必要的地方引入额外的复杂性。
扩展型广告在无线通信中的工作原理
如果仅仅通过 API 和数据包大小这些概念来描述扩展型广告模式，可能会让人觉得它很抽象；但一旦你了解了实际在无线通信中发生了什么，就会发现这种模式其实非常容易理解。其核心思想在于：广告传播不再是一个简单的事件，而是一个分为两个阶段的过程——首先是设备的被发现，然后才是设备详细信息的传递。蓝牙规范对这一过程进行了明确的规定，这样就可以让设备被快速找到，同时也不会迫使所有的扫描设备都承担接收大型数据包所带来的负担。
这个过程始于传统广告模式所使用的那些主要广告通道。使用扩展型广告模式的设备仍然会在 37、38 和 39 号通道上发送数据包，而这些数据包的大小被刻意设计得较小。它们的作用并不是详细描述设备的各项功能，而是用来宣告设备的存在，并提供一个指向更多详细信息的链接。这个链接就是“辅助指针”，它告诉扫描设备接下来应该在何时何地继续进行信息获取。从系统的角度来看，这种设计能够确保设备发现的效率和质量，这对于那些依靠电池供电的扫描设备来说尤为重要，比如手机和可穿戴设备。
一旦扫描设备接收到了这些初始广告信息，并认为该设备值得关注，它就会根据辅助指针前往次级广告通道。这些次级广告通道属于常规的数据传输通道，并非专门用于发送广告信息的通道。正是在这里，扩展型广告模式真正发挥了它的作用。次级数据包的大小可以更大，也可以使用不同的物理层协议进行传输；如果数据量太大，一个数据包无法完成传输，那么这些数据包还可以被串联起来一起发送。对于扫描设备来说，这种通信方式更像是一种有针对性的数据获取过程，而不是盲目的广播操作。
这种链式传输机制尤为重要。与一次性发送大量数据不同，扩展广告功能允许广告商将数据分成较小的部分，并依次进行传输。每个数据包都包含时间信息，这样扫描设备就能知道何时接收下一部分数据。这种方式能够减少数据冲突，提高传输的可靠性，同时避免占用过多的无线频段。此外，在信号拥挤的环境中，这种传输方式也更具扩展性，因为大型数据包不再需要与其它数据包竞争主频道的传输空间。
物理层协议的选择对扩展广告在无线环境中的传输效果有着重要影响。设备可以在主频道使用LE 1M物理层协议以实现最大的兼容性，而在辅助频道则切换到LE 2M物理层协议以加快数据传输速度；或者，在辅助频道使用LE编码物理层协议来覆盖更远的传输距离。这些选择并非理论上的假设，它们会直接影响信号的传播范围、延迟以及功耗。扩展广告机制正是将这些因素明确地考虑在内，而不是将它们隐藏在固定的默认设置之后。
这种设计的一个微妙但重要的后果是，并非所有扫描设备都能完整接收到所有的扩展广告信息。有些扫描设备可能会接收主广告内容，但选择不跟随辅助数据链接进行进一步操作——这可能是由于它们进行了主动的数据过滤，也可能是为了节省电量。这种设计初衷就是如此。扩展广告功能假定扫描设备会有一定的选择性，而广告商也能够接受这种选择性。如果你的系统要求所有扫描设备都必须接收到全部数据，那么扩展广告可能并不是最适合你的解决方案。
将扩展广告视为一种“对话”而非简单的“广播”，有助于我们更好地理解它的运作方式。主广告相当于在说：“我在这里，更多信息可以在这里找到。”而辅助广告则是在提供具体的“所需信息”。一旦你接受了这种传递逻辑，很多人们原本认为是程序漏洞的现象，其实往往都是为了实现可扩展性和能效优化而有意做出的设计决策。
Android支持：版本、控制器与实际应用
在Android系统中，扩展广告功能就是这样一个例子——API接口所揭示的信息仅是整个机制的一部分。从理论上讲，Android系统确实提供了支持扩展广告的API，而且现代手机也都配备了支持蓝牙5.0标准的控制器。但实际上，扩展广告能否正常工作取决于Android版本、控制器硬件以及厂商发布的固件这三者之间的配合。如果其中任何一方出现问题，开发团队就会陷入“调试蓝牙故障”的误区，而实际上这些问题往往是由于生态系统不兼容造成的。
从Android框架的角度来看，直到蓝牙5.0标准推出之后，开发者们才真正开始了解扩展广告功能的实现原理。早期的Android版本虽然能够支持蓝牙5.0控制器，但并没有提供直接使用扩展广告功能的方法。因此，在很长一段时间里，尽管硬件技术上已经具备了相关能力，但应用程序甚至系统组件都无法利用这一功能。当扩展广告API最终被正式引入时，开发者们在使用这些接口时也非常谨慎，因为其中包含了许多针对控制器行为的检测机制和假设条件。
即使在今天，与扩展广告功能相关的最重要的API调用也并非用于启动广告播放。实际上，这个调用是用来检测系统是否支持扩展广告功能的。在Android系统中，这一检测是通过蓝牙适配器来进行的，而这一检测结果所反映的并不仅仅是设备是否符合相关规范。它实际上体现了蓝牙芯片厂商对其产品功能进行了哪些测试、哪些功能已被启用以及哪些功能被认为是安全的。如果这个检测结果显示“不支持”，那么强行使用扩展广告功能无疑是愚蠢的行为，因为这可能会导致系统出现不可预测的问题。
接下来要考虑的是蓝牙控制器的兼容性。有些蓝牙控制器虽然宣称支持Bluetooth 5标准，但在实际使用扩展广告功能时仍会表现不佳；有些控制器仅在特定的物理层协议下才支持扩展广告功能；还有一些控制器的有效数据传输长度限制低于理论最大值；此外，某些固件版本在处理链式辅助数据包时会出现问题，或者在同时启用多个广告功能时出现时间同步异常。从Android系统的角度来看，这些都属于控制器的特殊行为；但从用户的角度来看，这些就是产品使用中的风险因素。
通常情况下，蓝牙芯片厂商的固件配置以及蓝牙系统本身的设置，比Android系统的版本本身更为重要。即使两款手机运行的是同一版本的Android系统，但如果它们的蓝牙固件不同，其表现也可能大相径庭。因此，有些设备上扩展广告功能可以正常使用，而有些设备上却会默默地出现故障，尽管这两款设备都声称自己支持这一功能。Android系统的蓝牙系统需要在提供高级功能与保护用户免受系统不稳定带来的影响之间取得平衡，而芯片厂商往往会在确信自己的产品在不同电源状态、不同共存环境下以及符合各种监管要求之后，才会启用这些功能。
另一个需要考虑的因素是Android系统本身在内部使用扩展广告功能的频率。系统的各个组件、辅助设备管理程序以及第三方服务都可能会消耗广告资源，而这些资源并不是无限的。有些控制器的资源限制程度其实相当低，因此当某个应用程序尝试使用扩展广告功能但失败时，根本原因可能并不在于这个应用程序本身，而是因为系统其他部分耗尽了可用的广告资源。正因如此，扩展广告功能的故障有时会呈现出间歇性特征，并且不同设备的表现也会有所不同。
在实际应用中，我们应该将Android系统中的扩展广告功能视为一种有条件的优化选项，而不是一个必然会生效的功能。那些用于检测系统是否支持扩展广告功能的代码并不是可有可无的冗余代码，它们实际上是系统与硬件之间的一种契约。如果扩展广告功能对你的产品体验至关重要，那么在进行测试时就必须涉及多种不同的设备、不同的芯片厂商以及不同版本的操作系统。Android系统提供了强大的工具，但它也要求用户在使用这些工具之前必须先获得许可，并且能够接受“不支持”这一结果。
如果你能以这种态度来对待Android系统的扩展广告功能，那么你就能节省大量的时间，避免收到许多错误的错误报告，也能减少在深夜进行调试的次数。
深入了解AOSP：从框架API到HCI命令
要真正理解Android中的扩展广告功能，就不能将其仅仅视作一次API调用，而应该将其看作是一个由多个环节组成的流程。当你要求Android启动扩展广告功能时，其实并不是在简单地切换一个开关，而是在触发一系列决策过程、数据转换操作以及验证步骤，而这些步骤涉及系统的多个层级，每个层级都有其特定的限制条件与可能出现故障的情况。了解这个流程中哪些地方容易出问题，往往能帮助我们更高效地进行调试，而不会陷入盲目的试错之中。
在这个流程的最上层是框架API，通常是通过BluetoothLeAdvertiser来访问这一层的。框架API的设计初衷就是提供高度灵活的配置机制。你不需要提供一整段配置代码，而是可以分别定义广告参数、广告数据、可选的扫描响应信息以及回调函数。这种设计体现了蓝牙规范将广告功能视为一个可被管理的对象，而非静态设置的理念。当你请求启动扩展广告功能时，框架会首先验证你的配置是否在逻辑上是合理的，例如会检查旧版模式、可扫描性以及可连接性这些参数之间是否存在矛盾。
一旦框架确认配置无误，请求就会传递到蓝牙系统服务层。在这里，政策设置开始发挥作用——该服务会制定一些全局性的限制规则，比如控制器支持的最大广告集数量，以及是否允许使用扩展广告功能。此外，它还会协调系统中那些可能争夺广告资源的组件与应用之间的冲突。如果这一环节出现故障，通常会表现为一个通用的错误反馈，尽管根本原因可能是资源耗尽或政策限制，而非配置格式错误。
从系统服务层开始，配置信息会通过JNI机制传递到原生代码中。这个转换过程不仅仅是语言层面的跨越，更是高级抽象概念被转化为控制器层面可执行指令的过程。广告参数会被转换为HCI命令中的相应字段，数据内容也会根据控制器的限制条件进行验证，而物理层的连接选项则需要与控制器所宣称的支持能力相匹配。如果这一环节出现故障，往往是因为控制器报告的能力与框架预期的存在细微差异。
在最低层，扩展广告功能是通过蓝牙5.0引入的一组专用HCI命令来控制的。这些命令用于设置扩展广告参数、提供广告数据，以及启用或禁用广告功能。与传统广告不同，扩展广告功能的配置需要分多个步骤完成：必须先设置参数，然后才能生成广告数据；只有当数据准备就绪后，才能真正启动广告功能。这种顺序是由控制器来强制执行的，违反这一规则就会导致系统出现严重错误。
这种架构的一个重要特点是：扩展广告功能出现的故障往往与其根本原因相去甚远。应用程序中某个配置错误的参数可能会导致HCI命令被拒绝，而这一错误会被报告为一种普通的故障。控制器的某些特性也可能导致只有在特定时间条件下，广告功能的启用才会失败。如果不了解从API到HCI这一整个处理流程，这些问题就会显得随机且难以预测。
这种分层设计并非偶然，它反映了Android需要在成千上万的设备变体中平衡灵活性、安全性和兼容性。对于开发人员来说，挑战在于学会理解这些不同层次之间的关联。框架日志、蓝牙服务的相关记录以及控制器的信息都能揭示部分问题真相。扩展广告功能之所以会出故障，并非因为它们本身不可靠，而是因为在很多环节上都必须确保操作的正确性，否则故障就会以隐蔽的形式出现。
一旦你掌握了这一处理流程，扩展广告功能就不会再那么神秘了。它不再是一种“有时能正常工作”的API，而是一个界限明确的系统。当你了解了这些界限之后，就可以有针对性地设计自己的广告功能使用方式，确保自己的操作始终在允许的范围内进行，而不会不断遇到那些行为不确定的情况。
如何在Android中创建扩展广告功能
在Android中创建扩展广告功能时，理论终于与实际应用相结合了。但许多开发人员也会发现，与传统的广告功能相比，扩展广告功能的容错性要低得多。这些API确实非常强大，但它们的前提是开发者必须清楚自己要求系统执行的具体操作。如果把传统的广告功能比作填写一张简单的表格，那么扩展广告功能就更像是在配置一个包含各种规则、限制条件以及生命周期的管理系统。
第一步就是确认你的设备是否支持扩展广告功能。这不是一个形式上的检查，也不是仅针对旧版本设备才需要进行的操作。Android会明确说明这一功能是否可用，因为是否支持该功能取决于控制器、固件以及供应商的配置设置，而不仅仅是与操作系统版本有关。如果适配器报告称不支持扩展广告功能，那么你就必须相信这个结论。强行继续使用这些API并不会自动切换回传统的广告功能，反而只会导致各种混乱的故障。
一旦确认设备支持扩展广告功能，你就可以创建一个AdvertisingSetParameters对象。在这个步骤中，你需要明确说明自己的需求。你必须明确禁用传统广告模式，因为扩展广告功能并不是对传统广告功能的简单扩展，而是一种完全不同的工作模式。此外，你还需要决定该广告功能是否支持扫描、是否允许连接，或者两者都不支持。这些选择的重要性远超你的想象：可扫描的广告会吸引用户进一步互动；可连接的广告则意味着有可能建立连接关系。如果选择两者都不支持，那就意味着系统只需完成发现目标即可。
PHY的选择也是一个不能被忽视的重要环节。主PHY和辅助PHY是独立配置的，所选择的组合会直接影响通信范围、延迟以及功耗。许多开发人员默认使用LE 1M模式，因为这种模式“始终能够正常工作”，但这样做其实忽略了扩展广告功能的目的。如果为辅助广告选择LE 2M模式，那么对于大型数据包来说，传输所需的时间将会大幅增加；而LE编码PHY则能够在传统广告模式难以覆盖的距离范围内实现设备间的发现与通信。这些都属于系统层面的权衡，而不是些表面上的选项而已。
扩展广告功能真正发挥作用的地方在于广告数据本身。虽然现在不再受31字节的限制，但这并不意味着可以随意设计广告数据包的结构。Android系统仍然会执行相关的限制规则，而这些限制可能低于理论上的最大值。此外，广告数据还必须符合特定的语义规范：它应该是结构完整的、具有版本信息的，并且可以被安全地忽略掉。扩展广告功能确实为开发者提供了更多的灵活性，但这也并不意味着可以随意将应用程序的其他协议包含在广告数据包中。
启动广告功能仅仅是一个开始，而非整个流程的结束。扩展广告功能会大量使用回调机制来报告操作的成功与否以及状态变化情况。这些回调机制并非可有可无的附加功能，而是判断广告功能是否已经成功创建、启用或被关闭的唯一可靠依据。将广告功能视为“一次性使用后即可忽略”的东西，是一种常见的错误做法，这种做法会导致广告功能无法正常工作，或者资源泄露，在超出限制时还会引发各种问题。
干净地停止扩展广告功能的操作与启动它同样重要。由于广告功能是系统中明确的对象，因此必须明确地对其进行禁用和释放。如果不这样做，后续的广告尝试很可能会失败，尤其是在那些广告功能使用权限有限的设备上。在长期运行的系统中，这种问题会影响到系统的稳定性，而这类问题的诊断往往更加困难。
在创建扩展广告功能时，最重要的观念转变就是要认识到：你不再是在配置一个静态的广播信号，而是在管理一个具有各种参数、数据、状态和所有权信息的动态对象。一旦你以这种方式来思考这个问题，相关的API也会变得易于理解。否则，扩展广告功能就会显得很不稳定。这种区别并不在于复杂性的高低，而在于能否在连接建立之前，更清晰、更准确地传递所需的信息。
如何设计能够长期使用的广告数据包
扩展广告功能确实消除了对广告数据包大小的最明显限制，但这并不意味着可以随意设计这些数据包。事实上，额外的空间反而使得良好的设计变得更加重要。一个设计不佳的广告数据包不仅会浪费字节资源，还会导致长期的维护问题、兼容性故障，以及调试上的麻烦——而这些问题的解决难度会在设备真正投入使用时变得更大。
一个优秀的广告数据包所遵循的首要原则是：它必须具备自描述能力。广告信息在传输过程中难免会出现丢失、顺序混乱或部分内容被忽略的情况。因此，每个广告数据包都必须包含足够的上下文信息，以便他人能够独立理解其内容。在这里，版本控制是必不可少的功能——在数据包的开头添加明确的版本字段，可以让扫描工具在无需与广告发布者同步更新的情况下进行进化发展；同时，当数据包格式发生变更时，这一机制也能为你提供有效的应对方案。
另一个重要的原则是向前兼容性。扩展型广告格式虽然能够实现更丰富的信息传递，但这种传递过程并不需要双方进行协商或确认。扫描工具应该能够忽略那些它无法理解的字段，而不会因此导致系统出现故障。通常来说，应将广告数据包设计成由带有长度前缀或类型标签的字段组成的序列，而不是采用固定的二进制结构。这样的设计方式可以让后续添加新字段时不会影响旧版本的解析器，即使增加一些字节也不会带来太大负担，相比之下，使用不可扩展的格式所带来的损失要严重得多。
还需要记住的是，广告数据是存在于一个共享的无线通信环境中的。仅仅因为你可以发送更多的数据，并不意味着你就应该发送所有信息。广告数据包应当只包含那些能够帮助扫描工具决定下一步该做什么的信息，例如设备的功能、角色信息、兼容性标志以及一些粗略的状态描述等。而详细的配置信息、用户数据或任何需要保密的内容，则不应该包含在广告数据包中。扩展型广告终究还是广告，并不是某种安全的传输机制。
功耗因素也会对广告数据包的设计产生影响。较大的数据包传输所需的时间更长，可能还需要通过多个连续的数据包来进行传输，这会增加通信所消耗的电量，进而影响广告发布者和扫描工具的能耗。即使在允许数据包规模扩大的情况下，设计紧凑的数据结构依然会带来长期的好处。扩展型广告格式确实为开发者提供了更多的灵活性，但高效的编码方式仍然是必不可少的，这并不是什么过时的要求。
团队们经常犯的一个错误就是将扩展型广告数据包当作存储内部数据结构的工具来使用。这种做法起初可能只是为了方便操作，但最终却会变成一种隐患。无论你是否有意如此，广告数据包都是你的公共接口的一部分，它们必然会被他人观察、记录、逆向分析，并被以你无法预料的方式加以利用。因此，清晰、有节制地设计广告数据包，实际上是对未来系统稳定运行的投资。
如果设计得当，扩展型广告数据包会随着时间的推移而逐渐完善。它们能够帮助生态系统持续发展，而不需要立即进行连接调整、固件更新或协议重新设计。相反，如果设计不当，这些数据包就会变成隐藏的技术隐患，只有在实际使用中出现问题时才会显现出来。扩展型广告格式确实为你提供了更多的思考空间，而如何明智地利用这一空间，才是区分优秀系统与脆弱系统的关键。
如何扫描扩展型广告数据包
在扫描这些扩展广告的过程中，许多开发人员首次意识到了理论上可行的技术与实际设备上的运行效果之间的差异。从扫描器的角度来看，这种扩展广告功能确实为用户提供了更多的选择权——扫描器能够检测到某台设备的存在，但并不一定非要接收该设备发送的所有数据。这种选择性是经过刻意设计的，如果你希望自己的系统能够表现出可预测的行为，那么理解这一设计原理就显得至关重要了。
从宏观角度来看，扫描过程仍然会从主要的广告渠道开始。扫描器会像检测传统广告一样，监听广告内容并应用相应的过滤规则。当遇到扩展广告时，初始数据包中可能只包含最基本的信息以及一个辅助指针。此时，扫描器需要决定是否跟随这个辅助指针来获取更多信息。这一决策可能会受到过滤规则、时间限制、功耗考虑因素，或者操作系统内部调度机制的影响。关键在于，即使接收到了主要广告内容，也不能保证一定能获得其中的扩展数据。
Android通过与检测传统广告相同的扫描API来处理扩展广告数据，但当有扩展数据可用时，这些API会添加额外的字段。这可能会让人觉得扫描过程是“自动进行的”，但实际上系统是在为你做出相应的决策。如果你的扫描设置较为激进，系统为了节省电量，可能会选择不跟随辅助指针来获取扩展数据；如果过滤规则过于宽泛，系统也可能会降低优先级，从而忽略扩展数据的传输。这些行为并非漏洞，而是平台在权衡各种因素后做出的取舍。
另一个需要注意的因素是时间控制。扩展广告的正常运行依赖于主要数据包与辅助数据包之间的精确协调。如果在辅助数据包被发送时，扫描器正在忙碌、处于睡眠状态，或者正在切换工作场景，就可能会完全错过这个数据包。这样一来，扫描结果就会不完整——设备虽然会被检测到，但其扩展数据却无法被获取。开发者有时会将这种现象视为系统的不稳定行为，但实际上这只是扫描器的任务周期和优先级设置所导致的。
在处理扩展广告时，过滤策略就显得更为重要了。由于跟随辅助指针会消耗一定的资源，因此扫描器最好能尽早有选择地接收信息。设计得当的广告数据结构会将最重要的标识信息放在主要广告内容中，这样扫描器就可以在不必接收全部扩展数据的情况下做出明智的决策。如果关键信息只存在于扩展数据中，扫描器可能永远无法获取到这些信息。
扩展广告还改变了开发者处理扫描结果的方式。根据不同的时间和环境条件，同一设备可能会被多次检测到，其显示的内容也可能会有所不同（有时会包含全部数据，有时则只显示部分内容）。那些假设扫描结果一定是完整且最终的代码，很可能会出现错误。而优秀的扫描系统会将扫描结果视为逐步更新的信息，通过不断合并数据来获取最终的结果，而不是期望所有信息一次性全部到达。
归根结底，扫描扩展广告实际上是一种基于概率思维的过程。你无法保证在每一个时刻都能获得完整准确的信息，但系统提供的结构足以帮助你在一段时间内做出正确的决策。当系统是按照这种思路设计的时，扩展广告就能帮助用户实现更丰富的信息发现体验，同时也不会影响系统的功耗效率；而当设计不合理时，扩展广告就会显得不可预测。这种差异其实更多体现在人们对这些系统的预期上，而非API本身的功能差异。
性能、功耗与时间开销的权衡
扩展型广告功能确实为开发者提供了更多灵活性，但同时也迫使他们面对那些传统广告模式所隐藏的权衡问题。在传统广告模式下，大部分关键决策早已被相关规范预先确定好了：数据包的大小是固定的，物理层传输机制也是既定的，其传输时序也相对容易预测。而扩展型广告功能去掉了这些束缚，虽然这为开发者带来了更多自主性，但若处理不当，也会带来危险。
功耗问题是大多数团队最容易低估的权衡因素。当广告数据包的大小增加时，设备处于无线电工作状态的时间也会相应延长，尤其是当这些数据包被分散在多个辅助数据包中传输时。每个额外的数据包都会增加传输时间，同时也会增加扫描设备为接收完整的数据包而多次唤醒自身的概率。对于广告发布方来说，如果广告发送间隔很短，或者同时有多个广告任务在运行，那么功耗就会显著增加；而对于扫描设备而言，过度依赖这些辅助数据包也会严重影响电池寿命，尤其是对于那些已经需要在后台执行许多任务的移动设备来说。
物理层传输机制的选择也会直接影响功耗。使用LE 2M协议进行辅助广告传输可以减少数据传输时间，因为这种协议的传输速度更快，尽管其瞬时数据传输速率较高，但总体功耗却会降低。而LE编码物理层协议虽然能扩大通信范围，但却会以增加传输时间和功耗为代价。对于需要实现远距离通信的场景来说，选择这种编码协议可能是正确的选择，但这一决定必须经过慎重考虑。否则很容易设计出在实验室环境中表现良好，但在实际使用中却会大量消耗电池电量的广告方案。
在传输时序方面，扩展型广告的功能也与许多开发者的预期不同。由于辅助广告数据包的发送时间是相对于主广告数据包来安排的，因此任何延迟或冲突都可能在整个数据传输链中产生连锁反应。这意味着扩展型广告在传输时序上的不确定性要远远高于传统广告模式。如果系统仅根据广告发送间隔来假设传输时序是稳定的，那么使用扩展型广告功能很可能会打破这些假设。因此，在设计系统时，应该注重系统的容错能力而非传输精度。
性能优化并不仅仅局限于无线电通信层面。在Android系统中，处理扩展型广告数据会增加蓝牙堆栈的处理负担，导致内存消耗增加，并且还会向应用程序发送更多的回调信息。如果扫描频率很高，而且数据包的大小较大，那么这些因素都会进一步增加CPU的使用负荷，并给垃圾回收机制带来压力。虽然这些影响单独来看可能并不显著，但在那些需要频繁进行后台扫描或持续进行设备识别的系统中，它们的累积效应就会变得非常明显。
最重要的性能优化措施之一就是适度控制数据传输量。扩展型广告功能确实允许发送更多数据，但通过更智能地控制数据传输量，往往能够获得更好的效果。将关键识别信息放在主广告数据包中，可以帮助扫描设备提前过滤掉不必要的辅助数据包，从而避免不必要的数据接收操作；同时，保持辅助数据包的大小适中也可以减少数据传输时间，提高系统的可靠性。这些优化措施并非多余之举，它们其实是构建可扩展系统的基础所在。
在实际应用中，最佳的扩展广告配置是通过反复测试得出的结果，而非凭猜测确定的。通过测量功耗、观察设备在负载下的扫描行为，并在真实的射频环境中进行测试，才能发现那些在简单测试中无法显现出来的权衡因素。只有将扩展广告视为一个系统级功能，而不是用来替代传统的广告机制，团队才能真正发挥它的作用。
如果运用得当，扩展广告可以通过减少不必要的连接并实现更智能的设备识别机制，从而提升性能和能效；但如果使用不当，反而可能产生相反的效果。关键在于要明白：灵活性总是伴随着责任，尤其是在无线系统中。
实际应用案例：可穿戴设备、配件与物联网
只有当扩展广告从演示环节真正应用于实际产品中时，它的价值才会得到充分体现。这时，“能够发送更多数据”与“能够设计出更优秀的系统”之间的区别就变得显而易见了。在生产环境中，扩展广告的意义不在于数据传输量，而在于减少连接次数、降低重复尝试的频率，以及避免无关设备之间产生不必要的交互。
可穿戴设备是扩展广告最明显的受益者之一。现代的可穿戴设备很少会孤立存在，它们通常会与手机、其他辅助设备、充电器甚至其他可穿戴设备进行互动。通过扩展广告，这些设备可以提前向用户说明自己的功能、兼容性等信息。这样，在尝试建立连接之前，手机就能判断该设备是否支持所需的各项功能或操作模式，从而避免不必要的配对尝试，使多设备协同使用变得更加顺畅。
音频配件也是扩展广告的典型应用场景。耳机和耳塞往往会在充满蓝牙设备的环境中使用，而传统的广告机制无法提供足够的识别信息来消除混淆。扩展广告则能够传递更多关于设备类型、支持的配置文件或当前状态等信息，从而帮助手机快速选择“正确的”设备进行连接。这种机制大大减少了连接到无关设备所带来的困扰，提升了用户体验。
物联网设备同样可以从扩展广告中受益。许多物联网设备被设计为可以被多个扫描设备随时发现并短暂交互。扩展广告使这些设备能够在不建立连接的情况下，主动暴露自身的配置状态、是否已准备好接受配置信息或所属者的身份信息。在部署和维护场景中，这一功能尤为重要，因为它能帮助技术人员或自动化系统快速而准确地识别目标设备，从而节省大量时间和精力。
总的来说，扩展广告通过多种方式提升了各种设备的用户体验和系统的稳定性。无论是可穿戴设备、音频配件还是物联网设备，扩展广告都能为它们带来实质性的好处。
另一个重要的应用场景是在异构生态系统中进行功能协商。当不同代际或不同厂商的设备共存时，扩展广告机制允许新设备宣传自身的高级功能，而旧设备则会忽略那些它们无法理解的功能。这样一来，系统就可以实现平滑进化，而无需进行硬分叉或强制升级。系统可以自然发展，扩展广告机制在这里起到了兼容性缓冲的作用，而非引发破坏性的变化。
在那些需要根据距离来调整行为的场景中，扩展广告机制也同样表现出色。设备可以传达自身所处的状态信息，比如是否准备好进行交互或参与某个临时小组活动，这样扫描设备就能做出相应的响应。这种方式能够减少不必要的干扰，让用户体验到响应迅速且不侵扰性的交互体验。在这种应用场景下，扩展广告机制的价值在于它所避免的问题，而不仅仅在于它所能实现的功能。
所有这些应用场景都有一个共同点，那就是选择性。只有当设备在发送信息时有所目的，而扫描设备在接收信息时也能有针对性地进行处理时，扩展广告机制才能发挥最佳效果。如果双方都能将广告信息视为有意义的交流内容，而不是背景噪音，那么扩展广告机制就会成为一种强大的系统架构工具，而不仅仅是一个数据包而已。
常见的生产环境中的错误与故障模式
虽然扩展广告机制已经足够成熟，可以确保其可靠性，但它仍然具有一定的复杂性，因此可能会出现一些在文档或示例代码中无法预见的故障。大多数生产环境中的问题并非源于对API的误解，而是由于人们对扩展广告机制在负载情况下、在不同设备上以及随着时间推移时的行为方式存在错误的假设。如果能够及早发现这些故障模式，就可以节省大量的调试时间，避免一些隐蔽的问题被发布到用户手中。
其中一个最常见的问题是人们认为扩展广告机制总会以一种平滑的方式失效或回退到旧版本。有些开发人员在没有进行适当的功能检测的情况下就启用了扩展广告机制，他们期望系统在遇到不支持的情况时能够自动切换回传统的广告方式。但实际上这种机制并不会自动切换。当扩展广告机制不被支持或暂时无法使用时，相关请求往往会直接失败。如果不能正确处理这种失败情况，设备可能会完全停止发送广告信息，而不会以降低功能强度的方式继续发送。
另一个常见的问题是广告集合资源被耗尽。控制器所能支持的广告集合数量是有限的，而且这个限制往往比人们想象的要小得多。如果不能及时停止或释放已使用的广告集合，这些资源就会不断累积，最终导致控制器无法创建新的广告集合。这种情况通常表现为间歇性的故障，只有在对系统进行长时间运行或特定的用户操作流程后才会出现。由于根本原因在于资源泄漏，而非配置错误，因此这些故障在短暂的测试环境中很难被重现。
与时间相关的错误也十分常见。扩展广告功能的实现依赖于主数据包与辅助数据包之间的精确协调，而这种协调关系可能会因设备电源状态的切换、射频信号的共存问题或系统负载的变化而受到影响。即使在条件看似完全相同的情况下，开发人员也会发现扫描结果中有时会包含扩展数据，而有时则不会。将扫描结果视为阶段性而非最终确定的成果，有助于缓解这些问题，但这需要开发者改变原有的扫描逻辑编写方式。
数据包的大小和结构问题也经常出现。虽然扩展广告功能允许使用更大的数据包，但控制器通常会设定低于理论最大值的限制。过大的数据包可能会被默默地截断或直接拒绝接收。而在其他情况下，结构不合理的数据包会导致扫描设备在解析过程中出现错误，这些错误往往会被误认为是传输失败所致。如果在数据包中添加明确的长度和版本字段，那么这些问题的检测和诊断就会变得容易得多。
另一种隐蔽的故障模式与系统其他组件的交互有关。在Android系统中，系统服务及厂商提供的功能可能已经在内部使用了扩展广告技术。当某个应用程序启动扩展广告功能时，它可能会在不知不觉中与其它组件争夺有限的系统资源，由此导致的故障看起来可能是随机的，除非考虑到更广泛的系统环境。这一点在那些具有严格功耗管理机制或厂商自定义蓝牙功能的设备上尤为明显。
最后还有一类错误只在实际的无线环境中才会出现。干扰、设备的密集度以及移动性等因素都可能影响扩展广告功能的表现。在实验室环境中能够正常工作的数据包，在拥挤的环境中可能会出现问题，从而导致次要数据包丢失或发现延迟。这些问题并非扩展广告技术本身的缺陷，而是提醒我们：无线系统的运行结果其实是具有随机性的。因此，在真实环境下进行测试是必不可少的。
大多数与扩展广告相关的问题并不会造成严重的后果。它们往往表现得比较隐蔽、间歇性出现，而且很容易被误判。应对这些问题的关键在于保持谦逊的态度：要认识到系统行为的不确定性，明确处理各种故障情况，并设计出即使在广告功能表现不理想时也能正常运行的系统。扩展广告技术确实非常强大，但它更依赖于精心的设计而非过于乐观的假设。
何时不应使用扩展广告
扩展广告技术确实很强大，但强大并不意味着它适用于所有场景。在很多情况下，扩展广告并不是合适的选择，而识别出这些情况与掌握其使用方法同样重要。仅仅因为某种技术存在，就想要在所有地方都使用它，这种冲动往往会导致不必要的复杂性、更高的功耗以及可避免的兼容性问题。
一个明显的例子就是超低功耗设备。那些设计为仅靠一枚纽扣电池就能运行多年的设备，它们的电源预算通常非常紧张。传统的广告技术由于数据包大小固定、发送时机可预测，因此更容易在这种环境下进行优化。而扩展广告技术，尤其是那些包含多个辅助数据包的技术，可能会引入额外的不确定性以及不必要的无线信号干扰，在这种设计中这些因素是难以被接受的。在这种情况下，简单性往往才是更好的选择。
向后兼容性也是避免使用扩展广告功能的另一个重要原因。如果你的设备必须能够被那些不支持蓝牙5功能的旧款手机、嵌入式扫描设备或系统所识别，那么使用传统的广告机制仍然是最安全的选择。虽然也可以采用混合方案，但仅仅依赖扩展广告功能的话，很可能会排除一部分潜在的用户群体。对于那些使用寿命较长或用户群体较为多样化的产品来说，这种风险可能会超过使用扩展广告功能所带来的好处。
对于那些需要精确时间控制的场景而言，扩展广告机制也不适合使用。因为辅助广告数据包的发送时间是相对于主广告数据包来安排的，而且可能会受到系统负载或射频环境等因素的影响，因此扩展广告无法确保数据一定能在预定的时间被接收。如果你的系统依赖精确的时间控制来进行同步或协调操作，那么任何形式的广告机制都可能不适合使用，而扩展广告也无法改变这一事实。
另外，在数据内容本身就非常敏感的情况下，也应当避免使用扩展广告。无论是否采用扩展广告机制，广告本质上都属于广播形式——即使这些数据不容易被解读，范围内的任何设备都能接收到这些信息。扩展广告无法提供保密性、认证功能或数据完整性保障。因此，如果需要保护所交换的信息，那么使用安全连接或加密通道才是更合适的解决方案。
最后，在蓝牙协议栈被过度定制或受到各种限制的环境中，也应谨慎使用扩展广告。有些设备仅部分支持扩展广告机制，或者在某些配置下会出现运行不稳定的情况。在这种环境下，选择传统的广告机制可能是一种更为实际的选择——这种做法虽然会牺牲一定的灵活性，但能够确保系统的稳定性。尤其是当系统出现故障所带来的损失很大，而扩展广告带来的好处又相对有限时，这种选择就更加合理了。
选择不使用扩展广告，并不等同于没有实现现代化。这其实是一种认识到：工程设计的重点在于是否适合特定场景的需求，而非追求新奇性。只有在对信息发现有较高要求且需要精确控制发现流程的情况下，扩展广告机制才具有价值；而在其他情况下，更简单的机制往往更为合适。优秀的系统会刻意选择使用扩展广告机制，而不是将其作为默认选项。
结语：蓝牙依然有些“奇怪”，但现在已经变得“更好”的奇怪了
蓝牙技术从诞生以来就一直在各种妥协中发展。它存在于无线电物理原理、功耗限制、向后兼容性以及截然不同的产品需求这些因素的交汇点上。扩展广告机制并不能改变这一现状，也无法让蓝牙技术变得简单易用。但它确实消除了那些多年来一直制约蓝牙设计的人为因素，从而使工程师们能够更坦诚地设计自己的设备，并明确这些设备应该如何被其他设备识别。
扩展广告机制带来的最重要的变化是概念上的，而非技术层面的。设备之间的信息发现过程不再是一个简单的“设备是否存在”之类的二进制判断问题，而变成了一种更加丰富、有意义的意图交流方式。设备可以在建立连接之前就清楚地表明自己的功能、兼容性以及使用环境等信息；扫描设备也可以根据这些信息来决定哪些设备值得关注，哪些可以忽略。这样一来，系统就会变得更加高效、可扩展，同时也更易于用户使用——即使其背后的技术实现机制更为复杂。
同时，扩展广告功能再次印证了一个古老的道理：灵活性总是伴随着责任。由于蓝牙技术规范允许存在更多的变体，因此这些API提供了更多选择，但这些变体必须得到妥善管理。设计不当的数据结构、过于激进的配置设置，或者对可靠性的不切实际期望，都可能迅速将这一强大的功能变成导致系统不稳定的因素。那些能够从整体角度思考问题、在真实环境中进行测试，并以发展而非追求完美为目标来进行设计的团队，才能真正利用好扩展广告功能。
还需要记住的是，扩展广告功能并不能取代之前的所有广告机制。传统的广告方式仍然具有其价值，在很多情况下，它们依然是最佳选择。蓝牙生态系统的健康发展，是因为它支持多种不同的设备型号，而不是因为强制所有人使用最新版本的设备。优秀的工程决策往往并不在于选择最先进的技术方案，而在于选择最适合当前需求的技术方案。
如果说从AOSP系统中扩展广告功能的实施中可以得出什么结论的话，那就是：蓝牙技术并没有变得不那么“奇怪”，而是其“奇怪之处”得到了更好的理解与设计，那些愿意深入研究这一技术的开发者也能更容易地利用这些功能。这就是进步——即使这种进步并没有伴随着任何营销口号。
扩展广告功能为我们提供了更强大的工具，但最终我们用这些工具创造出什么，仍然取决于我们自己。
