缓存第一个场景的 Service Worker 策略 - 预加载屏幕
我目前正在开发一个小型网络应用程序,它应该实现缓存的第一个场景(用户在提供wifi的基础上下载wep应用程序,然后应该能够离线使用它外部) 我没有使用任何框架,因此自己实现缓存(SW)。 由于我还在 iframe 上集成了一些 playcanvas 内容(有自己的加载屏幕),我想知道什么加载方面的总体策略才有意义。
在一个类似的项目中,我只是让服务工作人员与应用程序的(初始)加载并行下载资产。 但我想到,最好实现一个更接近本机应用程序行为的工作流程 - 意味着在服务工作人员下载过程中显示整体加载屏幕,并在此过程完成后构建/显示我的主应用程序(或确实失败 -> 强制网络场景或之前发生过 -> 离线场景)。另一个解决方案是显示非阻塞的“资产仍在下载”横幅。
导致第二个工作流程的主要想法是:
- 软件加载屏幕/横幅可以向用户提供更好的反馈:“所有资产已下载 - 我可以安全地离线”,而旧方案可能会导致问题 - 成功向用户显示第一个状态 - 而一些关键文件仍在后面下载。
- 使用 SW-Loading 屏幕,下载过程对我来说更加可控/易于理解 - 例如,SW-Download 和 Playcanvas Loading 的并行过程变得顺序。
如果有人可以向我提供反馈/信息,那就太好了:
- 如果我在第二种情况下处于正确的轨道上,以便变得更好,或者它只是开销,
- 如何/是否可以实现一个便宜的加载屏幕,例如意味着下载 230 个文件中的 100 个或其他。
- 一般来说,对于这种情况有更好的策略 一如既往
,感谢您的提前提醒。
I'm currently working on a small web app which should implement a cached first scenario (users download the wep app in a wifi provided base and then should be able use it offline outside)
I'm not using any framework and therefore implement the caching (SW) myself.
As I also integrate some playcanvas content (which has its own loading screen) over an iframe I was wondering what overall strategy in terms of loading would make sense.
In a similar project I simply let the service worker download the assets parallel to the (initial) load of the application.
But it came to my mind that that it would be better to implement a workflow which is closer to an native app behavior - meaning showing a overall loading screen during the service worker download process and building/showing my main application after this process is finished (or did fail -> forced network scenario or did happen before -> offline scenario). Another solution would be to show a non blocking "Assets are still being downloaded" banner.
The main thoughts leading mit to the second workflow where:
- The SW-Loading screen / banner could provide better feedback to the user: "All assets downloaded - I'm safe to go offline", while the old scenario could cause issues here - successfully showing the the user the first state - while some critical files are still downloaded in the back.
- With the SW-Loading screen the download process is a bit more controllable/understandable for me - as the parallel process of an SW-Download and the Playcanvas Loading for example become sequential.
It would be great if someone could provide me feedback/info:
- if I'm on the right track with this second scenario for being better or it just being overhead
- how / if it might be possible to implement a cheap loading screen, meaning for example 100 of 230 Files downloaded or else.
- better strategies for this scenario in general
As always, thanks for any heads up in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这很大程度上取决于您希望用户体验什么。底层技术可以完成您概述的任何场景。
例如,如果您想在初始 Service Worker 安装期间显示有关预缓存进度的信息,您可以通过添加以下代码来实现。
在您的 Service Worker 中:
在您的客户端页面中:
A lot of this comes down to what you want your users to experience. The underlying technology is there to accomplish any of the scenarios you outline.
For instance, if you want to show information about the precaching progress during initial service worker installation, you could do that by adding code along the lines of the following.
In your service worker:
In your client pages: