4

我们希望在我们的应用程序中加入信标技术，以通过屏幕关闭事件来创建用户参与度。

在当前用例中，我们假设最终用户将不断移动。

到目前为止，我们已经测试了两种不同的方法。

  • Kontakt SDK/Android 信标库，以便不断扫描信标。使用 UUID（假设我们使用 Eddystone），我们可以将它与我们为后端检索到的缓存消息相关联。然而，这最终会消耗大量电池。
  • Nearby Messages/Nearby Awareness这很有潜力，因为它有一个信标仪表板，可以轻松配置每个信标上的附件，并且它在 iOS 和 Android 上都有“相同”的实现。但是，在阅读文档并经过多次测试后，如果我们关闭屏幕，我们将无法检索信标附件。唯一可能的方法是让用户在信标前停留 3 分钟（取决于智能手机和能量设置），这违背了我们的假设，即用户一直在移动，因此可能会触发扫描当用户不在信标附近时。

另外：在 iOS 上使用Nearby Messages时，我们得到了想要的行为：如果应用程序和API都配置为后台使用，则应用程序将在使用Nearby Messages时发现信标。

因此，我们问：

  • 有没有办法将 Nearby API 与屏幕关闭事件一起使用？喜欢不断安排扫描？
  • 我们还有哪些其他替代方案可以在 iOS 和 Android 之间跨平台使用？（以便我们可以尝试确保平台之间的类似行为）

编辑：经过进一步阅读，我们得出结论，BLE信标扫描在正确使用时对电池的影响最小（强调正确，我们将不得不改变我们这边的启发式方法），请参阅：this。那么问题仍然存在：为什么我们不能在没有 附近消息自己的通知的情况下在附近的 api 中进行背景扫描，以便我们可以断言用户在信标附近经过？让我们感兴趣的是，这在 iOS 上运行良好......

4

1 回答 1

2

Nearby API 按照其选择的时间表进行扫描，包括事件屏幕。 您没有为您的应用程序自定义附近扫描规则的灵活性，因为它被设计为适用于手机上所有应用程序的服务。使用 Nearby 时，您必须接受此限制。

Android 信标库是开源的，允许灵活配置扫描时间。 如果您发现您的配置在您的用例中使用了过多的电池，您可以调整它。默认设置是为了在功耗和快速检测之间取得良好的平衡而设计的，因此建议使用这些设置。如果您发现默认设置不适合您，您可以通过多种不同的方式进行设置。最简单的方法是调整其背景的 scanPeriod 和 betweenScanPeriod。但是还有许多其他方法可以自定义其扫描行为。

但是，您应该注意，如果处于低延迟模式，“不断安排扫描”（如您的问题中所述）将消耗大量功率。Android Beacon 库默认是在低功耗模式下进行持续扫描，此时应用程序在后台并且周围没有信标。在大多数设备上，这会在 5 秒内产生检测，并产生类似于电池待机的合理用电量。

如果不知道您在 Android Beacon 库中使用的配置、测试条件到位以及目睹了多少功耗，很难提供更多建议。如果你能提供这些信息，我可能会提供更多帮助。

全面披露：我是 Android Beacon Library 开源项目的首席开发人员。

于 2017-12-06T16:25:14.570 回答