Beacon Ranging使用适用于Android的ProximityKit框架

时间:2018-04-20 18:55:07

标签: android ibeacon-android altbeacon

我正在努力将ProximityKit框架集成到我们的Android应用程序中,以检测我们从RadiusNetworks购买的信标。我们希望该应用程序能够测量或检测信标,考虑三个Android应用程序状态,这些状态在前台运行,在后台运行以及应用程序是否从任务切换器中被杀死(被刷掉)。截至目前,我们正在利用ProximityKit框架中的“didRangeBeaconsInRegion”方法来跟踪检测到信标时的日志。以下是我们的调查结果:

  1. 应用程序位于前台
    • 应用程序能够为信标提供范围,为每个检测到的信标提供日志 每一秒
    • 但是,我注意到在调试模式下,控制台在信标范围内快速显示大量类似的日志信息,我认为这可能会影响设备性能,电池使用情况以及设备在某种程度上变热的情况:< / LI>
  2. 04-20 14:16:17.258 18908-19492/com.droid.mobile.cho D/ScanRecord: first manudata for manu ID 04-20 14:16:17.273 18908-18920/com.droid.mobile.cho D/ScanRecord: parseFromBytes

    1. App处于后台/最小化

      • 应用程序能够为Android N或更早版本中每五分钟检测到的每个信标提供日志信标;但是,在Android O版本中每15分钟一次
    2. 应用程序被从任务切换器中删除(被刷掉)

      • 应用程序无法定位信标(如果信标范围很大,则通过启动本地通知进行验证,但是没有显示本地通知;最长20分钟的等待时间测试)
      • 我们提出了一个解决方案,即实现在后台处理接近套件信标范围的服务,但是,知道是否有更理想的方法来处理这种情况会很好。
      • 实施后台运行服务后,信标测距执行与
      • 上面的场景#1相同
      • 我还尝试在从任务切换器刷掉应用程序15分钟后检查设备日志:
    3. 04-23 10:34:44.449 13220-13220/com.droid.mobile.cho I/BeaconManager: BeaconManager started up on pid 13220 named 'com.droid.mobile.cho' for application package 'com.droid.mobile.cho'. isMainProcess=true 04-23 10:34:44.452 13220-13220/com.droid.mobile.cho D/BeaconParser: Parsing beacon layout: m:2-3=beac,i:4-19,i:20-21,i:22-23,p:24-24,d:25-25 04-23 10:48:02.760 13220-13228/com.droid.mobile.cho W/art: Suspending all threads took: 11.608ms 04-23 10:48:52.624 13220-13228/com.droid.mobile.cho W/art: Suspending all threads took: 25.439ms

      • 根据上面的日志,似乎在应用程序被杀死近15分钟后,所有线程都被暂停在设备上

      对于我们的测试设备,我们使用运行Android OS 5.0的LG G3手机和运行Android OS 7.0的三星Galaxy S6手机。

      考虑到我们的上述发现,我们主要关注应用程序从任务切换器中被杀死的情况,这导致应用程序没有测量任何信标以及应用程序在前台运行时显示的几个控制台日志。如果应用程序能够以正确的方式进行测距信号处理所有三种情况,那将是非常棒的。

      提前感谢您的回复。

0 个答案:

没有答案