手机 Android 操作系统是否曾经限制蓝牙？
我开发了一款 Android 手机应用程序，可以通过 BTLE 以 100 Hz 的频率从智能戒指接收传感器数据。 传感器数据被写入手机上的文件中。 应用程序的典型使用时间是运行 5-20 分钟。 使用带有唤醒锁的前台服务进行编程。 90% 的时间保持 100 Hz 速率，但有时采样率会在 3-15 分钟后降至 30-70 Hz。 有时它会下降两次，比如在 3-5 分钟时下降到 70 Hz，然后在 10-15 分钟时下降到 30 Hz。 Android 是否有可以限制 BTLE 的省电功能？
问题似乎与当前电池电量无关，例如充电 80% 或 40% 时都会发生。
线程继续运行并且正在接收数据，所以它不是打瞌睡。 刚刚节流。 是什么导致了节流？
看来答案是“是”。 BLE 节流可能因多种原因而发生，并且无法通过 Android WearOS 或 Apple WatchOS API 访问节流控制。 引用这篇研究论文：
“可穿戴医疗生态系统中的数据包丢失是 因以下因素而变得复杂。首先，在可穿戴医疗保健生态系统中，更大的数据包尺寸是首选。典型的蓝牙4.0仅支持23字节的数据包传输。 然而，在身体传感器网络 (BSN) 的情况下，生态系统中涉及多个可穿戴设备，组合数据以更大的数据包大小进行流式传输，最大可达 255 字节 [13, 14]。其次，BLE 芯片组和操作系统 (OS) 在可穿戴医疗保健生态系统中非常多样化，特别是考虑到现成的智能手机（Android、iPhone）或 Raspberry Pi 经常用作集线器 [8,15,16] 。第三，不同原始设备制造商 (OEM) 的 BLE 与外围可穿戴设备和中央主机之间的数据包传输相关的优化因素有所不同。这些因素包括连接参数、信号强度、外部信号干扰和数据损坏[17]。例如，iOS 为设备开发人员定义了一组连接参数值，并限制了最大传输单元 (MTU) 大小 [18]。另一方面，Android 允许应用程序开发人员设置所需的 MTU 大小。最后，BLE 芯片组驱动程序与主机中的自定义应用程序之间的交互也可能导致数据包丢失。最现代化的操作 系统使用硬件抽象层 (HAL) 从外部应用程序中抽象内部硬件驱动程序和参数 [19, 20]。开发者调用标准 函数来请求 BLE 特定任务并提供回调句柄，然后当内部驱动程序完成请求的操作时，操作系统会调用该回调句柄。该接口公开的函数数量仅限于最关键的操作。由于其他高优先级的原因，数据包也可能被传递到底层硬件芯片组，但不会从芯片组传递到请求的应用程序功能 主机上同时运行的任务。最终，芯片组可能会由于调度和优先级冲突而开始丢弃数据包。这些复杂的细微差别使得在可穿戴外设和主机之间开发基于 BLE 的稳健数据传输方案变得非常困难。”