他们来晚了，但他们似乎在决定菜单。

手机和平板电脑极大地加速了传感器的使用，这是由苹果和谷歌开创的。Windows 8有刚刚发布然而，突然间，在消费者设备和电脑的传感器集成方面，微软似乎掌握了主动权。

为什么?嗯，他们是一头相当大的大象，而且，即使有些人可能会认为这使他们缓慢而笨拙(或者——喘气!)-走向无关紧要)，他们仍然有相当大的影响力来决定他们坐在哪里。而且，很明显，尽管其他公司已经走在了前面，但微软似乎在说，“嗯，我们将从这里开始铺路，好吗?”传感器厂商也在倾听，在他们的新版本中明确表示，他们符合Windows 8人机界面设备(HID)规范的要求。因此，微软受到了非常重视。

最初的目的是处理诸如鼠标和键盘之类的输入外设，目前的HID抽象了构成“人”的概念:所有传感器，无论它们是否反映来自人类的输入，都在HID保护伞下管理。

在最基本的情况下，HID是一个API。与iOS或Android一样，任何想要在Windows 8系统上提供传感器的人都必须针对该API，以便应用程序软件可以访问传感器数据。

但它不仅仅是一个简单的API。传感器的数量如此之多，而且还在不断增加，如果一个系统假装了解所有传感器，那么它就不会成功。相反，传感器通过报告向系统“描述自己”，报告允许操作系统使用系统中的特定传感器。

当系统启动时，驾驶员需要知道传感器将如何报告数据;它通过向传感器请求“特征报告”来做到这一点。这定义了基本的传感器信息，如当前的“报告间隔”(传感器多长时间报告一次数据——如果使用这种方式，有点像反向轮询);最小报告间隔(传感器的最大数据更新频率);连接类型;传感器灵敏度;也许这是传感器的昵称。同时，传感器报告其当前状态，定义数据字段和值类型。

在操作过程中，“输入报告”会根据传感器报告时间异步发送给驱动程序，或者根据驱动程序的请求(假设是基于应用程序的请求)发送给驱动程序。同样，这些报告都是自我描述;数据由驱动程序存储，如果报表是由应用程序请求驱动的，则会转发到该应用程序。

传感器设置也可能随着时间的推移而改变——特别是灵敏度和报告频率。驱动程序通过向传感器写入特征报告来实现这一点——同样，通常是应应用程序的要求。

微软试图通过将某些传感器分组为“类别”和“类型”来“标准化”。这些传感器以及来自供应商的特定传感器都由全球唯一标识符(GUID)标识。他们分配了一些;供应商也可以分配它们。

在创建传感器分类方面，他们比Android走得更远，如表1所示，其中列出了官方认可的传感器。除了这些特定的传感器，还有关于“通用”和自定义传感器的规定，允许包括尚未存在或不适合这些类别的传感器。传感器也可以单独声明，也可以集合声明。

表1。Windows 8支持的传感器，并与Android进行比较。Windows需要粗体传感器。Android不需要传感器。

注:

1. 目前还不是必需的，但将来可能会。
2. 弃用。
3. 仅当存在无线广域网(WWAN，如蜂窝网络)无线电时才需要。

请注意，我试图找出iOS支持哪些传感器，但与Windows和Android不同的是，这方面的信息似乎没有那么多。谷歌搜索可以找到许多你可以付费的书籍和课程，但没有多少免费信息。我想，欢迎来到苹果控制的世界。也许我看得不够仔细，但是如果信息就在那里，它比竞争对手更难获得。

微软区分了所谓的“物理”传感器(如加速度计)和所谓的“虚拟”传感器(如方向或倾角计)，它们代表了从多个物理传感器融合而来的数据。事实上，您可以想象，随着人们想出越来越多的方法来组合物理传感器输入以提供新信息，虚拟传感器类别可能比物理类别增长得更快。

据推测，数据融合也可以在应用程序级别进行。这至少提供了三个层次的融合:在传感器本身;在低级代码中，生成一个虚拟传感器;作为应用程序的一部分。

微软还比其他公司走得更远，要求基本的最小传感器集，如上表中粗体所示。这意味着，对于任何Windows 8设备，无论大小或用途如何，都有一组基本传感器是不可选的。假设似乎是，每一台Windows 8设备，无论如何使用，都必须能够提供，例如，加速和旋转信息。

如果传感器信息与手头的设备无关，那么通过使用虚拟数据提供报告来伪造Windows是可能的——因为，很明显，为了操作系统的利益而为系统提供一个毫无意义的传感器将是愚蠢的——更不用说空间了。也许假设是，如果系统足够大，可以运行Windows，那么通过通用谐波收敛，基本传感器集将是相关的。

所以，不管你喜不喜欢Windows，尤其是Windows 8，微软似乎在迫使传感器厂商注意到这一点上做得不错。他们制定的需求是否会损害系统架构开放——这是不是一件好事——还有待观察。现在人们只是敬礼并满足要求。

• 
• 
• 
• 
•