HTTP2 协议学习笔记一

http/1.1 vs http/2

1999年6月份发布的http1.1协议,RFC2616 到现在有19年了,http1.1协议为web繁荣做出了巨大的贡献,但是随着web所承载的资源越来越多,http协议需要更新,以适应新时代的发展。2009年,Google工程师提出了HTTP协议的替代方案,SPDY .SPDY为HTTP2奠定了基础。SPDY协议包含了多路复用,帧和首部压缩的特性,这些特性也被在HTTP2协议中了 2015年5月14日HTTP/2协议发布。

怎么测试网站已使用http协议

我们可以下载Chrome浏览器插件HTTP/2 and SPDY indicator ,我们在浏览器地址栏中输入https://hpbn.co/primer-on-web-performance/#latency-as-a-performance-bottleneck  ,如下视频所示:

http2要解决的问题

http2要解决的问题就是减少延迟,在web服务中,延迟是web服务最重要的性能指标,也是web服务的性能瓶颈。  我们知道在OSI模型定义了七层结构。每层结构如下图所示:

阅读 “HTTP2 协议学习笔记一”

GC中的基础概念

在前一篇文章中,我们只是瞎扯一下垃圾回收。对垃圾回收的中的三大算法,标记-清除,引用计数,GC复制算法,并没有进行详细地描述。在论述这三大算法之前,我们先扯一扯GC中的基本概念,搞清楚基本概念,对理解垃圾回收算法就会容易一些。当然GC本来就是一个比较复杂的东西。

我们先看下面的一张图

在GC中,对应上图的,分别是 Heap(堆),Object(对象)Mutator(突变体),Stack(栈),Pointer(指针),Root(根)

阅读 “GC中的基础概念”

v8 javascript引擎 垃圾回收(1)

我们系统的内存是有限的,假如我们的服务器运行的服务存在内存泄漏时,如果用户基数大,垃圾会充斥着内存,导致我们的服务运行变慢,甚至系统宕机。说道内存泄漏,我们需要了解内存中堆与栈的概念。(垃圾回收相当复杂,本文是触及到一点点点点点皮毛,估计90%的是错误的)  阅读 “v8 javascript引擎 垃圾回收(1)”

Nodejs中block和non-blocking的概述(译+补充)

非堵塞IO说明图

本篇文章将介绍在Node.js中BlockingNon-Blocking调用的不同点。文中特指event looplibuv. 并不去阐述BlockingNon-Blocking的基础知识。读者需要对javascript 语言和Node.js的回调模式有个基础的了解。

“IO” 指的是通过libv实现与系统硬盘和网络的交互。

libv是个专为Nodejs编写的一个跨平台的基础库。它围绕事件驱动异步IO模型来设计的。下图libv库展示了各个子系统的构成。阅读 “Nodejs中block和non-blocking的概述(译+补充)”

使用parceljs构建项目

webpack的功能很强大,但是webpack的配置是一个让人头痛的问题,过于灵活的配置导致优化的地方很多,现在出现了一款打包工具Parcel 能解决我们这些头痛的问题。

Parcel的优势

快速打包

Parcel 使用工作进程启用多核编译,并具有文件系统缓存,即使在重新启动后也可快速重新构建

打包所有资源

Parcel 支持JS,CSS,HTML,文件资源等等 – 不需要安装任何插件。

零配置代码拆分

Parcel 使用动态 import() 语法拆分您的输出包,所以只加载初始加载时所需的内容。

模块热替换

当我们在开发过程中进行更改时,Parcel 会自动更新浏览器中的模块,不需要进行任何配置。阅读 “使用parceljs构建项目”

vue代码分割实践记录

vue代码分割的形象示意图
vue代码分割示意图

背景

在上一篇文章,介绍了利用webpack怎么建立长期有效的缓存机制,这篇文章将在此基础上,对vue代码进行分割的操作,这个是我们使用vue架构大型项目的时候,需要考虑的点。

一般使用vue开发项目的时候,我们把vue,vue-router,vuex,axios基础库代码打包成一个vendor.js文件,把业务代码打包成一个main.js类似名字的代码。库代码基本在较长时间内会一直保存不变,这样我们能够对这类代码进行长期缓存,减少带宽压力,减少http请求次数,最多增加304请求问题。

但是,随着项目越来越大,业务代码随之变大,如我在vipkid 参与的学习中心的业务代码已达到1.2MB,虽然服务器对代码进行了gzip压缩,在网络上的传输的体积也有将近300KB,当用户的网络环境比较差的时候,首屏加载变慢,有些情况下进入界面需要4s-5s 这对于用户来说,是不可忍受。在此情况下,我们需要降低首屏加载时间,希望能控制的1s-1.5s之内。阅读 “vue代码分割实践记录”

Vue2.4中$attrs和$listeners的使用-学习笔记

首先我们来看下面的一张图,图中表示一个多级组件嵌套的情形。

现在我们来讨论一种情况,A组件与C组件怎么通信,我们有多少种解决方案?

  1. 我们使用VueX来进行数据管理,但是如果项目中多个组件共享状态比较少,项目比较小,并且全局状态比较少,那使用VueX来实现该功能,并没有发挥出VueX的威力。
  2. 使用B来做中转站,当A组件需要把信息传给C组件时,B接受A组件的信息,然后利用属性传给C组件,这是一种解决方案,但是如果嵌套的组件过多,会导致代码繁琐,代码维护比较困难;如果C中状态的改变需要传递给A, 使用事件系统一级级往上传递 。本来
  3. 自定义一个Vue 中央数据总线,这个情况适合碰到组件跨级传递消息,但是使用VueX感觉又有点浪费的项目中,但是缺点是,碰到多人合作时,代码的维护性较低,代码可读性低

在很多开发情况下,我们只是想把A组件的信息传递给C组件,如果使用props 绑定来进行信息的传递,虽然能够实现,但是代码并不美观。

在vue2.4中,为了解决该需求,引入了$attrs$listeners , 新增了inheritAttrs 选项。 在版本2.4以前,默认情况下父作用域的不被认作props的属性属性百年孤独,将会“回退”且作为普通的HTML特性应用在子组件的根元素上。如下列的例子

阅读 “Vue2.4中$attrs和$listeners的使用-学习笔记”

还原真实的MV*模式(转)

本文转自https://github.com/livoras/blog/issues/11 

前言

做客户端开发、前端开发对MVC、MVP、MVVM这些名词不了解也应该大致听过,都是为了解决图形界面应用程序复杂性管理问题而产生的应用架构模式。网上很多文章关于这方面的讨论比较杂乱,各种MV模式之间的区别分不清,甚至有些描述都是错误的。本文追根溯源,从最经典的Smalltalk-80 MVC模式开始逐步还原图形界面之下最真实的MV模式。

GUI程序所面临的问题

图形界面的应用程序提供给用户可视化的操作界面,这个界面提供给数据和信息。用户输入行为(键盘,鼠标等)会执行一些应用逻辑,应用逻辑(application logic)可能会触发一定的业务逻辑(business logic)对应用程序数据的变更,数据的变更自然需要用户界面的同步变更以提供最准确的信息。例如用户对一个电子表格重新排序的操作,应用程序需要响应用户操作,对数据进行排序,然后需要同步到界面上。

在开发应用程序的时候,以求更好的管理应用程序的复杂性,基于职责分离(Saparetion of Duties)的思想都会对应用程序进行分层。在开发图形界面应用程序的时候,会把管理用户界面的层次称为View,应用程序的数据为Model(注意这里的Model指的是Domain Model,这个应用程序对需要解决的问题的数据抽象,不包含应用的状态,可以简单理解为对象)。Model提供数据操作的接口,执行相应的业务逻辑。

MV*M架构模式示意图

有了View和Model的分层,那么问题就来了:View如何同步Model的变更,View和Model之间如何粘合在一起。

带着这个问题开始探索MV模式,会发现这些模式之间的差异可以归纳为对这个问题处理的方式的不同。而几乎所有的MV模式都是经典的Smalltalk-80 MVC的修改版。阅读 “还原真实的MV*模式(转)”