Open lewenweijia opened 4 years ago
...不能拿着锤子, 就觉得到处都是钉子的啊, 觉得到处都应该加入sw? sw的本质是锦上添花, 用来极致化用户体验的(贴近原生应用) 大规模应用还是要仔细考量的, 作为知识储备就好了的啊
思考 网速够快的未来, 折腾缓存还有意义吗?
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密集型的任务, 处理方案:
setTimeout? 本质还是依赖页面的事件循环系统跑的啊 (rafUI有关, 所以一定得跟随页面循环系统 web worker呢? 让多线程编程成为可能(UI无关)
worker线程计算, 然后将结果传回主js线程, 主js线程才操作DOM进行UI更新 worker线程的限制?: 1. 存储无效 2. DOM访问无效
web worker 和 service worker的定位和放置位置都是不同的啊 因为web worker是和js主线程并行的角色定位, 所以, 限制资源访问, 放置资源竞争
File, Blob, ArrayBuffer 数据的传输方式?:
可怕的啊, 这里的性能快照这里, 基本都是黄色, 意味着js过分之心
pwa就是基于sw进行发展的啊 虚拟DOM?: 利用虚拟DOM来减少对实际DOM的操作从而提升性能, 具体:
React和web worker Redux和web worker
玩redux? 最后的最后肯定一堆异步action的呢
web worker里面跑的?: 纯函数, 上下文无感
Service Workers是浏览器和网络之间的虚拟代理 servcieWorker是实现pwa理念的关键基础技术
sw?
问题?:
历史上出现过的两种web应用离线技术
manifest
SW兼容性判断
SW和webpack的接入 插件: serviceworker-webpack-plugin 关键问题就是
sw.js
文件cacheFileList
关键变量web应用和native应用的区别 编译产物是放在客户端(native)还是服务端(web)
PWA定位和目标 提供和原生应用一样体验的web应用(血统纯正的web技术) 混合开发?(血统不纯正)