手把手教你如何开发AltBeacon安卓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 – 创建通知