第一篇文章我介绍了Beacon的一些基础知识，以及AltBeacon和它的蓝牙广告形式。今天将用一个实际的开发案例，指导读者学习如何用AltBeacon安卓API开发Beacon原型APP。
运用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 - 基本初始化步骤
更多干货往下看！
程序类别
针对不同的显示界面（包括主要展品信息界面、Beacon事件日志界面）的活动类别、以及其他一些辅助性的Java类别，这个APP包括一个自定义应用程序类和一个Actiivity类别。AltBeacon API自身就是一个库，它负责APP后台运行弹出，并提供一系列接口来支持与Beacon探测相关的回调函数。这些都通过自定义应用程序类“GyboApplication.java”执行。
图2 - AltBeacon API 关键接口
测定距离，更新范围
支持“监测”与“测距”功能。监测功能会在APP进入某一个或某一组Beacon区域时生成事件。这其实是一个二进制的概念，因为只有两种可能--APP在区域内、APP不在区域内。测距功能可以追踪游客距离某一组Beacon的距离，当两者近到一定程度时，就可以触发功能。
我们还必须对应用程序类别执行的RangeNotifier接口中的单实例对象方法“didRangeBeaconsInRegion（Collection<Beacon> beacons, Region region）”进行编码。AltBeacon库的后台蓝牙扫描进程能够发现附近的Beacon，而“didRangeBeaconsInRegion”每秒钟调用一次，并提供当次扫描到的Beacon列表。APP绝大多数功能都在此基础上实现。
分类则代表物理意义上的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米。当然你也可以允许用户手动设置、自定义这一类配置。
扫描配置又是什么？
类允许开发者对APP进行广告数据包扫描时长、活动间歇时长等参数进行配置。可以在初始代码中添加如下的代码。
图4 - 扫描配置
想要做好适合APP的扫描配置，需要考虑很多方面。扫描过程的电量消耗是很大的，因此扫描频次过高或时长过长就会增加电池电量的消耗。但如果扫描频次跟不上，Beacon探测结果的更新就会延迟，进而影响用户体验。
因此，根据实际应用场景的需要，我们必须在耗电水平和用户体验之间进行权衡取舍。例如，一个用来探测路途中经过的店铺的APP，就需要比博物馆导览APP拥有更快的Beacon广告探测和反应速度。
还需要考虑Beacon的广播频率。如果扫描频率高于Beacon广告，有时就会由于最近一次扫描活动中的广播数据包丢失而导致实际范围内的Beacon没有出现在API回调的报告中。
现实世界中的Beacon探测
不得不承认，现实世界总是不完美的。为了让APP能够更好的为人民服务，程序猿编写代码时也不得不考虑现实中的问题种种。在测试过程中，尽管我们很认真地设置了扫描配置，Beacon扫描偶尔还是会有漏网之鱼。现实中，由于游客和Beacon之间的物理屏障（如人群、其他物品等）、或Beacon配置与之前设想的不同，也会出现一些纰漏。物理屏障的存在会导致游客在展厅内行走时，APP数据回报出现短暂的异常。因此，Beacon应用不应当仅根据最近一次的数据回报就立刻作出回应。认识到这一点让我们收获颇多：与其中规中矩地根据AltBeacon库回调的数据行事，不如对算法进行适度的“模糊”处理，也许能改善Beacon APP的表现。为了改善算法，我们决定采用更复杂一些的方法来追踪范围内的Beacon。
