FF 和 Chrome 都开始支持使用应用清单和服务工作者的渐进式网络应用。
那么在编写清单时要记住的主要区别是什么（或者相同的清单文件可以在两者上工作）。
如果它是一个托管的 webapp（不是打包的），在让用户安装它的过程中有什么不同？
问问题
642 次
2 回答
6
这个问题有很多事情要做。我将尝试通过提供一些历史记录然后回答 OP可能提出的几个问题来解决所有问题。
背景
打包的应用程序
Chrome、Firefox、Opera 和许多其他平台在不同时期都有“打包”的应用程序平台，这些平台运行 HTML/JS/CSS 内容但不在网络上。这些通常使用某种清单文件与类似 zip 的打包和目录结构（有时是签名）相结合来分发应用程序。这些应用程序通常不参与同源策略或以与 Web 内容相同的约束和功能运行；通常，这些软件包是通过专有商店提供的，并且功能功能和 API 还不能用于“普通的旧 Web 内容”。
这些应用程序的清单格式（至少在Chrome 打包应用程序和Firefox 打包应用程序的情况下）是一个 JSON 文件，其内容和选项未标准化。
托管应用程序
一些系统将提供给其专有打包应用程序系统的额外功能与“真实的”基于 Web 的应用程序托管相结合，以创建“托管应用程序”。这些有多种形式，但 TL;DR 是它们还倾向于具有基于 JSON 的专有清单文件。例如，请参阅Chrome 托管应用程序、Firefox 托管应用程序和Windows 10 托管应用程序的文档。
同样，这些系统是专有的、非标准的和不可互操作的，尽管有问题的内容来自“真实网络”（不像他们的打包应用表亲）。
渐进式网络应用
渐进式 Web 应用程序与打包应用程序和托管应用程序的不同之处在于它们只是“普通的旧 Web 内容”，它也恰好指向基于标准跟踪Web 应用程序清单格式的清单文件。
这种格式是 Chrome 检测并用于触发“添加到主屏幕”行为的格式，也是 Opera 当前在您手动向主屏幕添加内容时使用的格式（以及将来，当 Opera 提示时）。
Mozilla 已经表示支持这种格式，他们的工程师已经大量参与了标准的设计和演变。我乐观地认为这将演变成对基于标准而非专有清单的 UI 的支持。
Mozilla 还有望在未来几个月内提供对 Service Workers 的支持，这将为 Chrome、Opera 和 FF 之间的互操作“安装”行为奠定基础。激动人心的时刻。
于 2015-11-26T20:42:52.787 回答
3
有两件事在起作用：遗产和未来。
Legacy 部分（因为需要一个更好的短语）是旧式包装系统（尽管它们仍然可以工作）。Mozilla 和 Chrome 都有自己的打包格式和大致相似的 JSON 清单。我个人会远离这两者，专注于未来。
面向未来的系统Web App Manifest，受 Chrome 支持，用于 Android 上的安装体验。Opera 和 Firefox OS 也支持它。您在两者上编写的清单应该适用于所有平台。显然，每个实现都处于不同的阶段，例如：
- Chrome 具有
chrome_related_applications和prefer_related_applications用于链接到本机应用程序 - Chrome 支持
background_color并theme_color生成启动画面 - Firefox 需要一个
splash_screens对象来创建启动画面。 - Firefox 定义了一个
scope告诉浏览器被认为是应用程序一部分的 url 路径。Chrome 和 Opera 忽略了这一点。
我会说 Web App Manifest 现在至少为可安装的 Web 应用程序定义了一个“一致”的愿景。
于 2015-11-26T10:45:30.650 回答