运用Beacon进行博物馆导览

将Beacon应用于博物馆导览

，这样当游客靠近展品时
，APP可以提示该展品的相关信息
，走过路过就再也不会错过！想象一下，如果故宫有了这款APP, 当游客走到一个不明觉厉的青铜方樽面前，只要拿起手机就能快速了解它的主人、出土信息和花纹的寓意
，再也不用担心被人嘲笑没文化了。

这个设计的设想是：首先，博物馆内安装的所有的Beacon基站都在APP能够探测到的范围内，而且APP能够默默地在后台运行并探测附近的Beacon，但只有当游客与Beacon基站的距离靠近至2米范围内时才会跳出弹窗，提示与这一Beacon相关的展品信息
；其次，针对同一展品，APP不会不识趣地反复跳出提示窗
；最后

，还能够查阅APP系统日志底层Beacon相关事件。下面请看实地操作！

如果你也是第一次创建Beacon应用APP，看这里！

绑定服务，设定“区域”

对于首次建立应用程序类别的开发者
，以下几点需要注意
：首先，用AltBeacon API BeaconManager将APP与后台运行的AltBeacon库中的服务绑定。另外，要着手设定一个或多个“区域”。这里所说的“区域”是指一个或一组Beacon
，由AltBeacon Beacon ID 域值来规定。Beacon ID域将20个八位字节的标识域分成1个16字节的主ID、1个2字节的二级ID、1个2字节的三级ID
。在我的这个APP中
，主Beacon是我所关注的，因此只设定了主ID，因此我将二级和三级ID设为空值。

图1 – 基本初始化步骤

更多干货往下看
！

APP程序类别

针对不同的显示界面（包括主要展品信息界面、Beacon事件日志界面）的活动类别、以及其他一些辅助性的Java类别，这个APP包括一个自定义应用程序类和一个Actiivity类别
。AltBeacon API自身就是一个库，它负责APP后台运行弹出，并提供一系列接口来支持与Beacon探测相关的回调函数。这些都通过自定义应用程序类“GyboApplication.java”执行。

图2 – AltBeacon API 关键接口

测定距离
，更新范围

AltBeacon API支持“监测”与“测距”功能。监测功能会在APP进入某一个或某一组Beacon区域时生成事件
。这其实是一个二进制的概念
，因为只有两种可能——APP在区域内、APP不在区域内。测距功能可以追踪游客距离某一组Beacon的距离，当两者近到一定程度时，就可以触发功能。

我们还必须对应用程序类别执行的RangeNotifier接口中的单实例对象方法“didRangeBeaconsInRegion（Collection<Beacon> beacons, Region region）”进行编码
。AltBeacon库的后台蓝牙扫描进程能够发现附近的Beacon

，而“didRangeBeaconsInRegion”每秒钟调用一次
，并提供当次扫描到的Beacon列表
。APP绝大多数功能都在此基础上实现。

Beacon分类则代表物理意义上的Beacon, 它有着一系列属性
，包括：Beacon类型标示
、蓝牙MAC地址和名称
、接收信号强度指示器RSSI（Received Signal Strength Indicator）、（制造过程中设定的）校准传输的Beacon发射功率
、与Beacon相对距离的估算值（以米为单位计量
、通过RSSI和Beacon发射功率计算得出）
。

定义最近的Beacon，判断信息推送时间

有了Beacon列表以及每个Beacon与游客的距离估算值
，要推算出哪个Beacon离游客最近应该是不成问题的。但是在测试过程中也有一些问题。有的Beacon明知道就在范围内，却没有出现在didRangeBeaconsInRegion方法获取的Beacon列表中，到底哪里出了问题
？经分析
，原因可能是Beacon广播频率与安卓APP扫描的频率和持续时间不匹配，导致有时扫描过程无法接收到实际范围内所有Beacon的广告数据包。这就引出了另一个问题：如何控制安卓APP里的这些参数？

当APP收到范围更新时，就要判断是否需要执行相应的功能。具体来说，就是看哪个Beacon离游客最近
、有没有近到需要向游客提示Beacon所对应的展品信息

。如果最近的Beacon发生了变化
，游客会收到提示信息。例如，游客离开刚刚驻足的展品，下一次范围更新之后，离他最近的Beacon可能就不是之前那一个（组）了
。当然，还要判断距离最近的Beacon是近到什么程度
，才能向游客发送通知信息
。实验中的APP把这一数值设定为2米
。当然你也可以允许用户手动设置、自定义这一类配置。

扫描配置又是什么？

BeaconManager类允许开发者对APP进行广告数据包扫描时长
、活动间歇时长等参数进行配置。可以在初始代码中添加如下的代码
。

图4 – 扫描配置

想要做好适合APP的扫描配置，需要考虑很多方面
。扫描过程的电量消耗是很大的，因此扫描频次过高或时长过长就会增加电池电量的消耗。但如果扫描频次跟不上
，Beacon探测结果的更新就会延迟，进而影响用户体验
。

因此，根据实际应用场景的需要，我们必须在耗电水平和用户体验之间进行权衡取舍
。例如，一个用来探测路途中经过的店铺的APP，就需要比博物馆导览APP拥有更快的Beacon广告探测和反应速度。

还需要考虑Beacon的广播频率。如果扫描频率高于Beacon广告

，有时就会由于最近一次扫描活动中的广播数据包丢失而导致实际范围内的Beacon没有出现在API回调的报告中
。

现实世界中的Beacon探测

不得不承认，现实世界总是不完美的。为了让APP能够更好的为人民服务
，程序猿编写代码时也不得不考虑现实中的问题种种
。在测试过程中
，尽管我们很认真地设置了扫描配置，Beacon扫描偶尔还是会有漏网之鱼。现实中
，由于游客和Beacon之间的物理屏障（如人群
、其他物品等）、或Beacon配置与之前设想的不同，也会出现一些纰漏
。物理屏障的存在会导致游客在展厅内行走时，APP数据回报出现短暂的异常。因此，Beacon应用不应当仅根据最近一次的数据回报就立刻作出回应

。认识到这一点让我们收获颇多：与其中规中矩地根据AltBeacon库回调的数据行事，不如对算法进行适度的“模糊”处理，也许能改善Beacon APP的表现。为了改善算法，我们决定采用更复杂一些的方法来追踪范围内的Beacon。

模糊的Beacon追踪

我们的方法简单而有效——保留了最近15秒的报告中提示位于范围内的Beacon的相关数据缓存

，以及每个Beacon最近一次被探测到的精确时间。通过计时器任务，把最近15秒内没有被探测到的Beacon视为“过期”、移除缓存。

在可以称得上“重中之重”的didRangeBeaconsInRegion方法中,我们更新了Beacon数据缓存和回调的Beacon对象列表，然后评估全部的缓存数据，以判定目前距离最近的Beacon。于是测试的结果有了改善。这类似于数据平滑处理，相关代码片段如下图。

图5 – GyboApplication.java中的Beacon缓存设置和使用

图6 –BeaconEvent类别

图7 –负责终止BeaconEvent对象的计时器任务

最后的最后，提醒用户！

一旦实际执行了获取范围内Beacon报告的代码、采取了某种方式追踪Beacon、并根据获得的数据判断哪一个Beacon离游客最近，那么就只剩最后一步了：在合适的情况下提示游客Beacon所关联的展品信息。怎样判断是否“合适”呢？主要看最后一次生成的通知是否为同一Beacon相关的
，因为没有必要反复提示用户同一个展品的信息
。还需要将估算的Beacon距离与既设的（触发行为的）最小距离值进行对比
，判断游客是否足够靠近Beacon（也就是展品），然后决定是否发送展品信息
。

如果APP是在前台运行，提示游客的方法就很简单
：更新主要展览信息页面、显示最近的展品介绍。我们使用内存中有关Beacon及其对应展品的数据结构
，每个Beacon都有自己的ID，就可以分别对应各自的展品信息
，并在APP本地映射了这些数据的对应关系，但正如第一篇中所讲到的，对于除了原型以外的任何APP，最好从远程服务器上获取相关数据，根据位置或其他信息配置Beacon。

图8 –Beacon Information类别

图9 –ThingOfInterest类别

通知列表下拉菜单中的通知，并将其链接到定义展品信息页面的Activity
。

图10 – 安卓系统通知
，提示附近发现Beacon

下图是安卓通知的代码。

图11 – 创建通知