Moorez

Moorez 查看完整档案

天津编辑天津工业大学  |  软件 编辑腾讯  |  前端工程师 编辑 shenzekun.cn/ 编辑
编辑

个人动态

Moorez 赞了文章 · 2020-12-17

实用浏览器调试技巧(动画、节点删除、节点增加)

今天分享一些平时不常用,但总有一天你会用到的浏览器调试技巧。先来看一个H5页面,下面是地址
http://liticool.info/wsvist/i... (订阅号里无法跳转外部链接的话请复制此链接在微信中打开liticool.info/wsvist/index.html#/?sharekey=0a4384df4f65b6b47a74f76f8f3f3e1d&source=wxd56b51346bc8cbfc)我是在微信中看到这个H5场景的,看到了里面酷炫的动画。就想看看这个效果是怎么实现的,然后我把地址复制到了浏览器中,我的踩坑之路也就此开始了。

坑1:当我把链接复制到浏览器之后,发现在浏览器中一直显示一个loading。不能正常观看。

思考:为啥在微信中可以,在浏览中就不行呢?然后立马想到了用微信开发者工具打开,果然好使。可以看到酷炫的动画了。然后我F12打开调试工具,选取其中一个dom元素。准备看它的css代码。但是问题又来了。

坑2:dom元素一直在动,css代码也一直在变。

经过高人指点:点击关闭按钮旁边的三个点->Moretools->Animation.你会发现出现一个新的面板,点击那个暂停按钮。你会发现css动画停止了。如图。图片描述
坑3:dom动一会儿就被删除了。出现了新的场景(渲染了新的dom元素)这该如何是好.

动画虽然停止了,但是dom的删除是js控制的。js的还在运行。过几秒之后又页面又重新渲染了其他dom元素。怎么让js也停止执行呢,首先想到的是打个断点,但问题是去哪里打断点呢。打的早了dom还没渲染出来,打的地方不对代码可能不走那里。于是高人又出来指点了:可以在dom节点上打断点:选取一个dom元素,右键->Break On->node removal.这样在此dom节点被删除的时候,程序就会停下来。如图。图片描述
如此这般,我们就可以轻松找到想要看的css代码了。
补充:还有一种阻止js执行的办法,就是禁用javascript。还是点击三个点->Settings->Debugger->Disable JavaScript打勾就可以了。这样js就不会执行了,dom元素也不会被删掉了。如图:图片描述图片描述
彩蛋:介绍一个在浏览器中全局搜索代码的方法,点击Sources面板,会看到左侧有目录结构,右键目录结构->Search in all files。这样就可以在所有文件中搜索代码了。这个在开发中还是很有作用的。如图:图片描述
小扩展:还有一个场景:一个页面会从后台请求字体包,字体包会在某个时刻通过js加入到style标签中。但是我们不知道是哪段js代码执行了这个操作。现在想找到这个代码,应该怎么办呢?方法:给style标签打断点:右键style标签->Break On->subtree modifications 这样,在style中插入@font-face时,就会直接停在执行插入的那一段js代码处。如图图片描述

作者:易企秀——Hison
查看原文

赞 2 收藏 1 评论 0

Moorez 赞了文章 · 2020-08-24

关于 Error: No PostCSS Config found in 的错误

问题描述:

项目在本地运行不报错,上传到 GitHub 之后,再 clone 到本地,

npm install

安装完成之后再执行

npm run dev

这时报错 Error: No PostCSS Config found in...
本以为是 GitHub 上传的问题,后开又试了两回,发现问题依然存在,于是就开始网上寻找办法。

解决方案:

在项目根目录新建postcss.config.js文件,并对postcss进行配置:

module.exports = {  
  plugins: {  
    'autoprefixer': {browsers: 'last 5 version'}  
  }  
} 

好了,大功告成,试一试:

npm run dev

完美运行。

依然存在疑问:

项目在本地运行时本来不报错的,但是为什么上传到 GitHub 之后,再 clone 下来,再运行就得单独写一个 postcss.config.js 的文件并配置一下呢?

查看原文

赞 6 收藏 3 评论 2

Moorez 赞了文章 · 2020-07-25

从输入URL到页面加载的过程?如何由一道题完善自己的前端知识体系!

前言

见解有限,如有描述不当之处,请帮忙指出,如有错误,会及时修正。

为什么要梳理这篇文章?

最近恰好被问到这方面的问题,尝试整理后发现,这道题的覆盖面可以非常广,很适合作为一道承载知识体系的题目。

关于这道题目的吐槽暂且不提(这是一道被提到无数次的题,得到不少人的赞同,也被很多人反感),本文的目的是如何借助这道题梳理自己的前端知识体系!

窃认为,每一个前端人员,如果要往更高阶发展,必然会将自己的知识体系梳理一遍,没有牢固的知识体系,无法往更高处走!

展现形式:本文并不是将所有的知识点列一遍,而是偏向于分析+梳理

内容:在本文中只会梳理一些比较重要的前端向知识点,其它的可能会被省略

目标:本文的目标是梳理一个较为完整的前端向知识体系

本文是个人阶段性梳理知识体系的成果,然后加以修缮后发布成文章,因此并不确保适用于所有人员,但是,个人认为本文还是有一定参考价值的

另外,如有不同见解,可以一起讨论

----------超长文预警,需要花费大量时间。----------

本文适合有一定经验的前端人员,新手请规避

本文内容超多,建议先了解主干,然后分成多批次阅读。

本文是前端向,以前端领域的知识为重点

大纲

  • 对知识体系进行一次预评级
  • 为什么说知识体系如此重要?
  • 梳理主干流程
  • 从浏览器接收url到开启网络请求线程

    • 多进程的浏览器
    • 多线程的浏览器内核
    • 解析URL
    • 网络请求都是单独的线程
    • 更多
  • 开启网络线程到发出一个完整的http请求

    • DNS查询得到IP
    • tcp/ip请求
    • 五层因特网协议栈
  • 从服务器接收到请求到对应后台接收到请求

    • 负载均衡
    • 后台的处理
  • 后台和前台的http交互

    • http报文结构
    • cookie以及优化
    • gzip压缩
    • 长连接与短连接
    • http 2.0
    • https
  • 单独拎出来的缓存问题,http的缓存

    • 强缓存与弱缓存
    • 缓存头部简述
    • 头部的区别
  • 解析页面流程

    • 流程简述
    • HTML解析,构建DOM
    • 生成CSS规则
    • 构建渲染树
    • 渲染
    • 简单层与复合层
    • Chrome中的调试
    • 资源外链的下载
    • loaded和domcontentloaded
  • CSS的可视化格式模型

    • 包含块(Containing Block)
    • 控制框(Controlling Box)
    • BFC(Block Formatting Context)
    • IFC(Inline Formatting Context)
    • 其它
  • JS引擎解析过程

    • JS的解释阶段
    • JS的预处理阶段
    • JS的执行阶段
    • 回收机制
  • 其它
  • 总结

对知识体系进行一次预评级

看到这道题目,不借助搜索引擎,自己的心里是否有一个答案?

这里,以目前的经验(了解过一些处于不同阶段的相关前端人员的情况),大概有以下几种情况:(以下都是以点见面,实际上不同阶段人员一般都会有其它的隐藏知识点的)

level1:

完全没什么概念的,支支吾吾的回答,一般就是这种水平(大致形象点描述):

  • 浏览器发起请求,服务端返回数据,然后前端解析成网页,执行脚本。。。

这类人员一般都是:

  • 萌新(刚接触前端的,包括0-6个月都有可能有这种回答)
  • 沉淀人员(就是那种可能已经接触了前端几年,但是仍然处于初级阶段的那种。。。)

当然了,后者一般还会偶尔提下http后台浏览器渲染js引擎等等关键字,但基本都是一详细的问就不知道了。。。

level2:

已经有初步概念,但是可能没有完整梳理过,导致无法形成一个完整的体系,或者是很多细节都不会展开,大概是这样子的:(可能符合若干条)

  • 知道浏览器输入url后会有http请求这个概念
  • 有后台这个概念,大致知道前后端的交互,知道前后端只要靠http报文通信
  • 知道浏览器接收到数据后会进行解析,有一定概念,但是具体流程不熟悉(如render树构建流程,layout、paint,复合层与简单层,常用优化方案等不是很熟悉)
  • 对于js引擎的解析流程有一定概念,但是细节不熟悉(如具体的形参,函数,变量提升,执行上下文以及VO、AO、作用域链,回收机制等概念不是很熟悉)
  • 如可能知道一些http规范初步概念,但是不熟悉(如http报文结构,常用头部,缓存机制,http2.0,https等特性,跨域与web安全等不是很熟悉)

到这里,看到这上面一大堆的概念后,心里应该也会有点底了。。。

实际上,大部分的前端人员可能都处于level2,但是,跳出这个阶段并不容易,一般需要积累,不断学习,才能水到渠成

这类人员一般都是:

  • 工作1-3年左右的普通人员(占大多数,而且大多数人员工作3年左右并没有实质上的提升)
  • 工作3年以上的老人(这部分人大多都业务十分娴熟,一个当好几个用,但是,基础比较薄弱,可能没有尝试写过框架、组件、脚手架等)

大部分的初中级都陷在这个阶段,如果要突破,不断学习,积累,自然能水到渠成,打通任督二脉

level3:

基本能到这一步的,不是高阶就是接近高阶,因为很多概念并不是靠背就能理解的,而要理解这么多,需形成体系,一般都需要积累,非一日之功。

一般包括什么样的回答呢?(这里就以自己的简略回答进行举例),一般这个阶段的人员都会符合若干条(不一定全部,当然可能还有些是这里遗漏的):

  • 首先略去那些键盘输入、和操作系统交互、以及屏幕显示原理、网卡等硬件交互之类的(前端向中,很多硬件原理暂时略去。。。)
  • 对浏览器模型有整体概念,知道浏览器是多进程的,浏览器内核是多线程的,清楚进程与线程之间得区别,以及输入url后会开一个新的网络线程
  • 对从开启网络线程到发出一个完整的http请求中间的过程有所了解(如dns查询,tcp/ip链接,五层因特网协议栈等等,以及一些优化方案,如dns-prefetch
  • 对从服务器接收到请求到对应后台接收到请求有一定了解(如负载均衡,安全拦截以及后台代码处理等)
  • 对后台和前台的http交互熟悉(包括http报文结构,场景头部,cookie,跨域,web安全,http缓存,http2.0,https等)
  • 对浏览器接收到http数据包后的解析流程熟悉(包括解析html,词法分析然后解析成dom树、解析css生成css规则树、合并成render树,然后layout、painting渲染、里面可能还包括复合图层的合成、GPU绘制、外链处理、加载顺序等)
  • 对JS引擎解析过程熟悉(包括JS的解释,预处理,执行上下文,VO,作用域链,this,回收机制等)

可以看到,上述包括了一大堆的概念,仅仅是偏前端向,而且没有详细展开,就已经如此之多的概念了,所以,个人认为如果没有自己的见解,没有形成自己的知识体系,仅仅是看看,背背是没用的,过一段时间就会忘光了。

再说下一般这个阶段的都可能是什么样的人吧。(不一定准确,这里主要是靠少部分现实以及大部分推测得出)

  • 工作2年以上的前端(基本上如果按正常进度的话,至少接触前端两年左右才会开始走向高阶,当然,现在很多都是上学时就开始学了的,还有部分是天赋异禀,不好预估。。。)
  • 或者是已经十分熟悉其它某门语言,再转前端的人(基本上是很快就可以将前端水准提升上去)

一般符合这个条件的都会有各种隐藏属性(如看过各大框架、组件的源码,写过自己的组件、框架、脚手架,做过大型项目,整理过若干精品博文等)

level4:

由于本人层次尚未达到,所以大致说下自己的见解吧。

一般这个层次,很多大佬都并不仅仅是某个技术栈了,而是成为了技术专家,技术leader之类的角色。所以仅仅是回答某个技术问题已经无法看出水准了,
可能更多的要看架构,整体把控,大型工程构建能力等等

不过,对于某些执着于技术的大佬,大概会有一些回答吧:(猜的)

  • 从键盘谈起到系统交互,从浏览器到CPU,从调度机制到系统内核,从数据请求到二进制、汇编,从GPU绘图到LCD显示,然后再分析系统底层的进程、内存等等

总之,从软件到硬件,到材料,到分子,原子,量子,薛定谔的猫,人类起源,宇宙大爆炸,平行宇宙?感觉都毫无违和感。。。

这点可以参考下本题的原始出处:

http://fex.baidu.com/blog/2014/05/what-happen/

为什么说知识体系如此重要?

为什么说知识体系如此重要呢?这里举几个例子

假设有被问到这样一道题目(随意想到的一个):

  • 如何理解getComputedStyle

在尚未梳理知识体系前,大概会这样回答:

  • 普通版本:getComputedStyle会获取当前元素所有最终使用的CSS属性值(最终计算后的结果),通过window.getComputedStyle等价于document.defaultView.getComputedStyle调用
  • 详细版本:window.getComputedStyle(elem, null).getPropertyValue("height")可能的值为100px,而且,就算是css上写的是inheritgetComputedStyle也会把它最终计算出来的。不过注意,如果元素的背景色透明,那么getComputedStyle获取出来的就是透明的这个背景(因为透明本身也是有效的),而不会是父节点的背景。所以它不一定是最终显示的颜色。

就这个API来说,上述的回答已经比较全面了。

但是,其实它是可以继续延伸的。

譬如现在会这样回答:

  • getComputedStyle会获取当前元素所有最终使用的CSS属性值,window.document.defaultView.等价...
  • getComputedStyle会引起回流,因为它需要获取祖先节点的一些信息进行计算(譬如宽高等),所以用的时候慎用,回流会引起性能问题。然后合适的话会将话题引导回流,重绘,浏览器渲染原理等等。当然也可以列举一些其它会引发回流的操作,如offsetXXXscrollXXXclientXXXcurrentStyle等等

再举一个例子:

  • visibility: hiddendisplay: none的区别

可以如下回答:

  • 普通回答,一个隐藏,但占据位置,一个隐藏,不占据位置
  • 进一步,display由于隐藏后不占据位置,所以造成了dom树的改变,会引发回流,代价较大
  • 再进一步,当一个页面某个元素经常需要切换display时如何优化,一般会用复合层优化,或者要求低一点用absolute让其脱离普通文档流也行。然后可以将话题引到普通文档流,absolute文档流,复合图层的区别,
  • 再进一步可以描述下浏览器渲染原理以及复合图层和普通图层的绘制区别(复合图层单独分配资源,独立绘制,性能提升,但是不能过多,还有隐式合成等等)

上面这些大概就是知识系统化后的回答,会更全面,容易由浅入深,而且一有机会就可以往更底层挖

前端向知识的重点

此部分的内容是站在个人视角分析的,并不是说就一定是正确答案

首先明确,计算机方面的知识是可以无穷无尽的挖的,而本文的重点是梳理前端向的重点知识

对于前端向(这里可能没有提到node.js之类的,更多的是指客户端前端),这里将知识点按重要程度划分成以下几大类:

  • 核心知识,必须掌握的,也是最基础的,譬如浏览器模型,渲染原理,JS解析过程,JS运行机制等,作为骨架来承载知识体系
  • 重点知识,往往每一块都是一个知识点,而且这些知识点都很重要,譬如http相关,web安全相关,跨域处理等
  • 拓展知识,这一块可能更多的是了解,稍微实践过,但是认识上可能没有上面那么深刻,譬如五层因特网协议栈,hybrid模式,移动原生开发,后台相关等等(当然,在不同领域,可能有某些知识就上升到重点知识层次了,譬如hybrid开发时,懂原生开发是很重要的)

为什么要按上面这种方式划分?

这大概与个人的技术成长有关。

记得最开始学前端知识时,是一点一点的积累,一个知识点一个知识点的攻克。

就这样,虽然在很长一段时间内积累了不少的知识,但是,总是无法将它串联到一起。每次梳理时都是很分散的,无法保持思路连贯性。

直到后来,在将浏览器渲染原理、JS运行机制、JS引擎解析流程梳理一遍后,感觉就跟打通了任督二脉一样,有了一个整体的架构,以前的知识点都连贯起来了。

梳理出了一个知识体系,以后就算再学新的知识,也会尽量往这个体系上靠拢,环环相扣,更容易理解,也更不容易遗忘

梳理主干流程

回到这道题上,如何回答呢?先梳理一个骨架

知识体系中,最重要的是骨架,脉络。有了骨架后,才方便填充细节。所以,先梳理下主干流程:

1. 从浏览器接收url到开启网络请求线程(这一部分可以展开浏览器的机制以及进程与线程之间的关系)

2. 开启网络线程到发出一个完整的http请求(这一部分涉及到dns查询,tcp/ip请求,五层因特网协议栈等知识)

3. 从服务器接收到请求到对应后台接收到请求(这一部分可能涉及到负载均衡,安全拦截以及后台内部的处理等等)

4. 后台和前台的http交互(这一部分包括http头部、响应码、报文结构、cookie等知识,可以提下静态资源的cookie优化,以及编码解码,如gzip压缩等)

5. 单独拎出来的缓存问题,http的缓存(这部分包括http缓存头部,etag,catch-control等)

6. 浏览器接收到http数据包后的解析流程(解析html-词法分析然后解析成dom树、解析css生成css规则树、合并成render树,然后layout、painting渲染、复合图层的合成、GPU绘制、外链资源的处理、loaded和domcontentloaded等)

7. CSS的可视化格式模型(元素的渲染规则,如包含块,控制框,BFC,IFC等概念)

8. JS引擎解析过程(JS的解释阶段,预处理阶段,执行阶段生成执行上下文,VO,作用域链、回收机制等等)

9. 其它(可以拓展不同的知识模块,如跨域,web安全,hybrid模式等等内容)

梳理出主干骨架,然后就需要往骨架上填充细节内容

从浏览器接收url到开启网络请求线程

这一部分展开的内容是:浏览器进程/线程模型,JS的运行机制

多进程的浏览器

浏览器是多进程的,有一个主控进程,以及每一个tab页面都会新开一个进程(某些情况下多个tab会合并进程)

进程可能包括主控进程,插件进程,GPU,tab页(浏览器内核)等等

  • Browser进程:浏览器的主进程(负责协调、主控),只有一个
  • 第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建
  • GPU进程:最多一个,用于3D绘制
  • 浏览器渲染进程(内核):默认每个Tab页面一个进程,互不影响,控制页面渲染,脚本执行,事件处理等(有时候会优化,如多个空白tab会合并成一个进程)

如下图:

多线程的浏览器内核

每一个tab页面可以看作是浏览器内核进程,然后这个进程是多线程的,它有几大类子线程

  • GUI线程
  • JS引擎线程
  • 事件触发线程
  • 定时器线程
  • 网络请求线程

可以看到,里面的JS引擎是内核进程中的一个线程,这也是为什么常说JS引擎是单线程的

解析URL

输入URL后,会进行解析(URL的本质就是统一资源定位符)

URL一般包括几大部分:

  • protocol,协议头,譬如有http,ftp等
  • host,主机域名或IP地址
  • port,端口号
  • path,目录路径
  • query,即查询参数
  • fragment,即#后的hash值,一般用来定位到某个位置

网络请求都是单独的线程

每次网络请求时都需要开辟单独的线程进行,譬如如果URL解析到http协议,就会新建一个网络线程去处理资源下载

因此浏览器会根据解析出得协议,开辟一个网络线程,前往请求资源(这里,暂时理解为是浏览器内核开辟的,如有错误,后续修复)

更多

由于篇幅关系,这里就大概介绍一个主干流程,关于浏览器的进程机制,更多可以参考以前总结的一篇文章(因为内容实在过多,里面包括JS运行机制,进程线程的详解)

从浏览器多进程到JS单线程,JS运行机制最全面的一次梳理

开启网络线程到发出一个完整的http请求

这一部分主要内容包括:dns查询,tcp/ip请求构建,五层因特网协议栈等等

仍然是先梳理主干,有些详细的过程不展开(因为展开的话内容过多)

DNS查询得到IP

如果输入的是域名,需要进行dns解析成IP,大致流程:

  • 如果浏览器有缓存,直接使用浏览器缓存,否则使用本机缓存,再没有的话就是用host
  • 如果本地没有,就向dns域名服务器查询(当然,中间可能还会经过路由,也有缓存等),查询到对应的IP

注意,域名查询时有可能是经过了CDN调度器的(如果有cdn存储功能的话)

而且,需要知道dns解析是很耗时的,因此如果解析域名过多,会让首屏加载变得过慢,可以考虑dns-prefetch优化

这一块可以深入展开,具体请去网上搜索,这里就不占篇幅了(网上可以看到很详细的解答)

tcp/ip请求

http的本质就是tcp/ip请求

需要了解3次握手规则建立连接以及断开连接时的四次挥手

tcp将http长报文划分为短报文,通过三次握手与服务端建立连接,进行可靠传输

三次握手的步骤:(抽象派)

客户端:hello,你是server么?
服务端:hello,我是server,你是client么
客户端:yes,我是client

建立连接成功后,接下来就正式传输数据

然后,待到断开连接时,需要进行四次挥手(因为是全双工的,所以需要四次挥手)

四次挥手的步骤:(抽象派)

主动方:我已经关闭了向你那边的主动通道了,只能被动接收了
被动方:收到通道关闭的信息
被动方:那我也告诉你,我这边向你的主动通道也关闭了
主动方:最后收到数据,之后双方无法通信

tcp/ip的并发限制

浏览器对同一域名下并发的tcp连接是有限制的(2-10个不等)

而且在http1.0中往往一个资源下载就需要对应一个tcp/ip请求

所以针对这个瓶颈,又出现了很多的资源优化方案

get和post的区别

get和post虽然本质都是tcp/ip,但两者除了在http层面外,在tcp/ip层面也有区别。

get会产生一个tcp数据包,post两个

具体就是:

  • get请求时,浏览器会把headersdata一起发送出去,服务器响应200(返回数据),
  • post请求时,浏览器先发送headers,服务器响应100 continue

浏览器再发送data,服务器响应200(返回数据)。

再说一点,这里的区别是specification(规范)层面,而不是implementation(对规范的实现)

五层因特网协议栈

其实这个概念挺难记全的,记不全没关系,但是要有一个整体概念

其实就是一个概念: 从客户端发出http请求到服务器接收,中间会经过一系列的流程。

简括就是:

从应用层的发送http请求,到传输层通过三次握手建立tcp/ip连接,再到网络层的ip寻址,再到数据链路层的封装成帧,最后到物理层的利用物理介质传输。

当然,服务端的接收就是反过来的步骤

五层因特网协议栈其实就是:

1.应用层(dns,http) DNS解析成IP并发送http请求

2.传输层(tcp,udp) 建立tcp连接(三次握手)

3.网络层(IP,ARP) IP寻址

4.数据链路层(PPP) 封装成帧

5.物理层(利用物理介质传输比特流) 物理传输(然后传输的时候通过双绞线,电磁波等各种介质)

当然,其实也有一个完整的OSI七层框架,与之相比,多了会话层、表示层。

OSI七层框架:物理层数据链路层网络层传输层会话层表示层应用层

表示层:主要处理两个通信系统中交换信息的表示方式,包括数据格式交换,数据加密与解密,数据压缩与终端类型转换等

会话层:它具体管理不同用户和进程之间的对话,如控制登陆和注销过程

从服务器接收到请求到对应后台接收到请求

服务端在接收到请求时,内部会进行很多的处理

这里由于不是专业的后端分析,所以只是简单的介绍下,不深入

负载均衡

对于大型的项目,由于并发访问量很大,所以往往一台服务器是吃不消的,所以一般会有若干台服务器组成一个集群,然后配合反向代理实现负载均衡

当然了,负载均衡不止这一种实现方式,这里不深入...

简单的说:

用户发起的请求都指向调度服务器(反向代理服务器,譬如安装了nginx控制负载均衡),然后调度服务器根据实际的调度算法,分配不同的请求给对应集群中的服务器执行,然后调度器等待实际服务器的HTTP响应,并将它反馈给用户

后台的处理

一般后台都是部署到容器中的,所以一般为:

  • 先是容器接受到请求(如tomcat容器)
  • 然后对应容器中的后台程序接收到请求(如java程序)
  • 然后就是后台会有自己的统一处理,处理完后响应响应结果

概括下:

  • 一般有的后端是有统一的验证的,如安全拦截,跨域验证
  • 如果这一步不符合规则,就直接返回了相应的http报文(如拒绝请求等)
  • 然后当验证通过后,才会进入实际的后台代码,此时是程序接收到请求,然后执行(譬如查询数据库,大量计算等等)
  • 等程序执行完毕后,就会返回一个http响应包(一般这一步也会经过多层封装)
  • 然后就是将这个包从后端发送到前端,完成交互

后台和前台的http交互

前后端交互时,http报文作为信息的载体

所以http是一块很重要的内容,这一部分重点介绍它

http报文结构

报文一般包括了:通用头部请求/响应头部请求/响应体

通用头部

这也是开发人员见过的最多的信息,包括如下:

Request Url: 请求的web服务器地址

Request Method: 请求方式
(Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE)

Status Code: 请求的返回状态码,如200代表成功

Remote Address: 请求的远程服务器地址(会转为IP)

譬如,在跨域拒绝时,可能是method为options,状态码为404/405等(当然,实际上可能的组合有很多)

其中,Method的话一般分为两批次:

HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法。
以及几种Additional Request Methods:PUT、DELETE、LINK、UNLINK

HTTP1.1定义了八种请求方法:GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

HTTP 1.0定义参考:https://tools.ietf.org/html/rfc1945

HTTP 1.1定义参考:https://tools.ietf.org/html/rfc2616

这里面最常用到的就是状态码,很多时候都是通过状态码来判断,如(列举几个最常见的):

200——表明该请求被成功地完成,所请求的资源发送回客户端
304——自从上次请求后,请求的网页未修改过,请客户端使用本地缓存
400——客户端请求有错(譬如可以是安全模块拦截)
401——请求未经授权
403——禁止访问(譬如可以是未登录时禁止)
404——资源未找到
500——服务器内部错误
503——服务不可用
...

再列举下大致不同范围状态的意义

1xx——指示信息,表示请求已接收,继续处理
2xx——成功,表示请求已被成功接收、理解、接受
3xx——重定向,要完成请求必须进行更进一步的操作
4xx——客户端错误,请求有语法错误或请求无法实现
5xx——服务器端错误,服务器未能实现合法的请求

总之,当请求出错时,状态码能帮助快速定位问题,完整版本的状态可以自行去互联网搜索

请求/响应头部

请求和响应头部也是分析时常用到的

常用的请求头部(部分):

Accept: 接收类型,表示浏览器支持的MIME类型
(对标服务端返回的Content-Type)
Accept-Encoding:浏览器支持的压缩类型,如gzip等,超出类型不能接收
Content-Type:客户端发送出去实体内容的类型
Cache-Control: 指定请求和响应遵循的缓存机制,如no-cache
If-Modified-Since:对应服务端的Last-Modified,用来匹配看文件是否变动,只能精确到1s之内,http1.0中
Expires:缓存控制,在这个时间内不会请求,直接使用缓存,http1.0,而且是服务端时间
Max-age:代表资源在本地缓存多少秒,有效时间内不会请求,而是使用缓存,http1.1中
If-None-Match:对应服务端的ETag,用来匹配文件内容是否改变(非常精确),http1.1中
Cookie: 有cookie并且同域访问时会自动带上
Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive
Host:请求的服务器URL
Origin:最初的请求是从哪里发起的(只会精确到端口),Origin比Referer更尊重隐私
Referer:该页面的来源URL(适用于所有类型的请求,会精确到详细页面地址,csrf拦截常用到这个字段)
User-Agent:用户客户端的一些必要信息,如UA头部等

常用的响应头部(部分):

Access-Control-Allow-Headers: 服务器端允许的请求Headers
Access-Control-Allow-Methods: 服务器端允许的请求方法
Access-Control-Allow-Origin: 服务器端允许的请求Origin头部(譬如为*)
Content-Type:服务端返回的实体内容的类型
Date:数据从服务器发送的时间
Cache-Control:告诉浏览器或其他客户,什么环境可以安全的缓存文档
Last-Modified:请求资源的最后修改时间
Expires:应该在什么时候认为文档已经过期,从而不再缓存它
Max-age:客户端的本地资源应该缓存多少秒,开启了Cache-Control后有效
ETag:请求变量的实体标签的当前值
Set-Cookie:设置和页面关联的cookie,服务器通过这个头部把cookie传给客户端
Keep-Alive:如果客户端有keep-alive,服务端也会有响应(如timeout=38)
Server:服务器的一些相关信息

一般来说,请求头部和响应头部是匹配分析的。

譬如,请求头部的Accept要和响应头部的Content-Type匹配,否则会报错

譬如,跨域请求时,请求头部的Origin要匹配响应头部的Access-Control-Allow-Origin,否则会报跨域错误

譬如,在使用缓存时,请求头部的If-Modified-SinceIf-None-Match分别和响应头部的Last-ModifiedETag对应

还有很多的分析方法,这里不一一赘述

请求/响应实体

http请求时,除了头部,还有消息实体,一般来说

请求实体中会将一些需要的参数都放入进入(用于post请求)。

譬如实体中可以放参数的序列化形式(a=1&b=2这种),或者直接放表单对象(Form Data对象,上传时可以夹杂参数以及文件),等等

而一般响应实体中,就是放服务端需要传给客户端的内容

一般现在的接口请求时,实体中就是对于的信息的json格式,而像页面请求这种,里面就是直接放了一个html字符串,然后浏览器自己解析并渲染。

CRLF

CRLF(Carriage-Return Line-Feed),意思是回车换行,一般作为分隔符存在

请求头和实体消息之间有一个CRLF分隔,响应头部和响应实体之间用一个CRLF分隔

一般来说(分隔符类别):

CRLF->Windows-style
LF->Unix Style
CR->Mac Style

如下图是对某请求的http报文结构的简要分析

cookie以及优化

cookie是浏览器的一种本地存储方式,一般用来帮助客户端和服务端通信的,常用来进行身份校验,结合服务端的session使用。

场景如下(简述):

在登陆页面,用户登陆了

此时,服务端会生成一个session,session中有对于用户的信息(如用户名、密码等)

然后会有一个sessionid(相当于是服务端的这个session对应的key)

然后服务端在登录页面中写入cookie,值就是:jsessionid=xxx

然后浏览器本地就有这个cookie了,以后访问同域名下的页面时,自动带上cookie,自动检验,在有效时间内无需二次登陆。

上述就是cookie的常用场景简述(当然了,实际情况下得考虑更多因素)

一般来说,cookie是不允许存放敏感信息的(千万不要明文存储用户名、密码),因为非常不安全,如果一定要强行存储,首先,一定要在cookie中设置httponly(这样就无法通过js操作了),另外可以考虑rsa等非对称加密(因为实际上,浏览器本地也是容易被攻克的,并不安全)

另外,由于在同域名的资源请求时,浏览器会默认带上本地的cookie,针对这种情况,在某些场景下是需要优化的。

譬如以下场景:

客户端在域名A下有cookie(这个可以是登陆时由服务端写入的)

然后在域名A下有一个页面,页面中有很多依赖的静态资源(都是域名A的,譬如有20个静态资源)

此时就有一个问题,页面加载,请求这些静态资源时,浏览器会默认带上cookie

也就是说,这20个静态资源的http请求,每一个都得带上cookie,而实际上静态资源并不需要cookie验证

此时就造成了较为严重的浪费,而且也降低了访问速度(因为内容更多了)

当然了,针对这种场景,是有优化方案的(多域名拆分)。具体做法就是:

  • 将静态资源分组,分别放到不同的域名下(如static.base.com
  • page.base.com(页面所在域名)下请求时,是不会带上static.base.com域名的cookie的,所以就避免了浪费

说到了多域名拆分,这里再提一个问题,那就是:

  • 在移动端,如果请求的域名数过多,会降低请求速度(因为域名整套解析流程是很耗费时间的,而且移动端一般带宽都比不上pc)
  • 此时就需要用到一种优化方案:dns-prefetch(让浏览器空闲时提前解析dns域名,不过也请合理使用,勿滥用)

关于cookie的交互,可以看下图总结

gzip压缩

首先,明确gzip是一种压缩格式,需要浏览器支持才有效(不过一般现在浏览器都支持),
而且gzip压缩效率很好(高达70%左右)

然后gzip一般是由apachetomcat等web服务器开启

当然服务器除了gzip外,也还会有其它压缩格式(如deflate,没有gzip高效,且不流行)

所以一般只需要在服务器上开启了gzip压缩,然后之后的请求就都是基于gzip压缩格式的,
非常方便。

长连接与短连接

首先看tcp/ip层面的定义:

  • 长连接:一个tcp/ip连接上可以连续发送多个数据包,在tcp连接保持期间,如果没有数据包发送,需要双方发检测包以维持此连接,一般需要自己做在线维持(类似于心跳包)
  • 短连接:通信双方有数据交互时,就建立一个tcp连接,数据发送完成后,则断开此tcp连接

然后在http层面:

  • http1.0中,默认使用的是短连接,也就是说,浏览器没进行一次http操作,就建立一次连接,任务结束就中断连接,譬如每一个静态资源请求时都是一个单独的连接
  • http1.1起,默认使用长连接,使用长连接会有这一行Connection: keep-alive,在长连接的情况下,当一个网页打开完成后,客户端和服务端之间用于传输http的tcp连接不会关闭,如果客户端再次访问这个服务器的页面,会继续使用这一条已经建立的连接

注意: keep-alive不会永远保持,它有一个持续时间,一般在服务器中配置(如apache),另外长连接需要客户端和服务器都支持时才有效

http 2.0

http2.0不是https,它相当于是http的下一代规范(譬如https的请求可以是http2.0规范的)

然后简述下http2.0与http1.1的显著不同点:

  • http1.1中,每请求一个资源,都是需要开启一个tcp/ip连接的,所以对应的结果是,每一个资源对应一个tcp/ip请求,由于tcp/ip本身有并发数限制,所以当资源一多,速度就显著慢下来
  • http2.0中,一个tcp/ip请求可以请求多个资源,也就是说,只要一次tcp/ip请求,就可以请求若干个资源,分割成更小的帧请求,速度明显提升。

所以,如果http2.0全面应用,很多http1.1中的优化方案就无需用到了(譬如打包成精灵图,静态资源多域名拆分等)

然后简述下http2.0的一些特性:

  • 多路复用(即一个tcp/ip连接可以请求多个资源)
  • 首部压缩(http头部压缩,减少体积)
  • 二进制分帧(在应用层跟传送层之间增加了一个二进制分帧层,改进传输性能,实现低延迟和高吞吐量)
  • 服务器端推送(服务端可以对客户端的一个请求发出多个响应,可以主动通知客户端)
  • 请求优先级(如果流被赋予了优先级,它就会基于这个优先级来处理,由服务器决定需要多少资源来处理该请求。)

https

https就是安全版本的http,譬如一些支付等操作基本都是基于https的,因为http请求的安全系数太低了。

简单来看,https与http的区别就是: 在请求前,会建立ssl链接,确保接下来的通信都是加密的,无法被轻易截取分析

一般来说,如果要将网站升级成https,需要后端支持(后端需要申请证书等),然后https的开销也比http要大(因为需要额外建立安全链接以及加密等),所以一般来说http2.0配合https的体验更佳(因为http2.0更快了)

一般来说,主要关注的就是SSL/TLS的握手流程,如下(简述):

1. 浏览器请求建立SSL链接,并向服务端发送一个随机数–Client random和客户端支持的加密方法,比如RSA加密,此时是明文传输。 

2. 服务端从中选出一组加密算法与Hash算法,回复一个随机数–Server random,并将自己的身份信息以证书的形式发回给浏览器
(证书里包含了网站地址,非对称加密的公钥,以及证书颁发机构等信息)

3. 浏览器收到服务端的证书后
    
    - 验证证书的合法性(颁发机构是否合法,证书中包含的网址是否和正在访问的一样),如果证书信任,则浏览器会显示一个小锁头,否则会有提示
    
    - 用户接收证书后(不管信不信任),浏览会生产新的随机数–Premaster secret,然后证书中的公钥以及指定的加密方法加密`Premaster secret`,发送给服务器。
    
    - 利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key-`session key`
    
    - 使用约定好的HASH算法计算握手消息,并使用生成的`session key`对消息进行加密,最后将之前生成的所有信息发送给服务端。 
    
4. 服务端收到浏览器的回复

    - 利用已知的加解密方式与自己的私钥进行解密,获取`Premaster secret`
    
    - 和浏览器相同规则生成`session key`
    
    - 使用`session key`解密浏览器发来的握手消息,并验证Hash是否与浏览器发来的一致
    
    - 使用`session key`加密一段握手消息,发送给浏览器
    
5. 浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,

之后所有的https通信数据将由之前浏览器生成的session key并利用对称加密算法进行加密

这里放一张图(来源:阮一峰-图解SSL/TLS协议

单独拎出来的缓存问题,http的缓存

前后端的http交互中,使用缓存能很大程度上的提升效率,而且基本上对性能有要求的前端项目都是必用缓存的

强缓存与弱缓存

缓存可以简单的划分成两种类型:强缓存200 from cache)与协商缓存304

区别简述如下:

  • 强缓存(200 from cache)时,浏览器如果判断本地缓存未过期,就直接使用,无需发起http请求
  • 协商缓存(304)时,浏览器会向服务端发起http请求,然后服务端告诉浏览器文件未改变,让浏览器使用本地缓存

对于协商缓存,使用Ctrl + F5强制刷新可以使得缓存无效

但是对于强缓存,在未过期时,必须更新资源路径才能发起新的请求(更改了路径相当于是另一个资源了,这也是前端工程化中常用到的技巧)

缓存头部简述

上述提到了强缓存和协商缓存,那它们是怎么区分的呢?

答案是通过不同的http头部控制

先看下这几个头部:

If-None-Match/E-tag、If-Modified-Since/Last-Modified、Cache-Control/Max-Age、Pragma/Expires

这些就是缓存中常用到的头部,这里不展开。仅列举下大致使用。

属于强缓存控制的:

(http1.1)Cache-Control/Max-Age
(http1.0)Pragma/Expires

注意:Max-Age不是一个头部,它是Cache-Control头部的值

属于协商缓存控制的:

(http1.1)If-None-Match/E-tag
(http1.0)If-Modified-Since/Last-Modified

可以看到,上述有提到http1.1http1.0,这些不同的头部是属于不同http时期的

再提一点,其实HTML页面中也有一个meta标签可以控制缓存方案-Pragma

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

不过,这种方案还是比较少用到,因为支持情况不佳,譬如缓存代理服务器肯定不支持,所以不推荐

头部的区别

首先明确,http的发展是从http1.0到http1.1

而在http1.1中,出了一些新内容,弥补了http1.0的不足。

http1.0中的缓存控制:

  • Pragma:严格来说,它不属于专门的缓存控制头部,但是它设置no-cache时可以让本地强缓存失效(属于编译控制,来实现特定的指令,主要是因为兼容http1.0,所以以前又被大量应用)
  • Expires:服务端配置的,属于强缓存,用来控制在规定的时间之前,浏览器不会发出请求,而是直接使用本地缓存,注意,Expires一般对应服务器端时间,如Expires:Fri, 30 Oct 1998 14:19:41
  • If-Modified-Since/Last-Modified:这两个是成对出现的,属于协商缓存的内容,其中浏览器的头部是If-Modified-Since,而服务端的是Last-Modified,它的作用是,在发起请求时,如果If-Modified-SinceLast-Modified匹配,那么代表服务器资源并未改变,因此服务端不会返回资源实体,而是只返回头部,通知浏览器可以使用本地缓存。Last-Modified,顾名思义,指的是文件最后的修改时间,而且只能精确到1s以内

http1.1中的缓存控制:

  • Cache-Control:缓存控制头部,有no-cache、max-age等多种取值
  • Max-Age:服务端配置的,用来控制强缓存,在规定的时间之内,浏览器无需发出请求,直接使用本地缓存,注意,Max-Age是Cache-Control头部的值,不是独立的头部,譬如Cache-Control: max-age=3600,而且它值得是绝对时间,由浏览器自己计算
  • If-None-Match/E-tag:这两个是成对出现的,属于协商缓存的内容,其中浏览器的头部是If-None-Match,而服务端的是E-tag,同样,发出请求后,如果If-None-MatchE-tag匹配,则代表内容未变,通知浏览器使用本地缓存,和Last-Modified不同,E-tag更精确,它是类似于指纹一样的东西,基于FileEtag INode Mtime Size生成,也就是说,只要文件变,指纹就会变,而且没有1s精确度的限制。

Max-Age相比Expires?

Expires使用的是服务器端的时间

但是有时候会有这样一种情况-客户端时间和服务端不同步

那这样,可能就会出问题了,造成了浏览器本地的缓存无用或者一直无法过期

所以一般http1.1后不推荐使用Expires

Max-Age使用的是客户端本地时间的计算,因此不会有这个问题

因此推荐使用Max-Age

注意,如果同时启用了Cache-ControlExpiresCache-Control优先级高。

E-tag相比Last-Modified?

Last-Modified

  • 表明服务端的文件最后何时改变的
  • 它有一个缺陷就是只能精确到1s,
  • 然后还有一个问题就是有的服务端的文件会周期性的改变,导致缓存失效

E-tag

  • 是一种指纹机制,代表文件相关指纹
  • 只有文件变才会变,也只要文件变就会变,
  • 也没有精确时间的限制,只要文件一遍,立马E-tag就不一样了

如果同时带有E-tagLast-Modified,服务端会优先检查E-tag

各大缓存头部的整体关系如下图

解析页面流程

前面有提到http交互,那么接下来就是浏览器获取到html,然后解析,渲染

这部分很多都参考了网上资源,特别是图片,参考了来源中的文章

流程简述

浏览器内核拿到内容后,渲染步骤大致可以分为以下几步:

1. 解析HTML,构建DOM树

2. 解析CSS,生成CSS规则树

3. 合并DOM树和CSS规则,生成render树

4. 布局render树(Layout/reflow),负责各元素尺寸、位置的计算

5. 绘制render树(paint),绘制页面像素信息

6. 浏览器会将各层的信息发送给GPU,GPU会将各层合成(composite),显示在屏幕上

如下图:

HTML解析,构建DOM

整个渲染步骤中,HTML解析是第一步。

简单的理解,这一步的流程是这样的:浏览器解析HTML,构建DOM树。

但实际上,在分析整体构建时,却不能一笔带过,得稍微展开。

解析HTML到构建出DOM当然过程可以简述如下:

Bytes → characters → tokens → nodes → DOM

譬如假设有这样一个HTML页面:(以下部分的内容出自参考来源,修改了下格式)

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img data-original="awesome-photo.jpg"></div>
  </body>
</html>

浏览器的处理如下:

列举其中的一些重点过程:

1. Conversion转换:浏览器将获得的HTML内容(Bytes)基于他的编码转换为单个字符

2. Tokenizing分词:浏览器按照HTML规范标准将这些字符转换为不同的标记token。每个token都有自己独特的含义以及规则集

3. Lexing词法分析:分词的结果是得到一堆的token,此时把他们转换为对象,这些对象分别定义他们的属性和规则

4. DOM构建:因为HTML标记定义的就是不同标签之间的关系,这个关系就像是一个树形结构一样
例如:body对象的父节点就是HTML对象,然后段略p对象的父节点就是body对象

最后的DOM树如下:

生成CSS规则

同理,CSS规则树的生成也是类似。简述为:

Bytes → characters → tokens → nodes → CSSOM

譬如style.css内容如下:

body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }

那么最终的CSSOM树就是:

构建渲染树

当DOM树和CSSOM都有了后,就要开始构建渲染树了

一般来说,渲染树和DOM树相对应的,但不是严格意义上的一一对应

因为有一些不可见的DOM元素不会插入到渲染树中,如head这种不可见的标签或者display: none

整体来说可以看图:

渲染

有了render树,接下来就是开始渲染,基本流程如下:

图中重要的四个步骤就是:

1. 计算CSS样式

2. 构建渲染树

3. 布局,主要定位坐标和大小,是否换行,各种position overflow z-index属性

4. 绘制,将图像绘制出来

然后,图中的线与箭头代表通过js动态修改了DOM或CSS,导致了重新布局(Layout)或渲染(Repaint)

这里Layout和Repaint的概念是有区别的:

  • Layout,也称为Reflow,即回流。一般意味着元素的内容、结构、位置或尺寸发生了变化,需要重新计算样式和渲染树
  • Repaint,即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的时候(例如,背景色,边框颜色,文字颜色等),此时只需要应用新样式绘制这个元素就可以了

回流的成本开销要高于重绘,而且一个节点的回流往往回导致子节点以及同级节点的回流,
所以优化方案中一般都包括,尽量避免回流。

什么会引起回流?

1.页面渲染初始化

2.DOM结构改变,比如删除了某个节点

3.render树变化,比如减少了padding

4.窗口resize

5.最复杂的一种:获取某些属性,引发回流,
很多浏览器会对回流做优化,会等到数量足够时做一次批处理回流,
但是除了render树的直接变化,当获取一些属性时,浏览器为了获得正确的值也会触发回流,这样使得浏览器优化无效,包括
    (1)offset(Top/Left/Width/Height)
     (2) scroll(Top/Left/Width/Height)
     (3) cilent(Top/Left/Width/Height)
     (4) width,height
     (5) 调用了getComputedStyle()或者IE的currentStyle

回流一定伴随着重绘,重绘却可以单独出现

所以一般会有一些优化方案,如:

  • 减少逐项更改样式,最好一次性更改style,或者将样式定义为class并一次性更新
  • 避免循环操作dom,创建一个documentFragment或div,在它上面应用所有DOM操作,最后再把它添加到window.document
  • 避免多次读取offset等属性。无法避免则将它们缓存到变量
  • 将复杂的元素绝对定位或固定定位,使得它脱离文档流,否则回流代价会很高

注意:改变字体大小会引发回流

再来看一个示例:

var s = document.body.style;

s.padding = "2px"; // 回流+重绘
s.border = "1px solid red"; // 再一次 回流+重绘
s.color = "blue"; // 再一次重绘
s.backgroundColor = "#ccc"; // 再一次 重绘
s.fontSize = "14px"; // 再一次 回流+重绘
// 添加node,再一次 回流+重绘
document.body.appendChild(document.createTextNode('abc!'));

简单层与复合层

上述中的渲染中止步于绘制,但实际上绘制这一步也没有这么简单,它可以结合复合层和简单层的概念来讲。

这里不展开,进简单介绍下:

  • 可以认为默认只有一个复合图层,所有的DOM节点都是在这个复合图层下的
  • 如果开启了硬件加速功能,可以将某个节点变成复合图层
  • 复合图层之间的绘制互不干扰,由GPU直接控制
  • 而简单图层中,就算是absolute等布局,变化时不影响整体的回流,但是由于在同一个图层中,仍然是会影响绘制的,因此做动画时性能仍然很低。而复合层是独立的,所以一般做动画推荐使用硬件加速

更多参考:

普通图层和复合图层

Chrome中的调试

Chrome的开发者工具中,Performance中可以看到详细的渲染过程:


资源外链的下载

上面介绍了html解析,渲染流程。但实际上,在解析html时,会遇到一些资源连接,此时就需要进行单独处理了

简单起见,这里将遇到的静态资源分为一下几大类(未列举所有):

  • CSS样式资源
  • JS脚本资源
  • img图片类资源

遇到外链时的处理

当遇到上述的外链时,会单独开启一个下载线程去下载资源(http1.1中是每一个资源的下载都要开启一个http请求,对应一个tcp/ip链接)

遇到CSS样式资源

CSS资源的处理有几个特点:

  • CSS下载时异步,不会阻塞浏览器构建DOM树
  • 但是会阻塞渲染,也就是在构建render时,会等到css下载解析完毕后才进行(这点与浏览器优化有关,防止css规则不断改变,避免了重复的构建)
  • 有例外,media query声明的CSS是不会阻塞渲染的

遇到JS脚本资源

JS脚本资源的处理有几个特点:

  • 阻塞浏览器的解析,也就是说发现一个外链脚本时,需等待脚本下载完成并执行后才会继续解析HTML
  • 浏览器的优化,一般现代浏览器有优化,在脚本阻塞时,也会继续下载其它资源(当然有并发上限),但是虽然脚本可以并行下载,解析过程仍然是阻塞的,也就是说必须这个脚本执行完毕后才会接下来的解析,并行下载只是一种优化而已
  • defer与async,普通的脚本是会阻塞浏览器解析的,但是可以加上defer或async属性,这样脚本就变成异步了,可以等到解析完毕后再执行

注意,defer和async是有区别的: defer是延迟执行,而async是异步执行。

简单的说(不展开):

  • async是异步执行,异步下载完毕后就会执行,不确保执行顺序,一定在onload前,但不确定在DOMContentLoaded事件的前或后
  • defer是延迟执行,在浏览器看起来的效果像是将脚本放在了body后面一样(虽然按规范应该是在DOMContentLoaded事件前,但实际上不同浏览器的优化效果不一样,也有可能在它后面)

遇到img图片类资源

遇到图片等资源时,直接就是异步下载,不会阻塞解析,下载完毕后直接用图片替换原有src的地方

loaded和domcontentloaded

简单的对比:

  • DOMContentLoaded 事件触发时,仅当DOM加载完成,不包括样式表,图片(譬如如果有async加载的脚本就不一定完成)
  • load 事件触发时,页面上所有的DOM,样式表,脚本,图片都已经加载完成了

CSS的可视化格式模型

这一部分内容很多参考《精通CSS-高级Web标准解决方案》以及参考来源

前面提到了整体的渲染概念,但实际上文档树中的元素是按什么渲染规则渲染的,是可以进一步展开的,此部分内容即: CSS的可视化格式模型

先了解:

  • CSS中规定每一个元素都有自己的盒子模型(相当于规定了这个元素如何显示)
  • 然后可视化格式模型则是把这些盒子按照规则摆放到页面上,也就是如何布局
  • 换句话说,盒子模型规定了怎么在页面里摆放盒子,盒子的相互作用等等

说到底: CSS的可视化格式模型就是规定了浏览器在页面中如何处理文档树

关键字:

包含块(Containing Block)
控制框(Controlling Box)
BFC(Block Formatting Context)
IFC(Inline Formatting Context)
定位体系
浮动
...

另外,CSS有三种定位机制:普通流浮动绝对定位,如无特别提及,下文中都是针对普通流中的

包含块(Containing Block)

一个元素的box的定位和尺寸,会与某一矩形框有关,这个框就称之为包含块。

元素会为它的子孙元素创建包含块,但是,并不是说元素的包含块就是它的父元素,元素的包含块与它的祖先元素的样式等有关系

譬如:

  • 根元素是最顶端的元素,它没有父节点,它的包含块就是初始包含块
  • static和relative的包含块由它最近的块级、单元格或者行内块祖先元素的内容框(content)创建
  • fixed的包含块是当前可视窗口
  • absolute的包含块由它最近的position 属性为absoluterelative或者fixed的祖先元素创建

    • 如果其祖先元素是行内元素,则包含块取决于其祖先元素的direction特性
    • 如果祖先元素不是行内元素,那么包含块的区域应该是祖先元素的内边距边界

控制框(Controlling Box)

块级元素和块框以及行内元素和行框的相关概念

块框:

  • 块级元素会生成一个块框(Block Box),块框会占据一整行,用来包含子box和生成的内容
  • 块框同时也是一个块包含框(Containing Box),里面要么只包含块框,要么只包含行内框(不能混杂),如果块框内部有块级元素也有行内元素,那么行内元素会被匿名块框包围

关于匿名块框的生成,示例:

<DIV>
Some text
<P>More text
</DIV>

div生成了一个块框,包含了另一个块框p以及文本内容Some text,此时Some text文本会被强制加到一个匿名的块框里面,被div生成的块框包含(其实这个就是IFC中提到的行框,包含这些行内框的这一行匿名块形成的框,行框和行内框不同)

换句话说:

如果一个块框在其中包含另外一个块框,那么我们强迫它只能包含块框,因此其它文本内容生成出来的都是匿名块框(而不是匿名行内框)

行内框:

  • 一个行内元素生成一个行内框
  • 行内元素能排在一行,允许左右有其它元素

关于匿名行内框的生成,示例:

<P>Some <EM>emphasized</EM> text</P>

P元素生成一个块框,其中有几个行内框(如EM),以及文本Some text,此时会专门为这些文本生成匿名行内框

display属性的影响

display的几个属性也可以影响不同框的生成:

  • block,元素生成一个块框
  • inline,元素产生一个或多个的行内框
  • inline-block,元素产生一个行内级块框,行内块框的内部会被当作块块来格式化,而此元素本身会被当作行内级框来格式化(这也是为什么会产生BFC
  • none,不生成框,不再格式化结构中,当然了,另一个visibility: hidden则会产生一个不可见的框

总结:

  • 如果一个框里,有一个块级元素,那么这个框里的内容都会被当作块框来进行格式化,因为只要出现了块级元素,就会将里面的内容分块几块,每一块独占一行(出现行内可以用匿名块框解决)
  • 如果一个框里,没有任何块级元素,那么这个框里的内容会被当成行内框来格式化,因为里面的内容是按照顺序成行的排列

BFC(Block Formatting Context)

FC(格式上下文)?

FC即格式上下文,它定义框内部的元素渲染规则,比较抽象,譬如

FC像是一个大箱子,里面装有很多元素

箱子可以隔开里面的元素和外面的元素(所以外部并不会影响FC内部的渲染)

内部的规则可以是:如何定位,宽高计算,margin折叠等等

不同类型的框参与的FC类型不同,譬如块级框对应BFC,行内框对应IFC

注意,并不是说所有的框都会产生FC,而是符合特定条件才会产生,只有产生了对应的FC后才会应用对应渲染规则

BFC规则:

在块格式化上下文中

每一个元素左外边与包含块的左边相接触(对于从右到左的格式化,右外边接触右边)

即使存在浮动也是如此(所以浮动元素正常会直接贴近它的包含块的左边,与普通元素重合)

除非这个元素也创建了一个新的BFC

总结几点BFC特点:

  1. 内部box在垂直方向,一个接一个的放置
  2. box的垂直方向由margin决定,属于同一个BFC的两个box间的margin会重叠
  3. BFC区域不会与float box重叠(可用于排版)
  4. BFC就是页面上的一个隔离的独立容器,容器里面的子元素不会影响到外面的元素。反之也如此
  5. 计算BFC的高度时,浮动元素也参与计算(不会浮动坍塌)

如何触发BFC?

  1. 根元素
  2. float属性不为none
  3. positionabsolutefixed
  4. displayinline-block, flex, inline-flextabletable-celltable-caption
  5. overflow不为visible

这里提下,display: table,它本身不产生BFC,但是它会产生匿名框(包含display: table-cell的框),而这个匿名框产生BFC

更多请自行网上搜索

IFC(Inline Formatting Context)

IFC即行内框产生的格式上下文

IFC规则

在行内格式化上下文中

框一个接一个地水平排列,起点是包含块的顶部。

水平方向上的 margin,border 和 padding 在框之间得到保留

框在垂直方向上可以以不同的方式对齐:它们的顶部或底部对齐,或根据其中文字的基线对齐

行框

包含那些框的长方形区域,会形成一行,叫做行框

行框的宽度由它的包含块和其中的浮动元素决定,高度的确定由行高度计算规则决定

行框的规则:

如果几个行内框在水平方向无法放入一个行框内,它们可以分配在两个或多个垂直堆叠的行框中(即行内框的分割)

行框在堆叠时没有垂直方向上的分割且永不重叠

行框的高度总是足够容纳所包含的所有框。不过,它可能高于它包含的最高的框(例如,框对齐会引起基线对齐)

行框的左边接触到其包含块的左边,右边接触到其包含块的右边。

结合补充下IFC规则:

浮动元素可能会处于包含块边缘和行框边缘之间

尽管在相同的行内格式化上下文中的行框通常拥有相同的宽度(包含块的宽度),它们可能会因浮动元素缩短了可用宽度,而在宽度上发生变化

同一行内格式化上下文中的行框通常高度不一样(如,一行包含了一个高的图形,而其它行只包含文本)

当一行中行内框宽度的总和小于包含它们的行框的宽,它们在水平方向上的对齐,取决于 `text-align` 特性

空的行内框应该被忽略

即不包含文本,保留空白符,margin/padding/border非0的行内元素,
以及其他常规流中的内容(比如,图片,inline blocks 和 inline tables),
并且不是以换行结束的行框,
必须被当作零高度行框对待

总结:

  • 行内元素总是会应用IFC渲染规则
  • 行内元素会应用IFC规则渲染,譬如text-align可以用来居中等
  • 块框内部,对于文本这类的匿名元素,会产生匿名行框包围,而行框内部就应用IFC渲染规则
  • 行内框内部,对于那些行内元素,一样应用IFC渲染规则
  • 另外,inline-block,会在元素外层产生IFC(所以这个元素是可以通过text-align水平居中的),当然,它内部则按照BFC规则渲染

相比BFC规则来说,IFC可能更加抽象(因为没有那么条理清晰的规则和触发条件)

但总的来说,它就是行内元素自身如何显示以及在框内如何摆放的渲染规则,这样描述应该更容易理解

其它

当然还有有一些其它内容:

  • 譬如常规流,浮动,绝对定位等区别
  • 譬如浮动元素不包含在常规流中
  • 譬如相对定位,绝对定位,Fixed定位等区别
  • 譬如z-index的分层显示机制等

这里不一一展开,更多请参考:

http://bbs.csdn.net/topics/340204423

JS引擎解析过程

前面有提到遇到JS脚本时,会等到它的执行,实际上是需要引擎解析的,这里展开描述(介绍主干流程)

JS的解释阶段

首先得明确: JS是解释型语音,所以它无需提前编译,而是由解释器实时运行

引擎对JS的处理过程可以简述如下:

1. 读取代码,进行词法分析(Lexical analysis),然后将代码分解成词元(token)

2. 对词元进行语法分析(parsing),然后将代码整理成语法树(syntax tree)

3. 使用翻译器(translator),将代码转为字节码(bytecode)

4. 使用字节码解释器(bytecode interpreter),将字节码转为机器码

最终计算机执行的就是机器码。

为了提高运行速度,现代浏览器一般采用即时编译(JIT-Just In Time compiler

即字节码只在运行时编译,用到哪一行就编译哪一行,并且把编译结果缓存(inline cache

这样整个程序的运行速度能得到显著提升。

而且,不同浏览器策略可能还不同,有的浏览器就省略了字节码的翻译步骤,直接转为机器码(如chrome的v8)

总结起来可以认为是: 核心的JIT编译器将源码编译成机器码运行

JS的预处理阶段

上述将的是解释器的整体过程,这里再提下在正式执行JS前,还会有一个预处理阶段
(譬如变量提升,分号补全等)

预处理阶段会做一些事情,确保JS可以正确执行,这里仅提部分:

分号补全

JS执行是需要分号的,但为什么以下语句却可以正常运行呢?

console.log('a')
console.log('b')

原因就是JS解释器有一个Semicolon Insertion规则,它会按照一定规则,在适当的位置补充分号

譬如列举几条自动加分号的规则:

  • 当有换行符(包括含有换行符的多行注释),并且下一个token没法跟前面的语法匹配时,会自动补分号。
  • 当有}时,如果缺少分号,会补分号。
  • 程序源代码结束时,如果缺少分号,会补分号。

于是,上述的代码就变成了

console.log('a');
console.log('b');

所以可以正常运行

当然了,这里有一个经典的例子:

function b() {
    return
    {
        a: 'a'
    };
}

由于分号补全机制,所以它变成了:

function b() {
    return;
    {
        a: 'a'
    };
}

所以运行后是undefined

变量提升

一般包括函数提升和变量提升

譬如:

a = 1;
b();
function b() {
    console.log('b');
}
var a;

经过变量提升后,就变成:

function b() {
    console.log('b');
}
var a;
a = 1;
b();

这里没有展开,其实展开也可以牵涉到很多内容的

譬如可以提下变量声明,函数声明,形参,实参的优先级顺序,以及es6中let有关的临时死区等

JS的执行阶段

此阶段的内容中的图片来源:深入理解JavaScript系列(10):JavaScript核心(晋级高手必读篇)

解释器解释完语法规则后,就开始执行,然后整个执行流程中大致包含以下概念:

  • 执行上下文,执行堆栈概念(如全局上下文,当前活动上下文)
  • VO(变量对象)和AO(活动对象)
  • 作用域链
  • this机制等

这些概念如果深入讲解的话内容过多,因此这里仅提及部分特性

执行上下文简单解释

  • JS有执行上下文
  • 浏览器首次载入脚本,它将创建全局执行上下文,并压入执行栈栈顶(不可被弹出)
  • 然后每进入其它作用域就创建对应的执行上下文并把它压入执行栈的顶部
  • 一旦对应的上下文执行完毕,就从栈顶弹出,并将上下文控制权交给当前的栈。
  • 这样依次执行(最终都会回到全局执行上下文)

譬如,如果程序执行完毕,被弹出执行栈,然后有没有被引用(没有形成闭包),那么这个函数中用到的内存就会被垃圾处理器自动回收

然后执行上下文与VO,作用域链,this的关系是:

每一个执行上下文,都有三个重要属性:

  • 变量对象(Variable object,VO)
  • 作用域链(Scope chain)
  • this

VO与AO

VO是执行上下文的属性(抽象概念),但是只有全局上下文的变量对象允许通过VO的属性名称来间接访问(因为在全局上下文里,全局对象自身就是变量对象)

AO(activation object),当函数被调用者激活,AO就被创建了

可以理解为:

  • 在函数上下文中:VO === AO
  • 在全局上下文中:VO === this === global

总的来说,VO中会存放一些变量信息(如声明的变量,函数,arguments参数等等)

作用域链

它是执行上下文中的一个属性,原理和原型链很相似,作用很重要。

譬如流程简述:

在函数上下文中,查找一个变量foo

如果函数的VO中找到了,就直接使用

否则去它的父级作用域链中(__parent__)找

如果父级中没找到,继续往上找

直到全局上下文中也没找到就报错

this指针

这也是JS的核心知识之一,由于内容过多,这里就不展开,仅提及部分

注意:this是执行上下文环境的一个属性,而不是某个变量对象的属性

因此:

  • this是没有一个类似搜寻变量的过程
  • 当代码中使用了this,这个 this的值就直接从执行的上下文中获取了,而不会从作用域链中搜寻
  • this的值只取决中进入上下文时的情况

所以经典的例子:

var baz = 200;
var bar = {
    baz: 100,
    foo: function() {
        console.log(this.baz);
    }
};
var foo = bar.foo;

// 进入环境:global
foo(); // 200,严格模式中会报错,Cannot read property 'baz' of undefined

// 进入环境:global bar
bar.foo(); // 100

就要明白了上面this的介绍,上述例子很好理解

更多参考:

深入理解JavaScript系列(13):This? Yes,this!

回收机制

JS有垃圾处理器,所以无需手动回收内存,而是由垃圾处理器自动处理。

一般来说,垃圾处理器有自己的回收策略。

譬如对于那些执行完毕的函数,如果没有外部引用(被引用的话会形成闭包),则会回收。(当然一般会把回收动作切割到不同的时间段执行,防止影响性能)

常用的两种垃圾回收规则是:

  • 标记清除
  • 引用计数

Javascript引擎基础GC方案是(simple GC):mark and sweep(标记清除),简单解释如下:

  1. 遍历所有可访问的对象。
  2. 回收已不可访问的对象。

譬如:(出自javascript高程)

当变量进入环境时,例如,在函数中声明一个变量,就将这个变量标记为“进入环境”。

从逻辑上讲,永远不能释放进入环境的变量所占用的内存,因为只要执行流进入相应的环境,就可能会用到它们。

而当变量离开环境时,则将其标记为“离开环境”。

垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记(当然,可以使用任何标记方式)。

然后,它会去掉环境中的变量以及被环境中的变量引用的变量的标记(闭包,也就是说在环境中的以及相关引用的变量会被去除标记)。

而在此之后再被加上标记的变量将被视为准备删除的变量,原因是环境中的变量已经无法访问到这些变量了。

最后,垃圾回收器完成内存清除工作,销毁那些带标记的值并回收它们所占用的内存空间。

关于引用计数,简单点理解:

跟踪记录每个值被引用的次数,当一个值被引用时,次数+1,减持时-1,下次垃圾回收器会回收次数为0的值的内存(当然了,容易出循环引用的bug)

GC的缺陷

和其他语言一样,javascript的GC策略也无法避免一个问题: GC时,停止响应其他操作

这是为了安全考虑。

而Javascript的GC在100ms甚至以上

对一般的应用还好,但对于JS游戏,动画对连贯性要求比较高的应用,就麻烦了。

这就是引擎需要优化的点: 避免GC造成的长时间停止响应。

GC优化策略

这里介绍常用到的:分代回收(Generation GC)

目的是通过区分“临时”与“持久”对象:

  • 多回收“临时对象”区(young generation
  • 少回收“持久对象”区(tenured generation
  • 减少每次需遍历的对象,从而减少每次GC的耗时。

像node v8引擎就是采用的分代回收(和java一样,作者是java虚拟机作者。)

更多可以参考:

V8 内存浅析

其它

可以提到跨域

譬如发出网络请求时,会用AJAX,如果接口跨域,就会遇到跨域问题

可以参考:

ajax跨域,这应该是最全的解决方案了

可以提到web安全

譬如浏览器在解析HTML时,有XSSAuditor,可以延伸到web安全相关领域

可以参考:

AJAX请求真的不安全么?谈谈Web安全与AJAX的关系。

更多

如可以提到viewport概念,讲讲物理像素,逻辑像素,CSS像素等概念

如熟悉Hybrid开发的话可以提及一下Hybrid相关内容以及优化

...

总结

上述这么多内容,目的是:梳理出自己的知识体系

本文由于是前端向,所以知识梳理时有重点,很多其它的知识点都简述或略去了,重点介绍的模块总结:

  • 浏览器的进程/线程模型、JS运行机制(这一块的详细介绍链接到了另一篇文章)
  • http规范(包括报文结构,头部,优化,http2.0,https等)
  • http缓存(单独列出来,因为它很重要)
  • 页面解析流程(HTML解析,构建DOM,生成CSS规则,构建渲染树,渲染流程,复合层的合成,外链的处理等)
  • JS引擎解析过程(包括解释阶段,预处理阶段,执行阶段,包括执行上下文、VO、作用域链、this、回收机制等)
  • 跨域相关,web安全单独链接到了具体文章,其它如CSS盒模型,viewport等仅是提及概念

关于本文的价值?

本文是个人阶段性梳理知识体系的成果,然后加以修缮后发布成文章,因此并不确保适用于所有人员

但是,个人认为本文还是有一定参考价值的

写在最后的话

还是那句话:知识要形成体系

梳理出知识体系后,有了一个骨架,知识点不易遗忘,而且学习新知识时也会更加迅速,更重要的是容易举一反三,可以由一个普通的问题,深挖拓展到底层原理

前端知识是无穷无尽的,本文也仅仅是简单梳理出一个承载知识体系的骨架而已,更多的内容仍然需要不断学习,积累

另外,本文结合从浏览器多进程到JS单线程,JS运行机制最全面的一次梳理这篇文章,更佳噢!

附录

博客

初次发布2018.03.12于我个人博客上面

http://www.dailichun.com/2018/03/12/whenyouenteraurl.html

招聘软广

阿里巴巴钉钉商业化团队大量hc,高薪股权。机会好,技术成长空间足,业务也有很大的发挥空间!

还在犹豫什么,来吧!!!

社招(P6~P7)

职责和挑战

  1. 负责钉钉工作台。工作台是帮助企业实现数字化管理和协同的门户,是拥有亿级用户量的产品。如何保障安全、稳定、性能和体验是对我们的一大挑战。
  2. 负责开放能力建设。针对纷繁的业务场景,提供合理的开放方案,既要做到深入用户场景理解并支撑业务发展,满足企业千人千面、千行千面的诉求,又要在技术上保障用户的安全、稳定和体验。需要既要有技术抽象能力、平台架构能力,又要有业务的理解和分析能力。
  3. 开放平台基础建设。保障链路的安全和稳定。同时对如何保障用户体验有持续精进的热情和追求。

职位要求

  1. 精通HTML5、CSS3、JS(ES5/ES6)等前端开发技术
  2. 掌握主流的JS库和开发框架,并深入理解其设计原理,例如React,Vue等
  3. 熟悉模块化、前端编译和构建工具,例如webpack、babel等
  4. (加分项)了解服务端或native移动应用开发,例如nodejs、Java等
  5. 对技术有强追求,有良好的沟通能力和团队协同能力,有优秀的分析问题和解决问题的能力。

前端实习

面向2021毕业的同学

  1. 本科及以上学历,计算机相关专业
  2. 熟练掌握HTML5/CSS3/Javascript等web前端技术
  3. 熟悉至少一种常用框架,例如React、vue等
  4. 关注新事物、新技术,有较强的学习能力,有强烈求知欲和进取心
  5. 有半年以上实际项目经验,大厂加分

image.png

image.png

内推邮箱

lichun.dlc@alibaba-inc.com

简历发我邮箱,必有回应,符合要求直接走内推!!!

一对一服务,有问必答!

也可加我微信了解更多:a546684355

参考资料

查看原文

赞 569 收藏 1042 评论 42

Moorez 赞了文章 · 2020-07-09

前端与编译原理——用JS写一个JS解释器

图片描述

说起编译原理,印象往往只停留在本科时那些枯燥的课程和晦涩的概念。作为前端开发者,编译原理似乎离我们很远,对它的理解很可能仅仅局限于“抽象语法树(AST)”。但这仅仅是个开头而已。编译原理的使用,甚至能让我们利用JS直接写一个能运行JS代码的解释器。

项目地址:https://github.com/jrainlau/c...

在线体验:https://codepen.io/jrainlau/p...

一、为什么要用JS写JS的解释器

接触过小程序开发的同学应该知道,小程序运行的环境禁止new Functioneval等方法的使用,导致我们无法直接执行字符串形式的动态代码。此外,许多平台也对这些JS自带的可执行动态代码的方法进行了限制,那么我们是没有任何办法了吗?既然如此,我们便可以用JS写一个解析器,让JS自己去运行自己。

在开始之前,我们先简单回顾一下编译原理的一些概念。

二、什么是编译器

说到编译原理,肯定离不开编译器。简单来说,当一段代码经过编译器的词法分析、语法分析等阶段之后,会生成一个树状结构的“抽象语法树(AST)”,该语法树的每一个节点都对应着代码当中不同含义的片段。

比如有这么一段代码:

const a = 1
console.log(a)

经过编译器处理后,它的AST长这样:

{
  "type": "Program",
  "start": 0,
  "end": 26,
  "body": [
    {
      "type": "VariableDeclaration",
      "start": 0,
      "end": 11,
      "declarations": [
        {
          "type": "VariableDeclarator",
          "start": 6,
          "end": 11,
          "id": {
            "type": "Identifier",
            "start": 6,
            "end": 7,
            "name": "a"
          },
          "init": {
            "type": "Literal",
            "start": 10,
            "end": 11,
            "value": 1,
            "raw": "1"
          }
        }
      ],
      "kind": "const"
    },
    {
      "type": "ExpressionStatement",
      "start": 12,
      "end": 26,
      "expression": {
        "type": "CallExpression",
        "start": 12,
        "end": 26,
        "callee": {
          "type": "MemberExpression",
          "start": 12,
          "end": 23,
          "object": {
            "type": "Identifier",
            "start": 12,
            "end": 19,
            "name": "console"
          },
          "property": {
            "type": "Identifier",
            "start": 20,
            "end": 23,
            "name": "log"
          },
          "computed": false
        },
        "arguments": [
          {
            "type": "Identifier",
            "start": 24,
            "end": 25,
            "name": "a"
          }
        ]
      }
    }
  ],
  "sourceType": "module"
}
常见的JS编译器有babylonacorn等等,感兴趣的同学可以在AST explorer这个网站自行体验。

可以看到,编译出来的AST详细记录了代码中所有语义代码的类型、起始位置等信息。这段代码除了根节点Program外,主体包含了两个节点VariableDeclarationExpressionStatement,而这些节点里面又包含了不同的子节点。

正是由于AST详细记录了代码的语义化信息,所以Babel,Webpack,Sass,Less等工具可以针对代码进行非常智能的处理。

三、什么是解释器

如同翻译人员不仅能看懂一门外语,也能对其艺术加工后把它翻译成母语一样,人们把能够将代码转化成AST的工具叫做“编译器”,而把能够将AST翻译成目标语言并运行的工具叫做“解释器”。

在编译原理的课程中,我们思考过这么一个问题:如何让计算机运行算数表达式1+2+3:

1 + 2 + 3

当机器执行的时候,它可能会是这样的机器码:

1 PUSH 1
2 PUSH 2
3 ADD
4 PUSH 3
5 ADD

而运行这段机器码的程序,就是解释器。

在这篇文章中,我们不会搞出机器码这样复杂的东西,仅仅是使用JS在其runtime环境下去解释JS代码的AST。由于解释器使用JS编写,所以我们可以大胆使用JS自身的语言特性,比如this绑定、new关键字等等,完全不需要对它们进行额外处理,也因此让JS解释器的实现变得非常简单。

在回顾了编译原理的基本概念之后,我们就可以着手进行开发了。

四、节点遍历器

通过分析上文的AST,可以看到每一个节点都会有一个类型属性type,不同类型的节点需要不同的处理方式,处理这些节点的程序,就是“节点处理器(nodeHandler)”

定义一个节点处理器:

const nodeHandler = {
  Program () {},
  VariableDeclaration () {},
  ExpressionStatement () {},
  MemberExpression () {},
  CallExpression () {},
  Identifier () {}
}

关于节点处理器的具体实现,会在后文进行详细探讨,这里暂时不作展开。

有了节点处理器,我们便需要去遍历AST当中的每一个节点,递归地调用节点处理器,直到完成对整棵语法书的处理。

定义一个节点遍历器(NodeIterator):

class NodeIterator {
  constructor (node) {
    this.node = node
    this.nodeHandler = nodeHandler
  }

  traverse (node) {
    // 根据节点类型找到节点处理器当中对应的函数
    const _eval = this.nodeHandler[node.type]
    // 若找不到则报错
    if (!_eval) {
      throw new Error(`canjs: Unknown node type "${node.type}".`)
    }
    // 运行处理函数
    return _eval(node)
  }

}

理论上,节点遍历器这样设计就可以了,但仔细推敲,发现漏了一个很重要的东西——作用域处理。

回到节点处理器的VariableDeclaration()方法,它用来处理诸如const a = 1这样的变量声明节点。假设它的代码如下:

  VariableDeclaration (node) {
    for (const declaration of node.declarations) {
      const { name } = declaration.id
      const value = declaration.init ? traverse(declaration.init) : undefined
      // 问题来了,拿到了变量的名称和值,然后把它保存到哪里去呢?
      // ...
    }
  },

问题在于,处理完变量声明节点以后,理应把这个变量保存起来。按照JS语言特性,这个变量应该存放在一个作用域当中。在JS解析器的实现过程中,这个作用域可以被定义为一个scope对象。

改写节点遍历器,为其新增一个scope对象

class NodeIterator {
  constructor (node, scope = {}) {
    this.node = node
    this.scope = scope
    this.nodeHandler = nodeHandler
  }

  traverse (node, options = {}) {
    const scope = options.scope || this.scope
    const nodeIterator = new NodeIterator(node, scope)
    const _eval = this.nodeHandler[node.type]
    if (!_eval) {
      throw new Error(`canjs: Unknown node type "${node.type}".`)
    }
    return _eval(nodeIterator)
  }

  createScope (blockType = 'block') {
    return new Scope(blockType, this.scope)
  }
}

然后节点处理函数VariableDeclaration()就可以通过scope保存变量了:

  VariableDeclaration (nodeIterator) {
    const kind = nodeIterator.node.kind
    for (const declaration of nodeIterator.node.declarations) {
      const { name } = declaration.id
      const value = declaration.init ? nodeIterator.traverse(declaration.init) : undefined
      // 在作用域当中定义变量
      // 如果当前是块级作用域且变量用var定义,则定义到父级作用域
      if (nodeIterator.scope.type === 'block' && kind === 'var') {
        nodeIterator.scope.parentScope.declare(name, value, kind)
      } else {
        nodeIterator.scope.declare(name, value, kind)
      }
    }
  },

关于作用域的处理,可以说是整个JS解释器最难的部分。接下来我们将对作用域处理进行深入的剖析。

五、作用域处理

考虑到这样一种情况:

const a = 1
{
  const b = 2
  console.log(a)
}
console.log(b)

运行结果必然是能够打印出a的值,然后报错:Uncaught ReferenceError: b is not defined

这段代码就是涉及到了作用域的问题。块级作用域或者函数作用域可以读取其父级作用域当中的变量,反之则不行,所以对于作用域我们不能简单地定义一个空对象,而是要专门进行处理。

定义一个作用域基类Scope

class Scope {
  constructor (type, parentScope) {
    // 作用域类型,区分函数作用域function和块级作用域block
    this.type = type
    // 父级作用域
    this.parentScope = parentScope
    // 全局作用域
    this.globalDeclaration = standardMap
    // 当前作用域的变量空间
    this.declaration = Object.create(null)
  }

  /*
   * get/set方法用于获取/设置当前作用域中对应name的变量值
     符合JS语法规则,优先从当前作用域去找,若找不到则到父级作用域去找,然后到全局作用域找。
     如果都没有,就报错
   */
  get (name) {
    if (this.declaration[name]) {
      return this.declaration[name]
    } else if (this.parentScope) {
      return this.parentScope.get(name)
    } else if (this.globalDeclaration[name]) {
      return this.globalDeclaration[name]
    }
    throw new ReferenceError(`${name} is not defined`)
  }

  set (name, value) {
    if (this.declaration[name]) {
      this.declaration[name] = value
    } else if (this.parentScope[name]) {
      this.parentScope.set(name, value)
    } else {
      throw new ReferenceError(`${name} is not defined`)
    }
  }

  /**
   * 根据变量的kind调用不同的变量定义方法
   */
  declare (name, value, kind = 'var') {
    if (kind === 'var') {
      return this.varDeclare(name, value)
    } else if (kind === 'let') {
      return this.letDeclare(name, value)
    } else if (kind === 'const') {
      return this.constDeclare(name, value)
    } else {
      throw new Error(`canjs: Invalid Variable Declaration Kind of "${kind}"`)
    }
  }

  varDeclare (name, value) {
    let scope = this
    // 若当前作用域存在非函数类型的父级作用域时,就把变量定义到父级作用域
    while (scope.parentScope && scope.type !== 'function') {
      scope = scope.parentScope
    }
    this.declaration[name] = new SimpleValue(value, 'var')
    return this.declaration[name]
  }

  letDeclare (name, value) {
    // 不允许重复定义
    if (this.declaration[name]) {
      throw new SyntaxError(`Identifier ${name} has already been declared`)
    }
    this.declaration[name] = new SimpleValue(value, 'let')
    return this.declaration[name]
  }

  constDeclare (name, value) {
    // 不允许重复定义
    if (this.declaration[name]) {
      throw new SyntaxError(`Identifier ${name} has already been declared`)
    }
    this.declaration[name] = new SimpleValue(value, 'const')
    return this.declaration[name]
  }
}

这里使用了一个叫做simpleValue()的函数来定义变量值,主要用于处理常量:

class SimpleValue {
  constructor (value, kind = '') {
    this.value = value
    this.kind = kind
  }

  set (value) {
    // 禁止重新对const类型变量赋值
    if (this.kind === 'const') {
      throw new TypeError('Assignment to constant variable')
    } else {
      this.value = value
    }
  }

  get () {
    return this.value
  }
}

处理作用域问题思路,关键的地方就是在于JS语言本身寻找变量的特性——优先当前作用域,父作用域次之,全局作用域最后。反过来,在节点处理函数VariableDeclaration()里,如果遇到块级作用域且关键字为var,则需要把这个变量也定义到父级作用域当中,这也就是我们常说的“全局变量污染”。

JS标准库注入

细心的读者会发现,在定义Scope基类的时候,其全局作用域globalScope被赋值了一个standardMap对象,这个对象就是JS标准库。

简单来说,JS标准库就是JS这门语言本身所带有的一系列方法和属性,如常用的setTimeoutconsole.log等等。为了让解析器也能够执行这些方法,所以我们需要为其注入标准库:

const standardMap = {
  console: new SimpleValue(console)
}

这样就相当于往解析器的全局作用域当中注入了console这个对象,也就可以直接被使用了。

六、节点处理器

在处理完节点遍历器、作用域处理的工作之后,便可以来编写节点处理器了。顾名思义,节点处理器是专门用来处理AST节点的,上文反复提及的VariableDeclaration()方法便是其中一个。下面将对部分关键的节点处理器进行讲解。

在开发节点处理器之前,需要用到一个工具,用于判断JS语句当中的returnbreakcontinue关键字。

关键字判断工具Signal

定义一个Signal基类:

class Signal {
  constructor (type, value) {
    this.type = type
    this.value = value
  }

  static Return (value) {
    return new Signal('return', value)
  }

  static Break (label = null) {
    return new Signal('break', label)
  }

  static Continue (label) {
    return new Signal('continue', label)
  }

  static isReturn(signal) {
    return signal instanceof Signal && signal.type === 'return'
  }

  static isContinue(signal) {
    return signal instanceof Signal && signal.type === 'continue'
  }

  static isBreak(signal) {
    return signal instanceof Signal && signal.type === 'break'
  }

  static isSignal (signal) {
    return signal instanceof Signal
  }
}

有了它,就可以对语句当中的关键字进行判断处理,接下来会有大用处。

1、变量定义节点处理器——VariableDeclaration()

最常用的节点处理器之一,负责把变量注册到正确的作用域。

  VariableDeclaration (nodeIterator) {
    const kind = nodeIterator.node.kind
    for (const declaration of nodeIterator.node.declarations) {
      const { name } = declaration.id
      const value = declaration.init ? nodeIterator.traverse(declaration.init) : undefined
      // 在作用域当中定义变量
      // 若为块级作用域且关键字为var,则需要做全局污染
      if (nodeIterator.scope.type === 'block' && kind === 'var') {
        nodeIterator.scope.parentScope.declare(name, value, kind)
      } else {
        nodeIterator.scope.declare(name, value, kind)
      }
    }
  },

2、标识符节点处理器——Identifier()

专门用于从作用域中获取标识符的值。

  Identifier (nodeIterator) {
    if (nodeIterator.node.name === 'undefined') {
      return undefined
    }
    return nodeIterator.scope.get(nodeIterator.node.name).value
  },

3、字符节点处理器——Literal()

返回字符节点的值。

  Literal (nodeIterator) {
    return nodeIterator.node.value
  }

4、表达式调用节点处理器——CallExpression()

用于处理表达式调用节点的处理器,如处理func()console.log()等。

  CallExpression (nodeIterator) {
    // 遍历callee获取函数体
    const func = nodeIterator.traverse(nodeIterator.node.callee)
    // 获取参数
    const args = nodeIterator.node.arguments.map(arg => nodeIterator.traverse(arg))

    let value
    if (nodeIterator.node.callee.type === 'MemberExpression') {
      value = nodeIterator.traverse(nodeIterator.node.callee.object)
    }
    // 返回函数运行结果
    return func.apply(value, args)
  },

5、表达式节点处理器——MemberExpression()

区分于上面的“表达式调用节点处理器”,表达式节点指的是person.sayconsole.log这种函数表达式。

  MemberExpression (nodeIterator) {
    // 获取对象,如console
    const obj = nodeIterator.traverse(nodeIterator.node.object)
    // 获取对象的方法,如log
    const name = nodeIterator.node.property.name
    // 返回表达式,如console.log
    return obj[name]
  }

6、块级声明节点处理器——BlockStatement()

非常常用的处理器,专门用于处理块级声明节点,如函数、循环、try...catch...当中的情景。

  BlockStatement (nodeIterator) {
    // 先定义一个块级作用域
    let scope = nodeIterator.createScope('block')

    // 处理块级节点内的每一个节点
    for (const node of nodeIterator.node.body) {
      if (node.type === 'VariableDeclaration' && node.kind === 'var') {
        for (const declaration of node.declarations) {
          scope.declare(declaration.id.name, declaration.init.value, node.kind)
        }
      } else if (node.type === 'FunctionDeclaration') {
        nodeIterator.traverse(node, { scope })
      }
    }

    // 提取关键字(return, break, continue)
    for (const node of nodeIterator.node.body) {
      if (node.type === 'FunctionDeclaration') {
        continue
      }
      const signal = nodeIterator.traverse(node, { scope })
      if (Signal.isSignal(signal)) {
        return signal
      }
    }
  }

可以看到这个处理器里面有两个for...of循环。第一个用于处理块级内语句,第二个专门用于识别关键字,如循环体内部的breakcontinue或者函数体内部的return

7、函数定义节点处理器——FunctionDeclaration()

往作用当中声明一个和函数名相同的变量,值为所定义的函数:

  FunctionDeclaration (nodeIterator) {
    const fn = NodeHandler.FunctionExpression(nodeIterator)
    nodeIterator.scope.varDeclare(nodeIterator.node.id.name, fn)
    return fn    
  }

8、函数表达式节点处理器——FunctionExpression()

用于定义一个函数:

  FunctionExpression (nodeIterator) {
    const node = nodeIterator.node
    /**
     * 1、定义函数需要先为其定义一个函数作用域,且允许继承父级作用域
     * 2、注册`this`, `arguments`和形参到作用域的变量空间
     * 3、检查return关键字
     * 4、定义函数名和长度
     */
    const fn = function () {
      const scope = nodeIterator.createScope('function')
      scope.constDeclare('this', this)
      scope.constDeclare('arguments', arguments)

      node.params.forEach((param, index) => {
        const name = param.name
        scope.varDeclare(name, arguments[index])
      })

      const signal = nodeIterator.traverse(node.body, { scope })
      if (Signal.isReturn(signal)) {
        return signal.value
      }
    }

    Object.defineProperties(fn, {
      name: { value: node.id ? node.id.name : '' },
      length: { value: node.params.length }
    })

    return fn
  }

9、this表达式处理器——ThisExpression()

该处理器直接使用JS语言自身的特性,把this关键字从作用域中取出即可。

  ThisExpression (nodeIterator) {
    const value = nodeIterator.scope.get('this')
    return value ? value.value : null
  }

10、new表达式处理器——NewExpression()

this表达式类似,也是直接沿用JS的语言特性,获取函数和参数之后,通过bind关键字生成一个构造函数,并返回。

  NewExpression (nodeIterator) {
    const func = nodeIterator.traverse(nodeIterator.node.callee)
    const args = nodeIterator.node.arguments.map(arg => nodeIterator.traverse(arg))
    return new (func.bind(null, ...args))
  }

11、For循环节点处理器——ForStatement()

For循环的三个参数对应着节点的inittestupdate属性,对着三个属性分别调用节点处理器处理,并放回JS原生的for循环当中即可。

  ForStatement (nodeIterator) {
    const node = nodeIterator.node
    let scope = nodeIterator.scope
    if (node.init && node.init.type === 'VariableDeclaration' && node.init.kind !== 'var') {
      scope = nodeIterator.createScope('block')
    }

    for (
      node.init && nodeIterator.traverse(node.init, { scope });
      node.test ? nodeIterator.traverse(node.test, { scope }) : true;
      node.update && nodeIterator.traverse(node.update, { scope })
    ) {
      const signal = nodeIterator.traverse(node.body, { scope })
      
      if (Signal.isBreak(signal)) {
        break
      } else if (Signal.isContinue(signal)) {
        continue
      } else if (Signal.isReturn(signal)) {
        return signal
      }
    }
  }

同理,for...inwhiledo...while循环也是类似的处理方式,这里不再赘述。

12、If声明节点处理器——IfStatemtnt()

处理If语句,包括ifif...elseif...elseif...else

  IfStatement (nodeIterator) {
    if (nodeIterator.traverse(nodeIterator.node.test)) {
      return nodeIterator.traverse(nodeIterator.node.consequent)
    } else if (nodeIterator.node.alternate) {
      return nodeIterator.traverse(nodeIterator.node.alternate)
    }
  }

同理,switch语句、三目表达式也是类似的处理方式。

---

上面列出了几个比较重要的节点处理器,在es5当中还有很多节点需要处理,详细内容可以访问这个地址一探究竟。

七、定义调用方式

经过了上面的所有步骤,解析器已经具备处理es5代码的能力,接下来就是对这些散装的内容进行组装,最终定义一个方便用户调用的办法。

const { Parser } = require('acorn')
const NodeIterator = require('./iterator')
const Scope = require('./scope')

class Canjs {
  constructor (code = '', extraDeclaration = {}) {
    this.code = code
    this.extraDeclaration = extraDeclaration
    this.ast = Parser.parse(code)
    this.nodeIterator = null
    this.init()
  }

  init () {
    // 定义全局作用域,该作用域类型为函数作用域
    const globalScope = new Scope('function')
    // 根据入参定义标准库之外的全局变量
    Object.keys(this.extraDeclaration).forEach((key) => {
      globalScope.addDeclaration(key, this.extraDeclaration[key])
    })
    this.nodeIterator = new NodeIterator(null, globalScope)
  }

  run () {
    return this.nodeIterator.traverse(this.ast)
  }
}

这里我们定义了一个名为Canjs的基类,接受字符串形式的JS代码,同时可定义标准库之外的变量。当运行run()方法的时候就可以得到运行结果。

八、后续

至此,整个JS解析器已经完成,可以很好地运行ES5的代码(可能还有bug没有发现)。但是在当前的实现中,所有的运行结果都是放在一个类似沙盒的地方,无法对外界产生影响。如果要把运行结果取出来,可能的办法有两种。第一种是传入一个全局的变量,把影响作用在这个全局变量当中,借助它把结果带出来;另外一种则是让解析器支持export语法,能够把export语句声明的结果返回,感兴趣的读者可以自行研究。

最后,这个JS解析器已经在我的Github上开源,欢迎前来交流~

https://github.com/jrainlau/c...

参考资料

从零开始写一个Javascript解析器

微信小程序也要强行热更代码,鹅厂不服你来肛我呀

jkeylu/evil-eval

查看原文

赞 194 收藏 125 评论 14

Moorez 收藏了文章 · 2020-06-11

可能这些是你想要的H5软键盘兼容方案

image

前言

最近一段时间在做 H5 聊天项目,踩过其中一大坑:输入框获取焦点,软键盘弹起,要求输入框吸附(或顶)在输入法框上。需求很明确,看似很简单,其实不然。从实验过一些机型上看,发现主要存在以下问题:

  • AndroidIOS 上,获知软键盘弹起和收起状态存在差异,且页面 webview 表现不同。
  • IOS12 上,微信版本 v6.7.4 及以上,输入框获取焦点,键盘弹起,页面(webview)整体往上滚动,当键盘收起后,不回到原位,导致键盘原来所在位置是空白的。
  • IOS 上,使用第三方输入法,高度计算存在偏差,导致在有些输入法弹起,将输入框挡住一部分。
  • 在有些浏览器上使用一些操作技巧,还是存在输入框被输入法遮挡。

下面就上述发现的问题,逐个探索一下解决方案。

获知软键盘弹起和收起状态

获知软键盘的弹起还是收起状态很重要,后面的兼容处理都要以此为前提。然而,H5 并没有直接监听软键盘的原生事件,只能通过软键盘弹起或收起,引发页面其他方面的表现间接监听,曲线救国。并且,在 IOSAndroid 上的表现不尽相同。

IOS 软键盘弹起表现

IOS 上,输入框(inputtextarea 或 富文本)获取焦点,键盘弹起,页面(webview)并没有被压缩,或者说高度(height)没有改变,只是页面(webview)整体往上滚了,且最大滚动高度(scrollTop)为软键盘高度。

Android 软键盘弹起表现

同样,在 Android 上,输入框获取焦点,键盘弹起,但是页面(webview)高度会发生改变,一般来说,高度为可视区高度(原高度减去软键盘高度),除了因为页面内容被撑开可以产生滚动,webview 本身不能滚动。

IOS 软键盘收起表现

触发软键盘上的“收起”按钮键盘或者输入框以外的页面区域时,输入框失去焦点,软键盘收起。

Android 软键盘收起表现

触发输入框以外的区域时,输入框失去焦点,软键盘收起。但是,触发键盘上的收起按钮键盘时,输入框并不会失去焦点,同样软键盘收起。

软键盘弹起,IOS 和 Android 的 webview 不同表现

监听软键盘弹起和收起

综合上面键盘弹起和收起在 IOSAndroid 上的不同表现,我们可以分开进行如下处理来监听软键盘的弹起和收起:

  • IOS 上,监听输入框的 focus 事件来获知软键盘弹起,监听输入框的 blur 事件获知软键盘收起。
  • Android 上,监听 webview 高度会变化,高度变小获知软键盘弹起,否则软键盘收起。
// 判断设备类型
var judgeDeviceType = function () {
  var ua = window.navigator.userAgent.toLocaleLowerCase();
  var isIOS = /iphone|ipad|ipod/.test(ua);
  var isAndroid = /android/.test(ua);

  return {
    isIOS: isIOS,
    isAndroid: isAndroid
  }
}()

// 监听输入框的软键盘弹起和收起事件
function listenKeybord($input) {
  if (judgeDeviceType.isIOS) {
    // IOS 键盘弹起:IOS 和 Android 输入框获取焦点键盘弹起
    $input.addEventListener('focus', function () {
      console.log('IOS 键盘弹起啦!');
      // IOS 键盘弹起后操作
    }, false)

    // IOS 键盘收起:IOS 点击输入框以外区域或点击收起按钮,输入框都会失去焦点,键盘会收起,
    $input.addEventListener('blur', () => {
      console.log('IOS 键盘收起啦!');
      // IOS 键盘收起后操作
    })
  }

  // Andriod 键盘收起:Andriod 键盘弹起或收起页面高度会发生变化,以此为依据获知键盘收起
  if (judgeDeviceType.isAndroid) {
    var originHeight = document.documentElement.clientHeight || document.body.clientHeight;

    window.addEventListener('resize', function () {
      var resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
      if (originHeight < resizeHeight) {
        console.log('Android 键盘收起啦!');
        // Android 键盘收起后操作
      } else {
        console.log('Android 键盘弹起啦!');
        // Android 键盘弹起后操作
      }

      originHeight = resizeHeight;
    }, false)
  }
}

var $inputs = document.querySelectorAll('.input');

for (var i = 0; i < $inputs.length; i++) {
  listenKeybord($inputs[i]);
}

弹起软键盘始终让输入框滚动到可视区

有时我们会做一个输入表单,有很多输入项,输入框获取焦点,弹起软键盘。当输入框位于页面下部位置时,在 IOS 上,会将 webview 整体往上滚一段距离,使得该获取焦点的输入框自动处于可视区,而在 Android 则不会这样,它只会改变页面高度,而不会去滚动到当前焦点元素到可视区。
由于上面已经实现监听 IOSAndroid 键盘弹起和收起,在这里,只需在 Android 键盘弹起后,将焦点元素滚动(scrollIntoView())到可视区。查看效果,可以戳这里

// 获取到焦点元素滚动到可视区
function activeElementScrollIntoView(activeElement, delay) {
  var editable = activeElement.getAttribute('contenteditable')

  // 输入框、textarea或富文本获取焦点后没有将该元素滚动到可视区
  if (activeElement.tagName == 'INPUT' || activeElement.tagName == 'TEXTAREA' || editable === '' || editable) {
    setTimeout(function () {
      activeElement.scrollIntoView();
    }, delay)
  }
}

// ...
// Android 键盘弹起后操作
activeElementScrollIntoView($input, 1000);
// ...

唤起纯数字软键盘

上面的表单输入框有要求输入电话号码,类似这样就要弹出一个数字软键盘了,既然说到了软键盘兼容,在这里就安插一下。比较好的解决方案如下:

<p>请输入手机号</p>
<input type="tel" novalidate="novalidate" pattern="[0-9]*" class="input">
  • type="tel", 是 HTML5 的一个属性,表示输入框类型为电话号码,在 AndroidIOS 上表现差不多,都会有数字键盘,但是也会有字母,略显多余。
  • pattern="[0-9]"pattern 用于验证表单输入的内容,通常 HTML5type 属性,比如 emailtelnumberdata 类、url 等,已经自带了简单的数据格式验证功能了,加上 pattern 后,前端部分的验证更加简单高效了。IOS 中,只有 [0-9]\* 才可以调起九宫格数字键盘,\d 无效,Android 4.4 以下(包括X5内核),两者都调起数字键盘。
  • novalidate="novalidate"novalidate 属性规定当提交表单时不对其进行验证,由于 pattern 校验兼容性不好,可以不让其校验,只让其唤起纯数字键盘,校验工作由 js 去做。

软键盘弹起,IOS 和 Android 的 webview 不同表现

兼容 IOS12 + V6.7.4+

如果你在用 IOS12V6.7.4+版本的微信浏览器打开上面表单输入的 demo ,就会惊奇的发现键盘收起后,原本被滚动顶起的页面并没有回到底部位置,导致原来键盘弹起的位置“空”了。

兼容 codeIOS12/code + codeV6.7.4+/code

其实这是 AppleIOSbug,会出现在所有的 Xcode10 打包的 IOS12 的设备上。微信官方已给出解决方案,只需在软键盘收起后,将页面(webview)滚回到窗口最底部位置(clientHeight位置)。修复后的上面表单输入 demo 可以戳这里

console.log('IOS 键盘收起啦!');
// IOS 键盘收起后操作
// 微信浏览器版本6.7.4+IOS12会出现键盘收起后,视图被顶上去了没有下来
var wechatInfo = window.navigator.userAgent.match(/MicroMessenger\/([\d\.]+)/i);
if (!wechatInfo) return;

var wechatVersion = wechatInfo[1];
var version = (navigator.appVersion).match(/OS (\d+)_(\d+)_?(\d+)?/);

if (+wechatVersion.replace(/\./g, '') >= 674 && +version[1] >= 12) {
  setTimeout(function () {
    window.scrollTo(0, Math.max(document.body.clientHeight, document.documentElement.clientHeight));
  })
}

兼容第三方输入法

上面说了那么多,其实已经把 H5 聊天输入框的坑填了一大半了,接下来就先看下聊天输入框的基本HTML结构

<div class="chat__content">
  <div>
    <p>一些聊天内容1</p>
  </div>
  <!-- 省略几千行聊天内容 -->
</div>
<div class="input__content">
  <div class="input" contenteditable="true"></div>
  <button>发送</button>
</div>

样式

/* 省略一些样式 */
.chat__content {
  height: calc(100% - 40px);
  margin-bottom: 40px;
  overflow-y: auto;
  overflow-x: hidden;
}

.input__content {
  display: flex;
  height: 40px;
  position: absolute;
  left: 0;
  right: 0;
  bottom: 0;
  align-items: center;
}
/* 省略一些样式 */

很简单,就是划分内容区和输入区,输入区是绝对定位,按照上面表单输入 demo 的做法,确实大部分 Android 浏览器是没问题的,但是测试在 IOS 上,UC 浏览器配合原生输入法和第三方输入法(比如搜狗输入法),输入框都会被完全挡住;QQ 浏览器或微信浏览器,配合第三方输入法,输入框会被遮住一半;百度浏览器配合第三方输入法输入框也会被完全遮住。查看效果可以用相应浏览器中访问这里

keyboard-chat-input.png

UC 浏览器上,软键盘弹起后,浏览器上面的标题栏高度就有个高度变小延时动态效果,这样导致 webview 往下滚了一点,底部输入框滚到了非可视区。
而对于第三方输入法,猜测本身是由于输入法面板弹起后高度计算有误,导致 webview 初始滚动定位有误。其实这两点都是 webview 滚动不到位造成的。可以让软键盘弹起后,让焦点元素再次滚到可视区,强迫 webview 滚到位。

console.log('Android 键盘弹起啦!');
// Android 键盘弹起后操作
activeElementScrollIntoView($input, 1000);

兼容 Android 小米浏览器的 Hack 方案

Android 的小米浏览器上,应用上面的方案,发现聊天输入框还是被遮挡得严严实实,scrollIntoView() 仍然纹丝不动。所以猜测,其实是滚到底了,软键盘弹起,页面实现高度大于可视区高度,这样只能在软键盘弹起后,强行增加页面高度,使输入框可以显示出来。综合上面兼容第三方输入法,查看效果可以戳这里

// Andriod 键盘收起:Andriod 键盘弹起或收起页面高度会发生变化,以此为依据获知键盘收起
if (judgeDeviceType.isAndroid) {
  var originHeight = document.documentElement.clientHeight || document.body.clientHeight;

  window.addEventListener('resize', function () {
    var resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
    if (originHeight < resizeHeight) {
      console.log('Android 键盘收起啦!');
      // Android 键盘收起后操作
      // 修复小米浏览器下,输入框依旧被输入法遮挡问题
      if (judgeDeviceType.isMiuiBrowser) {
        document.body.style.marginBottom = '0px';
      }
    } else {
      console.log('Android 键盘弹起啦!');
      // Android 键盘弹起后操作
      // 修复小米浏览器下,输入框依旧被输入法遮挡问题
      if (judgeDeviceType.isMiuiBrowser) {
        document.body.style.marginBottom = '40px';
      }
      activeElementScrollIntoView($input, 1000);
    }

    originHeight = resizeHeight;
  }, false)
}

总结

H5 端前路漫漫,坑很多,需要不断尝试。了解软键盘弹起页面在 IOSAndroid 上的表现差异是前提,其次是将焦点元素滚动到可视区,同时要考虑到第三方输入法和某些浏览器上的差别。总结肯定不全面,欢迎大家指正哈,完~

查看原文

Moorez 赞了文章 · 2020-06-11

可能这些是你想要的H5软键盘兼容方案

image

前言

最近一段时间在做 H5 聊天项目,踩过其中一大坑:输入框获取焦点,软键盘弹起,要求输入框吸附(或顶)在输入法框上。需求很明确,看似很简单,其实不然。从实验过一些机型上看,发现主要存在以下问题:

  • AndroidIOS 上,获知软键盘弹起和收起状态存在差异,且页面 webview 表现不同。
  • IOS12 上,微信版本 v6.7.4 及以上,输入框获取焦点,键盘弹起,页面(webview)整体往上滚动,当键盘收起后,不回到原位,导致键盘原来所在位置是空白的。
  • IOS 上,使用第三方输入法,高度计算存在偏差,导致在有些输入法弹起,将输入框挡住一部分。
  • 在有些浏览器上使用一些操作技巧,还是存在输入框被输入法遮挡。

下面就上述发现的问题,逐个探索一下解决方案。

获知软键盘弹起和收起状态

获知软键盘的弹起还是收起状态很重要,后面的兼容处理都要以此为前提。然而,H5 并没有直接监听软键盘的原生事件,只能通过软键盘弹起或收起,引发页面其他方面的表现间接监听,曲线救国。并且,在 IOSAndroid 上的表现不尽相同。

IOS 软键盘弹起表现

IOS 上,输入框(inputtextarea 或 富文本)获取焦点,键盘弹起,页面(webview)并没有被压缩,或者说高度(height)没有改变,只是页面(webview)整体往上滚了,且最大滚动高度(scrollTop)为软键盘高度。

Android 软键盘弹起表现

同样,在 Android 上,输入框获取焦点,键盘弹起,但是页面(webview)高度会发生改变,一般来说,高度为可视区高度(原高度减去软键盘高度),除了因为页面内容被撑开可以产生滚动,webview 本身不能滚动。

IOS 软键盘收起表现

触发软键盘上的“收起”按钮键盘或者输入框以外的页面区域时,输入框失去焦点,软键盘收起。

Android 软键盘收起表现

触发输入框以外的区域时,输入框失去焦点,软键盘收起。但是,触发键盘上的收起按钮键盘时,输入框并不会失去焦点,同样软键盘收起。

软键盘弹起,IOS 和 Android 的 webview 不同表现

监听软键盘弹起和收起

综合上面键盘弹起和收起在 IOSAndroid 上的不同表现,我们可以分开进行如下处理来监听软键盘的弹起和收起:

  • IOS 上,监听输入框的 focus 事件来获知软键盘弹起,监听输入框的 blur 事件获知软键盘收起。
  • Android 上,监听 webview 高度会变化,高度变小获知软键盘弹起,否则软键盘收起。
// 判断设备类型
var judgeDeviceType = function () {
  var ua = window.navigator.userAgent.toLocaleLowerCase();
  var isIOS = /iphone|ipad|ipod/.test(ua);
  var isAndroid = /android/.test(ua);

  return {
    isIOS: isIOS,
    isAndroid: isAndroid
  }
}()

// 监听输入框的软键盘弹起和收起事件
function listenKeybord($input) {
  if (judgeDeviceType.isIOS) {
    // IOS 键盘弹起:IOS 和 Android 输入框获取焦点键盘弹起
    $input.addEventListener('focus', function () {
      console.log('IOS 键盘弹起啦!');
      // IOS 键盘弹起后操作
    }, false)

    // IOS 键盘收起:IOS 点击输入框以外区域或点击收起按钮,输入框都会失去焦点,键盘会收起,
    $input.addEventListener('blur', () => {
      console.log('IOS 键盘收起啦!');
      // IOS 键盘收起后操作
    })
  }

  // Andriod 键盘收起:Andriod 键盘弹起或收起页面高度会发生变化,以此为依据获知键盘收起
  if (judgeDeviceType.isAndroid) {
    var originHeight = document.documentElement.clientHeight || document.body.clientHeight;

    window.addEventListener('resize', function () {
      var resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
      if (originHeight < resizeHeight) {
        console.log('Android 键盘收起啦!');
        // Android 键盘收起后操作
      } else {
        console.log('Android 键盘弹起啦!');
        // Android 键盘弹起后操作
      }

      originHeight = resizeHeight;
    }, false)
  }
}

var $inputs = document.querySelectorAll('.input');

for (var i = 0; i < $inputs.length; i++) {
  listenKeybord($inputs[i]);
}

弹起软键盘始终让输入框滚动到可视区

有时我们会做一个输入表单,有很多输入项,输入框获取焦点,弹起软键盘。当输入框位于页面下部位置时,在 IOS 上,会将 webview 整体往上滚一段距离,使得该获取焦点的输入框自动处于可视区,而在 Android 则不会这样,它只会改变页面高度,而不会去滚动到当前焦点元素到可视区。
由于上面已经实现监听 IOSAndroid 键盘弹起和收起,在这里,只需在 Android 键盘弹起后,将焦点元素滚动(scrollIntoView())到可视区。查看效果,可以戳这里

// 获取到焦点元素滚动到可视区
function activeElementScrollIntoView(activeElement, delay) {
  var editable = activeElement.getAttribute('contenteditable')

  // 输入框、textarea或富文本获取焦点后没有将该元素滚动到可视区
  if (activeElement.tagName == 'INPUT' || activeElement.tagName == 'TEXTAREA' || editable === '' || editable) {
    setTimeout(function () {
      activeElement.scrollIntoView();
    }, delay)
  }
}

// ...
// Android 键盘弹起后操作
activeElementScrollIntoView($input, 1000);
// ...

唤起纯数字软键盘

上面的表单输入框有要求输入电话号码,类似这样就要弹出一个数字软键盘了,既然说到了软键盘兼容,在这里就安插一下。比较好的解决方案如下:

<p>请输入手机号</p>
<input type="tel" novalidate="novalidate" pattern="[0-9]*" class="input">
  • type="tel", 是 HTML5 的一个属性,表示输入框类型为电话号码,在 AndroidIOS 上表现差不多,都会有数字键盘,但是也会有字母,略显多余。
  • pattern="[0-9]"pattern 用于验证表单输入的内容,通常 HTML5type 属性,比如 emailtelnumberdata 类、url 等,已经自带了简单的数据格式验证功能了,加上 pattern 后,前端部分的验证更加简单高效了。IOS 中,只有 [0-9]\* 才可以调起九宫格数字键盘,\d 无效,Android 4.4 以下(包括X5内核),两者都调起数字键盘。
  • novalidate="novalidate"novalidate 属性规定当提交表单时不对其进行验证,由于 pattern 校验兼容性不好,可以不让其校验,只让其唤起纯数字键盘,校验工作由 js 去做。

软键盘弹起,IOS 和 Android 的 webview 不同表现

兼容 IOS12 + V6.7.4+

如果你在用 IOS12V6.7.4+版本的微信浏览器打开上面表单输入的 demo ,就会惊奇的发现键盘收起后,原本被滚动顶起的页面并没有回到底部位置,导致原来键盘弹起的位置“空”了。

兼容 codeIOS12/code + codeV6.7.4+/code

其实这是 AppleIOSbug,会出现在所有的 Xcode10 打包的 IOS12 的设备上。微信官方已给出解决方案,只需在软键盘收起后,将页面(webview)滚回到窗口最底部位置(clientHeight位置)。修复后的上面表单输入 demo 可以戳这里

console.log('IOS 键盘收起啦!');
// IOS 键盘收起后操作
// 微信浏览器版本6.7.4+IOS12会出现键盘收起后,视图被顶上去了没有下来
var wechatInfo = window.navigator.userAgent.match(/MicroMessenger\/([\d\.]+)/i);
if (!wechatInfo) return;

var wechatVersion = wechatInfo[1];
var version = (navigator.appVersion).match(/OS (\d+)_(\d+)_?(\d+)?/);

if (+wechatVersion.replace(/\./g, '') >= 674 && +version[1] >= 12) {
  setTimeout(function () {
    window.scrollTo(0, Math.max(document.body.clientHeight, document.documentElement.clientHeight));
  })
}

兼容第三方输入法

上面说了那么多,其实已经把 H5 聊天输入框的坑填了一大半了,接下来就先看下聊天输入框的基本HTML结构

<div class="chat__content">
  <div>
    <p>一些聊天内容1</p>
  </div>
  <!-- 省略几千行聊天内容 -->
</div>
<div class="input__content">
  <div class="input" contenteditable="true"></div>
  <button>发送</button>
</div>

样式

/* 省略一些样式 */
.chat__content {
  height: calc(100% - 40px);
  margin-bottom: 40px;
  overflow-y: auto;
  overflow-x: hidden;
}

.input__content {
  display: flex;
  height: 40px;
  position: absolute;
  left: 0;
  right: 0;
  bottom: 0;
  align-items: center;
}
/* 省略一些样式 */

很简单,就是划分内容区和输入区,输入区是绝对定位,按照上面表单输入 demo 的做法,确实大部分 Android 浏览器是没问题的,但是测试在 IOS 上,UC 浏览器配合原生输入法和第三方输入法(比如搜狗输入法),输入框都会被完全挡住;QQ 浏览器或微信浏览器,配合第三方输入法,输入框会被遮住一半;百度浏览器配合第三方输入法输入框也会被完全遮住。查看效果可以用相应浏览器中访问这里

keyboard-chat-input.png

UC 浏览器上,软键盘弹起后,浏览器上面的标题栏高度就有个高度变小延时动态效果,这样导致 webview 往下滚了一点,底部输入框滚到了非可视区。
而对于第三方输入法,猜测本身是由于输入法面板弹起后高度计算有误,导致 webview 初始滚动定位有误。其实这两点都是 webview 滚动不到位造成的。可以让软键盘弹起后,让焦点元素再次滚到可视区,强迫 webview 滚到位。

console.log('Android 键盘弹起啦!');
// Android 键盘弹起后操作
activeElementScrollIntoView($input, 1000);

兼容 Android 小米浏览器的 Hack 方案

Android 的小米浏览器上,应用上面的方案,发现聊天输入框还是被遮挡得严严实实,scrollIntoView() 仍然纹丝不动。所以猜测,其实是滚到底了,软键盘弹起,页面实现高度大于可视区高度,这样只能在软键盘弹起后,强行增加页面高度,使输入框可以显示出来。综合上面兼容第三方输入法,查看效果可以戳这里

// Andriod 键盘收起:Andriod 键盘弹起或收起页面高度会发生变化,以此为依据获知键盘收起
if (judgeDeviceType.isAndroid) {
  var originHeight = document.documentElement.clientHeight || document.body.clientHeight;

  window.addEventListener('resize', function () {
    var resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
    if (originHeight < resizeHeight) {
      console.log('Android 键盘收起啦!');
      // Android 键盘收起后操作
      // 修复小米浏览器下,输入框依旧被输入法遮挡问题
      if (judgeDeviceType.isMiuiBrowser) {
        document.body.style.marginBottom = '0px';
      }
    } else {
      console.log('Android 键盘弹起啦!');
      // Android 键盘弹起后操作
      // 修复小米浏览器下,输入框依旧被输入法遮挡问题
      if (judgeDeviceType.isMiuiBrowser) {
        document.body.style.marginBottom = '40px';
      }
      activeElementScrollIntoView($input, 1000);
    }

    originHeight = resizeHeight;
  }, false)
}

总结

H5 端前路漫漫,坑很多,需要不断尝试。了解软键盘弹起页面在 IOSAndroid 上的表现差异是前提,其次是将焦点元素滚动到可视区,同时要考虑到第三方输入法和某些浏览器上的差别。总结肯定不全面,欢迎大家指正哈,完~

查看原文

赞 379 收藏 300 评论 36

Moorez 赞了文章 · 2020-05-26

一行js代码实现时间戳转时间格式

一行代码实现时间戳转时间格式

前端开发过程中,常常需要将时间戳转化为标准时间格式供用户浏览。不借助方法库的情况下,如何又快又好的实现呢?下面介绍两种方法。

老方法

平常用的基本是这个方法,用Date方法依次将年月日时分秒一个个算出来,然后拼接成需要的时间格式字符串。

function transformTime(timestamp = +new Date()) {
    if (timestamp) {
        var time = new Date(timestamp);
        var y = time.getFullYear(); //getFullYear方法以四位数字返回年份
        var M = time.getMonth() + 1; // getMonth方法从 Date 对象返回月份 (0 ~ 11),返回结果需要手动加一
        var d = time.getDate(); // getDate方法从 Date 对象返回一个月中的某一天 (1 ~ 31)
        var h = time.getHours(); // getHours方法返回 Date 对象的小时 (0 ~ 23)
        var m = time.getMinutes(); // getMinutes方法返回 Date 对象的分钟 (0 ~ 59)
        var s = time.getSeconds(); // getSeconds方法返回 Date 对象的秒数 (0 ~ 59)
        return y + '-' + M + '-' + d + ' ' + h + ':' + m + ':' + s;
      } else {
          return '';
      }
}
transformTime(); // "2018-8-8 12:9:12"

老方法改进版

上面的转换方法,通过将时间戳转换为Date实例,利用Date对应的方法获取对应的年月日时分秒,获取的时间格式是‘2018-8-8 12:9:12’,看着有点别扭。为了转化为我们常用的时间格式,还需要注意对小于10的值,在前面添加字符串‘0’,转换为‘2018-08-08 12:09:12’这种时间格式。

function transformTime(timestamp = +new Date()) {
    if (timestamp) {
        var time = new Date(timestamp);
        var y = time.getFullYear();
        var M = time.getMonth() + 1;
        var d = time.getDate();
        var h = time.getHours();
        var m = time.getMinutes();
        var s = time.getSeconds();
        return y + '-' + addZero(M) + '-' + addZero(d) + ' ' + addZero(h) + ':' + addZero(m) + ':' + addZero(s);
      } else {
          return '';
      }
}
function addZero(m) {
    return m < 10 ? '0' + m : m;
}
transformTime(); // "2018-08-08 12:09:12"

对返回小于10的时间数值进行处理,用‘addZero’方法为字符串添加‘0’,这样格式就对称了。

新思路

为了将时间戳转换为我们需要的时间格式,我们写了两个函数,加起来十几行。前段时间,部门大佬告知了另外一种方式,一行代码完成时间戳转换为‘YYYY-MM-DD HH:mm:ss’形式的时间格式,顿时代码精简了很多,话不多说,亮出代码

function time(time = +new Date()) {
    var date = new Date(time + 8 * 3600 * 1000); // 增加8小时
    return date.toJSON().substr(0, 19).replace('T', ' ');
}
time(); // "2018-08-09 18:25:54"

Date的‘toJSON’方法返回格林威治时间的JSON格式字符串,实际是使用‘toISOString’方法的结果。字符串形如‘2018-08-09T10:20:54.396Z’,转化为北京时间需要额外增加八个时区,我们需要取字符串前19位,然后把‘T’替换为空格,即是我们需要的时间格式。

function time(time = +new Date()) {
    var date = new Date(time + 8 * 3600 * 1000);
    return date.toJSON().substr(0, 19).replace('T', ' ').replace(/-/g, '.');
}
time(); // "2018.08.09 18:25:54"

把时间格式中的‘-’修改为‘.’或者其他符号都是可以的。对比老方法,这种方法代码量比以前省了不止一星半点的,读起来也简洁多了。如果时间格式需要毫秒数,只需要获取前23位字符串,和上面一样用replace方法替换。

查看原文

赞 48 收藏 30 评论 9

Moorez 发布了文章 · 2020-04-16

React 16.8.6 版本存在内存泄露

发现这个React 内存泄露问题是某一天的晚上一直开着直播页,直播页用的 react 版本是 16.8.6,到了早上跳到这个页面的时候,控制台有点卡,怀疑是有内存泄露,于是就开始分析这个直播页面。

分析

打开控制台 performance 面板点击开始录制,如下:

从上图可以发现在这时间内, nodes 节点一直在增长,很有可能发生了内存泄露。

我们来到 memory 面板分析内存变化:

注:上图的蓝色线条表示在时间轴的最后该对象依旧存在,灰色线条则说明对象在时间轴内被分配,但是已经被gc(垃圾回收)了。

上图都是点击 gc 再进行记录的,但是上图还有很多蓝色线条,而且内存一直往上涨,很明显的内存泄露问题,那会是什么导致内存泄露的呢?

很快发现这里有个 bi 的东西居然占了 31%的大小:

这个 bi 是用来干嘛的?展开 bi ,鼠标悬浮在 bi 某处:

发现这个节点是直播间里的进房消息,里面是 react 存的 FiberNode 节点,观察了一下里面这些 bi 基本上都是消息元素。

选择 summary,选出Detached (分离)的元素:

Detached HTMLDivElement 居然有41429个,展开,鼠标悬浮:

还是消息信息,说明是这个导致 bi 增加的。我们继续展开:

从上图看 react 会保留消息的上下兄弟节点的引用,而且保留的引用层级有点深,各个节点嵌套依赖,导致一直存在内存里:

仔细查下了项目消息相关代码,发现并不会存在有内存泄露的操作。这里简单说下渲染消息的逻辑,消息有进房消息,聊天消息,礼物消息等等,消息展示会根据 messages 数组里面的类型去渲染不同的消息。messages 数组不会无限增长,控制在 100 个,超过就删掉第一个元素,保证维持100个元素渲染消息,但是从上图来看,这些分离的元素并没有被 react 完全删除,还保存在内存里,查了下 React 的 Issue,并查了相关文章,发现有不少人遇到这个问题:

React 核心成员 Dan 给出的解决办法是升级到 16.9.0。

这里将项目 React 和 React-dom 版本升级16.9.0,
发现 FiberNode 节点还是会一直增加。。。

继续查看Issue 发现,React 版本 0.0.0-241c4467e 修复了这个问题。
Bug: Detached DOM node memory leak · Issue #18066 · facebook/react · GitHub

这个版本的 mr 已经合并在 React master 上
Null stateNode after unmount by bvaughn · Pull Request #17666 · facebook/react · GitHub

这个 mr 是 2019 年 12 月 20 号合并的,2019 年 12 月 20 号之后的版本是 16.13.0,这里将项目直接升级到 16.13.1,然后查看 node 节点:

发现 node 节点可以降下来了,查看 memory 面板:

对比Snapshot 5,分离的元素没有新增,说明这个版本基本修复了这个问题。

结论

React 16.8.6 (16.2.5到16.12.0 可能会有,这些版本没有验证,但是 issue 里面有人遇到)的版本会存在内存泄露问题,建议升级 React 到 16.13.0 以上。

查看原文

赞 13 收藏 2 评论 2

Moorez 赞了回答 · 2020-03-26

解决css 怎么将一个div做成高斯模糊

近期有个新的功能,先写下,作为参考

.navbar {
    /* Safari for macOS & iOS */
    -webkit-backdrop-filter: blur(15px); 
    /* Google Chrome */
    backdrop-filter: blur(15px); 
    /* 设置背景半透明黑色 */
    background: rgba(0, 0, 0, 0.8); 
}

参考 https://developer.mozilla.org...

关注 4 回答 4

Moorez 赞了文章 · 2020-03-20

React性能优化总结

文章同步于Github Pines-Cheng/blog

初学者对React可能满怀期待,觉得React可能完爆其它一切框架,甚至不切实际地认为React可能连原生的渲染都能完爆——对框架的狂热确实会出现这样的不切实际的期待。让我们来看看React的官方是怎么说的。React官方文档在Advanced Performanec这一节,这样写道:

One of the first questions people ask when considering React for a project is whether their application will be as fast and responsive as an equivalent non-React version

显然React自己也其实只是想尽量达到跟非React版本相当的性能。

你所不知道的render

react的组件渲染分为初始化渲染和更新渲染。
在初始化渲染的时候会调用根组件下的所有组件的render方法进行渲染,如下图(绿色表示已渲染,这一层是没有问题的):

图片描述

但是当我们要更新某个子组件的时候,如下图的绿色组件(从根组件传递下来应用在绿色组件上的数据发生改变):

图片描述

我们的理想状态是只调用关键路径上组件的render,如下图:

图片描述

但是react的默认做法是调用所有组件的render,再对生成的虚拟DOM进行对比,如不变则不进行更新。这样的render和虚拟DOM的对比明显是在浪费,如下图(黄色表示浪费的render和虚拟DOM对比)

图片描述

Tips:

  • 拆分组件是有利于复用和组件优化的。

  • 生成虚拟DOM并进行比对发生在render()后,而不是render()前。

更新阶段的生命周期

  • componentWillReceiveProps(object nextProps):当挂载的组件接收到新的props时被调用。此方法应该被用于比较this.props 和 nextProps以用于使用this.setState()执行状态转换。(组件内部数据有变化,使用state,但是在更新阶段又要在props改变的时候改变state,则在这个生命周期里面)

  • shouldComponentUpdate(object nextProps, object nextState): -boolean 当组件决定任何改变是否要更新到DOM时被调用。作为一个优化实现比较this.props 和 nextProps 、this.state 和 nextState ,如果React应该跳过更新,返回false。

  • componentWillUpdate(object nextProps, object nextState):在更新发生前被立即调用。你不能在此调用this.setState()

  • componentDidUpdate(object prevProps, object prevState): 在更新发生后被立即调用。(可以在DOM更新完之后,做一些收尾的工作)

Tips:

  • React的优化是基于shouldComponentUpdate的,该生命周期默认返回true,所以一旦prop或state有任何变化,都会引起重新render。

shouldComponentUpdate

react在每个组件生命周期更新的时候都会调用一个shouldComponentUpdate(nextProps, nextState)函数。它的职责就是返回true或false,true表示需要更新,false表示不需要,默认返回为true,即便你没有显示地定义 shouldComponentUpdate 函数。这就不难解释上面发生的资源浪费了。

为了进一步说明问题,我们再引用一张官网的图来解释,如下图( SCU表示shouldComponentUpdate,绿色表示返回true(需要更新),红色表示返回false(不需要更新);vDOMEq表示虚拟DOM比对,绿色表示一致(不需要更新),红色表示发生改变(需要更新)):

图片描述

根据渲染流程,首先会判断shouldComponentUpdate(SCU)是否需要更新。如果需要更新,则调用组件的render生成新的虚拟DOM,然后再与旧的虚拟DOM对比(vDOMEq),如果对比一致就不更新,如果对比不同,则根据最小粒度改变去更新DOM;如果SCU不需要更新,则直接保持不变,同时其子元素也保持不变。

  • C1根节点,绿色SCU (true),表示需要更新,然后vDOMEq红色,表示虚拟DOM不一致,需要更新。

  • C2节点,红色SCU (false),表示不需要更新,所以C4,C5均不再进行检查

  • C3节点同C1,需要更新

  • C6节点,绿色SCU (true),表示需要更新,然后vDOMEq红色,表示虚拟DOM不一致,更新DOM。

  • C7节点同C2

  • C8节点,绿色SCU (true),表示需要更新,然后vDOMEq绿色,表示虚拟DOM一致,不更新DOM。

带坑的写法:

  • {...this.props} (不要滥用,请只传递component需要的props,传得太多,或者层次传得太深,都会加重shouldComponentUpdate里面的数据比较负担,因此,请慎用spread attributes(<Component {...props} />))。

  • ::this.handleChange()。(请将方法的bind一律置于constructor)

  • this.handleChange.bind(this,id)

  • 复杂的页面不要在一个组件里面写完。

  • 请尽量使用const element

  • map里面添加key,并且key不要使用index(可变的)。具体可参考使用Perf工具研究React Key对渲染的影响

  • 尽量少用setTimeOut或不可控的refs、DOM操作。

  • propsstate的数据尽可能简单明了,扁平化。

  • 使用return null而不是CSS的display:none来控制节点的显示隐藏。保证同一时间页面的DOM节点尽可能的少。

性能检测工具

React官方提供的:React.addons.Perf

react官方提供一个插件React.addons.Perf可以帮助我们分析组件的性能,以确定是否需要优化。
打开console面板,先输入Perf.start()执行一些组件操作,引起数据变动,组件更新,然后输入Perf.stop()。(建议一次只执行一个操作,好进行分析)
再输入Perf.printInclusive查看所有涉及到的组件render,如下图(官方图片):
Flfo-tdhVWQNu3Qou1bPgIlHFLln

或者输入Perf.printWasted()查看下不需要的的浪费组件render,如下图(官方图片):
Fpcch1iZkcJU9U-mlUxjnX9lcO9S

优化前:
FuX9A-2VfmgFMDycQYvtnR1ovBEb
优化后:
Fi4w1W_Fq4A3eUdsv_0U67Z5WZ8N

其他的检测工具

react-perf-tool为React应用提供了一种可视化的性能检测方案,该工程同样是基于React.addons,但是使用图表来显示结果,更加方便。
图片描述

React官方的解决方案

PureRenderMixin(es5)

var PureRenderMixin = require('react-addons-pure-render-mixin');
React.createClass({
  mixins: [PureRenderMixin],

  render: function() {
    return <div className={this.props.className}>foo</div>;
  }
});

Shallow Compare (es6)

var shallowCompare = require('react-addons-shallow-compare');
export class SampleComponent extends React.Component {
  shouldComponentUpdate(nextProps, nextState) {
    return shallowCompare(this, nextProps, nextState);
  }

  render() {
    return <div className={this.props.className}>foo</div>;
  }
}

es7装饰器的写法:

import pureRender from "pure-render-decorator"
...

@pureRender
class Person  extends Component {
  render() {
    console.log("我re-render了");
    const {name,age} = this.props;

      return (
        <div>
          <span>姓名:</span>
          <span>{name}</span>
          <span> age:</span>
          <span>{age}</span>
        </div>
      )
  }
}

pureRender很简单,就是把传进来的component的shouldComponentUpdate给重写掉了,原来的shouldComponentUpdate,无论怎样都是return ture,现在不了,我要用shallowCompare比一比,shallowCompare代码及其简单,如下:

function shallowCompare(instance, nextProps, nextState) {
  return !shallowEqual(instance.props, nextProps) || !shallowEqual(instance.state, nextState);
}

缺点

shallowEqual其实只比较props的第一层子属性是不是相同,如果props是如下

{
  detail: {
    name: "123",
    age: "123"
  }
}

他只会比较props.detail ===nextProps.detail,导致在传入复杂的数据的情况下,优化失效。

补充(4.25)

React在15.3.0里面加入了了React.PureComponent - 一个可继承的新的基础类, 用来替换react-addons-pure-render-mixin。用法:

class CounterButton extends React.PureComponent {
  constructor(props) {
    super(props);
    this.state = {count: 1};
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}

在ES6里面写起来简直爽歪歪,可惜一样只支持浅比较。

immutable.js

我们也可以在 shouldComponentUpdate() 中使用使用 deepCopy 和 deepCompare 来避免无必要的 render(),但 deepCopy 和 deepCompare 一般都是非常耗性能的。

Immutable Data 就是一旦创建,就不能再被更改的数据。对 Immutable 对象的任何修改或添加删除操作都会返回一个新的 Immutable 对象。

Immutable 实现的原理是 Persistent Data Structure(持久化数据结构),也就是使用旧数据创建新数据时,要保证旧数据同时可用且不变。同时为了避免 deepCopy 把所有节点都复制一遍带来的性能损耗,Immutable 使用了 Structural Sharing(结构共享),即如果对象树中一个节点发生变化,只修改这个节点和受它影响的父节点,其它节点则进行共享。请看下面动画:

FpPDekdncL-A9N69NnI3-O8CgGQ8

Immutable 则提供了简洁高效的判断数据是否变化的方法,只需 === 和 is 比较就能知道是否需要执行 render(),而这个操作几乎 0 成本,所以可以极大提高性能。修改后的 shouldComponentUpdate 是这样的:

import { is } from 'immutable';

shouldComponentUpdate: (nextProps = {}, nextState = {}) => {
  const thisProps = this.props || {}, thisState = this.state || {};

  if (Object.keys(thisProps).length !== Object.keys(nextProps).length ||
      Object.keys(thisState).length !== Object.keys(nextState).length) {
    return true;
  }

  for (const key in nextProps) {
    if (!is(thisProps[key], nextProps[key])) {
      return true;
    }
  }

  for (const key in nextState) {
    if (thisState[key] !== nextState[key] || !is(thisState[key], nextState[key])) {
      return true;
    }
  }
  return false;
}

react-immutable-render-mixin

这是一个facebook/immutable-js的react pure render mixin 的库,可以简化很多写法。
使用react-immutable-render-mixin可以实现装饰器的写法。

import React from 'react';
import { immutableRenderDecorator } from 'react-immutable-render-mixin';

@immutableRenderDecorator
class Test extends React.Component {
  render() {
    return <div></div>;
  }
}

这里可参考我的另一篇blog:使用immutable优化React

无状态组件

为了避免一定程度的浪费,react官方还在0.14版本中加入了无状态组件
这种组件没有状态,没有生命周期,只是简单的接受 props 渲染生成 DOM 结构。无状态组件非常简单,开销很低,如果可能的话尽量使用无状态组件。比如使用箭头函数定义:

// es6
const HelloMessage = (props) => <div> Hello {props.name}</div>;
render(<HelloMessage name="John" />, mountNode);

因为无状态组件只是函数,所以它没有实例返回,这点在想用 refs 获取无状态组件的时候要注意,参见DOM 操作。

高阶组件(接下来的方向)

大部分使用mixin和class extends的地方,高阶组件都是更好的方案——毕竟组合优于继承

参考文章

使用ES6编写React应用(4):使用高阶组件替代Mixins
Mixin 已死,Composition 万岁

React同构直出(接下来方向)

同构基于服务端渲染,却不止是服务端渲染。

React在减少重复渲染方面确实是有一套独特的处理办法,那就是virtual DOM,但显示在首次渲染的时候React绝无可能超越原生的速度。因此,我们在做优化的时候,接下来可以做的事情就是:

  • 首屏时间可能会比较原生的慢一些,但可以尝试用React Server Render (又称Isomorphic)去提高效率

参考文章

React同构直出优化总结
腾讯新闻React同构直出优化实践

参考文章

react组件性能优化探索实践
React移动web极致优化
React vs Angular 2:冰与火之歌

时间仓促,难免有遗漏,如果觉得对你有帮助,请点推荐

查看原文

赞 106 收藏 124 评论 5

Moorez 发布了文章 · 2019-12-01

IVWEB 玩转 WASM 系列-WEBGL YUV渲染图像实践

最近团队在用 WASM + FFmpeg 打造一个 WEB 播放器。我们是通过写 C 语言用 FFmpeg 解码视频,通过编译 C 语言转 WASM 运行在浏览器上与 JavaScript 进行通信。默认 FFmpeg 去解码出来的数据是 yuv,而 canvas 只支持渲染 rgb,那么此时我们有两种方法处理这个yuv,第一个使用 FFmpeg 暴露的方法将 yuv 直接转成 rgb 然后给 canvas 进行渲染,第二个使用 webgl 将 yuv 转 rgb ,在 canvas 上渲染。第一个好处是写法很简单,只需 FFmpeg 暴露的方法将 yuv 直接转成 rgb ,缺点呢就是会耗费一定的cpu,第二个好处是会利用 gpu 进行加速,缺点是写法比较繁琐,而且需要熟悉 WEBGL 。考虑到为了减少 cpu 的占用,利用 gpu 进行并行加速,我们采用了第二种方法。

在讲 YUV 之前,我们先来看下 YUV 是怎么获取到的:
实现播放器必定要经过的步骤
由于我们是写播放器,实现一个播放器的步骤必定会经过以下这几个步骤:

  1. 将视频的文件比如 mp4,avi,flv等等,mp4,avi,flv 相当于是一个容器,里面包含一些信息,比如压缩的视频,压缩的音频等等, 进行解复用,从容器里面提取出压缩的视频以及音频,压缩的视频一般是 H265、H264 格式或者其他格式,压缩的音频一般是 aac或者 mp3。
  2. 分别在压缩的视频和压缩的音频进行解码,得到原始的视频和音频,原始的音频数据一般是pcm ,而原始的视频数据一般是 yuv 或者 rgb。
  3. 然后进行音视频的同步。

可以看到解码压缩的视频数据之后,一般就会得到 yuv。

YUV

YUV 是什么

对于前端开发者来说,YUV 其实有点陌生,对于搞过音视频开发的一般会接触到这个,简单来说,YUV 和我们熟悉的 RGB 差不多,都是颜色编码方式,只不过它们的三个字母代表的意义与 RGB 不同,YUV 的 “Y” 表示明亮度(Luminance或Luma),也就是灰度值;而 ”U” 和 ”V” 表示的则是色度(Chrominance或Chroma),描述影像色彩及饱和度,用于指定像素的颜色。

为了让大家对 YUV 有更加直观的感受,我们来看下,Y,U,V 单独显示分别是什么样子,这里使用了 FFmpeg 命令将一张火影忍者的宇智波鼬图片转成YUV420P:

ffmpeg -i frame.jpg -s 352x288 -pix_fmt yuv420p test.yuv

GLYUVPlay软件上打开 test.yuv,显示原图:
原图
Y分量单独显示:
Y
U分量单独显示:
U
V 分量单独显示:
V
由上面可以发现,Y 单独显示的时候是可以显示完整的图像的,只不过图片是灰色的。而U,V则代表的是色度,一个偏蓝,一个偏红。

使用YUV 的好处

  1. 由刚才看到的那样,Y 单独显示是黑白图像,因此YUV格式由彩色转黑白很简单,可以兼容老式黑白电视,这一特性用在于电视信号上。
  2. YUV的数据尺寸一般都比RGB格式小,可以节约传输的带宽。(但如果用YUV444的话,和RGB24一样都是24位)

YUV 采样

常见的YUV的采样有YUV444,YUV422,YUV420:

注:黑点表示采样该像素点的Y分量,空心圆圈表示采用该像素点的UV分量。
  1. YUV 4:4:4采样,每一个Y对应一组UV分量。
  2. YUV 4:2:2采样,每两个Y共用一组UV分量。
  3. YUV 4:2:0采样,每四个Y共用一组UV分量。

YUV 存储方式

YUV的存储格式有两类:packed(打包)和 planar(平面):

  • packed 的YUV格式,每个像素点的Y,U,V是连续交错存储的。
  • planar 的YUV格式,先连续存储所有像素点的Y,紧接着存储所有像素点的U,随后是所有像素点的V。

举个例子,对于 planar 模式,YUV 可以这么存 YYYYUUVV,对于 packed 模式,YUV 可以这么存YUYVYUYV。

YUV 格式一般有多种,YUV420SP、YUV420P、YUV422P,YUV422SP等,我们来看下比较常见的格式:

  • YUV420P(每四个 Y 会共用一组 UV 分量):

  • YUV420SP(packed,每四个 Y 会共用一组 UV 分量,和YUV420P不同的是,YUV420SP存储的时候 U,V 是交错存储):

  • YUV422P(planar,每两个 Y 共用一组 UV 分量,所以 U和 V 会比 YUV420P U 和 V 各多加一行):

  • YUV422SP(packed,每两个 Y 共用一组 UV 分量):

其中YUV420P和YUV420SP根据U、V的顺序,又可分出2种格式:

  • YUV420P:U前V后即YUV420P,也叫I420,V前U后,叫YV12
  • YUV420SP:U前V后叫NV12,V前U后叫NV21

数据排列如下:

I420: YYYYYYYY UU VV =>YUV420P

YV12: YYYYYYYY VV UU =>YUV420P

NV12: YYYYYYYY UV UV =>YUV420SP

NV21: YYYYYYYY VU VU =>YUV420SP

至于为啥会有这么多格式,经过大量搜索发现原因是为了适配不同的电视广播制式和设备系统,比如 ios 下只有这一种模式NV12,安卓的模式是 NV21,比如 YUV411YUV420格式多见于数码摄像机数据中,前者用于 NTSC 制,后者用于 PAL制。至于电视广播制式的介绍我们可以看下这篇文章【标准】NTSC、PAL、SECAM三大制式简介

YUV 计算方法

以YUV420P存储一张1080 x 1280图片为例子,其存储大小为 ((1080 x 1280 x 3) >> 1) 个字节,这个是怎么算出来的?我们来看下面这张图:

以 Y420P 存储那么 Y 占的大小为 W x H = 1080x1280,U 为(W/2) * (H/2)= (W*H)/4 = (1080x1280)/4,同理 V为
(W*H)/4 = (1080x1280)/4,因此一张图为 Y+U+V = (1080x1280)*3/2
由于三个部分内部均是行优先存储,三个部分之间是Y,U,V 顺序存储,那么YUV的存储位置如下(PS:后面会用到):

Y:0 到 1080*1280
U:1080*1280 到 (1080*1280)*5/4
V:(1080*1280)*5/4 到 (1080*1280)*3/2

## WEBGL

WEBGL 是什么

简单来说,WebGL是一项用来在网页上绘制和渲染复杂3D图形,并允许用户与之交互的技术。

WEBGL 组成

在 webgl 世界中,能绘制的基本图形元素只有点、线、三角形,每个图像都是由大大小小的三角形组成,如下图,无论是多么复杂的图形,其基本组成部分都是由三角形组成。

图来源于网络

着色器

着色器是在GPU上运行的程序,是用OpenGL ES着色语言编写的,有点类似 c 语言:

具体的语法可以参考着色器语言 GLSL (opengl-shader-language)入门大全,这里不在多加赘述。

在 WEBGL 中想要绘制图形就必须要有两个着色器:

  • 顶点着色器
  • 片元着色器

其中顶点着色器的主要功能就是用来处理顶点的,而片元着色器则是用来处理由光栅化阶段生成的每个片元(PS:片元可以理解为像素),最后计算出每个像素的颜色。

WEBGL 绘制流程

一、提供顶点坐标
因为程序很傻,不知道图形的各个顶点,需要我们自己去提供,顶点坐标可以是自己手动写或者是由软件导出:

在这个图中,我们把顶点写入到缓冲区里,缓冲区对象是WebGL系统中的一块内存区域,我们可以一次性地向缓冲区对象中填充大量的顶点数据,然后将这些数据保存在其中,供顶点着色器使用。接着我们创建并编译顶点着色器和片元着色器,并用 program 连接两个着色器,并使用。举个例子简单理解下为什么要这样做,我们可以理解成创建Fragment 元素: let f = document.createDocumentFragment()
所有的着色器创建并编译后会处在一种游离的状态,我们需要将他们联系起来,并使用(可以理解成 document.body.appendChild(f),添加到 body,dom 元素才能被看到,也就是联系并使用)。
接着我们还需要将缓冲区与顶点着色器进行连接,这样才能生效。

二、图元装配
我们提供顶点之后,GPU根据我们提供的顶点数量,会挨个执行顶点着色器程序,生成顶点最终的坐标,将图形装配起来。可以理解成制作风筝,就需要将风筝骨架先搭建起来,图元装配就是在这一阶段。

三、光栅化
这一阶段就好比是制作风筝,搭建好风筝骨架后,但是此时却不能飞起来,因为里面都是空的,需要为骨架添加布料。而光栅化就是在这一阶段,将图元装配好的几何图形转成片元(PS: 片元可以理解成像素)。

四、着色与渲染

着色这一阶段就好比风筝布料搭建完成,但是此时并没有什么图案,需要绘制图案,让风筝更加好看,也就是光栅化后的图形此时并没有颜色,需要经过片元着色器处理,逐片元进行上色并写到颜色缓冲区里,最后在浏览器才能显示有图像的几何图形。

总结
WEBGL 绘制流程可以归纳为以下几点:

  1. 提供顶点坐标(需要我们提供)
  2. 图元装配(按图元类型组装成图形)
  3. 光栅化(将图元装配好的图形,生成像素点)
  4. 提供颜色值(可以动态计算,像素着色)
  5. 通过 canvas 绘制在浏览器上。

WEBGL YUV 绘制图像思路

由于每个视频帧的图像都不太一样,我们肯定不可能知道那么多顶点,那么我们怎么将视频帧的图像用 webgl 画出来呢?这里使用了一个技巧—纹理映射。简单来说就是将一张图像贴在一个几何图形表面,使几何图形看起来像是有图像的几何图形,也就是将纹理坐标和 webgl 系统坐标进行一一对应:


如上图,上面那个是纹理坐标,分为 s 和 t 坐标(或者叫 uv 坐标),值的范围在【0,1】之间,值和图像大小、分辨率无关。下面那张图是webgl坐标系统,是一个三维的坐标系统,这里声明了四个顶点,用两个三角形组装成一个长方形,然后将纹理坐标的顶点与 webgl 坐标系进行一一对应,最终传给片元着色器,片元着色器提取图片的一个个纹素颜色,输出在颜色缓冲区里,最终绘制在浏览器里(PS:纹素你可以理解为组成纹理图像的像素)。但是如果按图上进行一一对应的话,成像会是反的,因为 canvas 的图像坐标,默认(0,0)是在左上角:

而纹理坐标则是在左下角,所以绘制时成像就会倒立,解决方法有两种:

  • 对纹理图像进行 Y 轴翻转,webgl 提供了api:
// 1代表对纹理图像进行y轴反转
gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, 1);
  • 纹理坐标和 webgl 坐标映射进行倒转,举个栗子🌰,如上图所示,本来的纹理坐标(0.0,1.0)对应的是webgl 坐标(-1.0,1.0,0.0)(0.0,0.0)对应的是(-1.0,-1.0,0.0),那么我们倒转过来,(0.0,1.0)对应的是(-1.0,-1.0,0.0),而(0.0,0.0)对应的是(-1.0,1.0,0.0),这样在浏览器成像就不会是反的。

详细步骤

  • 着色器部分
// 顶点着色器vertexShader
attribute lowp vec4 a_vertexPosition; // 通过 js 传递顶点坐标
attribute vec2 a_texturePosition; // 通过 js 传递纹理坐标
varying vec2 v_texCoord; // 传递纹理坐标给片元着色器
void main(){
    gl_Position=a_vertexPosition;// 设置顶点坐标
    v_texCoord=a_texturePosition;// 设置纹理坐标
}


// 片元着色器fragmentShader
precision lowp float;// lowp代表计算精度,考虑节约性能使用了最低精度
uniform sampler2D samplerY;// sampler2D是取样器类型,图片纹理最终存储在该类型对象中
uniform sampler2D samplerU;// sampler2D是取样器类型,图片纹理最终存储在该类型对象中
uniform sampler2D samplerV;// sampler2D是取样器类型,图片纹理最终存储在该类型对象中
varying vec2 v_texCoord; // 接受顶点着色器传来的纹理坐标
void main(){
  float r,g,b,y,u,v,fYmul;
  y = texture2D(samplerY, v_texCoord).r;
  u = texture2D(samplerU, v_texCoord).r;
  v = texture2D(samplerV, v_texCoord).r;
    
    // YUV420P 转 RGB    
  fYmul = y * 1.1643828125;
  r = fYmul + 1.59602734375 * v - 0.870787598;
  g = fYmul - 0.39176171875 * u - 0.81296875 * v + 0.52959375;
  b = fYmul + 2.01723046875 * u - 1.081389160375;
  gl_FragColor = vec4(r, g, b, 1.0);
}
  • 创建并编译着色器,将顶点着色器和片段着色器连接到 program,并使用:
let vertexShader=this._compileShader(vertexShaderSource,gl.VERTEX_SHADER);// 创建并编译顶点着色器
let fragmentShader=this._compileShader(fragmentShaderSource,gl.FRAGMENT_SHADER);// 创建并编译片元着色器

let program=this._createProgram(vertexShader,fragmentShader);// 创建program并连接着色器
  • 创建缓冲区,存顶点和纹理坐标(PS:缓冲区对象是WebGL系统中的一块内存区域,我们可以一次性地向缓冲区对象中填充大量的顶点数据,然后将这些数据保存在其中,供顶点着色器使用)。
let vertexBuffer = gl.createBuffer();
let vertexRectangle = new Float32Array([
    1.0,
    1.0,
    0.0,
    -1.0,
    1.0,
    0.0,
    1.0,
    -1.0,
    0.0,
    -1.0,
    -1.0,
    0.0
]);
gl.bindBuffer(gl.ARRAY_BUFFER, vertexBuffer);
// 向缓冲区写入数据
gl.bufferData(gl.ARRAY_BUFFER, vertexRectangle, gl.STATIC_DRAW);
// 找到顶点的位置
let vertexPositionAttribute = gl.getAttribLocation(program, 'a_vertexPosition');
// 告诉显卡从当前绑定的缓冲区中读取顶点数据
gl.vertexAttribPointer(vertexPositionAttribute, 3, gl.FLOAT, false, 0, 0);
// 连接vertexPosition 变量与分配给它的缓冲区对象
gl.enableVertexAttribArray(vertexPositionAttribute);

// 声明纹理坐标
let textureRectangle = new Float32Array([1.0, 0.0, 0.0, 0.0, 1.0, 1.0, 0.0, 1.0]);
let textureBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, textureBuffer);
gl.bufferData(gl.ARRAY_BUFFER, textureRectangle, gl.STATIC_DRAW);
let textureCoord = gl.getAttribLocation(program, 'a_texturePosition');
gl.vertexAttribPointer(textureCoord, 2, gl.FLOAT, false, 0, 0);
gl.enableVertexAttribArray(textureCoord); 
  • 初始化并激活纹理单元(YUV)
//激活指定的纹理单元
gl.activeTexture(gl.TEXTURE0);
gl.y=this._createTexture(); // 创建纹理
gl.uniform1i(gl.getUniformLocation(program,'samplerY'),0);//获取samplerY变量的存储位置,指定纹理单元编号0将纹理对象传递给samplerY

gl.activeTexture(gl.TEXTURE1);
gl.u=this._createTexture();
gl.uniform1i(gl.getUniformLocation(program,'samplerU'),1);//获取samplerU变量的存储位置,指定纹理单元编号1将纹理对象传递给samplerU

gl.activeTexture(gl.TEXTURE2);
gl.v=this._createTexture();
gl.uniform1i(gl.getUniformLocation(program,'samplerV'),2);//获取samplerV变量的存储位置,指定纹理单元编号2将纹理对象传递给samplerV
  • 渲染绘制(PS:由于我们获取到的数据是YUV420P,那么计算方法可以参考刚才说的计算方式)。
 // 设置清空颜色缓冲时的颜色值
 gl.clearColor(0, 0, 0, 0);
 // 清空缓冲
 gl.clear(gl.COLOR_BUFFER_BIT);

let uOffset = width * height;
let vOffset = (width >> 1) * (height >> 1);

gl.bindTexture(gl.TEXTURE_2D, gl.y);
// 填充Y纹理,Y 的宽度和高度就是 width,和 height,存储的位置就是data.subarray(0, width * height)
gl.texImage2D(
    gl.TEXTURE_2D,
    0,
    gl.LUMINANCE,
    width,
    height,
    0,
    gl.LUMINANCE,
    gl.UNSIGNED_BYTE,
    data.subarray(0, uOffset)
);

gl.bindTexture(gl.TEXTURE_2D, gl.u);
// 填充U纹理,Y 的宽度和高度就是 width/2 和 height/2,存储的位置就是data.subarray(width * height, width/2 * height/2 + width * height)
gl.texImage2D(
    gl.TEXTURE_2D,
    0,
    gl.LUMINANCE,
    width >> 1,
    height >> 1,
    0,
    gl.LUMINANCE,
    gl.UNSIGNED_BYTE,
    data.subarray(uOffset, uOffset + vOffset)
);

gl.bindTexture(gl.TEXTURE_2D, gl.v);
// 填充U纹理,Y 的宽度和高度就是 width/2 和 height/2,存储的位置就是data.subarray(width/2 * height/2 + width * height, data.length)
gl.texImage2D(
    gl.TEXTURE_2D,
    0,
    gl.LUMINANCE,
    width >> 1,
    height >> 1,
    0,
    gl.LUMINANCE,
    gl.UNSIGNED_BYTE,
    data.subarray(uOffset + vOffset, data.length)
);

gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); // 绘制四个点,也就是长方形

上述那些步骤最终可以绘制成这张图:

完整代码:

export default class WebglScreen {
    constructor(canvas) {
        this.canvas = canvas;
        this.gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');
        this._init();
    }

    _init() {
        let gl = this.gl;
        if (!gl) {
            console.log('gl not support!');
            return;
        }
        // 图像预处理
        gl.pixelStorei(gl.UNPACK_ALIGNMENT, 1);
        // GLSL 格式的顶点着色器代码
        let vertexShaderSource = `
            attribute lowp vec4 a_vertexPosition;
            attribute vec2 a_texturePosition;
            varying vec2 v_texCoord;
            void main() {
                gl_Position = a_vertexPosition;
                v_texCoord = a_texturePosition;
            }
        `;

        let fragmentShaderSource = `
            precision lowp float;
            uniform sampler2D samplerY;
            uniform sampler2D samplerU;
            uniform sampler2D samplerV;
            varying vec2 v_texCoord;
            void main() {
                float r,g,b,y,u,v,fYmul;
                y = texture2D(samplerY, v_texCoord).r;
                u = texture2D(samplerU, v_texCoord).r;
                v = texture2D(samplerV, v_texCoord).r;

                fYmul = y * 1.1643828125;
                r = fYmul + 1.59602734375 * v - 0.870787598;
                g = fYmul - 0.39176171875 * u - 0.81296875 * v + 0.52959375;
                b = fYmul + 2.01723046875 * u - 1.081389160375;
                gl_FragColor = vec4(r, g, b, 1.0);
            }
        `;

        let vertexShader = this._compileShader(vertexShaderSource, gl.VERTEX_SHADER);
        let fragmentShader = this._compileShader(fragmentShaderSource, gl.FRAGMENT_SHADER);

        let program = this._createProgram(vertexShader, fragmentShader);

        this._initVertexBuffers(program);

        // 激活指定的纹理单元
        gl.activeTexture(gl.TEXTURE0);
        gl.y = this._createTexture();
        gl.uniform1i(gl.getUniformLocation(program, 'samplerY'), 0);

        gl.activeTexture(gl.TEXTURE1);
        gl.u = this._createTexture();
        gl.uniform1i(gl.getUniformLocation(program, 'samplerU'), 1);

        gl.activeTexture(gl.TEXTURE2);
        gl.v = this._createTexture();
        gl.uniform1i(gl.getUniformLocation(program, 'samplerV'), 2);
    }
    /**
     * 初始化顶点 buffer
     * @param {glProgram} program 程序
     */

    _initVertexBuffers(program) {
        let gl = this.gl;
        let vertexBuffer = gl.createBuffer();
        let vertexRectangle = new Float32Array([
            1.0,
            1.0,
            0.0,
            -1.0,
            1.0,
            0.0,
            1.0,
            -1.0,
            0.0,
            -1.0,
            -1.0,
            0.0
        ]);
        gl.bindBuffer(gl.ARRAY_BUFFER, vertexBuffer);
        // 向缓冲区写入数据
        gl.bufferData(gl.ARRAY_BUFFER, vertexRectangle, gl.STATIC_DRAW);
        // 找到顶点的位置
        let vertexPositionAttribute = gl.getAttribLocation(program, 'a_vertexPosition');
        // 告诉显卡从当前绑定的缓冲区中读取顶点数据
        gl.vertexAttribPointer(vertexPositionAttribute, 3, gl.FLOAT, false, 0, 0);
        // 连接vertexPosition 变量与分配给它的缓冲区对象
        gl.enableVertexAttribArray(vertexPositionAttribute);

        let textureRectangle = new Float32Array([1.0, 0.0, 0.0, 0.0, 1.0, 1.0, 0.0, 1.0]);
        let textureBuffer = gl.createBuffer();
        gl.bindBuffer(gl.ARRAY_BUFFER, textureBuffer);
        gl.bufferData(gl.ARRAY_BUFFER, textureRectangle, gl.STATIC_DRAW);
        let textureCoord = gl.getAttribLocation(program, 'a_texturePosition');
        gl.vertexAttribPointer(textureCoord, 2, gl.FLOAT, false, 0, 0);
        gl.enableVertexAttribArray(textureCoord);
    }

    /**
     * 创建并编译一个着色器
     * @param {string} shaderSource GLSL 格式的着色器代码
     * @param {number} shaderType 着色器类型, VERTEX_SHADER 或 FRAGMENT_SHADER。
     * @return {glShader} 着色器。
     */
    _compileShader(shaderSource, shaderType) {
        // 创建着色器程序
        let shader = this.gl.createShader(shaderType);
        // 设置着色器的源码
        this.gl.shaderSource(shader, shaderSource);
        // 编译着色器
        this.gl.compileShader(shader);
        const success = this.gl.getShaderParameter(shader, this.gl.COMPILE_STATUS);
        if (!success) {
            let err = this.gl.getShaderInfoLog(shader);
            this.gl.deleteShader(shader);
            console.error('could not compile shader', err);
            return;
        }

        return shader;
    }

    /**
     * 从 2 个着色器中创建一个程序
     * @param {glShader} vertexShader 顶点着色器。
     * @param {glShader} fragmentShader 片断着色器。
     * @return {glProgram} 程序
     */
    _createProgram(vertexShader, fragmentShader) {
        const gl = this.gl;
        let program = gl.createProgram();

        // 附上着色器
        gl.attachShader(program, vertexShader);
        gl.attachShader(program, fragmentShader);

        gl.linkProgram(program);
        // 将 WebGLProgram 对象添加到当前的渲染状态中
        gl.useProgram(program);
        const success = this.gl.getProgramParameter(program, this.gl.LINK_STATUS);

        if (!success) {
            console.err('program fail to link' + this.gl.getShaderInfoLog(program));
            return;
        }

        return program;
    }

    /**
     * 设置纹理
     */
    _createTexture(filter = this.gl.LINEAR) {
        let gl = this.gl;
        let t = gl.createTexture();
        // 将给定的 glTexture 绑定到目标(绑定点
        gl.bindTexture(gl.TEXTURE_2D, t);
        // 纹理包装 参考https://github.com/fem-d/webGL/blob/master/blog/WebGL基础学习篇(Lesson%207).md -> Texture wrapping
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE);
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE);
        // 设置纹理过滤方式
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, filter);
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, filter);
        return t;
    }

    /**
     * 渲染图片出来
     * @param {number} width 宽度
     * @param {number} height 高度
     */
    renderImg(width, height, data) {
        let gl = this.gl;
        // 设置视口,即指定从标准设备到窗口坐标的x、y仿射变换
        gl.viewport(0, 0, gl.canvas.width, gl.canvas.height);
        // 设置清空颜色缓冲时的颜色值
        gl.clearColor(0, 0, 0, 0);
        // 清空缓冲
        gl.clear(gl.COLOR_BUFFER_BIT);

        let uOffset = width * height;
        let vOffset = (width >> 1) * (height >> 1);

        gl.bindTexture(gl.TEXTURE_2D, gl.y);
        // 填充纹理
        gl.texImage2D(
            gl.TEXTURE_2D,
            0,
            gl.LUMINANCE,
            width,
            height,
            0,
            gl.LUMINANCE,
            gl.UNSIGNED_BYTE,
            data.subarray(0, uOffset)
        );

        gl.bindTexture(gl.TEXTURE_2D, gl.u);
        gl.texImage2D(
            gl.TEXTURE_2D,
            0,
            gl.LUMINANCE,
            width >> 1,
            height >> 1,
            0,
            gl.LUMINANCE,
            gl.UNSIGNED_BYTE,
            data.subarray(uOffset, uOffset + vOffset)
        );

        gl.bindTexture(gl.TEXTURE_2D, gl.v);
        gl.texImage2D(
            gl.TEXTURE_2D,
            0,
            gl.LUMINANCE,
            width >> 1,
            height >> 1,
            0,
            gl.LUMINANCE,
            gl.UNSIGNED_BYTE,
            data.subarray(uOffset + vOffset, data.length)
        );

        gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);
    }

    /**
     * 根据重新设置 canvas 大小
     * @param {number} width 宽度
     * @param {number} height 高度
     * @param {number} maxWidth 最大宽度
     */
    setSize(width, height, maxWidth) {
        let canvasWidth = Math.min(maxWidth, width);
        this.canvas.width = canvasWidth;
        this.canvas.height = canvasWidth * height / width;
    }

    destroy() {
        const {
            gl
        } = this;

        gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT | gl.STENCIL_BUFFER_BIT);
    }
}

最后我们来看下效果图:

遇到的问题

在实际开发过程中,我们测试一些直播流,有时候渲染的时候图像显示是正常的,但是颜色会偏绿,经研究发现,直播流的不同主播的视频宽度是会不一样,比如在主播在 pk 的时候宽度368,热门主播宽度会到 720,小主播宽度是 540,而宽度为 540 的会显示偏绿,具体原因是 webgl 会经过预处理,默认会将以下值设置为 4:

// 图像预处理
gl.pixelStorei(gl.UNPACK_ALIGNMENT, 4);

这样默认设置会每行 4 个字节 4 个字节处理,而 Y分量每行的宽度是 540,是 4 的倍数,字节对齐了,所以图像能够正常显示,而 U,V 分量宽度是 540 / 2 = 270,270 不是4 的倍数,字节非对齐,因此色素就会显示偏绿。目前有两种方法可以解决这个问题:

  • 第一个是直接让 webgl 每行 1 个字节 1 个字节处理(对性能有影响):
// 图像预处理
gl.pixelStorei(gl.UNPACK_ALIGNMENT, 1);
  • 第二个是让获取到的图像的宽度是 8 的倍数,这样就能做到 YUV 字节对齐,就不会显示绿屏,但是不建议这样做, 转的时候CPU占用极大,建议采取第一个方案。

参考文章

图像视频编码和FFmpeg(2)——YUV格式介绍和应用 - eustoma - 博客园
YUV pixel formats
https://wiki.videolan.org/YUV/
使用 8 位 YUV 格式的视频呈现 | Microsoft Docs?redirectedfrom=MSDN)
IOS 视频格式之YUV - 简书
图解WebGL&Three.js工作原理 - cnwander - 博客园

查看原文

赞 6 收藏 2 评论 0

Moorez 发布了文章 · 2019-10-15

页面CPU和内存占用监控可视化Chrome插件-Graph Process

写这个插件的原因是最近要对比一下页面的 cpu 和内存占用的性能,本来是想找看看有没有什么软件能够去可视化一下当前标签页的cpu和内存占用,但是发现却找不到这种软件,mac 上有个活动监视器,但是当你开很多标签页的话并不很好的监听当前标签页的 cpu 和内存占用,能看到谷歌浏览器的 rendered 进程,但是谷歌浏览器的 rendered 进程很多你并不知道是哪个,

而且也没有可视化进行查看平均的 cpu 和内存占用,后来看到谷歌浏览器有个任务管理器可以查看当前标签页的 cpu 占用和内存占用,于是想到有没有人已经写了这种插件,但是遗憾的是并没有,后面仔细搜索了谷歌浏览器插件开发文档确定想要的功能能实现,于是这个插件就诞生了😀

效果图

主要功能

对当前标签页点击插件图标,会开始对当前的标签页也就是页面的CPU和内存进行监控,并生成对应的变化折线图和平均值和表格,平均值如果超过一定范围会有颜色变化。

有人可能会问页面开启扩展后会对当前页面统计造成影响,其实是不会的,谷歌扩展是独立的进程,不会对当前的页面的 cpu 和内存占用造成影响。

安装插件

注意,由于使用了谷歌浏览器的实验特性,因此插件需要运行在谷歌浏览器开发者版,由于使用了谷歌浏览器的实验特性,因此插件需要运行在谷歌浏览器开发者版,由于使用了谷歌浏览器的实验特性,因此插件需要运行在谷歌浏览器开发者版,重要的事情说三遍,可以在这里下载开发版谷歌浏览器开发者版

插件地址:https://chrome.google.com/web...

Tips

Graph Process 默认是以 popup 的形式出现的,也就是说如果你的鼠标点击 Graph Process 出现页面,然后点击其他元素的话,由于浏览器的特性失焦是会关闭 popup 页面的,如果想维持 Graph Process 的话,可以点击 Graph Process 出现页面的时候右击选择检查,然后一直不关掉那个检查页面即可一直维持 Graph Process。如果要关闭的话点击Graph Process 小图标即可关闭。

查看原文

赞 12 收藏 6 评论 9

Moorez 赞了文章 · 2019-08-30

聊聊安卓折叠屏给交互设计和开发带来的变化

很多年前,前端同学都觉得PC端的适配(兼容处理)难,都认为移动端的时代适配会容易得多,也无需考虑那么多的事情。事实并非如此,移动端的时代同样面临着各种适配的处理。特别是刘海机的出现,前端需要考虑刘海机适配。而如今随着三星Galaxy Fold和华为Mate X折叠屏手机的面世,前端同学接着又要处理折叠屏幕的适配。

就我们团队而言,在上个月就接到相关的通知,需要处理折叠屏的适配。碍于真机难得,前段时间就通过模拟机,做了一些简单的适配测试,不过幸运的是,今天拿到了真机(三星Galaxy Fold) ,写了一个简单的Demo,做了一些适配的测试。特此将相关心得和大家一起共享,希望对大家有所帮助。

折叠屏设备的相关参数

为了更好的做相应的适配处理,我们有必要先对设备相关的参数做一定的了解。

简单地说,三星Galaxy Fold和华为Mate X的最大区别即是 双屏内折叠对单屏外折叠

三星Galaxy Fold搭载了两块屏幕,一块位于机身外侧的一边,适合折叠状态下使用。这块外屏是一块4.6英寸1960 x 840 Dynamic AMOLED显示屏:

Galaxy Fold的另一块屏幕只有在机身被展开时才会出现。这块内屏尺寸达到了7.3英寸,比例为4.2:3,分辨率为 2152 x 1536

外屏的使用方式和现在手机一样,只不过小了些、边框宽了些。

内屏的大尺寸则能在玩游戏、看视频、看地图、拍照和视频通话等情况下提供更多的内容显示。大尺寸也让多任务处理不再是鸡肋,发布会现场展示的三任务同时处理让人印象深刻。

华为Mate X的折叠采用了一块外置屏幕。完全展开时,呈现在眼前的是一块 8英寸8:7.1的 2480 x 2200 OLED显示屏:

折叠起来后,一块大屏会变成两块分别位于机身正、反面的“小”屏。正面屏幕为 6.6英寸,分辨率为2480 x 1148,比例为19.5:9,是目前主流手机的屏幕比例。背面的屏幕则是一块 6.38 英寸 2480 x 892分辨率显示屏,比例为25:9

对于Web前端而言,我们主要关注的几个参数是 分辨率、 DPI 和 屏幕宽度*等。简单的将相关参数列入:

参数三星 Galaxy Fold (折叠状态)华为 Mate X (折叠状态)三星Galaxy Fold (展开状态)华为 Mate X (展开状态)
屏幕尺寸4.58英寸6.6英寸(正面);6.38英寸(背面)7.3英寸8英寸
分辨率1960px x 840px2480px x 1148px(正面);2480px x 892px(背面)2152px x 1536px2480px x 2200px
屏幕密度DPI420dpi(待真机确定)420dpi(待真机确定)
宽高比21:919.5:9(正面);25:9(背面)4.2:38:7.1
设备像素比 dpr2.6253.5(待真机确定)2.6253.5(待真机确定)
屏幕宽度(window.screen.width)320px(待真机确定)586px(待真机确定)
屏幕高度(window.screen.height)747px(待真机确定)820px(待真机确定)
视窗宽度(window.innerWidth)980px(待真机确定)981px(待真机确定)
视窗高度(window.innerHeight)1725px(待真机确定)1147px(待真机确定)

有关于设备相关的参数,我们可以通过相应的API来获取(这个很重要):

  • DPIwindow.devicePixelRatio
  • UserAgentwindow.navigator.userAgent
  • 屏幕宽度window.screen.width
  • 屏幕高度window.screen.height
  • 视窗宽度window.innerWidth
  • 视窗高度window.innerHeight

屏幕尺寸分辨率像素密度三者关系之间存在相应的计算关系:

比如屏幕分辨率为:1920px x 1080px,屏幕尺寸为 5英寸的话,那么对应的DPI440,即:

折叠屏给交互设计带来的差异化

不管是三星 Galaxy Fold的内折叠屏还是华为 Mate X的外折叠屏给我们最直观的效果类似于iPhone和iPad的差异:

折叠状态类似于iPhone;展开状态类似于iPad

屏幕宽窄的变化给我们的交互设计也会带来相关的变化。

对于Web设计而言,当折叠屏从小屏模式转变成大屏模式时不应该只是画面的等比例变大,而是要考虑响应式布局设计。描述响应式设计最著名的一句话就是:

“Content is like water,即如果将屏幕看作容器,那么内容就像水一样”

在以前响应式设计更多用在PC Web设计上,但现在折叠屏手机的出现,我们在移动端也应该考虑响应式设计,以下是设计时需要考虑的细节:

不是简单的响应式设计

折叠屏幕在 “展开”态时要考虑是平板模式还是双屏幕模式,如果是平板模式,那么内容应该在一个整体里;若是双屏幕模式则可以考虑不同屏幕展示不同内容。设计时需要根据实际需求和场景进行模式选择。

如上图所示,内容在同一个整体里,只是视觉(排版)效果上有差异

或者

上两图展示了不同的屏幕展示不同的内容

考虑通过Fragment(片段)来设计

Fragment是Android3.0提出的API,出现的初衷是为了UI更灵活地适应大屏幕的平板电脑。

Android官方对Fragment的描述是:

“Fragment表示Activity中的行为或用户界面部分。可以将多个Fragment组合在一个 Activity 中来构建多窗格 UI,以及在多个 Activity 中重复使用某个Fragment。

采用不同的Fragment来设计,可以做到不同内容在不同的屏幕展示,甚至在同一屏中可以展示多个不同的内容。对于这样的场景,交互的方式和行为都将会有所变化。比如进入每个不同的Fragment应该是怎么样的一个交互方式;比如返回按钮,滑屏等又是怎么一个交互方式。这一切都值得我们去探讨。

比如说,很有可能将来手淘就能像下面这样,在展开状态打开多个Fragment:

参考微软的UWP设计概念

UWP即Windows 10中的Universal Windows Platform(Windows通用应用平台)。

UWP应用的理念并不是为某一个终端而设计,而是同一套代码和设计可以在所有Windows10设备上运行,包括Windows 10 Mobile / Surface / PC / Xbox / HoloLens等等。它的响应式设计设计技巧包括以下6点:

下面的内容摘自《UWP 响应式程序设计介绍》一文。

调整位置

你可以改变 UI 元素在不同屏幕上的位置。比如下面这个例子:为了确保同时展示两个元素,在手机上我们必须采用纵向滚动界面,而在平板电脑上,我们可以调整框架的位置,变为横屏滚动界面。如果你用网格设计这些位置,你也可以不改变内容框架,但其他 UI 元素可以使用响应式设计。

这是一个图片应用的例子,内容框架在大屏幕上被改变了位置。

调整尺寸

你可以通过调整空白和 UI 元素的尺寸来优化框架,比如下面这个例子,可以通过简单的增大内容框架尺寸来提升大屏幕的阅读体验。

调整顺序

通过调整 UI 元素的顺序和方向,优化内容显示效果。举个例子,在大屏上运行时,可以再添加一栏,并且加入分类列表,这些都是合理的。

这个例子展示了在手机上使用一栏纵向滚动,而在平板上使用两栏横向滚动的优化。

展现

你可以基于屏幕的真实大小,设备支持的功能,特定的情况或者屏幕方向展示界面。

下图是一个含有相机按钮的 Tab 的例子。平板电脑和台式机可能没有摄像头,所以相机按钮不被显示出来。另一个例子是媒体播放器,小屏幕上这些按钮通常是被删减的,但在大屏幕上这些按钮是被完全保留的。PC 上的媒体播放器比手机上的有更多的功能。

换位

这项技巧是为特定屏幕尺寸或屏幕方向切换特定的界面。下面这个例子是导航菜单:小屏幕上他是隐藏在汉堡菜单中纵向排列的,但是在大屏幕上,更大的 Tab 是更好地选择。

改变结构

你可以为特定的设备优化特定的结构。下面这个例子就是两种不同的接合结构。

下图是一个智能家庭程序,运用了改变结构的技巧

折叠屏下的手淘将可能是这样的

UWP设计概念是一个非常好的一个概念。如果不久的将来,折叠屏为成为一个主流之一的话,除了UWP设计带来的设计和交互的变化之外,还会有其他更优秀,或更合理的交互设计概念吗?

或者简单地说,折叠屏时代的手淘将会是什么样的呢?

前面我们提到两个(或多个)Fragment的设计,如果将来的App中能在宽屏模式(折叠屏展开模式)启用多个Fragment时,我们的交互设计可许将会是这样的。

在2019年愚人节当日,淘宝设计 提出了手淘在折叠屏下的概念设计

在该文章中,作者提出折叠屏幕时代下,手淘App针对折叠屏的两大特性具体展开相应的设计。

大屏内容更丰富

在折叠屏中,顶部和底部导航性质的组件属于页面的公用功能,采取直观的 横向拉伸适配方式;而当中页面可以采用内容填充适配方式,将次级重要内容展示在第二屏

有可能将来在消息的第二屏内容是聊天窗口,能快速预览消息里的最新内容,提升聊天切换的效率。

多任务效率提升

在日常使用手机处理主任务时,经常会碰到临时通知消息等分支任务处理,主任务与分支任务场景的频繁切换给用户带来很高的操作成本。

折叠屏的 “第二屏” 可以让用户可以不离开当前场景即可便捷的处理子任务,提升多任务的处理效率。下面举例淘宝上的案例帮助大家体会多任务带来的种种便捷。

比如说,在折叠屏展开状态的模式下,你将可以一边看淘宝直播,还可以让宝贝列表呈现出更大更多的图片以及简要的信息帮助用户做初步的判断,边看边逛互不干扰

折叠屏适配姿势

都说 底层建筑将决定上层设计。这一点都不假。

在PC时代,众多前端开发者都疲于奔波处理各种不同版本浏览器客户端的兼容处理;在移动端时代,原本以为将会改变这一状况,事实并非如此。

随着iPhone6,iPhone6+的出现,不仅限于处理不同屏幕的Android设备,还需要考虑杂屏时代的iOS设备。在那个时候设计和开发为了更好的适配,采用了一种适中的设计,比如手淘设计师和前端开发的适配协作基本思路是:

  • 选择一种尺寸作为设计和开发基准
  • 定义一套适配规则,自动适配剩下的两种尺寸(其实不仅这两种,你懂的)
  • 特殊适配效果给出设计效果

手淘设计师常选择iPhone6作为基准设计尺寸,交付给前端的设计尺寸是按750px * 1334px为准(高度会随着内容多少而改变)。前端开发人员通过一套适配规则自动适配到其他的尺寸。

开发人员针对该场景提供了不同的适配解决方案。比如业务较为主流的一种适配方案,通过lib-flexible库配合CSS的rem单位来做相应的等比缩放适配。

flexible.js方案也就手淘团队提供的一种优秀的适配解决方案。即:《使用Flexible实现手淘H5页面的终端适配

事实上,flexible.js方案(业务常称rem适配方案)基本原理是模拟视窗单位vwvhvminvmax原理。随着视窗单位得到更多设备的支持之后,很多团队开始弃用flexible.js的适配方案,而改用vw-layout的适配方案。

vw方案(常称vw-layout方案)让我们在移动端适配变得更为容易。

vw方案如果运用于PC端或者屏幕较宽的终端设备上,会有一定的缺陷。

但这一切并没有结束。随着苹果公司(Apple)的刘海机iPhone X、iPhone XS、iPhone XR、iPhone XS Max的出现,不管是设计还是开发又要开始面对于刘海机终端的适配处理。

到目前为止,虽然安卓也有很多品牌有相应的刘海机,但面对不同的App(或者说团队),安卓刘海机不会做相应的考虑。

在刘海机中(或者说iOS11起)提出一个安全区域的概念。设计师也针对安全区域做出相应的处理:

前端开发也有相应的属性env()来做相应的适配处理。有关于刘海机的适配,请移步阅读:

而如今我们又将不得不开始着手于折叠屏的适配处理。

华为折叠屏官方适配方案建议

折叠屏在视觉效果来说就是,屏幕变大了,手机变平板了。这样就要求我们的APP在可折叠设备展开时,当前应用页面必须无缝延续到另一个屏幕,并可自动调整大小匹配新的布局,反之亦然。也就是说,应用程序需要准备好在多个屏幕(不同分辨率、密度等)之间切换。

其实Google之前有其应对的策略,在去年的 Android Dev Summit 上,Google 就已经宣布将要对折叠屏提供“Screen Continuity(屏幕连续性)”的原生系统支持,并将这项技术称之为:Foldables。利用这种柔性显示技术,App 可以做到折叠屏设备上的适配工作。

事实上,华为官方针对折叠屏也提供了一些适配方案

X 轴方向自适应

尽量保持Y轴方向上元素不变,X轴方向上自适应:

该方案较 适用于界面元素相对单一,没有大量列表类、或较多显示元素的页面

布局内容扩展

参考 iPad(平板)布局显示更多内容,对于区分了手机和iPad布局的应用,在展开态优先考虑参考iPad的大屏布局适配展开态界面,显示更多内容;尽量保证Y轴方向元素的不变:

该方案 一般适用于 WEB 类应用,页面特征一般为元素多,适配原则以尽量显示较多元素优先

分栏布局

对于设计过分栏能力的模块,需要在展开态体现分栏布局:

该方案 一般有明显 list 二级菜单的元素结构比较适合。

横竖屏布局一致

考虑到展开态 8:7.1 的比例,展开态的横屏和竖屏建议一套布局。横竖一致;不对展开态的横屏特殊处理,挪移布局不用体现。

如果仔细对比,不难发现华为官方提供的适配方案(展开状态模式)和 微软的UWP设计概念有些相似之处

两个(或多个)Fragment设计

前面也提到过,在未来,折叠屏在展开状态或许可以同时展示两个或更多个Fragment。对于这样的场景,前端或者设计都相对而言要更容易。因为多个Fragment更和我们现在的适配方式接近(未展开状态,和目前主流移动设备相似)。当然,在展开状态时,多个Fragment同时展示不同内容之时,或许每个Fragment所占屏幕的比例会有不同,针对于这种场景,我们目前采用的vw-layout适配方式,将毫无压力。

不过,同时打开两个或多个Fragment时,针对不同的场景在设计中也需要有所不同。比如说顶部Bar底部Bar采用比例拉伸,中间主内容打开多个Fragment,在不同的Fragment中显示不同的内容。

采用响应式设计方案

有了解过响应式设计的同学或许都知道,响应式设计在PC上的客户端得到较大范围的使用场景。对于移动端上,响应式设计的身影并不常见。但如今天,安卓折叠屏幕的出现,或许在未来的一些Web应用或Web页面中将会看到响应式设计的影子。

如果你决定在你的应用中采用响应式设计来适配折叠屏展开状态的效果,那么就有必要简单地了解一下响应式设计的几个基本原则。

@Sandijs Ruluks早在2014年就针对响应式设计提出九大基本设计原则

响应式 vs. 自适应网页设计

很多初学都都容易把响应式设计和自适应设计混淆。事实上,它们看起来似乎是相同的,但事实并非如此。这两种方法相辅相成,并没有说哪个是正确的那个是错误的,内容决定一切。

内容流动

随着屏幕尺寸变小,内容将会占据更多的垂直空间,而下方的内容就会被接着往下推,这就是所谓的流动。如果你是使用像素来进行设计的,这可能会有点棘手,但是当你习惯了之后,就会变得很有意义了。

相对单位

画布大小可以是DesktopMobile或是它们之间的任何尺寸。像素密度也可能有所不同,所以我们需要灵活的、在各种屏幕上都可以使用的单位。这就是相对单位(如%vw等)派上用场的时候了。所以设置50%的宽度也就意味着它会占据屏幕(或视窗,即打开的浏览器窗口的尺寸)的一半。

在CSS的世界中,相对单位有多个,不同的场景都有其优点:

上面提到%来做适配处理并无大碍,但%的计算相对而言会较为蛋疼,庆幸的是,我们可以采用视窗单位,比如vwvhvminvmax来替代%

不管是%还是视窗单位,它们计算方式都有所不同。他们也没有好坏之分,只有适合不适合之分

vw-layout适配方案,采用的就是视窗单位。

断点

断点是响应式设计中一个非常重要的概念。它允许布局在预定义的点改变相应的UI风格。例如:PC端浏览器布局是三列,但是在手机移动端上只展示一列。大多数CSS属性可以根据断点改变。通常你会根据具体的内容来设置断点。

这里所说的断点就是采用CSS中的媒体查询特性,但这样一来将会增加不少的代码量、开发成本和维护成本。

随着技术不断的革新,CSS的特性也越来越强大,就到目前为止,可以借助CSS Grid、minmax()repeat()auto-fillfr等特性,更易于实现响应式效果。当然一些特殊的场景还是需要强度依赖断点(媒体查询)来处理。

min-widthmax-width

前面提到过,在响应式设计中,最为关键的就是条件CSS中的媒体查询,即@media。媒体查询可以有条件的应用CSS规则,它告诉浏览器应该忽略或应用哪些CSS规则,而这些都取决于用户的设备终端。

在媒体特性中,大多数的媒体特性都可以带有minmax的前缀,比如说min-widthmax-width,用于表达 “最小的...” 或者 最大的...。用两张图来帮助大家来理解minmax的实际含义。

比如,设置width为100%,然后max-width1000px,那么内容会填满屏幕,但是不会超过1000px

嵌套对象

还记得相对位置吗?让很多元素的位置依赖于其它元素来定位是很难控制好的,因此使用容器来包裹元素可以让它更易理解,也更整洁。这就是静态单位(比如像素)发挥作用的时候了。对于你不想要模块化的内容(比如logo或按钮),它们是有用的。

Mobile优先 还是Desktop优先

从技术上讲,如果一个项目是从一个较小的屏幕开始,变成较大的屏幕(Mobile优先),还是反过来(Desktop优先),并没有太大的差别。然而它还是增加了额外的限制,可以帮助你决定是否从Mobile优先开始。通常大家在一开始的时候都会两端一起写,所以,还是看看哪个运行起来更好。

网页字体 vs 系统字体

希望你的网站上有很酷的字体吗?可以使用网页字体!虽然它们看起来非常棒,但是记住字体放得越多,你加载页面的时间也会越长。在另一方面,加载系统字体确是快如闪电,但当用户本地没有这套字体时,它就会返回默认的字体。

位图 vs 矢量图

你是否想过在图标上添加很多的细节和花哨的效果?如果想过的话,使用位图比较合适。如果没有,可以考虑使用矢量图。对于位图,使用的是jpgpnggif格式的图像,而对于矢量图,最好的选择是SVG或图标字体。每个都有对应的优势和缺点。但是图片的大小也需要重视——网页上的图片必须经过优化。另一个方面,矢量图通常比较小,但是一些旧版的浏览器不支持。此外,如果它有很多曲线的话,它也可能会比位图要重。所以,慎重选择。

有关于Web中图片或图标的使用,更详细的介绍可以阅读:

上面提到的九大基本原则,虽然提出的时间早,但对于使用响应式设计来设计Web页面或Web应用都具有极好的参考。当然,时至今日或未来,我们实现响应式设计可以借用其他的一些CSS特性,会让我们变得更为简单:

借助calc()函数,vw等视窗单位,可以对font-size进行精准设置:

在不同大小窗口下实现不同的字号。

通过CSS 的 grid布局、minmax()repeat()函数、fr单位以及auto-fill(或auto-fit)再配合min-contentmax-contentfill-content会让响应式布局越来越简单。

vw-layout和媒体查询相结合

不管是华方官方提供的适配方案或是淘宝设计团队提供的折叠屏幕的设计概念还是响应式设计(或者说UPW概念),对于折叠屏幕的适配都有不同的帮助。

  • vw-layout布局可以让我们轻易地达到X轴方向自适应或者横竖屏布局一致或横竖屏布局一致
  • 响应式设计(借助媒体查询)可以让我们轻易地达到布局内容扩展或分栏布局

如果采用多个Fragment来展示内容,那么vw-layout或其他的相对单位布局都可以非常轻易的帮助我们实现折叠屏在不同状态的适配效果。

如果你只想同比例放大,那么vw-layout也将是一个最佳方案。

如果你想在折叠状态和展开状态有不同的布局风格,那么响应式设计或者UWP概念将是不错的选择。在这种场景之下,把vw-layout和媒体查询(响应式设计)结合起来,将是最佳选择。

创建新属性或提出新标准

刘海机的出现,苹果公司针对该类型设备提出了env()函数和安全区域的概念。让我们在处理刘海机适配的时候将变得更容易。

虽然env()最初只用于iOS的系统,但随着这方面的需求更多,业内同行将该函数提到W3C规范的方案中,让其成为W3C规范。根据相同的一个概念,我们是否也可以针对安卓折叠机,提供一个类似的函数或者属性。比如folding()。另外,对于移动端,我们在媒体查询中orientation: landscapeorientation: portrait来判断设备是否横竖屏。同样的原理,我们是不是也可以借助类似媒体查询这种方式来对安卓折叠屏做相似的设置呢?

我们手淘 或者说集团很多App在安卓上都采用的是UC的内核,就算无法在W3C规范中推动,我们UC内核的同学是否可以针对折叠屏提供相应的判断条件呢?期待UC同学能提供。

案例

自接到要适配安卓折叠屏的需求时,其实我们团队在这方面的压力并不太大,因为我们采用的是vw-layout布局方案,再加上我们是Web页面(也就是大家所说的H5页面),在这方面具有天然的适配功能。只是在展开状态或许需要做一些细节化的处理。比如金币庄园:

借助媒体查询,可以轻易解决这样的细节问题。

另外为了更好的体验一下自己的想法:

vw-layoutgrid@media查询相结合,对三星折叠屏幕做相应的适配处理(华为还没有拿到真机)

于是我写了一个简单的小示例:

Demo在线效果可以点击这里

手淘卡片的布局:

最基本的方案是我们团队一直使用的vw-layout布局方案,再配合CSS Grid:

.card {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(340px, 1fr));
    grid-gap: 18px;
    grid-auto-flow: dense;
}

如果不做任何处理,我们在折叠屏两个状态下的效果如下:

如果我们想让在展开状态展示更多的内容时,或者说不同状态采用差异化的设计,那么我们可以借助媒体查询来处理。为了精准达到,先用JavaScript一些API获取设备相关参数:

<script>
    window.onload = function () {
        var winDPI = window.devicePixelRatio;
        var uAgent = window.navigator.userAgent;
        var screenHeight = window.screen.height;
        var screenWidth = window.screen.width;
        var winWidth = window.innerWidth;
        var winHeight = window.innerHeight;

        alert(
            "Windows DPI:" + winDPI +
            ";\ruAgent:" + uAgent +
            ";\rScreen Width:" + screenWidth +
            ";\rScreen Height:" + screenHeight +
            ";\rWindow Width:" + winWidth +
            ";\rWindow Height:" + winHeight
        )
    }
</script>

输出我们想要的数据:

借助媒体查询,我们就可以做我们想要的事情:

@media only screen and (device-width: 320px) and (device-height: 747px) and (-webkit-device-pixel-ratio: 2.625){ 
  body {
        background-color: blue;
  }
  body::before {
      content: '三星折叠机:折叠状态';
      position: absolute;
      top: 0;
      left: 0;
      z-index: 999;
      background-color: rgba(0,0,0,0.3);
      color: #fff;
  }
}

@media only screen and (device-width: 586px) and (device-height: 820px) and (-webkit-device-pixel-ratio: 2.625){ 
  body {
        background-color: orange;
  }
  body::before {
      content: '三星折叠机:展开状态';
      position: absolute;
      top: 0;
      left: 0;
      z-index: 999;
      background-color: rgba(0,0,0,0.3);
      color: #fff;
  }

  #app {
      grid-template-columns: repeat(auto-fill, minmax(22.6665vw, 1fr));
  }
}
</style>

这个时候你看到的效果如下:

如果你稍加处理,还可以得到更不一样的布局:

借助媒体查询来实现差异的设计,对于开发而言是较为蛋疼的,会增加不少的开发成本和维护成本。而助上面的媒体查询是只针对于三星折叠屏,但随着更多折叠屏设备的出现,事情会变得越来越困难:

所以我们还是希望有一个统一性的判断属性

这个示例向大家演示的是H5在三星中的适配。对于其他的折叠屏设备,我们可以按同样的方式或原理来进行

折叠屏设备调试

如果你没有真机的话,在调试折叠屏的时候可以采用模拟机:

可以运行相应的模拟机,比如华为Mate X模拟机:

如果你是使用Chrome进行调试,你还可以创建相应的模拟机。比如三星的UserAgent信息如下:

Mozilla/5.0 (Linux; U; Android 9; zh-CN; SM-F9000  Build/PPR1.180610.011) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.1.2.992 Mobile Safari/537.36

这样就可以创建折叠和展开的两种状态:

这样就可以直接在Chrome中调试了:

对于其他折叠屏设备,如果你有相关的参数,也可以按上面类似的方式进行设备。

小结

还是那句话,底层建筑永远决定上层设计!不管时代怎么变化,做为技术人员都应该不断的去探索,寻找相应或最佳的解决方案。

在这篇文章中,虽然我们以折叠屏为主线进行展开介绍,但全文除了折叠给我们带来的变化之外,还介绍了响应式设计、rem适配、vw-layout适配以及刘海机适配等方案。

事实上,这也是一篇有关于移动端适配大全或指南。

最后希望该文对大家有所帮助。



本文作者:大漠_w3cplus

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

查看原文

赞 39 收藏 32 评论 2

Moorez 赞了文章 · 2019-06-22

前端开发者必备的Nginx知识

nginx在应用程序中的作用

  • 解决跨域
  • 请求过滤
  • 配置gzip
  • 负载均衡
  • 静态资源服务器
nginx是一个高性能的HTTP和反向代理服务器,也是一个通用的TCP/UDP代理服务器,最初由俄罗斯人Igor Sysoev编写。

nginx现在几乎是众多大型网站的必用技术,大多数情况下,我们不需要亲自去配置它,但是了解它在应用程序中所担任的角色,以及如何解决这些问题是非常必要的。

下面我将从nginx在企业中的真实应用来解释nginx在应用程序中起到的作用。

为了便于理解,首先先来了解一下一些基础知识,nginx是一个高性能的反向代理服务器那么什么是反向代理呢?

正向代理与反向代理

代理是在服务器和客户端之间假设的一层服务器,代理将接收客户端的请求并将它转发给服务器,然后将服务端的响应转发给客户端。

不管是正向代理还是反向代理,实现的都是上面的功能。

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx2.png)

正向代理

正向代理,意思是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。

正向代理是为我们服务的,即为客户端服务的,客户端可以根据正向代理访问到它本身无法访问到的服务器资源。

正向代理对我们是透明的,对服务端是非透明的,即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。

反向代理

反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。

反向代理是为服务端服务的,反向代理可以帮助服务器接收来自客户端的请求,帮助服务器做请求转发,负载均衡等。

反向代理对服务端是透明的,对我们是非透明的,即我们并不知道自己访问的是代理服务器,而服务器知道反向代理在为他服务。
图片描述

基本配置

配置结构

下面是一个nginx配置文件的基本结构:

events { 

}

http 
{
    server
    { 
        location path
        {
            ...
        }
        location path
        {
            ...
        }
     }

    server
    {
        ...
    }

}
  • main:nginx的全局配置,对全局生效。
  • events:配置影响nginx服务器或与用户的网络连接。
  • http:可以嵌套多个server,配置代理,缓存,日志定义等绝大多数功能和第三方模块的配置。
  • server:配置虚拟主机的相关参数,一个http中可以有多个server。
  • location:配置请求的路由,以及各种页面的处理情况。
  • upstream:配置后端服务器具体地址,负载均衡配置不可或缺的部分。

内置变量

下面是nginx一些配置中常用的内置全局变量,你可以在配置的任何位置使用它们。

| 变量名 | 功能 |
| ------ | ------ |
| $host| 请求信息中的Host,如果请求中没有Host行,则等于设置的服务器名 |
| $request_method | 客户端请求类型,如GETPOST
| $remote_addr | 客户端的IP地址 |
|$args | 请求中的参数 |
|$content_length| 请求头中的Content-length字段 |
|$http_user_agent | 客户端agent信息 |
|$http_cookie | 客户端cookie信息 |
|$remote_addr | 客户端的IP地址 |
|$remote_port | 客户端的端口 |
|$server_protocol | 请求使用的协议,如HTTP/1.0、·HTTP/1.1` |
|$server_addr | 服务器地址 |
|$server_name| 服务器名称|
|$server_port|服务器的端口号|

解决跨域

先追本溯源以下,跨域究竟是怎么回事。

跨域的定义

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。通常不允许不同源间的读操作。

同源的定义

如果两个页面的协议,端口(如果有指定)和域名都相同,则两个页面具有相同的源。

image

nginx解决跨域的原理

例如:

  • 前端server的域名为:fe.server.com
  • 后端服务的域名为:dev.server.com

现在我在fe.server.comdev.server.com发起请求一定会出现跨域。

现在我们只需要启动一个nginx服务器,将server_name设置为fe.server.com,然后设置相应的location以拦截前端需要跨域的请求,最后将请求代理回dev.server.com。如下面的配置:

server {
        listen       80;
        server_name  fe.server.com;
        location / {
                proxy_pass dev.server.com;
        }
}

这样可以完美绕过浏览器的同源策略:fe.server.com访问nginxfe.server.com属于同源访问,而nginx对服务端转发的请求不会触发浏览器的同源策略。

请求过滤

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/404.jpg)

根据状态码过滤

error_page 500 501 502 503 504 506 /50x.html;
    location = /50x.html {
        #将跟路径改编为存放html的路径。
        root /root/static/html;
    }

根据URL名称过滤,精准匹配URL,不匹配的URL全部重定向到主页。

location / {
    rewrite  ^.*$ /index.html  redirect;
}

根据请求类型过滤。

if ( $request_method !~ ^(GET|POST|HEAD)$ ) {
        return 403;
    }

配置gzip

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/gzip.jpg)

GZIP是规定的三种标准HTTP压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTMLCSSJavaScript 等资源文件。

对于文本文件,GZip 的效果非常明显,开启后传输所需流量大约会降至 1/4 ~ 1/3

并不是每个浏览器都支持gzip的,如何知道客户端是否支持gzip呢,请求头中的Accept-Encoding来标识对压缩的支持。

image

启用gzip同时需要客户端和服务端的支持,如果客户端支持gzip的解析,那么只要服务端能够返回gzip的文件就可以启用gzip了,我们可以通过nginx的配置来让服务端支持gzip。下面的responecontent-encoding:gzip,指服务端开启了gzip的压缩方式。

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/gzip2.png)

    gzip                    on;
    gzip_http_version       1.1;        
    gzip_comp_level         5;
    gzip_min_length         1000;
    gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;

gzip

  • 开启或者关闭gzip模块
  • 默认值为 off
  • 可配置为 on / off

gzip_http_version

  • 启用 GZip 所需的 HTTP 最低版本
  • 默认值为 HTTP/1.1

这里为什么默认版本不是1.0呢?

HTTP 运行在 TCP 连接之上,自然也有着跟 TCP 一样的三次握手、慢启动等特性。

启用持久连接情况下,服务器发出响应后让TCP连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/keepalive.png)

为了尽可能的提高 HTTP 性能,使用持久连接就显得尤为重要了。

HTTP/1.1 默认支持 TCP 持久连接,HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文,客户端需要一种机制来准确判断结束位置,而在 HTTP/1.0 中,这种机制只有 Content-Length。而在HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。

nginx同样有着配置chunked的属性chunked_transfer_encoding,这个属性是默认开启的。

Nginx 在启用了GZip的情况下,不会等文件 GZip 完成再返回响应,而是边压缩边响应,这样可以显著提高 TTFB(Time To First Byte,首字节时间,WEB 性能优化重要指标)。这样唯一的问题是,Nginx 开始返回响应时,它无法知道将要传输的文件最终有多大,也就是无法给出 Content-Length 这个响应头部。

所以,在HTTP1.0中如果利用Nginx 启用了GZip,是无法获得 Content-Length 的,这导致HTTP1.0中开启持久链接和使用GZip只能二选一,所以在这里gzip_http_version默认设置为1.1

gzip_comp_level

  • 压缩级别,级别越高压缩率越大,当然压缩时间也就越长(传输快但比较消耗cpu)。
  • 默认值为 1
  • 压缩级别取值为1-9

gzip_min_length

  • 设置允许压缩的页面最小字节数,Content-Length小于该值的请求将不会被压缩
  • 默认值:0
  • 当设置的值较小时,压缩后的长度可能比原文件大,建议设置1000以上

gzip_types

  • 要采用gzip压缩的文件类型(MIME类型)
  • 默认值:text/html(默认不压缩js/css)

负载均衡

什么是负载均衡

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx3.jpg)

如上面的图,前面是众多的服务窗口,下面有很多用户需要服务,我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口,来达到资源的充分利用以及更少的排队时间。

把前面的服务窗口想像成我们的后端服务器,而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器,以达到服务端资源的充分利用和更少的请求时间。

nginx如何实现负载均衡

Upstream指定后端服务器地址列表

upstream balanceServer {
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

在server中拦截响应请求,并将请求转发到Upstream中配置的服务器列表。

    server {
        server_name  fe.server.com;
        listen 80;
        location /api {
            proxy_pass http://balanceServer;
        }
    }

上面的配置只是指定了nginx需要转发的服务端列表,并没有指定分配策略。

nginx实现负载均衡的策略

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/loadBalancing.png)

轮询策略

默认情况下采用的策略,将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的,但是如果其中某一台服务器压力太大,出现延迟,会影响所有分配在这台服务器下的用户。

upstream balanceServer {
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx5.png)

最小连接数策略

将请求优先分配给压力较小的服务器,它可以平衡每个队列的长度,并避免向压力大的服务器添加更多的请求。

upstream balanceServer {
    least_conn;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx4.png)

最快响应时间策略

依赖于NGINX Plus,优先分配给响应时间最短的服务器。

upstream balanceServer {
    fair;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

客户端ip绑定

来自同一个ip的请求永远只分配一台服务器,有效解决了动态网页存在的session共享问题。

upstream balanceServer {
    ip_hash;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

静态资源服务器

location ~* \.(png|gif|jpg|jpeg)$ {
    root    /root/static/;  
    autoindex on;
    access_log  off;
    expires     10h;# 设置过期时间为10小时          
}

匹配以png|gif|jpg|jpeg为结尾的请求,并将请求转发到本地路径,root中指定的路径即nginx本地路径。同时也可以进行一些缓存的设置。

小结

nginx的功能非常强大,还有很多需要探索,上面的一些配置都是公司配置的真实应用(精简过了)。

文中如有错误,欢迎在评论区指正,如果这篇文章帮助到了你,欢迎点赞和关注。

想阅读更多优质文章、可关注我的github博客,你的star✨、点赞和关注是我持续创作的动力!

推荐大家使用Fundebug,一款很好用的BUG监控工具~

推荐关注我的微信公众号【code秘密花园】,每天推送高质量文章,我们一起交流成长。

图片描述

查看原文

赞 370 收藏 291 评论 14

Moorez 发布了文章 · 2019-06-01

判断浏览器是否支持 webp 的几种解决方法

我们都知道,WebP 是 Google 推出的 WebP 图片格式,它是一种支持有损压缩和无损压缩的图片文件格式,根据Google测试,相同的图片,WebP 格式的图片均能比 PNG,JPG 格式的图片节约不少体积,但是其兼容性不是很好,如下:

因此我们需要做一些兼容处理,那么如何判断浏览器支持 webp 呢?下面有几种方法可供参考。

方法一

使用 canvas 的 toDataURL 进行判断

toDataURL方法在MDN解释如下:

HTMLCanvasElement.toDataURL() 方法返回一个包含图片展示的 data URI 。可以使用 type 参数其类型,默认为 PNG 格式。图片的分辨率为96dpi。
  • 如果画布的高度或宽度是0,那么会返回字符串“data:,”。
  • 如果传入的类型非“image/png”,但是返回的值以“data:image/png”开头,那么该传入的类型是不支持的。
  • Chrome支持“image/webp”类型。

toDataURL方法将图片转化为包含dataURI的DOMString,通过 base64 编码前面的图片类型值是image/webp进行判断。

比如在谷歌浏览器使用toDataURL方法转成image/webp:

在 Safari 浏览器使用toDataURL方法转成image/webp:

可以发现在不支持 webp 的浏览器进行toDataURL,得到的图片类型并不是 webp,因此我们可以通过这个进行判断。

实现方法:

var isSupportWebp = function () {
  try {
    return document.createElement('canvas').toDataURL('image/webp', 0.5).indexOf('data:image/webp') === 0;
  } catch(err) {
    return false;
  }
}

isSupportWebp()

方法二

在服务端根据请求header信息判断浏览器是否支持webp

谷歌浏览器上请求图片 header是这样的:

IE 浏览器请求图片 header是这样的:

在图片请求发出的时候,Request Headers 里有 Accept,服务端可以根据Accept 里面是否有 image/webp 进行判断。

方法三

通过加载一张 webp 图片进行判断

const supportsWebp = ({ createImageBitmap, Image }) => {
  if (!createImageBitmap || !Image) return Promise.resolve(false);

  return new Promise(resolve => {
      const image = new Image();
      image.onload = () => {
          createImageBitmap(image)
              .then(() => {
                  resolve(true);
              })
              .catch(() => {
                  resolve(false);
              });
      };
      image.onerror = () => {
          resolve(false);
      };
      image.src = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
  });
};

const webpIsSupported = () => {
  let memo = null;
  return () => {
      if (!memo) {
          memo = supportsWebp(window);
      }
      return memo;
  };
};

webpIsSupported()().then(res => {
    console.log("是否支持 webp", res)
}).catch(err => {
    console.log(err)
})

此方法会加载一张 1x1 的白色的正方形背景图,用来测试浏览器是否支持 webp。

在 Google 测试代码:

在 Firefox 测试代码:

在 Safari 测试代码:

Google官方文档是这样处理的(先加载一个WebP图片,如果能获取到图片的宽度和高度,就说明是支持WebP的,反之则不支持):

function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

参考

查看原文

赞 14 收藏 9 评论 1

Moorez 发布了文章 · 2019-05-31

JavaScript中的Object.freeze与const之间的区别(译)

原文:The differences between Object.freeze() vs Const in JavaScript 
作者:Bolaji Ayodeji
本文经授权翻译转载,版权归原作者所有!

image.png

自ES6发布以来,ES6给JavaScript带来了一些新特性和方法。对于JavaScript开发者来说,这些特性能够很好地改善了我们的工作流程以及工作效率,其中的特性就包括 Object.freeze() 方法和 const 。

一些开发人员特别是新手们会认为这两个功能的工作方式是一样的,但其实并不是。 让我来告诉你Object.freeze() 和 const  是如何不同的。

综述

const 和 Object.freeze() 完全不同。

  • const 的行为像 let 。它们唯一的区别是, const 定义了一个无法重新分配的变量。 通过 const 声明的变量是具有块级作用域的,而不是像 var 声明的变量具有函数作用域。
  • Object.freeze() 接受一个对象作为参数,并返回一个相同的不可变的对象。这就意味着我们不能添加,删除或更改对象的任何属性。
可变对象的属性能够进行更改,而不可变对象在创建对象后不能更改其属性。

例子

const

const user = 'Bolaji Ayodeji'
user = 'Joe Nash'

这个例子会抛出一个Uncaught TypeError,因为我们正在尝试重新分配使用const关键字声明的变量user,这样做是无效的。

image.png

这个例子中使用 let 或者 var 声明是能够正常工作的,但是使用 const 并不能。

const 的问题

使用const声明的对象仅能阻止其重新分配,但是并不能使其声明的对象具有不可变性(能够阻止更改其属性)。

参考以下代码,我们使用const关键字声明了一个变量,并为其分配了一个名为user的对象。

const user = {
  first_name: 'bolaji',
  last_name: 'ayodeji',
  email: 'hi@bolajiayodeji.com',
  net_worth: 2000
}
user.last_name = 'Samson';
// this would work, user is still mutable!
user.net_worth = 983265975975950;
// this would work too, user is still mutable and getting rich :)!
console.log(user);  // user is mutated

image.png

尽管我们无法重新分配这个名为 user 的变量,但是我们仍然可以改变其对象本身。

const user = {
  user_name: 'bolajiayodeji'
}
// won't work

image.png

我们肯定希望对象具有无法修改或删除的属性。 const 无法实现这样的功能,但是 Object.freeze  可以。

Object.freeze()

要禁用对象的任何更改,我们需要使用 Object.freeze() 。

const user = {
  first_name: 'bolaji',
  last_name: 'ayodeji',
  email: 'hi@bolajiayodeji.com',
  net_worth: 2000
}
Object.freeze(user);
user.last_name = 'Samson';
// this won't work, user is still immutable!
user.net_worth = 983265975975950;
// this won't work too, user is still immutable and still broke :(!
console.log(user);  // user is immutated

image.png

具有嵌套属性的对象实际上并未冻结

Object.freeze 只是做了层浅冻结,当遇到具有嵌套属性的对象的时候,我们需要递归Object.freeze 来冻结具有嵌套属性的对象。

const user = {
  first_name: 'bolaji',
  last_name: 'ayodeji',
  contact: {
    email: 'hi@bolajiayodeji.com',
    telephone: 08109445504,
  }
}

Object.freeze(user);
user.last_name = 'Samson';
// this won't work, user is still immutable!
user.contact.telephone = 07054394926;
// this will work because the nested object is not frozen
console.log(user);

image.png

因此,当具有嵌套属性的对象时, Object.freeze()  并不能完全冻结对象。

要完全冻结具有嵌套属性的对象,您可以编写自己的库或使用已有的库来冻结对象,如Deepfreeze 或 immutable-js

结论

const 和 Object.freeze() 并不同, const 是防止变量重新分配,而 Object.freeze() 是使对象具有不可变性。

感谢阅读,干杯!

查看原文

赞 7 收藏 5 评论 2

Moorez 赞了文章 · 2019-05-25

一键解决 go get golang.org/x 包失败

问题描述

当我们使用 go getgo installgo mod 等命令时,会自动下载相应的包或依赖包。但由于众所周知的原因,类似于 golang.org/x/... 的包会出现下载失败的情况。如下所示:

$ go get -u golang.org/x/sys

go get golang.org/x/sys: unrecognized import path "golang.org/x/sys" (https fetch: Get https://golang.org/x/sys?go-get=1: dial tcp 216.239.37.1:443: i/o timeout)

解决方式

那我们该如何解决问题呢?毕竟还要制造 bug 的嘛~

手动下载

我们常见的 golang.org/x/... 包,一般在 GitHub 上都有官方的镜像仓库对应。比如 golang.org/x/text 对应 github.com/golang/text。所以,我们可以手动下载或 clone 对应的 GitHub 仓库到指定的目录下。

mkdir $GOPATH/src/golang.org/x
cd $GOPATH/src/golang.org/x
git clone git@github.com:golang/text.git
rm -rf text/.git

当如果需要指定版本的时候,该方法就无解了,因为 GitHub 上的镜像仓库多数都没有 tag。并且,手动嘛,程序员怎么能干呢,尤其是依赖的依赖,太多了。

设置代理

如果你有代理,那么可以设置对应的环境变量:

export http_proxy=http://proxyAddress:port
export https_proxy=http://proxyAddress:port

或者,直接用 all_proxy

export all_proxy=http://proxyAddress:port

go mod replace

从 Go 1.11 版本开始,新增支持了 go modules 用于解决包依赖管理问题。该工具提供了 replace,就是为了解决包的别名问题,也能替我们解决 golang.org/x 无法下载的的问题。

go module 被集成到原生的 go mod 命令中,但是如果你的代码库在 $GOPATH 中,module 功能是默认不会开启的,想要开启也非常简单,通过一个环境变量即可开启 export GO111MODULE=on

以下为参考示例:

module example.com/hello

require (
    golang.org/x/text v0.3.0
)

replace (
    golang.org/x/text => github.com/golang/text v0.3.0
)

类似的还有 glidegopm 等这类第三方包管理工具,都不同方式的解决方案提供给我们。

GOPROXY 环境变量

终于到了本文的终极大杀器 —— GOPROXY

我们知道从 Go 1.11 版本开始,官方支持了 go module 包依赖管理工具。

其实还新增了 GOPROXY 环境变量。如果设置了该变量,下载源代码时将会通过这个环境变量设置的代理地址,而不再是以前的直接从代码库下载。这无疑对我等无法科学上网的开发良民来说是最大的福音。

更可喜的是,goproxy.io 这个开源项目帮我们实现好了我们想要的。该项目允许开发者一键构建自己的 GOPROXY 代理服务。同时,也提供了公用的代理服务 https://goproxy.io,我们只需设置该环境变量即可正常下载被墙的源码包了:

export GOPROXY=https://goproxy.io

不过,需要依赖于 go module 功能。可通过 export GO111MODULE=on 开启 MODULE。

如果项目不在 GOPATH 中,则无法使用 go get ...,但可以使用 go mod ... 相关命令。

也可以通过置空这个环境变量来关闭,export GOPROXY=

对于 Windows 用户,可以在 PowerShell 中设置:

$env:GOPROXY = "https://goproxy.io"

最后,我们当然推荐使用 GOPROXY 这个环境变量的解决方式,前提是 Go version >= 1.11

最后的最后,七牛也出了个国内代理 goproxy.cn 方便国内用户更快的访问不能访问的包,真是良心。

参考资料


感谢您的阅读,觉得内容不错,点个赞吧 😆

原文地址: https://shockerli.net/post/go...

查看原文

赞 26 收藏 12 评论 10

Moorez 评论了文章 · 2019-04-25

Vue全家桶+TypeScript使用总结

前言

最近重构了我之前项目 qq 音乐移动端,使用的技术是 vue,vuex,vue-router,和 typescript,在这期间,遇到的问题还是蛮多的,一会儿我会把我遇到的问题以及解决方法列出来,避免忘记。

重构完成的项目 ===> vue-qq-music

TypeScript与Vue全家桶的配置可以参考以下两篇文章(在这里由衷感谢两位作者):

  1. vue + typescript 新项目起手式
  2. Vue2.5+ Typescript 引入全面指南 - Vuex篇

TypeScript

为什么我要将TypeScriptVue 集成呢?因为TypeScript 有以下几个优势:

  • 可读性。TypeScript 是 JavaScript 的超集,这意味着他支持所有的 JavaScript 语法。并在此之上对 JavaScript 添加了一些扩展,如interface等。这样会大大提升代码的可阅读性
  • 静态类型检查。静态类型检查可以避免很多不必要的错误,不用在调试的时候才发现问题。
  • 代码提示。ts 搭配 vscode,代码提示非常友好
  • 代码重构。例如全项目更改某个变量名(也可以是类名、方法名,甚至是文件名[重命名文件自动修改的是整个项目的import]),在JS中是不可能的,而TS可以轻松做到。看看下面发生了什么神奇的事情?⬇️

遇到的问题以及解决方法

问题一

ts 无法识别$ref

解决方法
① 直接在 this.$refs.xxx 后面申明类型如:

this.$refs.lyricsLines as HTMLDivElement;

② 在export default class xxx extends Vue里面声明全部的$ref 的类型

$refs: {
    audio: HTMLAudioElement,
    lyricsLines: HTMLDivElement
}

问题二

ts 无法识别 require

解决方法

安装声明文件

yarn add @types/webpack-env -D

问题三

运行npm run build 出现

解决方法

You can fix this by using the most recent beta version of uglifyjs-webpack-plugin. Our team is working to remove completely the UglifyJsPlugin from within webpack, and instead have it as a standalone plugin.

If you do yarn add uglifyjs-webpack-plugin@beta --dev or npm install uglifyjs-webpack-plugin@beta --save-dev you should receive the latest beta which does successfully minify es6 syntax. We are hoping to have this released from beta extremely soon, however it should save you from errors for now!

也就是说升级你的uglifyjs-webpack-plugin版本:
yarn add uglifyjs-webpack-plugin@beta --dev

问题四

vue-property-decorator 装饰器写法不对。当时我是要把 mixins,注入到组件里,我就这样写:

ts提示找不到 mixin。我就很纳闷为什么找不到名字,由于官网vue-property-decorator例子太少,只好一步一步摸索?

解决方法

把mixins写在@Component里面...,像这样:

注意点

  1. 如果你引用第三方无类型声明的库,那就需要自己编写x.d.ts文件
  2. 如果引用 ui 组件的时候,如果控制台出现Property '$xxx' does not exist on type 'App'的话,那么可以在vue-shim.d.ts增加
declare module 'vue/types/vue' {
  interface Vue {
    $xxx: any,
  }
}

最后

经过几天的折腾,终于把项目重构完成,我个人认为加上 TypeScript,确实效率挺高了许多,不过 Vue+TypeScript 还是没 Angular支持那么完善,相信之后 vue 对于 ts 的集成会更加完善!

查看原文

Moorez 评论了文章 · 2019-04-25

Vue全家桶+TypeScript使用总结

前言

最近重构了我之前项目 qq 音乐移动端,使用的技术是 vue,vuex,vue-router,和 typescript,在这期间,遇到的问题还是蛮多的,一会儿我会把我遇到的问题以及解决方法列出来,避免忘记。

重构完成的项目 ===> vue-qq-music

TypeScript与Vue全家桶的配置可以参考以下两篇文章(在这里由衷感谢两位作者):

  1. vue + typescript 新项目起手式
  2. Vue2.5+ Typescript 引入全面指南 - Vuex篇

TypeScript

为什么我要将TypeScriptVue 集成呢?因为TypeScript 有以下几个优势:

  • 可读性。TypeScript 是 JavaScript 的超集,这意味着他支持所有的 JavaScript 语法。并在此之上对 JavaScript 添加了一些扩展,如interface等。这样会大大提升代码的可阅读性
  • 静态类型检查。静态类型检查可以避免很多不必要的错误,不用在调试的时候才发现问题。
  • 代码提示。ts 搭配 vscode,代码提示非常友好
  • 代码重构。例如全项目更改某个变量名(也可以是类名、方法名,甚至是文件名[重命名文件自动修改的是整个项目的import]),在JS中是不可能的,而TS可以轻松做到。看看下面发生了什么神奇的事情?⬇️

遇到的问题以及解决方法

问题一

ts 无法识别$ref

解决方法
① 直接在 this.$refs.xxx 后面申明类型如:

this.$refs.lyricsLines as HTMLDivElement;

② 在export default class xxx extends Vue里面声明全部的$ref 的类型

$refs: {
    audio: HTMLAudioElement,
    lyricsLines: HTMLDivElement
}

问题二

ts 无法识别 require

解决方法

安装声明文件

yarn add @types/webpack-env -D

问题三

运行npm run build 出现

解决方法

You can fix this by using the most recent beta version of uglifyjs-webpack-plugin. Our team is working to remove completely the UglifyJsPlugin from within webpack, and instead have it as a standalone plugin.

If you do yarn add uglifyjs-webpack-plugin@beta --dev or npm install uglifyjs-webpack-plugin@beta --save-dev you should receive the latest beta which does successfully minify es6 syntax. We are hoping to have this released from beta extremely soon, however it should save you from errors for now!

也就是说升级你的uglifyjs-webpack-plugin版本:
yarn add uglifyjs-webpack-plugin@beta --dev

问题四

vue-property-decorator 装饰器写法不对。当时我是要把 mixins,注入到组件里,我就这样写:

ts提示找不到 mixin。我就很纳闷为什么找不到名字,由于官网vue-property-decorator例子太少,只好一步一步摸索?

解决方法

把mixins写在@Component里面...,像这样:

注意点

  1. 如果你引用第三方无类型声明的库,那就需要自己编写x.d.ts文件
  2. 如果引用 ui 组件的时候,如果控制台出现Property '$xxx' does not exist on type 'App'的话,那么可以在vue-shim.d.ts增加
declare module 'vue/types/vue' {
  interface Vue {
    $xxx: any,
  }
}

最后

经过几天的折腾,终于把项目重构完成,我个人认为加上 TypeScript,确实效率挺高了许多,不过 Vue+TypeScript 还是没 Angular支持那么完善,相信之后 vue 对于 ts 的集成会更加完善!

查看原文

Moorez 收藏了文章 · 2019-04-22

AST抽象语法树——最基础的javascript重点知识,99%的人根本不了解

抽象语法树(AST),是一个非常基础而重要的知识点,但国内的文档却几乎一片空白。

本文将带大家从底层了解AST,并且通过发布一个小型前端工具,来带大家了解AST的强大功能

Javascript就像一台精妙运作的机器,我们可以用它来完成一切天马行空的构思。

我们对javascript生态了如指掌,却常忽视javascript本身。这台机器,究竟是哪些零部件在支持着它运行?

AST在日常业务中也许很难涉及到,但当你不止于想做一个工程师,而想做工程师的工程师,写出vue、react之类的大型框架,或类似webpack、vue-cli前端自动化的工具,或者有批量修改源码的工程需求,那你必须懂得AST。AST的能力十分强大,且能帮你真正吃透javascript的语言精髓。

事实上,在javascript世界中,你可以认为抽象语法树(AST)是最底层。 再往下,就是关于转换和编译的“黑魔法”领域了。

人生第一次拆解Javascript

小时候,当我们拿到一个螺丝刀和一台机器,人生中最令人怀念的梦幻时刻便开始了:

我们把机器,拆成一个一个小零件,一个个齿轮与螺钉,用巧妙的机械原理衔接在一起...

当我们把它重新照不同的方式组装起来,这时,机器重新又跑动了起来——世界在你眼中如获新生。

image

通过抽象语法树解析,我们可以像童年时拆解玩具一样,透视Javascript这台机器的运转,并且重新按着你的意愿来组装。

现在,我们拆解一个简单的add函数

function add(a, b) {
    return a + b
}

首先,我们拿到的这个语法块,是一个FunctionDeclaration(函数定义)对象。

用力拆开,它成了三块:

  • 一个id,就是它的名字,即add
  • 两个params,就是它的参数,即[a, b]
  • 一块body,也就是大括号内的一堆东西

add没办法继续拆下去了,它是一个最基础Identifier(标志)对象,用来作为函数的唯一标志,就像人的姓名一样。

{
    name: 'add'
    type: 'identifier'
    ...
}

params继续拆下去,其实是两个Identifier组成的数组。之后也没办法拆下去了。

[
    {
        name: 'a'
        type: 'identifier'
        ...
    },
    {
        name: 'b'
        type: 'identifier'
        ...
    }
]

接下来,我们继续拆开body
我们发现,body其实是一个BlockStatement(块状域)对象,用来表示是{return a + b}

打开Blockstatement,里面藏着一个ReturnStatement(Return域)对象,用来表示return a + b

继续打开ReturnStatement,里面是一个BinaryExpression(二项式)对象,用来表示a + b

继续打开BinaryExpression,它成了三部分,leftoperatorright

  • operator+
  • left 里面装的,是Identifier对象 a
  • right 里面装的,是Identifer对象 b

就这样,我们把一个简单的add函数拆解完毕,用图表示就是

image

看!抽象语法树(Abstract Syntax Tree),的确是一种标准的树结构。

那么,上面我们提到的Identifier、Blockstatement、ReturnStatement、BinaryExpression, 这一个个小部件的说明书去哪查?

请查看 AST对象文档

送给你的AST螺丝刀:recast

输入命令:

npm i recast -S

你即可获得一把操纵语法树的螺丝刀

接下来,你可以在任意js文件下操纵这把螺丝刀,我们新建一个parse.js示意:

parse.js

// 给你一把"螺丝刀"——recast
const recast = require("recast");

// 你的"机器"——一段代码
// 我们使用了很奇怪格式的代码,想测试是否能维持代码结构
const code =
  `
  function add(a, b) {
    return a +
      // 有什么奇怪的东西混进来了
      b
  }
  `
// 用螺丝刀解析机器
const ast = recast.parse(code);

// ast可以处理很巨大的代码文件
// 但我们现在只需要代码块的第一个body,即add函数
const add  = ast.program.body[0]

console.log(add)

输入node parse.js你可以查看到add函数的结构,与之前所述一致,通过AST对象文档可查到它的具体属性:

FunctionDeclaration{
    type: 'FunctionDeclaration',
    id: ...
    params: ...
    body: ...
}

你也可以继续使用console.log透视它的更内层,如:

console.log(add.params[0])
console.log(add.body.body[0].argument.left)

recast.types.builders 制作模具

一个机器,你只会拆开重装,不算本事。

拆开了,还能改装,才算上得了台面。

recast.types.builders里面提供了不少“模具”,让你可以轻松地拼接成新的机器。

最简单的例子,我们想把之前的function add(a, b){...}声明,改成匿名函数式声明const add = function(a ,b){...}

如何改装?

第一步,我们创建一个VariableDeclaration变量声明对象,声明头为const, 内容为一个即将创建的VariableDeclarator对象。

第二步,创建一个VariableDeclarator,放置add.id在左边, 右边是将创建的FunctionDeclaration对象

第三步,我们创建一个FunctionDeclaration,如前所述的三个组件,id params body中,因为是匿名函数id设为空,params使用add.params,body使用add.body。

这样,就创建好了const add = function(){}的AST对象。

在之前的parse.js代码之后,加入以下代码

// 引入变量声明,变量符号,函数声明三种“模具”
const {variableDeclaration, variableDeclarator, functionExpression} = recast.types.builders

// 将准备好的组件置入模具,并组装回原来的ast对象。
ast.program.body[0] = variableDeclaration("const", [
  variableDeclarator(add.id, functionExpression(
    null, // Anonymize the function expression.
    add.params,
    add.body
  ))
]);

//将AST对象重新转回可以阅读的代码
const output = recast.print(ast).code;

console.log(output)

可以看到,我们打印出了

const add = function(a, b) {
  return a +
    // 有什么奇怪的东西混进来了
    b
};

最后一行

const output = recast.print(ast).code;

其实是recast.parse的逆向过程,具体公式为

recast.print(recast.parse(source)).code === source

打印出来还保留着“原装”的函数内容,连注释都没有变。

我们其实也可以打印出美化格式的代码段:

const output = recast.prettyPrint(ast, { tabWidth: 2 }).code

输出为

const add = function(a, b) {
  return a + b;
};
现在,你是不是已经产生了“我可以通过AST树生成任何js代码”的幻觉?

我郑重告诉你,这不是幻觉。

实战进阶:命令行修改js文件

除了parse/print/builder以外,Recast的三项主要功能:

  • run: 通过命令行读取js文件,并转化成ast以供处理。
  • tnt: 通过assert()和check(),可以验证ast对象的类型。
  • visit: 遍历ast树,获取有效的AST对象并进行更改。

我们通过一个系列小务来学习全部的recast工具库:

创建一个用来示例文件,假设是demo.js

demo.js

function add(a, b) {
  return a + b
}

function sub(a, b) {
  return a - b
}

function commonDivision(a, b) {
  while (b !== 0) {
    if (a > b) {
      a = sub(a, b)
    } else {
      b = sub(b, a)
    }
  }
  return a
}

recast.run —— 命令行文件读取

新建一个名为read.js的文件,写入
read.js

recast.run( function(ast, printSource){
    printSource(ast)
})

命令行输入

node read demo.js

我们查以看到js文件内容打印在了控制台上。

我们可以知道,node read可以读取demo.js文件,并将demo.js内容转化为ast对象。

同时它还提供了一个printSource函数,随时可以将ast的内容转换回源码,以方便调试。

recast.visit —— AST节点遍历

read.js

#!/usr/bin/env node
const recast  = require('recast')

recast.run(function(ast, printSource) {
  recast.visit(ast, {
      visitExpressionStatement: function({node}) {
        console.log(node)
        return false
      }
    });
});

recast.visit将AST对象内的节点进行逐个遍历。

注意

  • 你想操作函数声明,就使用visitFunctionDelaration遍历,想操作赋值表达式,就使用visitExpressionStatement。 只要在 AST对象文档中定义的对象,在前面加visit,即可遍历。
  • 通过node可以取到AST对象
  • 每个遍历函数后必须加上return false,或者选择以下写法,否则报错:
#!/usr/bin/env node
const recast  = require('recast')

recast.run(function(ast, printSource) {
  recast.visit(ast, {
      visitExpressionStatement: function(path) {
        const node = path.node
        printSource(node)
        this.traverse(path)
      }
    })
});

调试时,如果你想输出AST对象,可以console.log(node)

如果你想输出AST对象对应的源码,可以printSource(node)

命令行输入`
node read demo.js`进行测试。

#!/usr/bin/env node 在所有使用recast.run()的文件顶部都需要加入这一行,它的意义我们最后再讨论。

TNT —— 判断AST对象类型

TNT,即recast.types.namedTypes,就像它的名字一样火爆,它用来判断AST对象是否为指定的类型。

TNT.Node.assert(),就像在机器里埋好的炸药,当机器不能完好运转时(类型不匹配),就炸毁机器(报错退出)

TNT.Node.check(),则可以判断类型是否一致,并输出False和True

上述Node可以替换成任意AST对象,例如TNT.ExpressionStatement.check(),TNT.FunctionDeclaration.assert()

read.js

#!/usr/bin/env node
const recast = require("recast");
const TNT = recast.types.namedTypes

recast.run(function(ast, printSource) {
  recast.visit(ast, {
      visitExpressionStatement: function(path) {
        const node = path.value
        // 判断是否为ExpressionStatement,正确则输出一行字。
        if(TNT.ExpressionStatement.check(node)){
          console.log('这是一个ExpressionStatement')
        }
        this.traverse(path);
      }
    });
});

read.js

#!/usr/bin/env node
const recast = require("recast");
const TNT = recast.types.namedTypes

recast.run(function(ast, printSource) {
  recast.visit(ast, {
      visitExpressionStatement: function(path) {
        const node = path.node
        // 判断是否为ExpressionStatement,正确不输出,错误则全局报错
        TNT.ExpressionStatement.assert(node)
        this.traverse(path);
      }
    });
});

命令行输入`
node read demo.js`进行测试。

实战:用AST修改源码,导出全部方法

exportific.js

现在,我们想让这个文件中的函数改写成能够全部导出的形式,例如

function add (a, b) {
    return a + b
}

想改变为

exports.add = (a, b) => {
  return a + b
}

除了使用fs.read读取文件、正则匹配替换文本、fs.write写入文件这种笨拙的方式外,我们可以用AST优雅地解决问题

查询AST对象文档

首先,我们先用builders凭空实现一个键头函数

exportific.js

#!/usr/bin/env node
const recast = require("recast");
const {
  identifier:id,
  expressionStatement,
  memberExpression,
  assignmentExpression,
  arrowFunctionExpression,
  blockStatement
} = recast.types.builders

recast.run(function(ast, printSource) {
  // 一个块级域 {}
  console.log('\n\nstep1:')
  printSource(blockStatement([]))

  // 一个键头函数 ()=>{}
  console.log('\n\nstep2:')
  printSource(arrowFunctionExpression([],blockStatement([])))

  // add赋值为键头函数  add = ()=>{}
  console.log('\n\nstep3:')
  printSource(assignmentExpression('=',id('add'),arrowFunctionExpression([],blockStatement([]))))

  // exports.add赋值为键头函数  exports.add = ()=>{}
  console.log('\n\nstep4:')
  printSource(expressionStatement(assignmentExpression('=',memberExpression(id('exports'),id('add')),
    arrowFunctionExpression([],blockStatement([])))))
});

上面写了我们一步一步推断出exports.add = ()=>{}的过程,从而得到具体的AST结构体。

使用node exportific demo.js运行可查看结果。

接下来,只需要在获得的最终的表达式中,把id('add')替换成遍历得到的函数名,把参数替换成遍历得到的函数参数,把blockStatement([])替换为遍历得到的函数块级作用域,就成功地改写了所有函数!

另外,我们需要注意,在commonDivision函数内,引用了sub函数,应改写成exports.sub

exportific.js

#!/usr/bin/env node
const recast = require("recast");
const {
  identifier: id,
  expressionStatement,
  memberExpression,
  assignmentExpression,
  arrowFunctionExpression
} = recast.types.builders

recast.run(function (ast, printSource) {
  // 用来保存遍历到的全部函数名
  let funcIds = []
  recast.types.visit(ast, {
    // 遍历所有的函数定义
    visitFunctionDeclaration(path) {
      //获取遍历到的函数名、参数、块级域
      const node = path.node
      const funcName = node.id
      const params = node.params
      const body = node.body

      // 保存函数名
      funcIds.push(funcName.name)
      // 这是上一步推导出来的ast结构体
      const rep = expressionStatement(assignmentExpression('=', memberExpression(id('exports'), funcName),
        arrowFunctionExpression(params, body)))
      // 将原来函数的ast结构体,替换成推导ast结构体
      path.replace(rep)
      // 停止遍历
      return false
    }
  })


  recast.types.visit(ast, {
    // 遍历所有的函数调用
    visitCallExpression(path){
      const node = path.node;
      // 如果函数调用出现在函数定义中,则修改ast结构
      if (funcIds.includes(node.callee.name)) {
        node.callee = memberExpression(id('exports'), node.callee)
      }
      // 停止遍历
      return false
    }
  })
  // 打印修改后的ast源码
  printSource(ast)
})

一步到位,发一个最简单的exportific前端工具

上面讲了那么多,仍然只体现在理论阶段。

但通过简单的改写,就能通过recast制作成一个名为exportific的源码编辑工具。

以下代码添加作了两个小改动

  1. 添加说明书--help,以及添加了--rewrite模式,可以直接覆盖文件或默认为导出*.export.js文件。
  2. 将之前代码最后的 printSource(ast)替换成 writeASTFile(ast,filename,rewriteMode)

exportific.js

#!/usr/bin/env node
const recast = require("recast");
const {
  identifier: id,
  expressionStatement,
  memberExpression,
  assignmentExpression,
  arrowFunctionExpression
} = recast.types.builders

const fs = require('fs')
const path = require('path')
// 截取参数
const options = process.argv.slice(2)

//如果没有参数,或提供了-h 或--help选项,则打印帮助
if(options.length===0 || options.includes('-h') || options.includes('--help')){
  console.log(`
    采用commonjs规则,将.js文件内所有函数修改为导出形式。

    选项: -r  或 --rewrite 可直接覆盖原有文件
    `)
  process.exit(0)
}

// 只要有-r 或--rewrite参数,则rewriteMode为true
let rewriteMode = options.includes('-r') || options.includes('--rewrite')

// 获取文件名
const clearFileArg = options.filter((item)=>{
  return !['-r','--rewrite','-h','--help'].includes(item)
})

// 只处理一个文件
let filename = clearFileArg[0]

const writeASTFile = function(ast, filename, rewriteMode){
  const newCode = recast.print(ast).code
  if(!rewriteMode){
    // 非覆盖模式下,将新文件写入*.export.js下
    filename = filename.split('.').slice(0,-1).concat(['export','js']).join('.')
  }
  // 将新代码写入文件
  fs.writeFileSync(path.join(process.cwd(),filename),newCode)
}


recast.run(function (ast, printSource) {
  let funcIds = []
  recast.types.visit(ast, {
    visitFunctionDeclaration(path) {
      //获取遍历到的函数名、参数、块级域
      const node = path.node
      const funcName = node.id
      const params = node.params
      const body = node.body

      funcIds.push(funcName.name)
      const rep = expressionStatement(assignmentExpression('=', memberExpression(id('exports'), funcName),
        arrowFunctionExpression(params, body)))
      path.replace(rep)
      return false
    }
  })


  recast.types.visit(ast, {
    visitCallExpression(path){
      const node = path.node;
      if (funcIds.includes(node.callee.name)) {
        node.callee = memberExpression(id('exports'), node.callee)
      }
      return false
    }
  })

  writeASTFile(ast,filename,rewriteMode)
})

现在尝试一下

node exportific demo.js

已经可以在当前目录下找到源码变更后的demo.export.js文件了。

npm发包

编辑一下package.json文件

{
  "name": "exportific",
  "version": "0.0.1",
  "description": "改写源码中的函数为可exports.XXX形式",
  "main": "exportific.js",
  "bin": {
    "exportific": "./exportific.js"
  },
  "keywords": [],
  "author": "wanthering",
  "license": "ISC",
  "dependencies": {
    "recast": "^0.15.3"
  }
}

注意bin选项,它的意思是将全局命令exportific指向当前目录下的exportific.js

这时,输入npm link 就在本地生成了一个exportific命令。

之后,只要哪个js文件想导出来使用,就exportific XXX.js一下。

这是在本地的玩法,想和大家一起分享这个前端小工具,只需要发布npm包就行了。

同时,一定要注意exportific.js文件头有

#!/usr/bin/env node

否则在使用时将报错。

接下来,正式发布npm包!

如果你已经有了npm 帐号,请使用npm login登录

如果你还没有npm帐号 https://www.npmjs.com/signup 非常简单就可以注册npm

然后,输入
npm publish

没有任何繁琐步骤,丝毫审核都没有,你就发布了一个实用的前端小工具exportific 。任何人都可以通过

npm i exportific -g

全局安装这一个插件。

提示:==在试验教程时,请不要和我的包重名,修改一下发包名称。==

结语

我们对javascript再熟悉不过,但透过AST的视角,最普通的js语句,却焕发出精心动魄的美感。你可以通过它批量构建任何javascript代码!

童年时,这个世界充满了新奇的玩具,再普通的东西在你眼中都如同至宝。如今,计算机语言就是你手中的大玩具,一段段AST对象的拆分组装,构建出我们所生活的网络世界。

所以不得不说软件工程师是一个幸福的工作,你心中住的仍然是那个午后的少年,永远有无数新奇等你发现,永远有无数梦想等你构建。

github地址:https://github.com/wanthering...

image

查看原文