Web应用的又一次进化 NFC支持

根据媒体报道的消息，目前使用的最为广泛的浏览器内核 —— Chromium 从版本 81 就已经开始对 Web NFC API 进行测试，这一测试将持续到版本 83，前后横跨 3 个大版本。
在 Chromium 84 正式推出之后，相关的功能会向所有用户启用。虽然从 81 到 84，这里已经有 4 个大版本了，但是实际上在现实时间里，这基本上只是半年，甚至半年不到的时间。

目前 Chrome 和 Edge 的 Stable 分支都已经进入到了版本 81，而 Dev 分支则早已进入 83。根据 Chromium 后续推出新版本的计划，由于 Chromium 82 的发布被取消，Chrome、Edge 后续都不会有版本 82 的更新，所有新内容将直接并入后续的 83 版本，而 83 进入 Stable 分支的时间预计是在 5 月中旬。
由此我们可以推算出，84 版本进入稳定版的时间其实并不会太晚，虽然 Google 对后续的版本更新计划进行了一些变动，但是 Chromium 的大版本迭代速度还是稳定在 6 周一次这个频率上。

也就是说，到今年的 6 月底，Web NFC API 就将在全球范围内大规模实装。国内相对而言对这个新 API 的跟进会相对慢一些，毕竟国内很多基于 Chromium 做浏览器的厂商都不怎么重视内核版本的更新，跟进的速度比较慢。

但如果你使用的是 Chrome 或 Edge，到 6 月底，Web NFC API 就已经能够使用了。开发者如果是使用 Dev 分支的话，那么开发者现在其实就已经可以开始针对这个新的 API 做一些测试或者小规模开发了，而且版本 84 很快就会抵达 Dev 分支，到版本 84，Web NFC API 可以说基本上是稳定的了。
如果你提前对此做好了相关的准备，那么等到 6 月底，你就可以开始考虑进一步开发或部署相关的应用或应用功能了。
看到这你可能就会问了，说了这么多，Web NFC API 有啥意义呢？我们不是开发者，这个东西对我们来说有用吗？
在回答问题之前，笔者要先简单介绍一下 Web API 是什么东西，只有在介绍了 Web API 是什么东西之后，笔者才能够比较清晰地给大家讲述 Web NFC API 有什么样的用途。

Web API 本质上是浏览器给开发者提供的一系列开发接口，略懂一些计算机的朋友应该都对「什么是应用程序」这个概念有比较清晰的认识，浏览器本质上只是一个应用程序，而 JavaScript 只是运行在它上面的一种脚本，在最最原始的设计上，浏览器的用途就是给用户呈现网页，而 JavaScript 仅仅只是操作网页内容、完成网页程序逻辑的一个脚本。
随着时间的推移，Web 发展的越来越强大，应用规模越来越广泛，很多 Web 已经不再只是一个单纯的「页面」那么简单，浏览器从一个「应用程序」逐步演化成了一个「平台」，而我们曾经说的「网站」则逐渐演化成了浏览器这个平台上的一个又一个「应用程序」，也就是我们所说的 Web App。
这个时候，问题来了，一旦 Web App 的规模大一些、功能复杂一些，它不可避免要和系统的各种东西打交道。举个简单的例子，一个在线考试系统，它为了防止替考、作弊等现象需要用摄像头来验证考生的身份，这个时候它就需要用到摄像头了。

很显然，摄像头不是属于 Web App 的东西，也不是一个属于浏览器的东西，它的管理权、支配权在操作系统手上。那问题来了，网页要怎么和摄像头打交道呢？
Web App 自然是不能直接和操作系统打交道的，它是一个运行在浏览器里的东西，对于操作系统来说，只有浏览器才是它认可的「应用程序」，Web App 并不是。
所以要和操作系统打交道，Web App 必须要通过浏览器，浏览器需要通过某种方式作为一个「中介」，在 Web App 和系统之间建立一个沟通的桥梁。这个桥梁就是「Web API」。
作为 Web API 的一员，这一次得到浏览器支持的 Web NFC API 到底是什么便不难理解了，它是一个供 Web 应用和系统 NFC 功能通信的「桥梁」，在浏览器支持之后，任何 Web 应用都可以非常轻松地通过这个 API 使用系统本身在 NFC 这方面的功能。

出于刷公交的便利性，很多国内手机厂商在相对偏中高端的产品上都基本加入了对 NFC 的支持。NFC 的用途完全不只局限于刷公交这一点，在 Android 手机上，得益于 NFC 权限的开放，NFC 还可以实现模拟门卡、读取某些特别标签的用途，配合特定的应用，我们也可以实现用手机直接模拟特定的消费卡。
随着现在越来越多设备都加入了 NFC 的支持，有的厂商也开始思考怎么提升 NFC 在日常生活中的实用性，比如华为，他们是把 NFC 玩出了新花样，做了一个基于触碰的传文件交互，非常新颖。
其实在很多场景下，NFC 带来的体验是要优于二维码的，因为「触碰」这个操作要比「扫码」简单不少，只是由于 NFC 成本相对高一些，标签必须是特别的、带有芯片的，而二维码则可以被轻松地印刷在各种材料上，自由度高、使用成本低，所以在现实生活中，二维码相对于 NFC 要更加普及。
然而，随着人们对各种场景下体验的优化，以及当下手机厂商不再像以前那样为了压缩那一点点的成本随意一刀就把 NFC 给砍掉，在当今这种设备基础下，未来 NFC 在日常生活中的实用价值还是非常值得探索的，特别是在未来物联网这一块在生活中越来越重要的趋势下。

目前，NFC 标签已经可以被做成一个非常小的贴纸，或者是一个圆形的小塑料片，成本基本上就在五毛钱左右，相对而言成本更高一些的会是读写它的设备。

不过在国内，很多国产手机在 NFC 上其实都是支持读写的，而那些连接电脑的读写设备价格也不高，还远不到一个树莓派 4，我们可以很方便地从电商平台买到这一类读写设备。

这意味着对于个人开发者来说，基于 NFC 做一套自己的应用并不是一件不现实的事情。然而，由于现在 NFC 的开发只能通过使用系统提供的原生 API、用系统原生的开发方式进行开发，导致 NFC 程序可移植性非常差，而且开发上也比较繁琐，需要消耗开发者较多的时间。

Web NFC API 则能够大幅度的降低 NFC 应用的开发门槛，而且能够非常好地提升应用的可移植性，即使是一个完全和原生不沾边的、纯粹基于前端技术打造的 Web 应用，它也可以具备读写 NFC 的功能。
对于开发者来说，这绝对是一大福音，而开发门槛的降低也会促使更多的开发者去探索 NFC 在日常生活中的应用可能，对于整个 NFC 生态的向前发展，这也是一件好事，对于企业来说，他们也可以在更多的设备上以更加轻松地方式去做一个基于 NFC 的东西，这也有利于 NFC 在未来物联网时代的进一步普及。

任天堂的 Amiibo 就很好地告诉了我们，NFC 的应用其实完全不只局限在支付，或者开门上，只要有创意，其实我们也可以基于 NFC 打造出很多有意思的东西。
相较于二维码，NFC 还是有一些独特优势的，毕竟二维码必须要印在东西的表面，而且二维码的在现实生活中的写入操作只有一个 —— 印刷，如果你要改变二维码的信息，那么你必须要印一个新的二维码盖在上面。

这就会带来一些麻烦，比如这样一个例子：我面前有 ABCDEFG……等若干个不透明的塑料储物盒，里面的东西是会随时更换的，在不一一开盖看的情况下，我需要用手机快速地知道哪个盒子里放了什么。
基于二维码 + 每个盒子的唯一 ID，结合一个在线的应用，二维码确实也可以实现这样的功能，但是这太不优雅，有一种杀鸡用牛刀的感觉。其实我们完全可以在盒子的本体或者盖子上嵌入一个 NFC 标签，然后我们手机往上一放，就能快速知道里面有什么，而如果我们要修改这个内容，也可以非常好地进行修改。

在 Web NFC API 开始普及之后，结合 NFC 贴纸，哪怕是普通的盒子，我们也可以非常方便地撰写一个应用来做这方面的事情。

当然，Web NFC API 也不单单只局限于这种 NFC 的通信，手机和手机之间的 NFC 通信，或者手机模拟卡去和卡机通信，这样的功能都能够得到 Web NFC API 的支持，小程序也可以尝试借助 NFC API 在 NFC 硬件功能这一块得到一个强化，从长远来看，笔者还是很看好这个新鲜事物的。

目前网络上还没有什么关于 Web NFC API 的开发文档可供参考，如果你想要做这方面的开发，那么你可能需要花比较多的时间和精力去对这个 API 做一个深层次的挖掘。
在未来，Web NFC API 的推广在 Android 设备和 PC 上基本上是没有阻力的，阻力主要是在苹果这方面，一个是 Safari 在后续是否会跟进支持，另一个是苹果在安全和隐私上的政策是否会对 Web App 的行为做什么很严格的限制。
就苹果目前的态度来看，iOS 对原生应用的 NFC 权限获取都还没有完全开放，这项技术在 iOS 平台上的推进可能还是存在困难，不过这并不意味着 Web NFC API 对于开发者来说没有意义，毕竟 iOS 设备的市场份额已经远小于 Android，开发者仍然还是可以做出一些有意义的东西出来。