Web vs App（AR版）

关于更多机器学习、人工智能、增强现实、Unity、Unreal资源和技术干货，可以关注公众号：AIRX社区，共同学习，一起进步

鉴于Web技术的最新进展，在开发基于AR的解决方案时，它提供了一组新的选择。网络浏览器的最新更新为AR的应用打开了大门。使用Web或本地应用程序构建AR体验更好吗？在本文中，我将简要概述JS在本机应用程序世界中的使用，然后将深入探讨什么是WebAR，它如何工作，如何与本机应用程序竞争以及哪种是更好的解决方案。

前面我们通过一篇文章相信介绍过WebAR：万字干货介绍WebAR的实现与应用

这篇文章主要详细介绍WebAR与native AR的区别，本文译自Hermes（Agora.io的开发人员，也是Blippar的前工程师）。

JS在应用程序端扮演什么角色？

Javascript无处不在，包括嵌入在本机应用程序中。使用JS代码执行C ++代码的能力使Blippar，Zappar，Facebook，Snapchat和其他此类平台能够使开发人员更好地控制其AR体验。JS具有许多吸引人的特性，但最引人注目的是Java语言由iOS和Android原生。

为了提供有关JS和C ++如何协同工作的上下文和详细信息，我将使用Blippar的移动SDK作为示例。Blippar SDK的核心是一个基于C ++的OpenGL渲染引擎，该引擎使该应用在各个平台之间的比价更高。Blippar的Javascript API允许第三方开发者使用JS控制底层引擎，但获得了C ++的所有响应能力并为用户提供了本机效果。

前面提到的所有SDK / API都比ARKit和ARCore早。现在，每个平台都有本机实现，Viro Media创建了一个React插件，该插件可以实现本机和跨平台AR开发。

当我们讨论使用Java的AR平台时，我们不能忽略Amazon。亚马逊推出了Sumerian平台，旨在弥补创作者/出版者立场之间的差距。亚马逊在AWS之上构建了自己的XR渲染引擎和Studio。允许用户在AWS基础设施的所有支持下扩展他们的游戏/应用/体验。

显然，这是亚马逊吸引新开发人员并保留现有客户以在其平台上进行构建的一种方式。这里有几件事要注意，对于后端和架构师，这表明亚马逊看到了明确的平台。对于前端人员而言，Somerian工作室全部基于网络，脚本编写全部使用基于Javascript的API完成。

Adobe是创作者领域的另一位强大参与者，他们的Project Aero处于私人Beta版，它可以使创作者使用USDZ格式。

我们不能谈论所有人，更不用说Sketchfab了。最初是供3D艺术家上传并很好地显示作品的资源库，如今已发展成为具有API的市场，并且启用了ARKit的iOS应用允许用户在自己的世界中放置3D模型。随着AR和VR越来越流行，Sketchfab是一家值得关注的公司。

什么是WebAR？

WebAR不仅仅是AR的子集，它还是一个笼统的术语，涵盖了许多不同的实现。WebAR解决方案的范围很广，既可以使用设备的陀螺仪/加速度计传感器作为背景，也可以使用相机输入，也可以使用更复杂的解决方案，例如AR.js，TensorFlowJS和USDZ。

根本上，AR正在使用移动设备的传感器来跟踪其在增强场景中的位置。在过去的几年中，移动浏览器已经增加了对JS Sensor API的支持，例如照相机，陀螺仪，加速度计，方向，磁力计（阅读：指南针）。利用这些传感器，开发人员可以创造一系列的体验。

Blippar是最早通过横幅广告启动浏览器内AR体验的公司之一；在AR的背景下，该布局是一个相对新颖的概念，但在推出时引起了极大的轰动。该广告是汽车内部装饰的360⁰体验³，其中按钮重叠，以切换显示汽车的详细信息。

我问的第一个问题是响应速度如何？AR在计算上很昂贵，那么它如何在浏览器中工作？WebAssembly是网络标准，允许浏览器执行汇编使用二进制文件代码。WebAssembly文件是通过将C / C ++编译为.wasm使用JS代码执行的文件来创建的。

让我们考虑一下这里的含义。使用WebAssembly，可以使用原始Javascript在Web浏览器中以接近本机的性能运行计算密集型操作。WebAssembly使TensorFlowJS和ML5JS等项目成为可能。

WebAssembly很酷，但是仅占WebAR的一半。WebAssembly在AR的计算机视觉方面完成了所有繁重的工作，而我们拥有用于渲染的webGL。WebAssembly和WebGL是基础，但是我们如何使用这些API创建基于Web的AR体验？输入由Jerome Etienne编写的框架AR.js，该框架使用A-Frame（在Three.js之上构建）和JSARToolkit5 （ARToolKit的脚本端口），还有其他一些WebAR框架，但是大多数都需要特殊的Web浏览器应用程序或利用专有的API。AR.js是开源的，不需要任何特殊的应用程序，它可在默认浏览器中运行。

为了讨论AR.js及其对WebAR的含义，值得快速浏览一下为框架提供支持的组件。A-Frame是在Three.js之上的基于JS的API框架，使其更像具有实体组件关系的游戏编码。这简化了Three.js的语法，使开发人员可以专注于体验/游戏。然后，AR.js使用JSARToolkit跟踪3D场景到标记，并利用Computer Vision检测特征点。这是大多数早期基于应用程序的AR体验的动力。AR.js为移动网络提供了前进的脚，并可以与基于应用程序的AR竞争。

看一下苹果和谷歌的努力，我们看到他们已经采取了一些措施，以实现3D模型与其各自的移动浏览器之间更深层次的集成。让我们从Apple的.usdz文件格式开始。

什么是USDZ，它如何运作？用最简单的话说，Apple已将ARkit功能内置到iOS的Safari中。带有几行html和一个文件.usdz，任何网站都可以包含AR元素。

<a rel="ar" href="model.usdz">   <img src =“ model-preview.jpg”> </a>

.USDZ是Apple的标准本机文件格式，用于在其移动浏览器，iMsg，电子邮件和Notes应用程序中显示3D。

在谈论USDZ和Apple之前，我们不得不提及Google在WebXR Device API和WebXR Hit Test API（Chrome Canary中）方面的进步。Google希望将基于Web的AR放在首位。

我将假设Google使用与Poly项目类似的文件类型.obj以及.glTF文件格式。与苹果公司不同，谷歌选择采用流行的标准格式，这表明谷歌已经在考虑降低3D生态系统中已经采用的障碍。

无需应用程序

无应用程序AR是指使用本机Web浏览器来提供AR体验，使其可以在所有平台，设备和移动OS上运行。当Blippar启动AR数字展示位置（在网络浏览器中启动AR的横幅广告）时，我们看到了大量潜在客户。代理商，零售，娱乐，制药等机构都有巨大的需求，所有这些机构都希望与用户互动，而无需下载应用程序。大多数代理商和品牌都愿意将AR体验添加到现有应用程序中，但他们也意识到这种参与与删除应用程序下载时的体验不同。网络无摩擦，每个人都有一个带有QR扫描仪的相机应用程序，可以链接到网站。回到我前面提到的AR广告展示位置；当时最大的争斗集中在浏览器兼容性上。迄今为止，基于Web的AR体验仍然是一个问题。

并非每个移动浏览器都支持Sensors API，或者设备缺少某些传感器，这是我们在Android设备上尤其看到的一个巨大问题。通过商店发布应用程序时，可以控制可以在哪个设备上安装该应用程序，但是在网络上则没有该控件。是的，它可以在网页中添加检查，但是随后你会看到一个屏幕，上面写着“抱歉，不支持您的设备”，这就很让人崩溃！

WebAR竞争力

当前，Web浏览器在AR摄像机方面没有足够的访问权限。AR摄像头与传统摄像头的不同之处在于，它在OS级别而不是其顶部处理增强。当前基于Web的AR的实现要求在OS之上进行计算，从而导致计算滞后，限制渲染，有时甚至导致可见滞后。

要使AR通过Web更加可访问性，迈出的一大步就是Web Standards采用API直接访问ARCamera对象。

如果该抽象可以作为标准的Web API存在，则任何浏览器应用程序都可以利用ARkit / ARCore或存在的任何底层平台。Web API一旦存在，就会出现许多不同的框架。有一些实验性浏览器利用ARKit / ARCore，但它们需要特定的JS框架。

USDZ是一个良好的开端，但缺少重要的组成部分，而这一层增加了对交互的支持。谷歌的努力仍然仅在Canary版本的Chrome中可用，因此在其正式版中加入之前，它将落后于苹果公司。

当我开始写这篇文章时，我的想法是会有一个明确的利弊清单，但是在坐下来并仔细研究了我认为的利弊之后，无论Web和Native哪里都不足，都有SDK和API可以补充。

视觉搜索只能通过基于应用程序的解决方案来实现。例如，Blippar的识别引擎不依赖QR码，它使用ai识别其系统中的已知实体，并在存在匹配项时提供体验。对于希望利用其现有印刷材料而不必更改其设计的公司而言，这非常有用。

视觉搜索的行为仍然是新事物，并不是很直观，大多数人不习惯将手机对准东西，即使会出现炫酷的AR内容。

代替可视搜索，WebAR依靠QR码。从设计角度来看，QR码不是很性感，但是自从iOS和Android都在其本机相机应用程序中都添加了对QR码识别的支持后，扫描QR码的行为已得到越来越广泛的使用。

可以提出另一个论点，即互联网和增强现实技术在全球范围内都可以使用，我们需要牢记，在某些新兴市场中，互联网的速度和可靠性并不那么快。这就需要支持离线使用，这只能通过应用程序获得。另一方面，让某人下载应用程序比访问网站困难得多。因此，最终结论是……这确实取决于项目。

WebAR如何发展

许多人都对AR的未来做出了预测，无论它的耳机，投影仪还是植入芯片的极端特性，等等。为了加入这个世界大胆而勇敢的算命先生的行列，我将分享我的想法。当前，大多数AR内容（体验中的媒体）都托管在设备上或从云加载。Blippar，Facebook，Snapchat，Zappar都使用基于云的CMS，该CMS基于某种触发（链接，标记，面部，qr代码等）下载AR体验。为了提供有关云交付的AR如何工作的背景信息，移动应用程序具有某种触发或进入点（链接，标记，面部，二维码等），可以启动体验。此触发器提示应用程序向后端系统发出请求，以发送体验的资产和代码。大多数平台在启动之前都会下载整个体验，这解释了为什么Facebook和Snapchat的上限为4 mb，以保持快速运行。在Blippar，我们提供了各种体验，因此有时我们不得不发挥创造力。项目的内容从页面上的视频到3D世界，赛车上山路甚至在Apps上完全可用。因此我们的广告系列范围从> 1 mb到85 mb或更大。为什么这很麻烦？就像我之前提到的，我们过去常常通过对场景进行编码以在后台下载资产的方式来发挥创意，那么有什么大不了的呢？事实证明，为什么大小很重要，保持正确的平衡对您的AR体验的成功至关重要，但背后还有一些颇具影响力的数字。在Blippar，我们发现，花费30秒以上才能进行加载（下载和初始化）的所有体验都会减少约50％的体验，而那些最初尝试进行互动的用户还会流失约75％的用户。这意味着，较长的下载时间可能会导致多达90％的受众群体流失，大约有10％的用户会重新参与。因此，现在除了必须以某种方式让某人下载应用程序之外，还可以使用户保持您的应用程序需要快速加载。如果您获得适当的平衡，则体验可以看到每位用户最多3倍的参与度，而停留时间是2倍。WebAR使用Web优化进行下载和传送，但是大小仍然很重要。如果不流式传输内容，则体验越大，在移动浏览器中加载所需的时间就越长。