我们是如何做好前端工程化和静态资源管理

2016/07/30 · 基础技术 ·
工程化,
静态资源

原文出处:
凹凸实验室   

图片 1

随着互联网的发展,我们的业务也日益变得更加复杂且多样化起来,前端工程师也不再只是做简单的页面开发这么简单,我们需要面对的十分复杂的系统性问题,例如,业务愈来愈复杂,我们要如何清晰地梳理;团队人员愈来愈多,我们要如何更好地进行团队协作;功能愈来愈多,我们要如何保证页面的性能不至于下降,等等。所有的这些都可以归结为如何提升开发体验和性能问题。

我也想来谈谈HTTPS

2016/11/04 · 基础技术 ·
HTTPS

本文作者: 伯乐在线 –
ThoughtWorks
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

React 同构应用 PWA 升级指南

2018/05/25 · JavaScript
· PWA,
React

原文出处:
林东洲   

提升开发体验

我们主要从以下三个方面来提升我们的开发体验。

安全越来越被重视

2014年8月份Google在官博上发表《 HTTPS as a ranking
signal 》。表示调整其搜索引擎算法,采用HTTPS加密的网站在搜索结果中的排名将会更高,鼓励全球网站采用安全度更高的HTTPS以保证访客安全。

同一年(2014年),百度开始对外开放了HTTPS的访问,并于3月初正式对全网用户进行了HTTPS跳转。对百度自身来说,HTTPS能够保护用户体验,降低劫持/隐私泄露对用户的伤害。

而2015年,百度开放收录HTTPS站点公告。全面支持HTTPS页面直接收录;百度搜索引擎认为在权值相同的站点中,采用HTTPS协议的页面更加安全,排名上会优先对待。

前言

最近在给我的博客网站 PWA 升级,顺便就记录下 React 同构应用在使用 PWA
时遇到的问题,这里不会从头开始介绍什么是 PWA,如果你想学习 PWA
相关知识,可以看下下面我收藏的一些文章:

  • 您的第一个 Progressive Web
    App
  • 【Service
    Worker】生命周期那些事儿
  • 【PWA学习与实践】(1)
    2018,开始你的PWA学习之旅
  • Progressive Web Apps (PWA)
    中文版

规范化

当团队人员不断扩充时,我们需要制定统一的规范来对平时的开发工作做出一定约束和指导。统一的规范包括前端的代码规范,根据规范定义好一套代码检查的规则,在代码提交的时候进行检查,让开发人员知道自己的代码情况。

同时,根据以往的开发经验,我们制定了统一的项目框架,根据业务功能不同,将一个项目(app)拆分成不同的业务模块(module),而每一个模块都包含自身的页面(page)以及构成页面所需要的组件(widget),每一个项目涉及到app、module、page、widget这些已经约定好的概念,这样让项目结构更加清晰,而且让团队内不同业务的人员之间切换无障碍。

图片 2

“HTTP = 不安全”,为什么说HTTP不安全?

HTTP报文是由一行行简单字符串组成的,是纯文本,可以很方便地对其进行读写。一个简单事务所使用的报文:

图片 3

HTTP传输的内容是明文的,你上网浏览过、提交过的内容,所有在后台工作的实体,比如路由器的所有者、网线途径路线的不明意图者、省市运营商、运营商骨干网、跨运营商网关等都能够查看。举个不安全的例子:

一个简单非HTTPS的登录采用POST方法提交包含用户名和密码的表单,会发生什么?

图片 4

POST表单发出去的信息,没有做任何的安全性信息置乱(加密编码),直接编码为下一层协议(TCP层)需要的内容,所有用户名和密码信息一览无余,任何拦截到报文信息的人都可以获取到你的用户名和密码,是不是想想都觉得恐怖?

那么问题来了,怎么样才是安全的呢?

PWA 特性

PWA 不是单纯的某项技术,而是一堆技术的集合,比如:Service
Worker,manifest 添加到桌面,push、notification api 等。

而就在前不久时间,IOS 11.3 刚刚支持 Service worker 和类似 manifest
添加到桌面的特性,所以这次 PWA
改造主要还是实现这两部分功能,至于其它的特性,等 iphone 支持了再升级吧。

组件化

在项目中引入组件化的概念,这里的组件对应上文讲到的widget,每一个组件都会包含组件自身的模板、css、js、图片以及说明文件,我们使用组件来拼装页面,像搭积木一样来拼装我们的页面,同时一个组件内可以调用另一个组件。

图片 5

在拿到设计稿后,我们首先需要确定哪些需要做成公共组件,那些是要做成独立组件,以及组件间如何进行通信。在页面中调用这些组件后,会自动加载组件的模板以及组件的静态资源,而当组件不再需要时,只要移除掉组件引用,那么相应的模板和静态资源也会不再加载。

组件化的好处主要有这么几点

  • 管理方便,我们可以把一个独立功能相关的文件在工程目录中放在一起,这样代码管理起来会非常便利
  • 组件复用,通过抽取公共组件,可以实现组件复用,从而减少工作量,创造价值
  • 分而治之,这是组件化最重要的一点,将页面组件化,就是对页面功能的拆分,将一个大的工程拆成小的零件,我们只需要关注每一个零件的功能,极大地降低了页面的开发与维护的难度

对于包含用户敏感信息的网站需要进行怎样的安全防护?

对于一个包含用户敏感信息的网站(从实际角度出发),我们期望实现HTTP安全技术能够满足至少以下需求:

  • 服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话)
  • 客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话)
  • 完整性(客户端和服务器的数据不会被修改)
  • 加密(客户端和服务器的对话是私密的,无需担心被窃听)
  • 效率(一个运行的足够快的算法,以便低端的客户端和服务器使用)
  • 普适性(基本上所有的客户端和服务器都支持这个协议)
  • 管理的可扩展性(在任何地方的任何人都可以立即进行安全通信)
  • 适应性(能够支持当前最知名的安全方法)
  • 在社会上的可行性(满足社会的政治文化需要)

Service Worker

service worker
在我看来,类似于一个跑在浏览器后台的线程,页面第一次加载的时候会加载这个线程,在线程激活之后,通过对
fetch 事件,可以对每个获取的资源进行控制缓存等。

自动化编译

在前端开发中,我们总是会去使用很多工具、手段来优化代码、提升开发效率,例如,我们会使用sass、less等CSS预处理工具来编写更好维护的样式代码,我们也会使用CSSLint、eslint等代码检查工具来检查代码的语法错误,使用文件合并压缩等手段来减少资源大小,除此之外我们还会去做雪碧图合并、多倍图处理、字体压缩处理、代码发布等等。

曾经有大神说过,超过90s的工作都应该自动化掉。而以上所有的这些工作,贯穿我们整个开发流程,但是不同工具的切换不但显得凌乱,而且影响开发效率。在自动化、工程编译的思想早已深入人心的当下,我们当然也要紧跟潮流,所以我们考虑通过自动化手段来提升我们的效率,让所有操作可以一键式开速执行完。

我们将通过定义好一系列的编译任务,按照一定顺序依次对我们的项目自动进行编译操作,最后产生出可上线的代码。

HTTPS协议来解决安全性的问题:HTTPS和HTTP的不同 – TLS安全层(会话层)

超文本传输安全协议(HTTPS,也被称为HTTP over TLS,HTTP over SSL或HTTP
Secure)是一种网络安全传输协议。

HTTPS开发的主要目的,是提供对网络服务器的认证,保证交换信息的机密性和完整性。

它和HTTP的差别在于,HTTPS经由超文本传输协议进行通信,但利用SSL/TLS來对包进行加密,即所有的HTTP请求和响应数据在发送到网络上之前,都要进行加密。如下图:
图片 6
安全操作,即数据编码(加密)和解码(解密)的工作是由SSL一层来完成,而其他的部分和HTTP协议没有太多的不同。更详细的TLS层协议图:
图片 7
SSL层是实现HTTPS的安全性的基石,它是如何做到的呢?我们需要了解SSL层背后基本原理和概念,由于涉及到信息安全和密码学的概念,我尽量用简单的语言和示意图来描述。

明确哪些资源需要被缓存?

那么在开始使用 service worker 之前,首先需要清楚哪些资源需要被缓存?

提升性能

我们主要从以下四个方面来做好性能优化。

SSL层背后基本原理和概念

介绍HTTPS背后的基本原理和概念,涉及到的概念:加密算法,数字证书,CA中心等。

加密算法
加密算法严格来说属于编码学(密码编码学),编码是信息从一种形式或格式转换为另一种形式的过程。解码,是编码的逆过程(对应密码学中的解密)。

图片 8

对称加密算法

加密算法主要分两类:对称和非对称加密算法。在对称加密算法中,使用的密钥只有一个,发收信双方都使用这个密钥对数据进行加密和解密,这就要求解密方事先必须知道加密密钥。
图片 9

但是对称加密算法有一个问题:一旦通信的实体多了,那么管理秘钥就会成为问题。

图片 10
非对称加密算法(加密和签名)

非对称加密算法需要两个密钥:公开密钥(public
key)
私有密钥(private
key)
。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密,这个反过来的过程叫作数字签名(因为私钥是非公开的,所以可以验证该实体的身份)。

他们就像是锁和钥匙的关系。Alice把打开的锁(公钥)发送给不同的实体(Bob,Tom),然后他们用这把锁把信息加密,Alice只需要一把钥匙(私钥)就能解开内容。

图片 11

那么,有一个很重要的问题:加密算法是如何保证数据传输的安全,即不被破解?有两点:

1.利用数学计算的困难性(比如:离散对数问题)
2.加密算法是公开的,关键在于秘钥,密码学中有柯克霍夫斯基原则,即加密算法的安全性依赖的是密钥的保密而不是算法的保密,因此,保证秘钥的定期更换是非常重要的。

数字证书,用来实现身份认证和秘钥交换

数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息,使用的加密算法以及公开密钥的文件。

图片 12

以数字证书为核心的加密技术可以对网络上传输的信息进行加密和解密、数字签名和签名验证,确保网上传递信息的机密性、完整性及交易的不可抵赖性。使用了数字证书,即使您发送的信息在网上被他人截获,甚至您丢失了个人的账户、密码等信息,仍可以保证您的账户、资金安全。(比如,支付宝的一种安全手段就是在指定电脑上安装数字证书)

身份认证(我凭什么信任你)

身份认证是建立每一个TLS连接不可或缺的部分。比如,你有可能和任何一方建立一个加密的通道,包括攻击者,除非我们可以确定通信的服务端是我们可以信任的,否则,所有的加密(保密)工作都没有任何作用。

而身份认证的方式就是通过证书以数字方式签名的声明,它将公钥与持有相应私钥的主体(个人、设备和服务)身份绑定在一起。通过在证书上签名,CA可以核实与证书上公钥相应的私钥为证书所指定的主体所拥有。
图片 13

缓存静态资源

首先是像 CSS、JS 这些静态资源,因为我的博客里引用的脚本样式都是通过 hash
做持久化缓存,类似于:main.ac62dexx.js 这样,然后开启强缓存,这样下次用户下次再访问我的网站的时候就不用重新请求资源。直接从浏览器缓存中读取。对于这部分资源,service
worker 没必要再去处理,直接放行让它去读取浏览器缓存即可。

我认为如果你的站点加载静态资源的时候本身没有开启强缓存,并且你只想通过前端去实现缓存,而不需要后端在介入进行调整,那可以使用
service worker 来缓存静态资源,否则就有点画蛇添足了。

首屏优化

页面的打开速度一直是大家非常关心的一个指标,一个页面打开太慢会让让用户失去等待的耐心,为了让用户更快地看到页面,我们考虑将页面中部分静态资源代码直接嵌入页面中,我们通过工具处理,在工程编译阶段,将指定的静态资源代码内嵌入页面中,这样可以减少HTTP请求,提升首屏加载速度,同时降低页面裸奔风险。

了解TLS协议

HTTPS的安全主要靠的是TLS协议层的操作。那么它到底做了什么,来建立一条安全的数据传输通道呢?

TLS握手:安全通道是如何建立的

图片 14

0 ms
TLS运行在一个可靠的TCP协议上,意味着我们必须首先完成TCP协议的三次握手。

56 ms
在TCP连接建立完成之后,客户端会以明文的方式发送一系列说明,比如使用的TLS协议版本,客户端所支持的加密算法等。

84 ms
服务器端拿到TLS协议版本,根据客户端提供的加密算法列表选择一个合适的加密算法,然后将选择的算法连同服务器的证书一起发送到客户端。

112 ms
假设服务器和客户端协商后,得到一个共同的TLS版本和加密算法,客户端检测服务端的证书,非常满意,客户端就会要么使用RSA加密算法(公钥加密)或者DH秘钥交换协议,得到一个服务器和客户端公用的对称秘钥。

由于历史和商业原因,基于RSA的秘钥交换占据了TLS协议的大片江山:客户端生成一个对称秘钥,使用服务器端证书的公钥加密,然后发送给服务器端,服务器端利用私钥解密得到对称秘钥。

140 ms
服务器处理由客户端发送的秘钥交换参数,通过验证MAC(Message
Authentication
Code,消息认证码)来验证消息的完整性,返回一个加密过的“Finished”消息给客户端。

在密码学中,消息认证码(英语:Message Authentication
Code,缩写为MAC),又译为消息鉴别码、文件消息认证码、讯息鉴别码、信息认证码,是经过特定算法后产生的一小段信息,检查某段消息的完整性,以及作身份验证。它可以用来检查在消息传递过程中,其内容是否被更改过,不管更改的原因是来自意外或是蓄意攻击。同时可以作为消息来源的身份验证,确认消息的来源。

168 ms
客户端用协商得到的堆成秘钥解密“Finished”消息,验证MAC(消息完整性验证),如果一切ok,那么这个加密的通道就建立完成,可以开始数据传输了。

在这之后的通信,采用对称秘钥对数据加密传输,从而保证数据的机密性。

到此为止,我是想要介绍的基本原理的全部内容,但HTTPS得知识点不止如此,还有更多说,现在来点干货(实战)!!

缓存页面

缓存页面显然是必要的,这是最核心的部分,当你在离线的状态下加载页面会之后出现:

图片 15

究其原因就是因为你在离线状态下没办法加载页面,现在有了 service
worker,即使你在没网络的情况下,也可以加载之前缓存好的页面了。

按需加载

同时,我们考虑通过尽量减小页面体积来提升页面打开速度,在业务上我们将页面划分为一个个楼层组件,以京东美妆馆为例,页面中从上而下分为首焦、至IN尖货、今日特惠、潮流前沿、口碑榜单这么几个楼层组件,其实这个页面还有很长,内容非常多且复杂。

图片 16

之前我们的做法是整个页面直出,这样一次性加载的内容会非常多,为了提升打开速度,我们考虑通过按需加载的方式来优化页面的加载。我们在页面中只放每一个楼层的框架性代码,楼层的模板和数据都通过异步的方式去拉取,来实现楼层组件的按需加载,同时我们可以对模板以及数据进行缓存,以此来减少请求,做更极致的优化。在开发中我们以正常组件的方式去开发整个页面,随后通过编译工具,在代码编译阶段自动将楼层的模板抽离成一个独立的JS文件,并给楼层容器打上标记位,通过页面加载逻辑去按需拉取模板,再进行渲染。

通过给楼层容器和模板分别加上标记位 o2-out-tpl-wrapper o2-out-tpl

图片 17

在编译时自动将指定的模板代码抽离成独立js文件

图片 18

并且给楼层容器打上标记

图片 19

同时在逻辑脚本适当位置自动加入模板的版本

图片 20

通过上述步骤,实现按需加载的自动化生成,在提升性能的同时,很好地解放我们生产力。

那么,教练,我想用HTTPS

图片 21

选择合适的证书,Let’s Encrypt(It’s free, automated, and
open.)是一种不错的选择

ThoughtWorks在2016年4月份发布的技术雷达中对Let’s Encrypt项目进行了介绍:

从2015年12月开始,Let’s
Encrypt项目从封闭测试阶段转向公开测试阶段,也就是说用户不再需要收到邀请才能使用它了。Let’s
Encrypt为那些寻求网站安全的用户提供了一种简单的方式获取和管理证书。Let’s
Encrypt也使得“安全和隐私”获得了更好的保障,而这一趋势已经随着ThoughtWorks和我们许多使用其进行证书认证的项目开始了。

据Let’s
Encrypt发布的数据来看,至今该项目已经颁发了超过300万份证书——300万这个数字是在5月8日-9日之间达成的。Let’s
Encrypt是为了让HTTP连接做得更加安全的一个项目,所以越多的网站加入,互联网就回变得越安全。

1 赞 1 收藏
评论

缓存后端接口数据

缓存接口数据是需要的,但也不是必须通过 service worker
来实现,前端存放数据的地方有很多,比如通过 localstorage,indexeddb
来进行存储。这里我也是通过 service worker
来实现缓存接口数据的,如果想通过其它方式来实现,只需要注意好 url
路径与数据对应的映射关系即可。

基于资源表加载

根据页面组件化,通过工具分析,我们将获得页面与组件的依赖关系表,同时也能确认页面所引用资源的依赖关系,例如,我们在页面hello中同步引用组件topbar,那么依赖关系表中将会记录同步引用关系hello引用topbar.tpl、topbar.css、topbar.js,那么页面hello将会自动加载组件topbar的CSS与JS,同时依赖表会记录异步引用的关系,假如我们在组件C中通过API异步引用了组件D的js,那么会在依赖表中记录C异步引用D.js这一个依赖关系,这样D.js这个资源将会在用到的时候被异步调用。

图片 22

图片 23

同步引用的资源通过生成combo形式链接,在服务端进行文件合并,这样在页面加载的时候,页面只会加载自己需要的同步资源,异步的资源将会在用到的时候再加载,有效避免资源冗余。同时删除、增加组件也非常方便,只需改动模板中对组件调用,通过编译工具会自动重新生成模板以及combo链接。

我们可以将资源加载的操作抽离出来,形成一套统一的资源加载框架设计,这样我们使用的模板可以变得更加灵活,无论是纯html模板,还是PHP或Java之类的后端模板都能有效支持。编译工具扫描代码后只生成资源依赖表,我们通过实现各语言平台的资源加载框架,让不同语言的模板都能基于同一个资源依赖表进行资源加载。

同时,对资源进行MD5重命名处理,文件md5重命名也是一种提升性能的有效手段,使用文件md5后开启服务器强缓存,可以提升缓存的利用率并避免不必要的缓存判断处理。但文件md5重命名后会出现开发时引用的文件名对不上的问题,这就需要在资源表中记录原文件名与md5重命名后之间的对应关系,当我们引用一个资源时,就会通过查表获取重命名后的资源名,然后利用代码中引用资源定位的能力来进行资源名自动替换。

图片 24

关于作者:ThoughtWorks

图片 25

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,致力于科技驱动商业变革。擅长构建定制化软件产品,帮助客户快速将概念转化为价值。同时为客户提供用户体验设计、技术战略咨询、组织转型等咨询服务。

个人主页 ·
我的文章 ·
84 ·
  

图片 26

缓存策略

明确了哪些资源需要被缓存后,接下来就要谈谈缓存策略了。

静态资源预加载

所谓静态资源预加载,就是当用户在进行浏览页面的时候,我们可以在当前页面静默加载下一个页面的静态资源,这样当用户进入到下一个页面时就能快速打开页面,从而在不知不觉中提升页面的打开速度。

图片 27

我们会在静态资源预加载平台上配置每一个页面id对应需要预加载页面资源的id,然后系统通过读取资源依赖表获取到所需要预加载的静态资源,生成预加载资源列表文件,再将文件推送到线上服务器,通过页面挂载js请求获取预加载资源列表,随后静默加载资源。在有了资源依赖表后,我们可以准确地分析到每一个页面引用资源的请求,就可以很好地实现静态资源预加载的功能。

图片 28

页面缓存策略

因为是 React
单页同构应用,每次加载页面的时候数据都是动态的,所以我采取的是:

  1. 网络优先的方式,即优先获取网络上最新的资源。当网络请求失败的时候,再去获取
    service worker 里之前缓存的资源
  2. 当网络加载成功之后,就更新 cache
    中对应的缓存资源,保证下次每次加载页面,都是上次访问的最新资源
  3. 如果找不到 service worker 中 url 对应的资源的时候,则去获取 service
    worker 对应的 /index.html 默认首页

// sw.js self.addEventListener(‘fetch’, (e) => {
console.log(‘现在正在请求:’ + e.request.url); const currentUrl =
e.request.url; // 匹配上页面路径 if (matchHtml(currentUrl)) { const
requestToCache = e.request.clone(); e.respondWith( // 加载网络上的资源
fetch(requestToCache).then((response) => { // 加载失败 if (!response
|| response.status !== 200) { throw Error(‘response error’); } //
加载成功,更新缓存 const responseToCache = response.clone();
caches.open(cacheName).then((cache) => { cache.put(requestToCache,
responseToCache); }); console.log(response); return response;
}).catch(function() { //
获取对应缓存中的数据,获取不到则退化到获取默认首页 return
caches.match(e.request).then((response) => { return response ||
caches.match(‘/index.html’); }); }) ); } });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// sw.js
self.addEventListener(‘fetch’, (e) => {
  console.log(‘现在正在请求:’ + e.request.url);
  const currentUrl = e.request.url;
  // 匹配上页面路径
  if (matchHtml(currentUrl)) {
    const requestToCache = e.request.clone();
    e.respondWith(
      // 加载网络上的资源
      fetch(requestToCache).then((response) => {
        // 加载失败
        if (!response || response.status !== 200) {
          throw Error(‘response error’);
        }
        // 加载成功,更新缓存
        const responseToCache = response.clone();
        caches.open(cacheName).then((cache) => {
          cache.put(requestToCache, responseToCache);
        });
        console.log(response);
        return response;
      }).catch(function() {
        // 获取对应缓存中的数据,获取不到则退化到获取默认首页
        return caches.match(e.request).then((response) => {
           return response || caches.match(‘/index.html’);
        });
      })
    );
  }
});

为什么存在命中不了缓存页面的情况?

  1. 首先需要明确的是,用户在第一次加载你的站点的时候,加载页面后才会去启动
    sw,所以第一次加载不可能通过 fetch 事件去缓存页面
  2. 我的博客是单页应用,但是用户并不一定会通过首页进入,有可能会通过其它页面路径进入到我的网站,这就导致我在
    install 事件中根本没办法指定需要缓存那些页面
  3. 最终实现的效果是:用户第一次打开页面,马上断掉网络,依然可以离线访问我的站点

结合上面三点,我的方法是:第一次加载的时候会缓存 /index.html 这个资源,并且缓存页面上的数据,如果用户立刻离线加载的话,这时候并没有缓存对应的路径,比如 /archives 资源访问不到,这返回 /index.html 走异步加载页面的逻辑。

在 install 事件缓存 /index.html,保证了 service worker
第一次加载的时候缓存默认页面,留下退路。

import constants from ‘./constants’; const cacheName =
constants.cacheName; const apiCacheName = constants.apiCacheName; const
cacheFileList = [‘/index.html’]; self.addEventListener(‘install’, (e)
=> { console.log(‘Service Worker 状态: install’); const
cacheOpenPromise = caches.open(cacheName).then((cache) => { return
cache.addAll(cacheFileList); }); e.waitUntil(cacheOpenPromise); });

1
2
3
4
5
6
7
8
9
10
11
12
import constants from ‘./constants’;
const cacheName = constants.cacheName;
const apiCacheName = constants.apiCacheName;
const cacheFileList = [‘/index.html’];
 
self.addEventListener(‘install’, (e) => {
  console.log(‘Service Worker 状态: install’);
  const cacheOpenPromise = caches.open(cacheName).then((cache) => {
    return cache.addAll(cacheFileList);
  });
  e.waitUntil(cacheOpenPromise);
});

在页面加载完后,在 React 组件中立刻缓存数据:

// cache.js import constants from ‘../constants’; const apiCacheName =
constants.apiCacheName; export const saveAPIData = (url, data) => {
if (‘caches’ in window) { // 伪造 request/response 数据
caches.open(apiCacheName).then((cache) => { cache.put(url, new
Response(JSON.stringify(data), { status: 200 })); }); } }; // React 组件
import constants from ‘../constants’; export default class extends
PureComponent { componentDidMount() { const { state, data } =
this.props; // 异步加载数据 if (state === constants.INITIAL_STATE ||
state === constants.FAILURE_STATE) { this.props.fetchData(); } else {
// 服务端渲染成功,保存页面数据 saveAPIData(url, data); } } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// cache.js
import constants from ‘../constants’;
const apiCacheName = constants.apiCacheName;
 
export const saveAPIData = (url, data) => {
  if (‘caches’ in window) {
    // 伪造 request/response 数据
    caches.open(apiCacheName).then((cache) => {
      cache.put(url, new Response(JSON.stringify(data), { status: 200 }));
    });
  }
};
 
// React 组件
import constants from ‘../constants’;
export default class extends PureComponent {
  componentDidMount() {
    const { state, data } = this.props;
    // 异步加载数据
    if (state === constants.INITIAL_STATE || state === constants.FAILURE_STATE) {
      this.props.fetchData();
    } else {
        // 服务端渲染成功,保存页面数据
      saveAPIData(url, data);
    }
  }
}

这样就保证了用户第一次加载页面,立刻离线访问站点后,虽然无法像第一次一样能够服务端渲染数据,但是之后能通过获取页面,异步加载数据的方式构建离线应用。

图片 29

用户第一次访问站点,如果在不刷新页面的情况切换路由到其他页面,则会异步获取到的数据,当下次访问对应的路由的时候,则退化到异步获取数据。

图片 30

当用户第二次加载页面的时候,因为 service worker
已经控制了站点,已经具备了缓存页面的能力,之后在访问的页面都将会被缓存或者更新缓存,当用户离线访问的的时候,也能访问到服务端渲染的页面了。

图片 31

Athena

工欲善其事,必现利其器。为了实现我们对提升开发效率和产品性能的诉求,我们提出了比较完整的工程化解决方案以及对应的工具Athena。

Athena是由京东【凹凸实验室】(aotu.io)
推出的一套项目流程工具,通过Athena,我们可以很流程地跑完整个开发流程。Athena分为两部分,一是本地自动化编译工具,二是资源管理平台,其架构如下

图片 32

接口缓存策略

谈完页面缓存,再来讲讲接口缓存,接口缓存就跟页面缓存很类似了,唯一的不同在于:页面第一次加载的时候不一定有缓存,但是会有接口缓存的存在(因为伪造了
cache 中的数据),所以缓存策略跟页面缓存类似:

  1. 网络优先的方式,即优先获取网络上接口数据。当网络请求失败的时候,再去获取
    service worker 里之前缓存的接口数据
  2. 当网络加载成功之后,就更新 cache
    中对应的缓存接口数据,保证下次每次加载页面,都是上次访问的最新接口数据

所以代码就像这样(代码类似,不再赘述):

self.addEventListener(‘fetch’, (e) => { console.log(‘现在正在请求:’

  • e.request.url); const currentUrl = e.request.url; if
    (matchHtml(currentUrl)) { // … } else if (matchApi(currentUrl)) {
    const requestToCache = e.request.clone(); e.respondWith(
    fetch(requestToCache).then((response) => { if (!response ||
    response.status !== 200) { return response; } const responseToCache =
    response.clone(); caches.open(apiCacheName).then((cache) => {
    cache.put(requestToCache, responseToCache); }); return response;
    }).catch(function() { return caches.match(e.request); }) ); } });
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
self.addEventListener(‘fetch’, (e) => {
  console.log(‘现在正在请求:’ + e.request.url);
  const currentUrl = e.request.url;
  if (matchHtml(currentUrl)) {
    // …
  } else if (matchApi(currentUrl)) {
    const requestToCache = e.request.clone();
    e.respondWith(
      fetch(requestToCache).then((response) => {
        if (!response || response.status !== 200) {
          return response;
        }
        const responseToCache = response.clone();
        caches.open(apiCacheName).then((cache) => {
          cache.put(requestToCache, responseToCache);
        });
        return response;
      }).catch(function() {
        return caches.match(e.request);
      })
    );
  }
});

这里其实可以再进行优化的,比如在获取数据接口的时候,可以先读取缓存中的接口数据进行渲染,当真正的网络接口数据返回之后再进行替换,这样也能有效减少用户的首屏渲染时间。当然这可能会发生页面闪烁的效果,可以添加一些动画来进行过渡。

本地自动化工具

Athena本地编译工具是一个基于NodeJs的命令行工具,通过执行命令的方式来优化我们的开发流程,目前Athena的主要功能有

  • 自动创建项目、模块、页面、组件结构
  • 轻量组件化功能,根据组件加载情况生成资源依赖表
  • Sass/less 编译
  • 代码检查
  • CSS prefix等处理
  • CSS合并压缩,JS合并压缩
  • 自动生成雪碧图,自动多倍图,图片压缩
  • 字体文件压缩
  • 自定义图片转base64
  • 文件内联,可以内联样式及JS代码
  • 文件MD5戳,将文件进行使用MD5进行重命名
  • 本地预览,直接查看整个项目
  • 资源定位(图片等资源路径替换)
  • 生成CSS页面片,提供将页面引用的CSS/JS抽离成页面片的形式,方便管理CSS资源
  • 部署到预览机和开发机

其它问题

到现在为止,已经基本上可以实现 service worker
离线缓存应用的效果了,但是还有仍然存在一些问题:

创建项目结构

在执行创建命令时,Athena会从管理平台下载自定义好的项目模板,可以根据模板创建项目、模块、页面、和组件。Athena有四个创建命令:

通过执行 $ ath app demo 命令就可以生成定义好目录结构的项目。

图片 33

随后可以通过 $ ath module home来创建一个业务模块;

通过 $ ath page index 来创建页面;

通过 $ ath widget widgetName 来创建组件。

快速激活 service worker

默认情况下,页面的请求(fetch)不会通过 sw,除非它本身是通过 sw
获取的,也就是说,在安装 sw 之后,需要刷新页面才能有效果。sw
在安装成功并激活之前,不会响应 fetch或push等事件。

因为站点是单页面应用,这就导致了你在切换路由(没有刷新页面)的时候没有缓存接口数据,因为这时候
service worker 还没有开始工作,所以在加载 service worker
的时候需要快速地激活它。代码如下:

self.addEventListener(‘activate’, (e) => { console.log(‘Service
Worker 状态: activate’); const cachePromise = caches.keys().then((keys)
=> { return Promise.all(keys.map((key) => { if (key !== cacheName
&& key !== apiCacheName) { return caches.delete(key); } return null;
})); }); e.waitUntil(cachePromise); // 快速激活 sw,使其能够响应 fetch
事件 return self.clients.claim(); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
self.addEventListener(‘activate’, (e) => {
  console.log(‘Service Worker 状态: activate’);
  const cachePromise = caches.keys().then((keys) => {
    return Promise.all(keys.map((key) => {
      if (key !== cacheName && key !== apiCacheName) {
        return caches.delete(key);
      }
      return null;
    }));
  });
  e.waitUntil(cachePromise);
  // 快速激活 sw,使其能够响应 fetch 事件
  return self.clients.claim();
});

有的文章说还需要在 install
事件中添加 self.skipWaiting(); 来跳过等待时间,但是我在实践中发现即使不添加也可以正常激活
service worker,原因不详,有读者知道的话可以交流下。

现在当你第一次加载页面,跳转路由,立刻离线访问的页面,也可以顺利地加载页面了。

开发使用

不要强缓存 sw.js

用户每次访问页面的时候都会去重新获取
sw.js,根据文件内容跟之前的版本是否一致来判断 service worker
是否有更新。所以如果你对 sw.js
开启强缓存的话,就将陷入死循环,因为每次页面获取到的 sw.js
都是一样,这样就无法升级你的 service worker。

另外对 sw.js 开启强缓存也是没有必要的:

  1. 本身 sw.js
    文件本身就很小,浪费不了多少带宽,觉得浪费可以使用协商缓存,但额外增加开发负担
  2. sw.js 是在页面空闲的时候才去加载的,并不会影响用户首屏渲染速度
组件化

Athena中实现组件化主要是分为两种,一是针对纯HTML模板,通过扩展模板引擎方法实现,提供了组件化API
widget.load,它可以方法接收三个参数,第一个参数是widget的名称,后面两个参数是可选参数,第二个是向widget传递的一些参数,第三个是widget所属的模块,如果是本模块,可以不传例如

JavaScript

<%= widget.load(‘user’) %> <%= widget.load(‘user’, { param:
‘test’ }) %> <%= widget.load(‘user’, null, ‘gb’) %>

1
2
3
4
5
6
7
<%= widget.load(‘user’) %>
<%=
widget.load(‘user’, {
param: ‘test’
})
%>
<%= widget.load(‘user’, null, ‘gb’) %>

通过模板引擎编译,执行widget.load方法,可以实现加载模板,记录依赖关系的目的。

图片 34

二是针对不同语言的后端模板,通过实现各自的组件化框架来进行组件的加载,例如
PHP 下使用
<?= $widget->load('user', NULL, 'gb') ?>来进行组件加载,再通过代码扫描得出组件依赖关系。

避免改变 sw 的 URL

在 sw 中这么做是“最差实践”,要在原地址上修改 sw。

举个例子来说明为什么:

  1. index.html 注册了 sw-v1.js 作为 sw
  2. sw-v1.js 对 index.html 做了缓存,也就是缓存优先(offline-first)
  3. 你更新了 index.html 重新注册了在新地址的 sw sw-v2.js

如果你像上面那么做,用户永远也拿不到 sw-v2.js,因为 index.html 在
sw-v1.js 缓存中,这样的话,如果你想更新为 sw-v2.js,还需要更改原来的
sw-v1.js。

发表评论

电子邮件地址不会被公开。 必填项已用*标注