[翻译]Service Worker的配置

原文

前期准备

如下的基础知识:

• [翻译]生产环境中的Service Worker

src/ngsw-config.json的配置文件定义了 Angular service worker需要缓存哪些文件和数据并应该如何去更新它们。CLI在ng build --prod期间处理配置文件。手动，您可以使用ngsw-config工具处理它:

ngsw-config dist src/ngsw-config.json /base/href

配置文件使用json格式。所有文件的路劲必须以/开头，这表示在部署根目录内（在cli的项目中一般指dist）。

路径格式使用一般的国际格式:

• ** 匹配0 或多个路径.
• *匹配一个路径或文件.
• ! 前缀表示相反，即不包括后面的文件

例子路径:

1. /**/*.html 表示所有html文件
2. /*.html 仅表示跟路径的html文件
3. !/**/*.map 不包括所有的sourcemaps文件

下面将说明每一小个定义项

appData

这是给你传递用来描述该版本app的数据。SwUpdate 服务会将其包括在更新通知中。许多app在提示用户有新更新的页面中使用此数据提供额外的信息。

index

这是定义初入口的页面，通常这就是/index.html

assetGroups

这是与app一同更新的资源集合。可包括基础脚本、从CDNs加载的第三方脚本及其它url资源。因为构建过程中不可能知道所有的的额外url资源，所以只要是URL 格式的就能匹配。

这部分包括一个资源对象数组，每一个包括一系列资源和如何缓存的规则

{
  "assetGroups": [{
    ...
  }, {
    ...
  }]
}

每一个子对象定义了一组资源表及如何管理的规则。这规则觉得资源如何被获取和在发现新更新后如何被处理

定义对象的Typescript借口如下：

interface AssetGroup {
  name: string;
  installMode?: 'prefetch' | 'lazy';
  updateMode?: 'prefetch' | 'lazy';
  resources: {
    files?: string[];
    versionedFiles?: string[];
    urls?: string[];
  };
}

name

name是必要。它被用来识别特定的资源组

installMode

installMode 决定了这些资源在初始化时如何缓存，有2种：

• prefetch告诉Angular service worker在缓存当前版本的应用程序的同时获取每个列出的资源。这是带宽密集型的，但确保了资源在请求时可用，即使浏览器当前处于脱机状态。
• lazy 不预先缓存任何资源。相反，Angular service worker只缓存它收到请求的资源。这是一个按需缓存模式。永远不会被请求的资源不会被缓存。这对于如有不同分辨率的图像是很有用的，所以service worker只会缓存对应符合当前窗口的图像。

updateMode

对于那些缓存已有的资源，updateMode决定当发现app新版时的缓存行为。根据updateMode更新自上一版本以来组中的被更改的所有资源。

• prefetch 告诉service worker马上下载并缓存被修改的资源。
• lazy installMode is also lazy.告诉service worker不要缓存这些被修改的资源。取代的是，它把这些资源当做未请求资源，只会在资源被再请求时更新他们。此模式只会在installMode 也是lazy时有效。

resources

这区域描述被缓存的资源，分别三块。

• files 列出需要包括文件的路径，可以是如上的国际规则
• versionedFiles 这也是文件列，但只要是那些用于构建的名字里有hash码的文件，这是用来消除缓存的。 如果Angular service worker能假设某些文件内容是不变的，它就能部分自我优化。
• urls包括那些将在运行中匹配的资源url规则。这些资源不是直接获取并且不带有内容hash码，但是它们将安装其HTTP headers去缓存。这是对于如Google Fonts service等的CDNs是十分有用的。

dataGroups

不想资源组，数据请求不是跟随着app的版本的而改变的。它们根据手动配置的规则进行缓存，这些规则对于API请求和其他数据依赖等情况更为有用。

Data groups 的Typescript 接口如下:

export interface DataGroup {
  name: string;
  urls: string[];
  version?: number;
  cacheConfig: {
    maxSize: number;
    maxAge: string;
    timeout?: string;
    strategy?: 'freshness' | 'performance';
  };
}

name

类似assetGroups, 就是一个唯一标识码。

urls

url规则列. 符合的url资源就会安照下面的规则去缓存。

version

有时API会以不向后兼容的方式更改格式。新版本的应用程序可能与旧API格式不兼容，因此可能与该API中现有的缓存资源不兼容

version 提供了一种机制来指示被缓存的资源已经以向后不兼容的方式被更新，并且旧的缓存条目（来自以前版本的条目）应该被丢弃。

version 是整数类型，默认为0.

cacheConfig

这部分定义符合的请求如何去缓存。

maxSize

(必须) 缓存中的条目或响应的最大容量。开放式缓存可以无限制地增长，最终超过存储配额，要求清除缓存。

maxAge

(必须) 表示回复可在缓存内最大时间，超过则被认为无效并被清除。maxAge 是一个时长字符串，可用下面的单位：

• d: days
• h: hours
• m: minutes
• s: seconds
• u: milliseconds

例如, 字符串3d12h 将缓存内容3.5天。

timeout

这时长字符串定义请求的最长时间。如果定义了，Angular service worker向网络作的请求不会超过此时长，超过后，则会直接使用缓存去回复app。

strategy

Angular service worker有两种数据缓存策略。

• performance,默认值。优化响应，使其尽可能快。如果缓存中存在资源，则使用缓存版本。这允许一些过时，取决于maxAge，以换取更好的性能。这适用于不经常改变的资源;例如，用户头像图像。
• freshness
  优化数据的货币，优先从网络获取请求的数据。只有当网络超时，根据超时设定，请求才回落到缓存。这对经常变化的资源是有用的;例如账户余额

你们的赞赏是我的无限动力