Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serviceWorker #49

Open
lewenweijia opened this issue Oct 26, 2019 · 2 comments
Open

serviceWorker #49

lewenweijia opened this issue Oct 26, 2019 · 2 comments

Comments

@lewenweijia
Copy link
Owner

lewenweijia commented Oct 26, 2019

Service Workers是浏览器和网络之间的虚拟代理
servcieWorker是实现pwa理念的关键基础技术

  1. 脱机使用/支持离线使用

sw?

  1. 离线能力 => 内存是有限的, 注意对缓存的清理(activate事件)
  2. 资源预加载
  3. 耗时计算

问题?:

  1. sw的更新
  2. index.html的更新

历史上出现过的两种web应用离线技术

  1. AppCache => 相关文件manifest
  2. Service Worker

SW兼容性判断

function bootStrapPWA() {
  // 如果当前浏览器不支持sw, 那么当啥事都没发生过, pwa中的p字思想
   if (!navigator.serviceWorker)  return;
}

SW和webpack的接入
插件: serviceworker-webpack-plugin
关键问题就是sw.js文件

  1. sw.js文件中的cacheFileList关键变量

web应用和native应用的区别
编译产物是放在客户端(native)还是服务端(web)

PWA定位和目标
提供和原生应用一样体验的web应用(血统纯正的web技术)
混合开发?(血统不纯正)

@lewenweijia
Copy link
Owner Author

...不能拿着锤子, 就觉得到处都是钉子的啊, 觉得到处都应该加入sw?
sw的本质是锦上添花, 用来极致化用户体验的(贴近原生应用)
大规模应用还是要仔细考量的, 作为知识储备就好了的啊

思考
网速够快的未来, 折腾缓存还有意义吗?

资源
Service Worker 从入门到出门

@lewenweijia
Copy link
Owner Author

web相较native, 缺少了:
1. 离线使用能力
2. 消息推送能力
3. 一级入口, 将web应用安装到桌面

针对web相较native短板, pwa引入的解决方案:
1. sw: 离线存储 | 消息推送
2. manifest: 一级入口问题

Service Worker?
出生: 2014年 -> 前辈(AppCahce, 淘汰, 实践中暴露太多问题)
核心思想: 页面和网络之间增加一层拦截层, 用于请求拦截和缓存控制
核心功能: 缓存管理(构建|删除) + 拦截请求

页面主线程 | 渲染主线程

js不能执行过久, 会导致渲染主线程阻塞, 使得渲染一帧的时间变长, 低于60fps, 让用户产生卡顿的感觉

Web Worker 和 Service Worker
同: 让部分的js代码运行在渲染主线程之外
异: web worker是一次性的, 不持久化状态

service worker的生存时间长度是和浏览器生存长度是一致的, 也就是可以为多个页面进行提供sw服务

pwa也是关联一系列技术的总总称的啊

页面渲染效率

CPU密集型任务?
解决大量计算导致的UI阻塞问题

JS在渲染主线程上的执行时间超过一定阈值(僵死状态), 浏览器会让用户选择是停止脚本还是继续运行

众所周知? JS执行时间过长会导致UI堵塞问题
JS执行时间过长? 也就是JS领到了CPU密集型的任务
针对CPU密集型的任务, 处理方案:

  1. server端进行处理
  2. 任务分块, setTimeout|setInterval => requestAnimationFrame
  3. web woker -> 完全不是在渲染主线程上跑的呢

setTimeout? 本质还是依赖页面的事件循环系统跑的啊 (rafUI有关, 所以一定得跟随页面循环系统
web worker呢? 让多线程编程成为可能(UI无关)

worker线程计算, 然后将结果传回主js线程, 主js线程才操作DOM进行UI更新
worker线程的限制?: 1. 存储无效 2. DOM访问无效

web worker 和 service worker的定位和放置位置都是不同的啊
因为web worker是和js主线程并行的角色定位, 所以, 限制资源访问, 放置资源竞争

File, Blob, ArrayBuffer
数据的传输方式?:

  1. 拷贝(深拷贝, 结构化复制算法
  2. 转移Transferable object

可怕的啊, 这里的性能快照这里, 基本都是黄色, 意味着js过分之心

pwa就是基于sw进行发展的啊
虚拟DOM?:
利用虚拟DOM来减少对实际DOM的操作从而提升性能, 具体:

  1. JS对象模拟DOM树
  2. diff算法对比两个虚拟DOM的差异
  3. 将差异应用到真正的DOM树上

React和web worker
Redux和web worker

玩redux? 最后的最后肯定一堆异步action的呢

web worker里面跑的?: 纯函数, 上下文无感

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant