Native 和 PWA：选择，而不是挑战者！

已发表: 2022-03-10
快速总结 ↬决定构建 PWA 或原生应用程序应基于特定项目的需求，而不是炒作。 在本文中，Aaron Gustafson 将向您介绍每种方法的优缺点，以帮助您做出明智的决定。

很难确切地说出“原生”和“网络”之间的裂痕是从哪里真正开始的。 我觉得这是自 Flash 早期以来一直在表面下搅动的事情之一，只是随着移动平台的兴起最近才爆发。 无论如何，开发人员已经克服了这个“巨大的鸿沟”，互相辱骂，试图支持自己的立场。

我对那场战斗没有兴趣。 当然，我是一个“网络人”，但这并不意味着我看不到原生开发的吸引力； 我也是一名软件开发人员。 不过，最重要的是，我是一个实用主义者。 我意识到每个项目都是不同的，我们对每个项目的方法都应该根据项目的需求和目标量身定制。

随着渐进式 Web 应用程序 (PWA) 蚕食原生开发的地盘，我认为现在可能是退后一步并评估这两种构建产品的方法的好时机。 我希望我们都能够清楚地看到每种方法的优势，以期找到最适合我们创造的产品的能力。

速射比较

几乎从一开始，基于 Web 的体验就与从桌面软件（最初的“原生应用程序”）到交互式 CD-ROM 到 Flash 以及最近的移动应用程序的所有内容进行了比较。 尽管多次被宣布死亡，但网络仍然存在。 在许多情况下，它甚至比它所谓的杀手（RIP Flash）寿命更长。

网络在这方面的主要优势之一是它的适应性。 它几乎可以去任何有互联网连接的地方，并不断获得新的功能。 所有的编程语言都在发展，所以这并不出人意料，但随着时间的推移，网络不断扩大的边界继续蚕食传统软件的地盘。

跳跃后更多！ 继续往下看↓

然而，网络历史上出现不足的一个领域是性能领域。 已安装的软件能够以网络无法做到的方式连接到底层操作系统。 它们是用宿主的通用语言编写的，可以直接访问硬件或我们常说的“更接近金属”。 Web 几乎总是在其之上运行一个或多个抽象层，在性能方面很难与之竞争。 虽然性能差距随着时间的推移而缩小，但本机代码可能会继续比 Web 代码运行得更快，至少在 Web 能够直接从硬件引脚解释信号之前。

与性能优势齐头并进，原生开发可以更多（和更早地）访问设备功能，例如 NFC、蓝牙、接近和环境光传感器等。 网络也在稳步获得对这些功能的访问，但它总是落后于原生，因为在网络可以利用它们之前需要开发原生 API，并且跨浏览器的标准化需要时间。

此外，本机代码可以与地址簿和日历等操作系统级功能挂钩。 推送通知是另一个重要功能，但 Service Worker 现在也使 Web 能够利用该功能。 最近网络上的支付处理也得到了类似的改进。 也许地址簿和日历访问最终也会出现在网络上。

暂时回到 Service Worker，这个最近添加到 Web 开发人员工具箱的功能还有许多其他技巧。 首先，它提供了一个比 Web 之前使用 AppCache 更强大的缓存系统。 您可以使用 Service Worker 来管理离线请求、缓存特定资源、在用户甚至没有打开站点时与远程服务器同步数据等等。 可能比任何其他单一技术更重要的是，Service Workers 使 Web 能够提供更像应用程序的体验。

Service Worker 是 PWA 的三个技术关键之一。 另一个是 Web App Manifest。 虽然听起来有点无聊，但 Web App Manifest 实际上是一个非常强大的工具，它使网站能够将自己宣传为一个应用程序。 这种相对简单的 JSON 文件格式提供了关于它所描述的网站的大量信息，并使支持 PWA 的浏览器和操作系统能够像安装本机软件一样安装该网站。

一些应用商店甚至开始索引 PWA，使用它们的 Manifest 来填充它们的关联条目。 从用户的角度来看，应用商店中的 PWA 与它们周围的原生应用没有任何不同。 它们是可安装的、不可安装的，甚至可以将它们的设置暴露给底层操作系统的应用程序管理工具。 还值得注意的是，PWA 实际上并不需要用户显式安装它们才能使用它们，因为它们存在于网络上。

同时在网络上和网络上也意味着 PWA 始终是最新的。 用户无需主动下载任何新内容即可访问新功能。 即使确实推出了新的内容和功能，用户也极不可能像大多数原生应用程序那样需要重新下载整个 PWA。 如果有的话，他们可能会得到一些新的资产和一些新的 HTML，而且它会立即发生，不需要应用商店。 当然，您仍然可以使用应用商店提供的发现和分发选项，所以它确实是两全其美的选择。

在应用商店中，PWA 在发现、分发和货币化方面与原生应用处于同等地位。 事实上，它甚至可以使网络超越原生网络，因为 PWA 也可以通过搜索引擎发现，并且比应用程序具有无限的共享性，因为它们存在于 URL 中。 如果构建良好，PWA 还可以跨浏览器、平台和设备进行互操作。 PWA 甚至可以在不支持 Service Worker 等功能的浏览器中工作，因为 PWA 功能是渐进式增强。

Web 还提供了非常成熟的可访问性支持，从而相对容易地确保您的项目可供最广泛的用户使用。 复杂的界面在编程方面确实需要更多的努力，但语义 HTML 提供的可访问性优势可以从容地处理基线可访问性——尤其是在涉及大量文本、信息或简单的基于表单的产品时。 相比之下，您几乎总是需要了解可访问性 API 并将其合并到您的本机代码中。

关于开发的话题，我认为在开发体验方面没有明显的赢家。 每种语言都有它的粉丝，开发者工具也是如此。 你喜欢你喜欢的东西，并且你倾向于使用你所知道和热衷的工具和语言来提高效率。 Web 和本地开发都没有任何明显的优势。

然而，本机开发的亮点在于确保使用其 SDK（软件开发工具包）构建的 UI 质量始终如一。 大多数原生 SDK 提供用于测试性能、设计、功能等的工具。 它们还包括样板代码、设计系统和其他有助于提高本地软件产品整体标准的工具。 当然，也有类似的 Web 工具，但它们分散在 Web 中，并不是在人们用来构建网站的所有不同开发环境中都通用。 没有一个实体可以定义高质量的 Web 体验并提供构建它们的工具（尽管许多人已经尝试过）。

在为产品开发人员配备人员时，雇用知道如何为网络构建的人肯定更容易。 在我打字时，编程语言索引目前将 JavaScript 列为最流行的语言，Java 紧随其后。 C# 排名第 5，HTML 排名第 7，CSS 排名第 9，Swift 排名第 15。 该索引交叉引用了 Stack Overflow 标记，并在 GitHub 上的公共存储库中更改了行，因此应该对它持保留态度，但它提供了一个非常明确的指示，表明许多人都知道（并使用）Web 技术。 另一方面，寻找和雇用有才华的本地开发人员通常具有挑战性，因为他们人数较少且需求量很大。

人才稀缺意味着您最终可能会为本地开发支付更多费用。 每个项目显然都不同，并且具有不同的功能和要求，但将平均开发成本作为比较可以说明问题。 Comentum 建议构建一个中等大小的网络应用程序的成本在 10,000 美元到 150,000 美元之间。 在原生端，Appster 估计中等规模的移动应用项目的构建成本在 110,000 美元到 305,000 美元之间。 可以肯定的是，原生项目的开发成本可能是 Web 项目的两倍。 这是每个平台。 原生应用程序通常也需要更长的时间来开发。

值得注意的是，可以选择使用 Web 技术构建本机软件，而无需构建 PWA。 React Native、PhoneGap、Ionic 和 Appcelerator Titanium 等框架使您能够从 HTML、CSS 和 JavaScript 生成本机代码。 与雇用本地开发人员团队相比，使用其中一种工具可以降低您的人员配备和开发成本，但在访问设备功能方面，您的项目将仅限于框架已实现的那些。 相应地计划。

开发应用程序后，您还必须考虑所述应用程序的持续维护成本。 在回应 Clutch 进行的一项调查时，Dom & Tom 建议第一年将产品初始价格的 50% 预算，第二年预算 25%，之后每年预算在 15-25% 之间。

一旦您对 Web 和原生开发的比较和对比有了相当的了解，您就可以开始评估哪些优势和劣势与您的项目相关。 您可能必须做出一些权衡，这是意料之中的。 没有一种万能的解决方案。 如果有，它不会适合任何人。

让我们通过几个假设的项目来更清楚地了解原生开发和 PWA 开发之间的区别。

项目 #1：现有的原生应用程序

假设您已经完成了构建本机应用程序的过程。 如果一切顺利，就没有理由改变方向。 不要放弃所有现有工作来切换到 PWA，除非你有充分的理由这样做。 我只能真正想到一种可能需要考虑切换到 PWA 的场景：将对新操作系统的支持纳入其中。 即便如此，只有当您的应用程序的需求可以仅通过 Web 来满足时，它才真正有意义。

如果您正在为产品添加对新平台的支持，则它为评估项目的需求和目标以及满足这些需求的成本创造了绝佳的机会。 如果网络不能胜任这项任务，请坚持使用本机。 但是，如果是这样，请停下来考虑一下：使​​用 PWA 添加对新平台的支持将使您能够支持其他平台（包括 Web），甚至可以让您在 PWA 有后替换现有的本机应用程序进行了彻底的测试。

如果用 PWA 替换现有的原生应用程序对您来说似乎是不可想象的，请考虑一下：星巴克和 Twitter 已经在探索这个想法。

如果有特定原因需要保持应用程序原生，仍然值得考虑将某些应用程序功能“外包”到网络。 几年前，我正在为一家大型金融服务公司做一个项目，他们选择将其本地应用程序的登录流程转移到网络上，以使他们能够比典型的应用程序商店更快地推出安全功能审批流程使他们能够实现。 也许您的项目有类似的需求，网络可以让您的原生应用程序满足这些需求。

项目 #2：现有的跨平台应用程序

如果您有一个现有的跨平台应用程序，您可能会为该应用程序的持续开发和维护花费大量资金。 您还可能会看到一些不同的应用内功能，因为每个原生平台往往都有自己的开发时间表。 例如，零售商 Target 的应用程序目前允许用户在 iOS 上管理购物清单，但 Android 版本没有该功能。 在许多方面，它类似于我们有时在网站的“桌面”和“移动”版本之间看到的差异。

如果 Web 已经是你跨平台组合的一部分，那么它提供了一个很好的机会，可以加倍投资，并考虑用 PWA 替换你的原生应用程序。 声纳和 Lighthouse 等工具可以让您深入了解现有站点对 PWA 化的准备情况，它们还可以告诉您需要做什么。 从那里开始，将您的网站变成 PWA 相对简单。 甚至还有一些免费工具可以帮助您在几分钟内将您的网站升级为 PWA。 但是，如果不是这样，那么除非平台之间的功能差异变得非常严重，或者您正在考虑将另一个原生平台（或网络）添加到组合中，否则实际上没有太大的动力去采取这一举措。

项目#3：一种新的跨平台产品

如果您要启动一个针对多个平台的新项目，那么绝对应该将其作为 PWA 在一个地方创建和维护。 根据您的预算和员工，可能会最大限度地扩展您的预算。 也就是说，如果您的产品需要直接连接到硬件或底层操作系统，您可能仍需要采用原生方式。 但在你走这条路之前，列出你的所有要求，然后验证网络可以做什么（以及不能做什么）。 一定要检查多个浏览器的支持。

项目#4：一个新的超聚焦产品

如果您正在构建一个新产品，并且该产品的整个目的的一部分是它与特定平台的深度连接，那么一定要为该平台构建。 例如，如果您的产品依赖于 Apple 的 Messages 平台或与 HomeKit 的集成，请务必使用 Swift 为 iOS 和/或 macOS 构建。 如果您的产品通过小部件最能满足用户需求，或者您正在构建自定义启动器，那么您最好构建 Android，并且您需要使用 Java。

然而，并非所有本土特色都是围墙花园。 虽然 Amazon 的 Alexa、Apple 的 Siri 和 Google Assistant 都需要本地代码（或 JSON API）来与您的应用程序集成，但有趣的是，Microsoft 的 Cortana 将仅使用从您的 HTML head链接的 XML 文件为您的 PWA 启用语音。 也许其他人会跟随他们的脚步。

PWA 还是原生？ 这是你的选择

网络和原生都有很多东西可以提供。 如果您要问我哪个更好，我会简单地回答“这取决于”，因为确实如此。 我不是在回避或不置可否； 确定哪个最适合您的项目完全取决于您项目的具体需求。 它需要考虑您正在构建的内容、负责构建它的现有团队的组成或您需要雇用的团队，以及您必须使用的预算。 在许多情况下，网络可能会提供您完成项目目标所需的一切，但总有例外。 如果您想探索网络提供的可能性，我在本文末尾提供了一些资源。

在权衡不同的软件开发方法（或不同的框架、库、语言、设计系统等）时，您可以做的最重要的事情是考虑与手头项目相关的选项。 做你的研究并权衡你的选择。 并且不要让自己被聪明的营销、性感的演示或狂热的粉丝所左右。 包括这个。

PWA 相关资源

  • PWA 构建器
    一个包含有用建议和食谱的 3 步网站到 PWA 创建工具。 它还使您能够将您的 PWA 转变为适用于 Windows、Android 和 iOS 的可安装本机应用程序。
  • 渐进式 Web 应用程序的渐进式路线图
    Jason Grigsby 讲述了他的团队如何在几个月的时间里开始将 PWA 的各个方面整合到他们的网站中，很好地展示了如何一次添加一些不同的功能。
  • 是的，那个 Web 项目应该是 PWA
    PWA 的 UX 机会（和风险）概述，由您真实撰写。
  • MDN 上的渐进式 Web 应用
    您需要了解的有关高质量 PWA 特征的所有技术信息的中心。
  • 网络今天能做什么
    查看您的设备、操作系统和浏览器支持的 API。 你的发现可能会让你大吃一惊。
  • 我可以用吗
    每个主要浏览器中可用的 API 和功能以及相对于人们实际使用的浏览器的支持如何衡量的权威数据库。 它还可以让您及时了解某些功能的向后兼容性。