Angular Service Worker 详解内置缓存、离线支持与版本更新的原理与实践【免费下载链接】angularDeliver web apps with confidence 项目地址: https://gitcode.com/GitHub_Trending/an/angular本篇指南围绕 Angular 官方文档中的服务工作者Service Worker总览展开系统讲解 Angular 应用如何借助内置的angular/service-worker包获得离线支持、缓存加速与后台版本更新能力。读完本文你将理解 Angular 服务工作者的设计准则、清单manifest机制、注册与配置选项并能够从源码层面印证其更新检测、空闲调度与不可恢复状态处理等关键实现。什么是服务工作者服务工作者扩展了传统的 Web 部署模型使应用能够提供接近原生应用可靠性与性能的用户体验。为 Angular 应用添加服务工作者是将应用打造为渐进式 Web 应用PWA的关键步骤之一。从最简视角看服务工作者是一个在浏览器中运行、负责管理应用缓存的脚本。它充当网络代理network proxy拦截应用发出的所有 HTTP 请求并决定如何响应例如查询本地缓存命中时直接返回缓存响应代理范围不仅限于通过fetch等编程 API 发起的请求还包括 HTML 中引用的资源甚至是对index.html的初始请求因此基于服务工作者的缓存是完全可编程的不依赖服务器指定的缓存头caching headers。与构成应用的其他脚本如 Angular 应用 bundle不同服务工作者在用户关闭标签页之后仍然存在。下次浏览器加载该应用时服务工作者会最先加载并拦截所有资源请求。如果其设计如此它可以在完全不依赖网络的情况下满足整个应用的加载需求。即使在快速可靠的网络上往返延迟也会给应用加载带来可观的时延用服务工作者降低对网络的依赖可以显著改善用户体验。Angular 服务工作者的设计准则作为单页应用SPAAngular 应用天然适合从服务工作者中获益。Angular 内置了一个服务工作者实现开发者无需直接面向底层 API 编程即可使用。其核心目标是在慢速或不可靠的网络连接上优化最终用户体验同时把“提供过期内容”的风险降到最低。为此Angular 服务工作者遵循以下准则来自官方文档 overview缓存应用如同安装原生应用应用作为一个整体单元被缓存所有文件一起更新运行中的应用始终使用同一版本的全部文件不会突然收到来自新版本、可能不兼容的缓存文件用户刷新应用时看到最新完整缓存版本新标签页加载最新已缓存代码更新在后台进行在变更发布后尽快发生在更新安装就绪之前继续提供旧版本尽可能节省带宽只有发生变更的资源才会被下载。从源码结构看这些准则的落点在 worker 驱动 中Driver维护clientVersionMap客户端 ID 到清单哈希的映射与versions哈希到AppVersion实例的映射确保每个客户端被“固定”在服务于它的某个应用版本上这正是准则 2 的实现基础。清单机制ngsw-config.json 与 ngsw.json为支撑上述行为Angular 服务工作者会从服务器加载一个**清单manifest**文件ngsw.json注意不要与 Web 应用的 [Web App Manifest] 混淆。它描述需要缓存的资源并包含每个文件内容的哈希值。当应用发布更新后清单内容随之变化服务工作者据此得知应下载并缓存新版本。该清单由 CLI 生成的配置文件ngsw-config.json在构建时生成。worker 侧对清单的解析定义见 manifest.ts核心结构包括configVersion配置格式版本driver 中定义了SUPPORTED_CONFIG_VERSION 1不匹配时 worker 无法正常工作hashTable{[url: string]: string}即“每个文件内容的哈希”的数据结构是增量下载准则 5的依据assetGroups/dataGroups分别描述随应用版本更新的静态资源组与独立版本控制的数据请求组navigationUrls与navigationRequestStrategyfreshness或performance决定导航请求如何被满足applicationMaxAge整个应用允许在缓存中保留的最长时间。hashManifest()通过对整个清单做 SHA-1 计算得出“清单哈希”ManifestHash这就是每次更新检测时比对的指纹。清单生成逻辑位于 service-worker CLI其构建入口同时依赖 config 包的 schema 与生成器。缓存策略assetGroups 与 dataGroupsconfig 包的 JSON Schema 定义了ngsw-config.json的全部可选字段这也是“节省带宽、最小化过期风险”准则的完整参数面配置项说明index满足导航请求的索引页通常为/index.html必填项appData任意描述本版本应用的数据SwUpdate会把其包含在更新通知中常用于更新提示 UIassetGroups[].installModeprefetch默认安装应用版本时预取全部列出资源lazy仅在被请求时才按需缓存assetGroups[].updateMode新版本出现时如何更新组内已变更资源lazy仅在installMode也是lazy时有效默认取installMode的值assetGroups[].resources.files匹配发行目录中文件的模式可用于计算内容哈希assetGroups[].resources.urls运行时匹配的 URL 及模式不计算哈希、按 HTTP 头缓存适合 CDN 资源dataGroups[].cacheConfig.strategyperformance默认缓存优先允许陈旧或freshness网络优先超时时回退缓存dataGroups[].cacheConfig.maxSize/maxAge缓存最大条目数 / 最长保留时长时长串单位后缀为dhmsu如3d12hdataGroups[].cacheConfig.timeout/refreshAhead网络超时时长 / 到期前提前刷新时长dataGroups[].version数据组版本号API 不兼容变更时用于丢弃旧缓存条目navigationRequestStrategyperformance默认导航请求走缓存或freshness强制走网络applicationMaxAge整个应用缓存的最长有效期超过则绕过缓存安装与注册安装 Angular 服务工作者只需运行一条 Angular CLI 命令ng add angular/pwa。该命令会完成 Getting Started 文档 所列动作为项目添加angular/service-worker包在 CLI 中启用服务工作者构建支持在应用根 provider 中导入并注册服务工作者更新index.html加入对manifest.webmanifest的引用与theme-color元标签安装 PWA 所需图标文件创建服务工作者配置文件ngsw-config.json用于指定缓存行为及其他设置。随后执行ng buildCLI 构建产物中即包含 worker 脚本与ngsw.json。在应用代码中注册通过provideServiceWorker()完成。其定义位于 provider.tsimport {ApplicationConfig, isDevMode} from angular/core; import {provideServiceWorker} from angular/service-worker; export const appConfig: ApplicationConfig { providers: [ provideServiceWorker(ngsw-worker.js, { enabled: !isDevMode(), }), ], };从源码看provideServiceWorker(script, options)返回一组环境 provider注册SwPush与SwUpdate服务、保存脚本路径与选项、提供通信通道NgswCommChannel工厂并通过provideAppInitializer(ngswAppInitializer)把注册逻辑挂到应用初始化流程上。也就是说CLI 的ng add angular/pwa除了注册 worker还让若干可注入服务SwUpdate、SwPush等可用——应用可以询问“新更新何时可用”、也可以主动要求 worker 向服务器检查更新。注册前置条件HTTPS 与 localhost 例外要充分发挥 Angular 服务工作者的能力需要满足两点前提使用最新版本的 Angular 与 Angular CLI应用必须通过 HTTPS 访问。浏览器会忽略在不安全连接页面上注册的服务工作者——因为服务工作者权限很大必须额外确保其脚本未被篡改。唯一的例外是localhost为简化本地开发浏览器在通过localhost访问应用时不要求安全连接。worker 侧对此有对应实现driver.ts 中的isLocalhost()用正则识别localhost、[::1]与127.x.x.x地址供安全策略判断使用。注册选项 SwRegistrationOptionsSwRegistrationOptions定义于 provider.ts提供对注册行为的精细控制选项默认值说明enabledtrue是否注册 worker 并让相关服务与之通信设为false时行为等同于浏览器不支持updateViaCache浏览器默认控制浏览器更新 worker 或其importScripts()脚本时是否查询 HTTP 缓存imports仅导入脚本、all、nonetypeclassicmodule时以 ES module 方式注册脚本内允许import/exportscope脚本所在目录注册作用域决定 worker 可拦截的 URL 范围registrationStrategyregisterWhenStable:30000注册时机策略支持字符串策略或返回Observable的工厂函数注册策略的具体实现见ngswAppInitializerprovider.tsregisterWhenStable:timeout应用稳定无待处理微任务/宏任务即注册但最迟不超过timeout毫秒省略超时则等待直到稳定。源码中用Promise.race([appRef.whenStable(), delayWithTimeout(...)])实现registerImmediately立即注册Promise.resolve()registerWithDelay:timeout延迟指定毫秒注册返回Observable的工厂函数订阅后首个值触发即注册可实现完全自定义的注册时机遇到未知策略字符串会抛出运行时错误UNKNOWN_REGISTRATION_STRATEGY。值得注意的实现细节注册过程整体运行在 Angular zone 之外ngZone.runOutsideAngular以避免长轮询等场景阻塞“应用稳定”判定注册失败时不会抛出未捕获 rejection而是打印SERVICE_WORKER_REGISTRATION_FAILED运行时错误。此外初始化器还会在controllerchange事件上向 worker 发送{action: INITIALIZE}消息使 worker 即使在没有应用流量时也能完成初始化。与服务工作者通信SwUpdate应用侧与服务工作者的交互集中在SwUpdate服务update.ts它暴露isEnabled: boolean——worker 是否已启用浏览器支持且未被选项禁用。在调用其他方法前应先检查此属性以避免在不支持 worker 的浏览器中产生错误versionUpdates: ObservableVersionEvent——版本更新事件流unrecoverable: ObservableUnrecoverableStateEvent——不可恢复状态事件checkForUpdate(): Promiseboolean——检查更新并等待新版本下载就绪解析为true发现并准备好新版本、false无新版本出错时 rejectactivateUpdate(): Promiseboolean——将当前客户端切换到已就绪的最新版本。文档明确建议大多数场景应通过重载页面而非调用此方法来更新客户端因为 shell 与懒加载 chunk 之间可能出现版本错配导致应用损坏。事件类型定义于 low_level.tsVERSION_DETECTED在服务器上检测到新版本、即将开始下载、VERSION_INSTALLATION_FAILED下载或检查失败可用于日志监控、VERSION_READY新版本已下载、可激活附带currentVersion与latestVersion、NO_NEW_VERSION_DETECTED未发现新版本。当 worker 禁用时versionUpdates与unrecoverable是NEVER流从不发出值而checkForUpdate()/activateUpdate()会返回被 reject 的 Promise——这与总览文档中“主动与服务工作者交互会得到 rejected promises”的描述一致。底层通信由NgswCommChannel完成它监听controllerchange与message事件postMessageWithOperation()通过随机 nonce 发起操作并等待对应的OPERATION_COMPLETED事件按 nonce 过滤、take(1)来把异步消息收敛为 Promise——SwUpdate.checkForUpdate()返回的布尔值正是走这条链路。更新检测如何发生总览文档强调“更新在后台进行”。结合 Getting Started 的实测日志worker 检查更新的信号是带缓存穿透参数的请求GET /ngsw.json?ngsw-cache-bust0.9365263935102124 Mozilla/5.0 ...即 worker 定期以ngsw-cache-bust查询参数请求ngsw.json比对新旧清单哈希发现差异后在空闲期后台下载新版本资源安装完成后下次页面加载/刷新即切换到新版本对应VERSION_READY事件与“刷新后看到新版本”的准则 3、4。worker 的空闲调度参数定义于 driver.tsIDLE_DELAY 5000空闲 5 秒后执行空闲任务与MAX_IDLE_DELAY 30000最长等待上限 30 秒。不可恢复状态unrecoverable事件对应 worker 无法从缓存或服务器取回必需资源等“损坏”状态例如缓存被浏览器部分清理。从源码结构看worker 的DriverReadyState分为NORMAL、EXISTING_CLIENTS_ONLY降级仅服务旧客户端、SAFE_MODE完全放弃请求处理直到下次重启三态driver.ts。收到UNRECOVERABLE_STATE事件的推荐处理方式是引导用户执行完整页面重载。绕过缓存与调试页两个实用的运维细节同样可以在源码中得到印证绕过 worker请求头携带ngsw-bypass或 URL 中携带ngsw-bypass查询参数时worker 直接放行请求到网络onFetch中的首段判断调试页访问ngsw/state相对于注册作用域路径会渲染 worker 调试页展示版本、客户端分配等状态由DebugHandler处理。生命周期细节skipWaiting 与 clients.claimworker 代码更新与应用更新是分离的driver.ts 因此在install事件中总是skipWaiting()——新 SW 版本可以立即激活而无需等待应用标签页关闭activate事件中clients.claim()立即接管现有客户端因为新 SW 版本会继续服务于旧应用版本切换是安全的。随后 worker 通过向自身postMessage({action: INITIALIZE})的方式在独立事件上下文中调度初始化避免阻塞激活事件的解析与流量服务——初始化由waitUntil()在该上下文中保活。浏览器支持要受益于 Angular 服务工作者应用必须运行在支持服务工作者的浏览器中。目前 Chrome、Firefox、Edge、Safari、Opera、UC BrowserAndroid 版与 Samsung Internet 的最新版本均支持IE 与 Opera Mini 不支持。在不支持服务工作者的浏览器中worker 不会被注册相关行为离线缓存管理、推送通知等也不会发生。具体表现为浏览器不会下载服务工作者脚本与ngsw.json清单文件主动尝试与服务工作者交互如调用SwUpdate.checkForUpdate()会返回被 reject 的 Promise相关服务的可观察事件如versionUpdates不会被触发。因此官方强烈建议确保应用在没有服务工作者支持的浏览器中也能正常工作。虽然不支持的浏览器会忽略 worker 缓存但若应用尝试与之交互仍会报错例如checkForUpdate()返回 rejected promise。规避方式就是在交互前检查SwUpdate.isEnabled。从源码看这一判断对应NgswCommChannel.isEnabled——即navigator.serviceWorker存在且enabled ! false当它不可用时checkForUpdate()会以Service workers are disabled or not supported by this browser错误 reject见 low_level.ts 中的ERR_SW_NOT_SUPPORTED常量。现状与演进方向需要特别指出Angular Service Worker 是一个面向简单离线支持的基础缓存工具功能集有限官方声明除安全修复外不再接受新功能提案。对于更高级的缓存与离线能力官方推荐直接探索浏览器原生 API。这一定位与源码结构相符angular/service-worker包由 worker 实现、应用侧服务、构建期清单生成 CLI 与 配置校验 schema 组成功能边界清晰、没有继续扩张的迹象。相关文档本仓库中与 Angular 服务工作者相关的其他文章路径相对仓库根目录配置文件详解与服务工作者通信推送通知服务工作者 devopsApp shell 模式自定义 worker 脚本快速上手关键源码入口应用侧 API 与 provider、低层通信通道、worker 主驱动、清单类型定义、配置 schema、包说明。【免费下载链接】angularDeliver web apps with confidence 项目地址: https://gitcode.com/GitHub_Trending/an/angular创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考