Beacon技术的未来.docx

Beacon技术的未来移动和网页应用以及Beacon技术的未来自从苹果公司推出iBeacon以来已经差不多两年的时间， 其自成一脉的Beacon格式，发动了一场上下情景计算的革命。同时也是计算机历史上，第一次能够像使用iPhone这类消费类电子设备实现大规模分布式部署及感知仅由电池供电的微小的无线设备广播的位置信息。最重要的创新是消除了所有用户交互过程中不方便的地方。在iBeacon出现之前，你可能会使用二维码这种方式来和手机之间传送上下消息，但这种方式很不方便：想象一下，你拿出手机，打开扫描二维码应用，将镜头对准二维码。。。等等。但是有了Beacon技术，用户只需要进入其识别范围，一个预先设定好的程序逻辑就会自动触发并出现在他（她）的手机屏幕上 ——很方便不是吗。苹果让这项技术变得优雅、简单且注重隐私。它们预计届时可能会存在多达数十亿台的设备，于是在设计iBeacon协议格式的时候，使用了20字节的容量来存储一个静态的标识符（UUID + Major + Minor）-- 这下足够标识这个星球上的所有设备了吧。当一个手机发现并设别了某个Beacon设备，就会触发预设应用里事先对应到这个Beacon设备的动作。这就是我们所说的优雅设计最棒的一部分：预设应用必需搜索特定的Beacon设备（这同时也表示这项技术是一种预置技术）。苹果知道强大和便利的使用体验可能会让用户陷入被垃圾信息骚扰，以及在不知情情况下被追踪的危险。这就是为什么要让用户一定要明确的有选择地去下载他们喜欢的商店或是品牌的应用程序。通过这样做，用户就可以允许应用的开发者去推送提醒信息到他们的手机上或是使用定位服务。当用户感觉应用程序不应该使用其位置信息，或者没有太多价值的时候，他（她）就可以卸载这个应用。这也就是为什么应用的开发者们更应该专注于给用户提供更多有价值的东西。想像一下，当一个人搭上了一列火车，在到达目的地之后，自动弹出车票的支付信息并引导他（她）完成支付，是多么梦幻的一种体验。又或者一个将要搭乘飞机去往某地的旅客，到达机场后手机应用自动规划出换取登机牌的路线，靠近登机口时自动完成检票操作，这又是多么美妙且便利的用户体验啊！然而，广播静态标识符并触发预设好的动作是一回事，通过动态程序内容和用户进行交互又是另一回事。当一个用户走进家具展厅，来到她最中意的沙发旁边时，她可以通过手机查看该产品的图片、描述及价格。但是这些数据可能会随着时间而改变。为了维护这些数据，开发者一种方式是通过将新数据重新编译到应用内再发布新版本到应用商店，或者另一种简便的方式，由用户的手机通过发送Beacon标识符与商家的CMS系统对接后获取新数据，而这些新数据是商家在CMS系统后台实时维护的。谷歌的Eddystone和移动Web问题是，我们该如何同这么多的品牌、这么多的机场、这么多的零售商店去互动呢？难道把它们的应用程序全下一遍吗？当然不是。谷歌最近就推出了一款不一样的Beacon协议格式——“Eddystone”。与iBeacon不同的是，它不仅广播一个标识符，而且还广播一个预置的网页地址。因此，与那么多各种应用程序携带着各自的情景消息数据不同，取而代之的是我们可能只需要一个应用程序，甚至简单到仅仅就是一个网页浏览器。这也许预示着用一个应用程序同多个Beacon设备通讯的诺言即将实现。Eddystone类似的改变早在90年代就出现过。当时有很多独立的应用程序使用各自不同的数据格式同服务器进行交互。比如FTP协议与FTP客户端，IRC即时聊天协议和它的客户端，新闻组，文件检索，邮件等等。而随着时间的推移，大多数上述的服务都转化为web形式，并由因特网浏览器所处理。这样它们就可以运行在任何一台电脑、处理器架构、和屏幕上。对于开发者来说，设计、编码、发布和更新web应用会变得比开发其它程序更快速也更成本低廉。更高的网络带宽和更先进的浏览器，使得用户更难分辨出像Outlook、Excel这样的传统独立应用和Gmail、谷歌地图、谷歌文档这类所谓的Web2.0应用之间的区别。而这种趋势在移动应用领域还不明显。大部分流行的应用程序诸如Snapchat、Facebook或者游戏仍然是以独立的原生应用形式运行着。究其原因是因为性能问题。原生应用有着更快的运行速度，更优化的电池效能，以及直接调用如传感器、摄像头、内存等底层设备的能力。然而随着时间的推移，移动设备、平台、屏幕尺寸的碎片化可能再次将这种改变朝着web应用的方向发展，特别是当浏览器变得更快，获得更多调用底层设备能力的时候。还是谷歌，举例来说，最近为iOS系统发布的Chrome浏览器，就能够用原生的方法扫描Beacon设备发出的广播地址。网页应用还是原生应用仅安装一个应用程序来同所有的Beacon设备通讯，这不失为应用部署问题的一种优雅的解决