手机WiFi协会响应能力

Question

我们的应用程序试图解决一个严重的人道主义问题，但是 - 不可否认，但有很好的理由 - 高度依赖于手机与我们的WiFi接入点的关联速度。这甚至是正确的，特别是如果用户暂时没有触摸他们的手机，也许我们会短暂地进入他们的范围。大部分发生在细胞范围之外。

其次很重要，尽管我们尽最大努力阅读平台文档和其他公开信息，但我们有时会看到电话连接到接入点之前的几分钟，有时接近一小时它会持续且非常强大接待。在这两个平台上，我们的应用程序已为此目的预先配置了SSID，但使用用户创建的SSID的性能也很有趣。

让我们以Android为例，因为它的理念更加透明且适合应用程序（例如，如果该应用程序的核心功能受到不利影响，则表示关注＆＃34 ;通过电池优化）。在确定最短响应时间的极端实验中，手机配置为：

• 睡眠期间的WiFi =始终
• WiFi lock由申请人持有
• Partial wake lock由申请人持有
• 免除battery optimization申请
• 每次都有新的SSID，以防OS＆＃34;学习＆＃34;该SSID没有互联网连接
• 信标速率设置为10 Hz至30 Hz（有时会发现有所改善） 在此配置中，我们仍未获得完全一致的结果。我们认为应用程序和设备之间的区别，或维持关联与建立关联，可能是潜在的原因。

所以问题是：

• 有人知道要测试的其他想法或变量吗？ （证据 它们是爆炸测试矩阵的随机猜测的关键）
• 其他已解决此问题的人？
• 文档/博客/等。我们可能错过了？
• 人们，尤其是Apple或Google内部的人，可能愿意提供帮助吗？

我们甚至愿意购买咖啡或晚餐，旅行，支付咨询费率，以支持具有适当专业知识的人。

更新：所以很明显，即使被动地监听AP信标是可能的，合理的和预期的，Android也不会监听WiFi信标，除非它主动扫描。换句话说，为了最大化关联响应，您必须将WifiManager.startScan（）置于紧密（15 Hz）循环中。

所以......要做到这一点，你必须让代码一直在运行，从SCAN_RESULTS_AVAILABLE_ACTION意图接收器开始一个新的扫描实际上变得很容易。这个代码实际上会在打瞌睡期间继续运行（IDLE状态），这太棒了！ （对电池寿命TBD的影响，但显然不为零）

现在的问题是WiFi无线电在该模式下关闭，即使WifiManager.isWifiEnabled（）仍然报告为真。扫描只需在20毫秒而不是4000毫秒内返回。我正在考虑是否有任何远程WiFi相关API会触发它唤醒，如P2P，WPS或Hotspot2。

第二次更新：P2P和WPS没有效果。但是在20毫秒内返回的扫描仍在扫描 - 你可以看到ScanResults正在改变！然而，似乎经常依赖于打盹模式。在完全IDLE下，它每隔约130秒发生一次，而IDLE_MAINTENANCE仍然连续发生，就像在ACTIVE和INACTIVE状态下一样。但是，这仍然没有在90％的时间内扫描。