hezhongfeng

hezhongfeng 查看完整档案

填写现居城市长春理工大学  |  电子科学与技术 编辑吉林祥云  |  前端工程师 编辑 www.hezf.online/ 编辑
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 个人简介什么都没有

个人动态

hezhongfeng 赞了文章 · 2020-09-08

陪尤雨溪一起,实现 Vuex 无限层级类型推断。(TS 4.1 新特性)

前言

前几天,TypeScript 发布了一项 4.1 版本的新特性,字符串模板类型,还没有了解过的小伙伴可以先去这篇看一下:TypeScript 4.1 新特性:字符串模板类型,Vuex 终于有救了?

本文就利用这个特性,简单实现下 Vuex 在 modules 嵌套情况下的 dispatch 字符串类型推断,先看下效果,我们有这样结构的 store

const store = Vuex({
  mutations: {
    root() {},
  },
  modules: {
    cart: {
      mutations: {
        add() {},
        remove() {},
      },
    },
    user: {
      mutations: {
        login() {},
      },
      modules: {
        admin: {
          mutations: {
            login() {},
          },
        },
      },
    },
  },
})

需要实现这样的效果,在 dispatch 的时候可选的 action 字符串类型要可以被提示出来:

store.dispatch('root')
store.dispatch('cart/add')
store.dispatch('user/login')
store.dispatch('user/admin/login')

实现

定义函数骨架

首先先定义好 Vuex 这个函数,用两个泛型把 mutationsmodules 通过反向推导给拿到:

type Store<Mutations, Modules> = {
  // 下文会实现这个 Action 类型
  dispatch(action: Action<Mutations, Modules>): void
}

type VuexOptions<Mutations, Modules> = {
  mutations: Mutations
  modules: Modules
}

declare function Vuex<Mutations, Modules>(
  options: VuexOptions<Mutations, Modules>
): Store<Mutations, Modules>

实现 Action

那么接下来的重点就是实现 dispatch(action: Action<Mutations, Modules>): void 中的 Action 了,我们的目标是把他推断成一个 'root' | 'cart/add' | 'user/login' | 'user/admin/login' 这样的联合类型,这样用户在调用 dispatch 的时候,就可以智能提示了。

Action 里首先可以简单的先把 keyof Mutations 拿到,因为根 store 下的 mutations 不需要做任何的拼接,

重头戏在于,我们需要根据 Modules 这个泛型,也就是对应结构:

modules: {
   cart: {
      mutations: {
         add() { },
         remove() { }
      }
   },
   user: {
      mutations: {
         login() { }
      },
      modules: {
         admin: {
            mutations: {
               login() { }
            },
         }
      }
   }
}

来拿到 modules 中的所有拼接后的 key

推断 Modules Keys

先提前和大伙同步好,后续泛型里的:

  • Modules 代表 { cart: { modules: {} }, user: { modules: {} } 这种多个 Module 组合的对象结构。
  • Module 代表单个子模块,比如 cart

利用

type Values<Modules> = {
  [K in keyof Modules]: Modules[K]
}[keyof Modules]

这种方式,可以轻松的把对象里的所有 类型给展开,比如

type Obj = {
  a: 'foo'
  b: 'bar'
}

type T = Values<Obj> // 'foo' | 'bar'

由于我们要拿到的是 cartuser 对应的值里提取出来的 key

所以利用上面的知识,我们编写 GetModulesMutationKeys 来获取 Modules 下的所有 key

type GetModulesMutationKeys<Modules> = {
  [K in keyof Modules]: GetModuleMutationKeys<Modules[K], K>
}[keyof Modules]

首先利用 K in keyof Modules 来拿到所有的 key,这样我们就可以拿到 cartuser 这种单个 Module,并且传入给 GetModuleMutationKeys 这个类型,K 也要一并传入进去,因为我们需要利用 cartuser 这些 key 来拼接在最终得到的类型前面。

推断单个 Module Keys

接下来实现 GetModuleMutationKeys,分解一下需求,首先单个 Module 是这样子的:

cart: {
   mutations: {
      add() { },
      remove() { }
   }
},

那么拿到它的 Mutations 后,我们只需要去拼接 cart/addcart/remove 即可,那么如何拿到一个对象类型中的 mutations

我们用 infer 来取:

type GetMutations<Module> = Module extends { mutations: infer M } ? M : never

然后通过 keyof GetMutations<Module>,即可轻松拿到 'add' | 'remove' 这个类型,我们再实现一个拼接 Key 的类型,注意这里就用到了 TS 4.1 的字符串模板类型了

type AddPrefix<Prefix, Keys> = `${Prefix}/${Keys}`

这里会自动把联合类型展开并分配,${'cart'}/${'add' | 'remove'} 会被推断成 'cart/add' | 'cart/remove',不过由于我们传入的是 keyof GetMutations<Module> 它还有可能是 symbol | number 类型,所以用 Keys & string 来取其中的 string 类型,这个技巧也是老爷子在 Template string types MR 中提到的:

Above, a keyof T & string intersection is required because keyof T could contain symbol types that cannot be transformed using template string types.
type AddPrefix<Prefix, Keys> = `${Prefix & string}/${Keys & string}`

那么,利用 AddPrefix<Key, keyof GetMutations<Module>> 就可以轻松的把 cart 模块下的 mutations 拼接出来了。

推断嵌套 Module Keys

cart 模块下还可能有别的 Modules,比如这样:

cart: {
   mutations: {
      add() { },
      remove() { }
   }
   modules: {
      subCart: {
          mutations: {
          add() { },
        }
      }
   }
},

其实很简单,我们刚刚已经定义好了从 Modules 中提取 Keys 的工具类型,也就是 GetModulesMutationKeys,只需要递归调用即可,不过这里我们需要做一层预处理,把 modules 不存在的情况给排除掉:

type GetModuleMutationKeys<Module, Key> =
  // 这里直接拼接 key/mutation
  | AddPrefix<Key, keyof GetMutations<Module>>
  // 这里对子 modules 做 keys 的提取
  | GetSubModuleKeys<Module, Key>

利用 extends 去判断类型结构,对不存在 modules 的结构直接返回 never,再用 infer 去提取出 Modules 的结构,并且把前一个模块的 key 拼接在刚刚写好的 GetModulesMutationKeys 返回的结果之前:

type GetSubModuleKeys<Module, Key> = Module extends { modules: infer SubModules }
  ? AddPrefix<Key, GetModulesMutationKeys<SubModules>>
  : never

以这个 cart 模块为例,分解一下每个工具类型得到的结果:

cart: {
   mutations: {
      add() { },
      remove() { }
   }
   modules: {
      subCart: {
          mutations: {
          add() { },
        }
      }
   }
},

type GetModuleMutationKeys<Module, Key> =
    // 'cart/add' | 'cart | remove'
    AddPrefix<Key, keyof GetMutations<Module>> |
    // 'cart/subCart/add'
    GetSubModuleKeys<Module, Key>

type GetSubModuleKeys<Module, Key> = Module extends { modules: infer SubModules }
   ? AddPrefix<
       // 'cart'
       Key,
       // 'subCart/add'
       GetModulesMutationKeys<SubModules>
   >
   : never

这样,就巧妙的利用递归把无限层级的 modules 拼接实现了。

完整代码

type GetMutations<Module> = Module extends { mutations: infer M } ? M : never

type AddPrefix<Prefix, Keys> = `${Prefix & string}/${Keys & string}`

type GetSubModuleKeys<Module, Key> = Module extends { modules: infer SubModules }
   ? AddPrefix<Key, GetModulesMutationKeys<SubModules>>
   : never

type GetModuleMutationKeys<Module, Key> = AddPrefix<Key, keyof GetMutations<Module>> | GetSubModuleKeys<Module, Key>

type GetModulesMutationKeys<Modules> = {
   [K in keyof Modules]: GetModuleMutationKeys<Modules[K], K>
}[keyof Modules]

type Action<Mutations, Modules> = keyof Mutations | GetModulesMutationKeys<Modules>

type Store<Mutations, Modules> = {
   dispatch(action: Action<Mutations, Modules>): void
}

type VuexOptions<Mutations, Modules> = {
   mutations: Mutations,
   modules: Modules
}

declare function Vuex<Mutations, Modules>(options: VuexOptions<Mutations, Modules>): Store<Mutations, Modules>

const store = Vuex({
   mutations: {
      root() { },
   },
   modules: {
      cart: {
         mutations: {
            add() { },
            remove() { }
         }
      },
      user: {
         mutations: {
            login() { }
         },
         modules: {
            admin: {
               mutations: {
                  login() { }
               },
            }
         }
      }
   }
})

store.dispatch("root")
store.dispatch("cart/add")
store.dispatch("user/login")
store.dispatch("user/admin/login")

前往 TypeScript Playground 体验。

结语

这个新特性给 TS 库开发的作者带来了无限可能性,有人用它实现了 URL Parser 和 HTML parser,有人用它实现了 JSON parse 甚至有人用它实现了简单的正则,这个特性让类型体操的爱好者以及框架的库作者可以进一步的大展身手,期待他们写出更加强大的类型库来方便业务开发的童鞋吧~

谢谢大家

关注公众号「前端从进阶到入院」,后台回复 TS,送几本「TypeScript项目实战」了,非常棒的一本实战书。

查看原文

赞 9 收藏 5 评论 4

hezhongfeng 发布了文章 · 2020-08-18

有趣的算法『爬楼梯』

爬楼梯

这道题最初是在一个孙红雷演的电影《少年班》里面看到的,当时没搞懂怎么解决,但有了一个印象,后来再遇到的时候就感觉很有趣,值得研究一下。

假设你正在爬楼梯。需要 n  阶你才能到达楼顶。

每次你可以爬 1 或 2 个台阶。你有多少种不同的方法可以爬到楼顶呢?

注意:给定 n 是一个正整数。

示例 1:

输入: 2
输出: 2
解释: 有两种方法可以爬到楼顶。
1.  1 阶 + 1 阶
2.  2 阶

示例 2:

输入: 3
输出: 3
解释: 有三种方法可以爬到楼顶。
1.  1 阶 + 1 阶 + 1 阶
2.  1 阶 + 2 阶
3.  2 阶 + 1 阶

来源:LeetCode

思路

这道题的难度是 Easy,但是我第一次见到的时候并没有想到办法,后来看到别人的解法才感到恍然大悟,我们一步步来。

说下这道题的思路:上 第 N 阶台阶的话,最后一步只能是迈 1 阶或者 2 阶这两种情况,所以到 N 阶台阶的所有方法等于到 N-1 阶和 到 N-2 阶的所有方法的和。

转化成公式就是:f(N)=f(N-1)+f(N-2)f(N)的意思是到 N 阶台阶的所有方法数

已知:f(1)=1f(2)=2,上代码

var climbStairs = function (n) {
  if (n === 1) {
    return 1;
  }
  if (n === 2) {
    return 2;
  }
  return climbStairs(n - 1) + climbStairs(n - 2);
};

测试下,结果在算 45 阶的时候超时了,下一步需要考虑怎么优化

优化

我们可以看到,按照上面的思路是没有问题的,只是运算超时了,那么就需要考虑下怎么加快运算,我们可以尝试画出求解的整个过程,来寻找优化的思路。

分解45

通过上图我们可以看到,f(45) = f(43)+f(44) ,然后可以继续分解:

f(45) = f(43) + f(44);
f(45) = f(41) + f(42) + f(42) + f(43);
// .....
// .....
// .....
// 最后分解到了已知值,即:
f(1) = 1;
f(2) = 2;

在整个分解的过程中,我们会发现其实有一些重复的值,比如上面的f(42)求解了两次,而且f(42)f(43)会继续分解出重复的值。

那么我们可以想办法不去求解重复的值,利用已经求解完毕的值做一个备份,发现已经求解的直接拿来用,上代码。

let dp = new Map();
dp.set(1, 1).set(2, 2);

var climbStairs = function (n) {
  if (dp.has(n)) {
    return dp.get(n);
  }
  let result = climbStairs(n - 1) + climbStairs(n - 2);
  dp.set(n, result);
  return result;
};

提交后的结果:

  • 45/45 cases passed (92 ms)
  • Your runtime beats 9.54 % of javascript submissions
  • Your memory usage beats 42.58 % of javascript submissions (37.5 MB)

还可以,终于不是超时了,但是结果来看,我们的排名并不靠前,那么还有继续优化的空间了吗?

继续优化

我们发现,求解完毕一个 f(45) 之后,dp 里面记录了从 f(1)f(45)的所有的值,实际上我们只想要f(45)的值。

我们换个思路,求f(45)的过程,分解为先求f(3),然后再求f(4)......一直到f(45),上代码:

var climbStairs = function (n) {
  if (n === 1 || n === 2) {
    return n;
  }
  // 前一个值
  let pre = 2;
  // 前一个的前一个的值
  let beforePre = 1;
  // 中间变量
  let temp = null;
  for (let index = 3; index <= n; index++) {
    temp = pre;
    pre = pre + beforePre;
    beforePre = temp;
  }
  return pre;
};

提交下看看结果:

  • 45/45 cases passed (76 ms)
  • Your runtime beats 42.21 % of javascript submissions
  • Your memory usage beats 79.72 % of javascript submissions (37.4 MB)

感觉还不错,上面的方法只用了 3 个变量,就从f(3)一直算到了 f(45),时间复杂度和空间复杂度都很低

查看原文

赞 0 收藏 0 评论 0

hezhongfeng 发布了文章 · 2020-08-06

浏览器缓存最佳实践

最佳实践

上来先说结论,原因放在后面:

  1. index.html 不做缓存,每次请求都获取最新版本
  2. 使用 webpack 等 build 后的其他所有资源文件(包括 js、css 和图片等),都做强缓存(一个月打底,可以设置一年)

原因

强缓存和协商缓存在社区已经被写烂了,都知道是怎么回事,这里就不做详细解释了,这里解释下为什么说上面的是最佳实践。

我们知道协商缓存其实也向服务端发起了一个请求,只不过最后经过一系列验证,结果就是不传输具体内容了,但是验证的过程也给后端造成了一些开销,所以我们要尽量减少这种开销。

那么把前端资源都用作强缓存就是最好的处理办法了,但是又面临一个问题『前端发版怎么更新』

这时候我们需要注意 build 后的前端资源,现在各个脚手架默认都会把文件名字生成一段 hash 值
xxx.6ae44c4e.js这种。原来我一直不明白这样的意义在哪,现在明白了。

首先 index.html 不做缓存,所以当我们发版以后浏览器会获取到最新的 index.html 文件,由于每次 build 之后生成的文件名字不同,index.html 引入的前端的资源就不同,旧的所有的资源文件包括 js、css 和图片等)都不会影响新发版的内容。

这样的话就做到了在不发版的情况下,每次刷新基本就一个 index.html 的资源还有一些接口请求,其余的全都是强缓存资源。发版之后可以立马更新,不会造成资源混乱。现在掘金和 segmentfault 都是采取的这种策略。

实践数据对比

强缓存

和运维的同事商量了强缓存的优化,将 build 之后的 static 文件夹全部做了 add_header Cache-Control "max-age=30243600",也就是强缓存 30 天的设置。

经过测试发现,由协商缓存到强缓存后,有如下变化:

类型请求数实际传输资源大小传输完毕(Finish)DOMContentLoadedLoad
协商缓存631168K2.00s447 ms717 ms
强缓存63123K1.43s424 ms704 ms

结果分析

首先,请求数量是一样的,完全 Load 的时候差不多,Finish 的时间提升了 25%,传输的资源大小减少了 80% 以上,同时由于没有和服务端去进行协商,相当于对服务端也做了优化。这些都是在协商缓存的基础上做的优化对比,如果后端服务连协商缓存都没上的话,真的应该优化一下了。

查看原文

赞 6 收藏 3 评论 4

hezhongfeng 发布了文章 · 2020-08-05

有趣的算法『打开转盘锁』

题目描述

你有一个带有四个圆形拨轮的转盘锁。每个拨轮都有 10 个数字: '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' 。每个拨轮可以自由旋转:例如把 '9' 变为   '0','0' 变为 '9' 。每次旋转都只能旋转一个拨轮的一位数字。

锁的初始数字为 '0000' ,一个代表四个拨轮的数字的字符串。

列表 deadends 包含了一组死亡数字,一旦拨轮的数字和列表里的任何一个元素相同,这个锁将会被永久锁定,无法再被旋转。

字符串 target 代表可以解锁的数字,你需要给出最小的旋转次数,如果无论如何不能解锁,返回 -1。

示例 1:

输入:deadends = ["0201","0101","0102","1212","2002"], target = "0202"
输出:6
解释:
可能的移动序列为 "0000" -> "1000" -> "1100" -> "1200" -> "1201" -> "1202" -> "0202"。
注意 "0000" -> "0001" -> "0002" -> "0102" -> "0202" 这样的序列是不能解锁的,
因为当拨动到 "0102" 时这个锁就会被锁定。

示例 2:

输入: deadends = ["8888"], target = "0009"
输出:1
解释:
把最后一位反向旋转一次即可 "0000" -> "0009"。

示例 3:

输入: deadends = ["8887","8889","8878","8898","8788","8988","7888","9888"], target = "8888"
输出:-1
解释:
无法旋转到目标数字且不被锁定。

示例 4:

输入: deadends = ["0000"], target = "8888"
输出:-1

提示:

  1. 死亡列表 deadends 的长度范围为 [1, 500]。
  2. 目标数字 target 不会在 deadends 之中。
  3. 每个 deadends 和 target 中的字符串的数字会在 10,000 个可能的情况 '0000' 到 '9999' 中产生。

来源:力扣(LeetCode)链接

思路

这道题很有意思,有个类似于我们皮箱的那种密码锁,可以通过上下转动转出任意的密码,不过这里有个限制,就是不能通过一些死亡数字,算是给我们增加了一些难度,否则的话就只看密码的数字是大还是小了,例如是 3 的话就从0->1->2->3,是 8 的话就0->9->8

我们可以把0 0 0 0看做一个原点,然后这 1 个点可以变化出 8 种不同的结果,如下图所示:

图1

然后这 8 个点可以继续变化:

图2

请注意观察上图,其中有 8 种组合又回到了 0 0 0 0,还有蓝色部分都是具有重合项的。

那么我们的思路来了,可以利用这种变化,从0 0 0 0变化为 8 个点,再继续由先和 8 个点继续变化。。。直到我们找到了目标密码,每变化一次需要旋转一次。

var openLock = function (deadends, target) {
  // 存储所有的原点,最初是 0000
  let nodes = new Set();
  nodes.add('0000');
  // 匹配过的点,比如 0000 这种,对于匹配过的点不会加入到原点集合里面去
  const history = new Set();
  // 初始化旋转次数
  let step = 0;
  // 向上旋转,例如从0->1
  const plus = function (nums, i) {
    let array = nums.split('');
    if (array[i] === '9') {
      array[i] = '0';
    } else {
      array[i] = Number(array[i]) + 1;
    }
    return array.join('');
  };
  // 向下旋转,例如从0->9
  const miuns = function (nums, i) {
    let array = nums.split('');
    if (array[i] === '0') {
      array[i] = '9';
    } else {
      array[i] = Number(array[i]) - 1;
    }
    return array.join('');
  };

  // 原点没有目标密码
  while (!nodes.has(target)) {
    // 新增的原点集合
    const newNodes = new Set();
    // 当前原点集合
    for (const nums of nodes) {
      // 遇到不通的路就跳过
      if (deadends.includes(nums)) {
        continue;
      }
      // 遍历数字,分别做向上和向下旋转
      for (let i = 0; i < nums.length; i++) {
        // 旋转后的结果,把向上和向下旋转后的原点都存储起来
        let result = plus(nums, i);
        // 排除已选择的原点
        if (!history.has(result) && !newNodes.has(result)) {
          newNodes.add(result);
        }
        result = miuns(nums, i);
        if (!history.has(result) && !newNodes.has(result)) {
          newNodes.add(result);
        }
      }
      // 已检查过的原点
      history.add(nums);
    }
    step++;
    // 新生成的原点集合,下一轮将对这些原点进行旋转
    nodes = newNodes;
    // 这里很关键,最后可能收敛没了
    if (nodes.size === 0) {
      return -1;
    }
  }

  return step;
};

经过测试结果如下:

  • 43/43 cases passed (652 ms)
  • Your runtime beats 33.05 % of javascript submissions
  • Your memory usage beats 72.41 % of javascript submissions (48.8 MB)

结果正确,但好像运行时间有点长,哪里可以优化呢?

我们目前的思路是由一个原点慢慢扩散到终点,也就是目标密码。就像是向水面扔了一颗石子,激起了一圈的涟漪,然后这圈涟漪最终碰到了我们的目标,那么如果我同时在目标处扔一个石子,让两个涟漪互相靠近,这样是不是会快很多呢?直觉告诉我肯定会快很多,而且,涟漪不需要扩散得很大就可以发现目标,我们来试一下

var openLock = function (deadends, target) {
  // 存储所有的原点,最初是 0000
  let nodes = new Set();
  nodes.add('0000');
  // 目标原点
  let targetNodes = new Set();
  targetNodes.add(target);
  // 匹配过的点,比如 0000 这种,对于匹配过的点不会加入到原点集合里面去
  const history = new Set();
  // 初始化旋转次数
  let step = 0;
  // 向上旋转,例如从0->1
  const plus = function (nums, i) {
    let array = nums.split('');
    if (array[i] === '9') {
      array[i] = '0';
    } else {
      array[i] = Number(array[i]) + 1;
    }
    return array.join('');
  };
  // 向下旋转,例如从0->9
  const miuns = function (nums, i) {
    let array = nums.split('');
    if (array[i] === '0') {
      array[i] = '9';
    } else {
      array[i] = Number(array[i]) - 1;
    }
    return array.join('');
  };

  // 原点没有目标密码
  while (nodes.size > 0 && targetNodes.size > 0) {
    // 新增的原点集合
    const newNodes = new Set();
    // 当前原点集合
    for (const nums of nodes) {
      // 遇到不通的路就跳过
      if (deadends.includes(nums)) {
        continue;
      }
      // 相遇
      if (targetNodes.has(nums)) {
        return step;
      }
      // 遍历数字,分别做向上和向下旋转
      for (let i = 0; i < nums.length; i++) {
        // 旋转后的结果,把向上和向下旋转后的原点都存储起来
        let result = plus(nums, i);
        // 排除已选择的原点
        if (!history.has(result) && !newNodes.has(result)) {
          newNodes.add(result);
        }
        result = miuns(nums, i);
        if (!history.has(result) && !newNodes.has(result)) {
          newNodes.add(result);
        }
      }
      // 已检查过的原点
      history.add(nums);
    }
    step++;
    // 交换集合,下一轮对targetNodes进行检查
    nodes = targetNodes;
    // 新生成的原点集合,下下一轮将对这些原点进行旋转
    targetNodes = newNodes;
  }

  // 没有结果
  return -1;
};

代码稍加改动的结果:

  • 43/43 cases passed (208 ms)
  • Your runtime beats 80 % of javascript submissions
  • Your memory usage beats 100 % of javascript submissions (44.2 MB)

借用斯温(DOTA 英雄)的一句名言:『这下牛 b 了』,运行时间和所占内存都上了一个台阶

最近在看算法方面的内容,碰到有趣的就分享一下,会持续分享

查看原文

赞 7 收藏 5 评论 0

hezhongfeng 发布了文章 · 2020-07-21

Vue完美记住滚动条和实现下拉加载

滚动条

常见于移动端 App 在滚动点击进入的时候

问题描述

当我们在开发 web app 的时候,经常会遇到一个问题,就是当从一个可滚动的列表页进入到下一个详情页面,然后返回列表页面的时候,很难去还原滚动条的状态,无法记住进来时候的位置。

以前我尝试过很多方法:

  1. 有 vue-router 自带的 scrollBehavior,需要记住 scrollTop,然后还原,但是管理这个 scrollTop 显得很麻烦,有的时候还不容易取值
  2. 还有使用纯 CSS 的方式,在列表页面放置一个 router-view,详情页面利用 position 和 z-index 覆盖列表页面,返回后直接显示的就是原来的列表页面,这个必须把各层页面路由预先配置好,不然就会显示混乱了,并且同一个页面出现在不同的子路由下,需要配置多次,比如商品详情需要配置在很多个地方,造成冗余

以上解决方案都不理想

解决方案

后来我参考 keep-alive 开发了 vue-page-stack 来保存 Vue 页面的栈,即 Vue 中的虚拟 dom,但是滚动条的问题仍然没解决。因为虚拟 dom 没有记录各个组件的滚动状态,所以无法恢复。

在我使用 cube-ui 的时候发现,使用这个组件库里面的滚动容器,是可以还原出滚动条的,进一步发现是黄轶老师的 better-scroll 的原因。

通过查看 bs 的源码发现,原来是 bs 的内部实现不是原生滚动,而是记录一些滚动的信息,其中最重要的就是 x 和 y,也就是滚动的值,自己实现了一套滚动行为通过 transform 去实现,在还原虚拟 dom 的时候,滚动的信息也被还原了。

最终就是 vue—page-stack + bs 可以完美实现页面栈的还原

下拉加载

这个问题多见于消息记录等查询,在小程序中也会这遇到这样的问题

问题描述

绝大多数滚动场景都是上拉加载,上拉加载的时候,加载的内容在滚动区域的下方出现,加载之后,我们将数据添加到列表,由 Vue 等负责渲染新加载的内容,我们继续上拉就可以继续滚动查看。

但在我们的场景下,在某一会话中翻阅消息记录的时候,是下拉加载更多消息,加载后,继续下拉慢慢滚动查看。这就导致了一个很严重的问题:下拉加载后出现的内容在滚动区域的上方,不做任何处理的话加载后会直接跳到新加载内容的最上方,因为滚动距离没变,这就出问题了,和我们想实现的不一致。

解决方案

也想了很多的方法,包括计算新增加消息的总长度,然后滚回来,但是消息的类型和高度不一致,计算会有误差。

最终想到的处理办法就是:

  1. 通过接口获取到加载信息后首先标记(使用 shouldScroll 标记)后端返回的第一条信息,也就是加载后我们的视角要看到的新内容
  2. messageList 更新后,Vue 会更新数据和视图,这时候页面 dom 被更新了
  3. MessageItem 组件 mounted 后,这时候已经完成了视图的渲染,通过检查标记(shouldScroll),通知父容器滚动到刚才标记的位置,也就是加载的第一条信息处,这样也就把渲染和滚动做到一起了

以上两个问题在下图均有体现,效果还可以,如下:

以上内容在我的即时通讯应用客户端中均有体现,欢迎查看源码

现已部署上线,欢迎体验客户端管理端

查看原文

赞 8 收藏 6 评论 0

hezhongfeng 发布了文章 · 2020-07-20

搭建完整的IM(即时通讯)应用(2)

即时通讯应用服务,整套包含服务端管理端客户端,欢迎Star支持和查看源码。

现已部署上线,欢迎体验客户端管理端

咱们书接上文,继续完成完整的即时通讯服务,这篇着重讲下Server端项目中我认为几个重要的点,大部分内容需要去我的仓库源码和 egg 官网查看。

server 端详细说明

使用脚手架npm init egg --type=simple初始化 server 项目,安装 mysql(我的是 8.0 版本),配置上 sequelize 所需的数据库链接密码等,就可以启动了
着重讲下 Server 端项目中我认为几个重要的点,大部分内容需要去 egg 官网查看。

// 目录结构说明

├── package.json // 项目信息
├── app.js // 启动文件,其中有一些钩子函数
├── app
|   ├── router.js // 路由
│   ├── controller
│   ├── service
│   ├── middleware // 中间件
│   ├── model // 实体模型
│   └── io // socket.io 相关
│       ├── controller
│       └── middleware // io独有的中间件
├── config // 配置文件
|   ├── plugin.js // 插件配置文件
|   └── config.default.js // 默认的配置文件
├── logs // server运行期间产生的log文件
└── public // 静态文件和上传文件目录

路由

Router 主要用来描述请求 URL 和具体承担执行动作的 Controller 的对应关系,即 app/router

  1. 路由使用了版本号 v1,方便以后升级,一般的增删改查直接使用 restful 的方式比较简单
  2. 除了登录和注册的接口,在其余所有 http 接口添加了对 session 的检查,校验登录状态,位置在app/middleware/auth.js
  3. 在所有管理端的接口处添加了对 admin 权限的检查,位置在app/middleware/admin.js

统一鉴权

因为本系统预设有管理员和一般通信用户的不同角色,所以需要针对管理和通信的接口路由做一下统一的鉴权处理。

比如管理端的路由/v1/admin/...,想在这个系列路由全都添加管理员的鉴权,这时候可以用中间件的方式进行鉴权,下面是在 admin router 中使用中间件的具体例子

// middware
module.exports = () => {
  return async function admin(ctx, next) {
    let { session } = ctx;

    // 判断admin权限
    if (session.user && session.user.rights.some(right => right.keyName === 'admin')) {
      await next();
    } else {
      ctx.redirect('/login');
    }
  };
};

// router
const admin = app.middleware.admin();
router.get('/api/v1/admin/rights', admin, controller.v1.admin.rightsIndex);

数据库相关

使用的 sequelize+mysql 组合,egg 也有 sequelize 的相关插件,sequelize 即是一款 Node 环境使用的 ORM,支持 Postgres, MySQL, MariaDB, SQLite 和 Microsoft SQL Server,使用起来还是挺方便的。需要先定义模型和模型直接的关系,有了关系之后便可以使用一些预设的方法了。

model 实体模型

模型的基础信息比较容易处理,需要注意的就是实体之间的关系设计,即 associate,下面是 user 的关系描述

// User.js
module.exports = app => {
  const { STRING } = app.Sequelize;

  const User = app.model.define('user', {
    provider: {
      type: STRING
    },
    username: {
      type: STRING,
      unique: 'username'
    },
    password: {
      type: STRING
    }
  });

  User.associate = function() {
    // One-To-One associations
    app.model.User.hasOne(app.model.UserInfo);

    // One-To-Many associations
    app.model.User.hasMany(app.model.Apply);

    // Many-To-Many associations
    app.model.User.belongsToMany(app.model.Group, { through: 'user_group' });
    app.model.User.belongsToMany(app.model.Role, { through: 'user_role' });
  };

  return User;
};

一对一

例如 user 和 userInfo 的关系就是一对一的关系,定义好了之后,我们在新建 user 的时候就可以使用 user.setUserInfo(userInfo)了,想获取此 user 的基础信息的时候也可以通过user.getUserInfo()

一对多

User 和 Apply(申请)的关系就是一对多,即一个用户可以对应多个自己的申请,目前只有好友申请和入群申请:

添加申请的时候可以user.addApply(apply),获取的时候可以这样获取:

const result = await ctx.model.Apply.findAndCountAll({
  where: {
    userId: ctx.session.user.id,
    hasHandled: false
  }
});

多对多

user 和 group 的关系就是多对多,即一个用户可以对应多个群组,一个群组也可以对应多个用户,这样 sequelize 会建立一个中间表 user_group 来实现这种关系。

一般我这么使用:

group.addUser(user); // 建立群组和用户的关系
user.getGroups(); // 获取用户的群组信息

需要注意的点

  1. sequelize 的所有操作都是基于 Promise 的,所有大多时候都使用 await 进行等待
  2. 修改了某个模型的实例的某个属性后,需要进行 save
  3. 当我们需要把模型的数据进行组合后返回给前端的时候,需要通过 get({plain: true})这种方式,转化成数据,然后再拼接,例如获取会话列表的时候

socketio

egg 提供了 egg-socket.io 插件,需要在安装 egg-socket.io 后在 config/plugin.js 开启插件,io 有自己的中间件和 controller

socketio 的路由

io 的路由和一般的 http 请求的不太一样,注意这里的路由不能添加中间件处理(我没成功),所以禁言处理我是在 controller 里面处理的

// 加入群
io.of('/').route('/v1/im/join', app.io.controller.im.join);
// 发送消息
io.of('/').route('/v1/im/new-message', app.io.controller.im.newMessage);
// 查询消息
io.of('/').route('/v1/im/get-messages', app.io.controller.im.getMessages);

注意:我把群组和好友关系都看做是一个 room(也就是一个会话),这样就是直接向这个 romm 里面发消息,里面的人都可以收到

socketio 的中间件

有两个默认的中间件,一个是连接和断开时候调用的 connection Middleware,这里用来校验登录状态和处理业务逻辑了;另外一个是每次发消息时候调用的 packet Middleware,这里用来打印 log

由于预设了禁言权限,在 controller 里面进行处理

// 对用户发言的权限进行判断
if (!ctx.session.user.rights.some(right => right.keyName === 'speak')) {
  return;
}

聊天

聊天分为单聊和群聊,聊天信息暂时有一般的文字、图片、视频和定位消息,可以根据业务扩展为订单或者商品等

消息

message 的结构设计参考了几家第三方服务的设计,也结合本项目自身的情况做了调整,可以随意扩展,做如下说明:

const Message = app.model.define('message', {
  /**
    * 消息类型:
    * 0:单聊
    * 1:群聊
    */
  type: {
    type: STRING
  },
  // 消息体
  body: {
    type: JSON
  },
  fromId: { type: INTEGER },
  toId: { type: INTEGER }
});

body 里面存放的是消息体,使用 json 用来存放不同的消息格式:

// 文本消息
{
  "type": "txt",
  "msg":"哈哈哈" //消息内容
}
// 图片消息
{
  "type": "img",
  "url": "http://nimtest.nos.netease.com/cbc500e8-e19c-4b0f-834b-c32d4dc1075e",
  "ext":"jpg",
  "w":360,    //宽
  "h":480,    //高
  "size": 388245
}
// 视频消息
{
  "type": 'video',
  "url": "http://nimtest.nos.netease.com/cbc500e8-e19c-4b0f-834b-c32d4dc1075e",
  "ext":"mp4",
  "w":360,    //宽
  "h":480,    //高
  "size": 388245
}
// 地理位置消息
{
  "type": "loc",
  "title":"中国 浙江省 杭州市 网商路 599号",    //地理位置title
  "lng":120.1908686708565,        // 经度
  "lat":30.18704515647036            // 纬度
}

定时任务

当前只有一个,就是更新 baidu 的 token,这里还算简单,参考官方文档即可

机器人聊天

智能对话定制与服务平台 UNIT

这个还是挺有意思的,可以在 https://ai.baidu.com/ 新建机器人和添加对应的技能,我这里是闲聊,还有智能问答等可以选择

  1. 新建机器人,管理机器人的技能,至少一个
  2. 前往百度云"应用列表"中创建、查看 API Key / Secret Key
  3. 在 config.default.js 中配置 baidu 相关参数,相关接口说明在这里

如果不想启动可以在 app.js 和 app/schedule/baidu.js 中删除 ctx.service.baidu.getToken();

上传文件

首先需要在配置文件里面进行配置,我这里限制了文件大小,饼跨站了 ios 的视频文件格式:

config.multipart = {
  mode: 'file',
  fileSize: '3mb',
  fileExtensions: ['.mov']
};

使用了一个统一的接口来处理文件上传,核心问题是文件的写入,files 是前端传来的文件列表

for (const file of ctx.request.files) {
  // 生成文件路径,注意upload文件路径需要存在
  const filePath = `./public/upload/${
    Date.now() + Math.floor(Math.random() * 100000).toString() + '.' + file.filename.split('.').pop()
  }`;
  const reader = fs.createReadStream(file.filepath); // 创建可读流
  const upStream = fs.createWriteStream(filePath); // 创建可写流
  reader.pipe(upStream); // 可读流通过管道写入可写流
  data.push({
    url: filePath.slice(1)
  });
}

我这里是存储到了 server 目录的/public/upload/,这个目录需要做一下静态文件的配置:

config.static = {
  prefix: '/public/',
  dir: path.join(appInfo.baseDir, 'public')
};

passport

这个章节的 egg 官方文档,要你的命,例子啥也没有,一定要去看源码,太坑人了,我研究了很久才弄明白是怎么回事。

因为我想更自由的控制账户密码登录,所以账号密码登录并没有使用 passport,使用的就是普通的接口认证配合 session。

下面详细说下使用第三方平台(我选用的是 GitHub)登录的过程:

  1. GitHub OAuth Apps新建你的应用,获取 key 和 secret
  2. 在项目安装 egg-passport 和 egg-passport-github

开启插件:

// config/plugin.js
module.exports.passport = {
  enable: true,
  package: 'egg-passport',
};

module.exports.passportGithub = {
  enable: true,
  package: 'egg-passport-github',
};
  1. 配置:
// config.default.js
config.passportGithub = {
  key: 'your_clientID',
  secret: 'your_clientSecret',
  callbackURL: 'http://localhost:3000/api/v1/passport/github/callback' // 注意这里非常的关键,这里需要和你在github上面设置的Authorization callback URL一致
};
  1. 在 app.js 中开启 passport
this.app.passport.verify(verify);
  1. 需要设置两个 passport 的 get 请求路由,第一个是我们在 login 页面点击的请求,第二个是我们在上一步设置的 callbackURL,这里主要是第三方平台会给我们一个可用的 code,然后根据 OAuth2 授权规则去获取用户的详细信息
const github = app.passport.authenticate('github', { successRedirect: '/' }); // successRedirect就是最后校验完毕后前端会跳转的路由,我这里直接跳转到主页了
router.get('/v1/passport/github', github);
router.get('/v1/passport/github/callback', github);
  1. 这时候在前端点击/v1/passport/github会发起 github 对这个应用的授权,成功后 github 会 302 到http://localhost:3000/v1/passport/github/callback?code=12313123123,我们的 githubPassport 插件会去获取用户在 github 上的信息,获取到详细信息后,我们需要在 app/passport/verify.js 去验证用户信息,并且和我们自身平台的用户信息做关联,也要给 session 赋值
// verify.js
module.exports = async (ctx, githubUser) => {
  const { service } = ctx;
  const { provider, name, photo, displayName } = githubUser;
  ctx.logger.info('githubUser', { provider, name, photo, displayName });

  let user = await ctx.model.User.findOne({
    where: {
      username: name
    }
  });

  if (!user) {
    user = await ctx.model.User.create({
      provider,
      username: name
    });
    const userInfo = await ctx.model.UserInfo.create({
      nickname: displayName,
      photo
    });
    const role = await ctx.model.Role.findOne({
      where: {
        keyName: 'user'
      }
    });
    user.setUserInfo(userInfo);
    user.addRole(role);
    await user.save();
  }
  const { rights, roles } = await service.user.getUserAttribute(user.id);

  // 权限判断
  if (!rights.some(item => item.keyName === 'login')) {
    ctx.body = {
      statusCode: '1',
      errorMessage: '不具备登录权限'
    };
    return;
  }

  ctx.session.user = {
    id: user.id,
    roles,
    rights
  };

  return githubUser;
};

注意看上面的代码,如果是首次授权将会创建这个用户,如果是第二次授权,那么用户已经被创建了

初始化

系统部署或者运行的时候,需要预设一些数据和表,代码在app.jsapp/service/startup.js

逻辑就是项目启动完毕后,利用 model 同步表结构到数据库中,然后开始新建一些基础数据:

  1. 新建角色和权限,并给角色分配权限
  2. 新建不同用户,分配角色
  3. 给一些用户建立好友关系
  4. 添加申请
  5. 创建群组,并添加一些人

做完以上这些就算是完成了初始数据了,可以进行正常的运转

部署

我是在腾讯云买的服务器 centos,在阿里云买的域名,装了 node(12.18.2) 、 nginx 和 mysql8.0,直接在 centos 上面启动,前端使用 nginx 进行反向代理。由于服务器资源有限,没有使用一些自动化工具 Jenkins 和 Docker,这就导致了我在更新的时候得有一些手动操作。

未完待续,下一篇讲解前端实现的技术难点

查看原文

赞 10 收藏 7 评论 0

hezhongfeng 发布了文章 · 2020-07-15

搭建完整的IM(即时通讯)应用(1)

介绍

即时通讯应用服务,整套包含服务端管理端客户端

预计3篇分享:这次是第一篇,项目的整体介绍和实体关系的梳理

现已部署上线,客户端管理端,欢迎体验

可以注册客户端账号,也可以使用初始默认账号,现有初始账号说明:

账号密码说明
admin123456管理端账号
user123456客户端普通用户账号
muteuser123456客户端被禁言用户账号
disabled123456客户端被封禁用户账号
member1123456客户端普通用户账号
member2123456客户端普通用户账号
...123456客户端普通用户账号
member30123456客户端普通用户账号

<img width="300" data-original="https://i.loli.net/2020/07/15/fO2naUmPluYRsBd.png">

功能简介

  1. 注册,登录,个人、群组聊天,个人信息编辑等基础功能
  2. 申请添加好友和申请入群
  3. 表情,图片,视频,定位信息支持
  4. 聊天会话列表记录
  5. 消息记录(微信的消息记录真实一言难尽)
  6. 支持多点同时登录
  7. 百度 UNIT 机器人自动回复(todo)
  8. 管理端,进行角色和权限的管理,群状态管理(我也当一回马化腾)

需求简介

移动互联网发展至今,以微信为首的即时通讯服务已经融入了我们生活中的各个角落,在公司的一些业务中也扮演着重要的角色,对于即时通讯我们公司原来是使用的环信的服务,但是有很多定制化的需求无法实现,所以后来决定内部开发一个满足定制化需求的即时通讯微服务。

使用socket.io框架是因为当时后端缺人,加上看了一些例子后觉得使用起来真的很方便,而且全平台支持,所以这个微服务就在前端团队进行落地实践,目前效果还不错。

社区目前这方面的内容比较少或者太简陋(只有一个公共的聊天室这种)。另外就是在业务开发过程中被 PM 搞得很难受,所以想脱离一些特有的业务上的东西,实现一个功能简单五脏俱全的不掺杂公司业务的 IM 应用,包含服务端,管理端和客户端。客户端的模仿对象是微信,因为我很熟悉,不用在产品上面思考太多,另外就是试用的人很熟悉,不需要太多的沟通成本。

框架简介

要开发一套完整的即时通讯服务,需要以下部分:

  1. 服务端:用来实现基础的服务接口和数据持久化
  2. 客户端:完成登录、聊天等基础功能,类似微信
  3. 管理端:管理群组、用户和角色权限

server

为企业级框架和应用而生

选用阿里的 egg.js 框架做支撑,看中的原因是他们内部大规模的落地和安全方面做得比较好,没有选择 nest 的原因是集成 socket.io 比较麻烦,ORM 选用 sequelize,数据库是 mysql ,之前一起使用过,上手难度小

admin

开箱即用的中台前端/设计解决方案

选择 Ant Design Pro 作为模板开发管理端,选用的原因是我对 Vue 全家桶比较熟悉,想借着这个机会熟悉下整套 React 生态 的开发流程,感受下目前国内两大开发框架的本质区别和殊途同归,Ant Design Pro 已经发布了好几年了,也的确给中小型企业带来效率的提升,也正好适合我这的需求。

client

🛠️ Vue.js 开发的标准工具

使用 @vue/cli 搭建 IM 服务的客户端,一个移动端的 H5 项目,UI 框架使用的有赞 vant,集成了我的开源组件vue-page-stack和黄老师的better-scroll,实现 IM 的基础功能

实体关系

作为一个前端工程师,大多数的日常工作是不需要思考实体关系的。但是,就我的实际体验来看,懂得实体关系可以帮助我们更好的理解业务模型。而对产品和业务理解的提升对我们的帮助是非常大的,可以在需求评审的时候发现很多不符合逻辑的地方(怎么又要吐槽产品经理了),这时候能提出来就会主动避免我们在后续的过程中进行反复开发,同时可以和产品侧的同学形成比较良好的互动(而不是互怼)。下面简单罗列下比较重要的实体关系:

<img width="600" data-original="https://i.loli.net/2020/07/14/Zhz85V2ptOylDcj.png">

通过上图可以看到 user 是整个关系图中的核心,下面介绍下各个实体之间的关系:

  1. user 和 user_info(用户信息) 是一对一的关系
  2. user 和 role(角色)是多对多的关系
  3. role 和 right(权限)是多对多的关系
  4. user 和 apply(申请)是多对多的关系,申请都是涉及到两个 user(申请人和被申请人)
  5. user 和 group(群组)是多对多的关系
  6. group 和 conversation(会话) 是一对一的关系
  7. friend 和 conversation(会话) 是一对一的关系
  8. conversation 和 message(消息)是 1 对多的关系
  9. friend(好友关系) 和 user 没有直接关系,friend 由两个 user 确定

下面详细介绍下会话、角色与权限:

会话

完成一个即时通讯应用,需要考虑的第一个事情就是会话,就是我们微信里面的对话窗口。思考会话和消息、用户、群组之间的关系花费了不少的精力,最终形成以下的基本关系:

  1. 2 个用户参与的聊天属于建立了 Friend 关系(互为好友)
  2. 多个用户参与的聊天组成了群组关系
  3. Friend 和会话之间的关系是 1 对 1 的关系,可以通过 Friend 找到此 Friend 的会话,也可以通过会话确定 Friend
  4. 群组和会话之间的关系是 1 对 1 的关系,可以通过群组找到此群组的会话,也可以通过会话确定群组
  5. 消息属于某个会话,可以根据会话查看对应的消息列表
  6. 保存消息的时候更新会话的激活时间,用户的会话列表根据激活时间排序,也就是最近的会话再最前面

也就是说,用户和会话没有直接的关系,只能通过用户对应的单聊和群聊去获取会话,这样做可以有以下的好处:

  1. 无论是单聊还是群聊,连接上的用户只要 join 进对应的会话 room 里面就可以,消息也是在对应的 room 里面发布
  2. 无论是单聊还是群聊,消息的保存和查询都比较简单,都是只针对这个会话
  3. 获取个人的会话列表也变得很简单,用户的会话列表通过查询用户『所有的 Friend 和群组』->『所有的会话』->『排序会话(根据激活时间)』,就可以获取

角色和权限

为了设计一个灵活、通用、方便的权限管理系统,本系统采用 RBAC(基于角色的访问控制)控制,来设计一个通用的『用户角色权限』平台,方便后期扩展。

RBAC

RBAC(基于角色的访问控制)是指用户通过角色与权限进行关联。即一个用户拥有若干角色,每一个角色拥有若干权限(当然了,别把冲突的角色和权限配在一起)。这样,就构造成“用户—角色—权限”的授权模型。在这种模型中,用户与角色之间、角色与权限之间,一般是多对多的关系。

本系统默认的角色和权限

本系统默认有管理员、一般用户、禁言用户和封禁用户这几种角色,给不同的角色分配不同的权限,所以需要针对管理和发言等接口路由做一下统一的鉴权(通过中间件的方式)处理,具体方式和方法在后端项目中会详细说明。本系统暂时采用预先定义了角色和权限的方式,后续想要扩展的话可以编辑角色和权限。

管理员

没见过微信的管理端,但是可以想象一下,管理员可以配置用户的角色和权限,可以编辑群组的状态:

  1. 登录的权限
  2. 群组状态的编辑
  3. 针对用户的角色和权限的编辑

普通用户

注册登录后,可以正常的添加好友和加入群组,可以修改个人基础信息和处理申请

  1. 注册登录
  2. 编辑个人基础信息
  3. 添加好友,申请入群
  4. 处理好友申请和入群申请
  5. 聊天

禁言用户

  1. 注册登录
  2. 编辑个人基础信息
  3. 添加好友,申请入群
  4. 处理好友申请和入群申请

封禁用户

无法登录

角色的组合

举个例子:现在有一个新版的个人中心需要上线测试,首先新建一个角色『测试个人中心』,再给这个角色分配对应的权限;然后给普通用户做个分组,选出一些人配置上这个角色,这样就可以进行测试了。

即时通讯原理

下面说下即时通讯服务的核心通讯原理,和一般的 http 服务一样,有一个服务端和客户端进行通讯,只不过详细的协议和处理方式不一样。

WebSocket

由于历史原因,现在主流的 http 协议是无状态协议(HTTP2 暂时应用不广泛),一般情况是由客户端主动发起请求,然后服务端去响应。那么为了实现服务端向客户端推送信息,就需要前端主动向后端去轮询,这种方式低效且容易出错,在之前我们的管理端首页确实是这么做的(5s 一次)。

为了实现这种服务端主动推送信息的需求, HTML5 开始提供一种在单个 TCP 连接上进行全双工通讯的协议,也就是 WebSocket。WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。WebSocket 协议在 2008 年诞生,2011 年成为国际标准,目前绝大部分浏览器都已经支持了。

WebSocket 的用法相当简单:

var ws = new WebSocket("wss://echo.websocket.org");

ws.onopen = function(evt) {
  console.log("Connection open ...");
  ws.send("Hello WebSockets!");
};

ws.onmessage = function(evt) {
  console.log( "Received Message: " + evt.data);
  ws.close();
};

ws.onclose = function(evt) {
  console.log("Connection closed.");
};

有了 WebSocket 协议让服务端主动推送信息有了先进的武器,那么有没有什么方式可以兼容新旧浏览器呢?其实很多人想到了这点,答案就是socket.io

socket.io

socket.io进一步封装了WebSocket的接口,而且可以在旧版本浏览器中自主切换到使用轮询的方式进行通讯(我们使用者是不会感知的),形成了一套统一的接口,大大减轻了开发的负担。主要具有以下优点:

  1. 封装出了一套非常易用的接口,前后端统一,使用非常简单
  2. 全平台支持(原生和 H5,微信小程序中也有对应的实现)
  3. 自适应浏览器,在比较老的浏览器中主动切换使用轮询的方式,不需要我们自己搞轮询

这是 socket.io 主页

最快,最可靠的即时通讯引擎(FEATURING THE FASTEST AND MOST RELIABLE REAL-TIME ENGINE)

使用起来真的很简单:

var io = require('socket.io')(80);
var cfg = require('./config.json');
var tw = require('node-tweet-stream')(cfg);
tw.track('socket.io');
tw.track('javascript');
tw.on('tweet', function(tweet){
  io.emit('tweet', tweet);
});

总结

有了以上的基础,我们就基本完成了开始写代码之前的准备:明确了这个应用的基础功能和实体之间的关系,也明确了基础的技术方案选型,划分了3个项目的各自任务。下面就开始完成 server 端吧

未完待续:下一篇介绍 server 端

查看原文

赞 11 收藏 6 评论 0

hezhongfeng 赞了文章 · 2020-06-04

为什么0.1+0.2不等于0.3

原文地址:为什么0.1+0.2不等于0.3

先看两个简单但诡异的代码:

0.1 + 0.2 > 0.3 // true
0.1 * 0.1 = 0.010000000000000002

0.1加0.2为什么就不等于0.3昵?要回答这个问题,得先了解计算机内部是如何表示数的。

计算机内部如何表示数

我们都知道,计算机用位来储存及处理数据。每一个二进制数(二进制串)都一一对应一个十进制数。

1. 计算机内部如何表示整数

这里以十进制数13来展示“按位计数法”如何表示整数:

十进制值进制按位格式描述
1310131x10^1 + 3x10^0 = 10 + 3
13211011x2^3 + 1x2^2 + 0x2^1 + 1x2^0 = 8 + 4 + 0 + 1
2. 计算机内部如何表示小数

再看小数怎么用按位计数法表示,以十进制数0.625为例:

十进制值进制按位格式描述
0.625100.6256x10^-1 + 2x10^-2 + 5x10^-3 = 0.6 + 0.02 + 0.005
0.62520.1011x2^-1 + 0 x2^-2 + 1x2^-3 = 1/2 + 0 + 1/8
3. 如何用二进制表示0.1

关于十进制与二进制间如何转换,这里不细说,直接给出结论:

十进制整数转二进制方法:除2取余;十进制小数转二进制方法:乘2除整

十进制0.1转换成二进制,乘2取整过程:

0.1 * 2 = 0.2 # 0
0.2 * 2 = 0.4 # 0
0.4 * 2 = 0.8 # 0
0.8 * 2 = 1.6 # 1
0.6 * 2 = 1.2 # 1
0.2 * 2 = 0.4 # 0

.....

从上面可以看出,0.1的二进制格式是:0.0001100011....。这是一个二进制无限循环小数,但计算机内存有限,我们不能用储存所有的小数位数。那么在精度与内存间如何取舍呢?

答案是:在某个精度点直接舍弃。当然,代价就是,0.1在计算机内部根本就不是精确的0.1,而是一个有舍入误差的0.1。当代码被编译或解释后,0.1已经被四舍五入成一个与之很接近的计算机内部数字,以至于计算还没开始,一个很小的舍入错误就已经产生了。这也就是 0.1 + 0.2 不等于0.3 的原因。

有误差的两个数,其计算的结果,当然就很可能与我们期望的不一样了。注意前面的这句话中的“很可能”这三个字?为啥是很可能昵?

0.1 + 0.1 为什么等于0.2

答案是:两个有舍入误差的值在求和时,相互抵消了,但这种“负负得正,相互抵消”不一定是可靠的,当这两个数字是用不同长度数位来表示的浮点数时,舍入误差可能不会相互抵消。

又如,对于 0.1 + 0.3 ,结果其实并不是0.4,但0.4是最接近真实结果的数,比其它任何浮点数都更接近。许多语言也就直接显示结果为0.4了,而不展示一个浮点数的真实结果了。

另外要注意,二进制能精确地表示位数有限且分母是2的倍数的小数,比如0.5,0.5在计算机内部就没有舍入误差。所以0.5 + 0.5 === 1

计算机这样胡乱舍入,能满足所有的计算需求吗

我们看两个现实的场景:

  • 对于一个修建铁路的工程师而言,10米宽,还是10.0001米宽并没有什么不同。铁路工程师就不需要这么高0.x这样的精度
  • 对于芯片设计师,0.0001米就会是一个巨大不同,他也永远不用处理超过0.1米距离

不同行业,要求的精度不是线性的,我们允许(对结果无关紧要的)误差存在。10.0001与10.001在铁路工程师看来都是合格的。

虽然允许误差存在,但程序员在使用浮点数进行计算或逻辑处理时,不注意,就可能出问题。记住,永远不要直接比较两个浮点的大小

var a = 0.1
var b = 0.2

if (a + b === 0.3) {
  // doSomething
}

JS中如何进入浮点数运算

将浮点运算转换成整数计算

整数是完全精度的,不存在舍入误差。例如,一些关于人民币的运算,都会以分为基本单位,计算采用分,展示再转换成元。当然,这样也有一些问题,会带来额外的工作量,如果那天人民币新增了一个货币单位,对系统的扩展性也会有考验。

使用bignumber进行运算

bignumber.js会在一定精度内,让浮点数计算结果符合我们的期望。

{
  let x = new BigNumber(0.1);
  let y = new BigNumber(0.2)
  let z = new BigNumber(0.3)

  console.log(z.equals(x.add(y))) // 0.3 === 0.1 + 0.2, true
  console.log(z.minus(x).equals(y)) // true
  console.log(z.minus(y).equals(x)) // true
}
{
  let x = 0.2
  console.log(x * x === 0.04) // false
  let y = new BigNumber(0.2)
  let r = y.mul(y) // 0.04
  console.log(r.equals(new BigNumber(0.04))) // true
}

更多例子,可以看bignumber.js官方示例。

小结

本文主要介绍了浮点数计算问题,简单回答了为什么以及怎么办两个问题:

  • 为什么0.1 + 0.2 不等于0.3。因为计算机不能精确表示0.1, 0.2这样的浮点数,计算时使用的是带有舍入误差的数
  • 并不是所有的浮点数在计算机内部都存在舍入误差,比如0.5就没有舍入误差
  • 具有舍入误差的运算结可能会符合我们的期望,原因可能是“负负得正”
  • 怎么办?1个办法是使用整型代替浮点数计算;2是不要直接比较两个浮点数,而应该使用bignumber.js这样的浮点数运算库

最后,本文只是简单回答了为什么,如果读者对更根本深入的原理感兴趣,可以自行google之。限于水平有限,本文如果有错误,欢迎指正。

查看原文

赞 62 收藏 61 评论 17

hezhongfeng 赞了文章 · 2020-04-28

preload、prefetch的认识

预加载

现在的网络情况虽然很乐观,但是

defer和async

当浏览器碰到 script 脚本的时候:

<script data-original="script.js"></script>

没有 defer 或 async,浏览器会立即加载并执行指定的脚本,“立即”指的是在渲染该 script 标签之下的文档元素之前,也就是说不等待后续载入的文档元素,读到就加载并执行。

<script async data-original="script.js"></script>

有 async,加载和渲染后续文档元素的过程将和 script.js 的加载与执行并行进行(异步)。

<script defer data-original="myscript.js"></script>

有 defer,加载后续文档元素的过程将和 script.js 的加载并行进行(异步),但是 script.js 的执行要在所有元素解析完成之后,DOMContentLoaded 事件触发之前完成。

然后从实用角度来说呢,首先把所有脚本都丢到 </body> 之前是最佳实践,因为对于旧浏览器来说这是唯一的优化选择,此法可保证非脚本的其他一切元素能够以最快的速度得到加载和解析。

接着,我们来看一张图咯:

clipboard.png

此图告诉我们以下几个要点:

  1. defer 和 async 在网络读取(下载)这块儿是一样的,都是异步的(相较于 HTML 解析)
  2. 它俩的差别在于脚本下载完之后何时执行,显然 defer 是最接近我们对于应用脚本加载和执行的要求的
  3. 关于 defer,此图未尽之处在于它是按照加载顺序执行脚本的,这一点要善加利用
  4. async 则是一个乱序执行的主,反正对它来说脚本的加载和执行是紧紧挨着的,所以不管你声明的顺序如何,只要它加载完了就会立刻执行
  5. 仔细想想,async 对于应用脚本的用处不大,因为它完全不考虑依赖(哪怕是最低级的顺序执行),不过它对于那些可以不依赖任何脚本或不被任何脚本依赖的脚本来说却是非常合适的,

preload和refetch

preload通常在页面中,我们需要加载一些脚本和样式,而使用 preload 可以对当前页面所需的脚本、样式等资源进行预加载,而无需等到解析到 script 和 link 标签时才进行加载。这一机制使得资源可以更早的得到加载并可用,且更不易阻塞页面的初步渲染,进而提升性能。

使用方式
将 link 标签的 rel 属性的值设为 preload,as 属性的值为资源类型(如脚本为 script,样式表为 style)

<head>
  <meta charset="utf-8">
  <title>preload example</title>
  <!-- 对 style.css 和 index.js 进行预加载 -->
  <link rel="preload" href="style.css" as="style">
  <link rel="preload" href="index.js" as="script">

  <link rel="stylesheet" href="style.css">
</head>

<body>
  <div id="app"></div>

  <script data-original="index.js"></script>
</body>

prefetchpreload 一样,都是对资源进行预加载,但是 prefetch 加载的资源一般不是用于当前页面的,即未来很可能用到的这样一些资源,简单点说就是其他页面会用到的资源。当然,prefetch 不会像 preload 一样,在页面渲染的时候加载资源,而是利用浏览器空闲时间来下载。当进入下一页面,就可直接从 disk cache 里面取,既不影响当前页面的渲染,又提高了其他页面加载渲染的速度。

使用方式
preload 很相似,无需指定 as 属性:

<head>
  <meta charset="utf-8">
  <title>preload example</title>
  <!-- 对 style.css 和 index.js 进行 preload 预加载 -->
  <link rel="preload" href="style.css" as="style">
  <link rel="preload" href="index.js" as="script">

  <!-- 对资源进行 prefetch 预加载 -->
  <link rel="prefetch" href="next.css">
  <link rel="prefetch" href="next.js">

  <link rel="stylesheet" href="style.css">
</head>

<body>
  <div id="app"></div>

  <script data-original="index.js"></script>
</body>

总结:对当前页面需要的资源,使用 preload 进行预加载,对其它页面需要的资源进行 prefetch 预加载。

Subresource和Prerender

subresource可以用来指定资源是最高优先级的。比如,在Chrome和Opera中我们可以加上下面的代码:

<link rel="subresource" href="styles.css">

Chromium的文档这么解释:
和 "Link rel=prefetch"的语义不同,"Link rel=subresource"是一种新的连接关系。rel=prefetch指定了下载后续页面用到资源的低优先级,而rel=subresource则是指定当前页面资源的提前加载。

所以,如果资源是在当前页面需要,或者马上就会用到,则推荐用subresource,否则还是用prefetch。

prerender是一个重量级的选项,它可以让浏览器提前加载指定页面的所有资源。

<link rel="prerender" href="/thenextpage.html" />

Steve Souders的文章详细解释了这个技术:
prerender就像是在后台打开了一个隐藏的tab,会下载所有的资源、创建DOM、渲染页面、执行JS等等。如果用户进入指定的链接,隐藏的这个页面就会进入马上进入用户的视线。Google Search多年前就利用了这个特性实现了Instant Pages功能。微软最近也宣布会让Bing在IE11上用类似prerender的技术。

但是要注意,一定要在十分确定用户回点某个链接时才用这个特性,否则客户端就会无端的下载很多资源和渲染这个页面。
正如任何提前的动作一样,预判总是有一定风险出错。如果提前的动作是昂贵的(比如高CPU、耗电、占用带宽),就要谨慎使用了。虽然不容易预判用户会点进哪个页面,但还是存在一些典型的场景:

如果用户搜索到了一个明显正确的结果时,那么这个页面就很有可能被点入
如果用户在登录页面,那么登录成功后的页面就很可能接下来会被加载了
如果用户在阅读一个多页面的文章或者有页码的内容时,下一页就很可能会马上被点击了
利用Page Visibility API可以用来防止页面在还没真正展示给用户时就触发了JS的执行。

参考:
defer和async
prefetch与 preload
prefetch预加载
preload当即加载
加载技术概述
dnc fetch

Prerender Subresource

查看原文

赞 16 收藏 12 评论 1

hezhongfeng 赞了文章 · 2020-04-28

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

前言

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

----------超长文+多图预警,需要花费不少时间。----------

如果看完本文后,还对进程线程傻傻分不清,不清楚浏览器多进程、浏览器内核多线程、JS单线程、JS运行机制的区别。那么请回复我,一定是我写的还不够清晰,我来改。。。

----------正文开始----------

最近发现有不少介绍JS单线程运行机制的文章,但是发现很多都仅仅是介绍某一部分的知识,而且各个地方的说法还不统一,容易造成困惑。
因此准备梳理这块知识点,结合已有的认知,基于网上的大量参考资料,
从浏览器多进程到JS单线程,将JS引擎的运行机制系统的梳理一遍。

展现形式:由于是属于系统梳理型,就没有由浅入深了,而是从头到尾的梳理知识体系,
重点是将关键节点的知识点串联起来,而不是仅仅剖析某一部分知识。

内容是:从浏览器进程,再到浏览器内核运行,再到JS引擎单线程,再到JS事件循环机制,从头到尾系统的梳理一遍,摆脱碎片化,形成一个知识体系

目标是:看完这篇文章后,对浏览器多进程,JS单线程,JS事件循环机制这些都能有一定理解,
有一个知识体系骨架,而不是似懂非懂的感觉。

另外,本文适合有一定经验的前端人员,新手请规避,避免受到过多的概念冲击。可以先存起来,有了一定理解后再看,也可以分成多批次观看,避免过度疲劳。

大纲

  • 区分进程和线程
  • 浏览器是多进程的

    • 浏览器都包含哪些进程?
    • 浏览器多进程的优势
    • 重点是浏览器内核(渲染进程)
    • Browser进程和浏览器内核(Renderer进程)的通信过程
  • 梳理浏览器内核中线程之间的关系

    • GUI渲染线程与JS引擎线程互斥
    • JS阻塞页面加载
    • WebWorker,JS的多线程?
    • WebWorker与SharedWorker
  • 简单梳理下浏览器渲染流程

    • load事件与DOMContentLoaded事件的先后
    • css加载是否会阻塞dom树渲染?
    • 普通图层和复合图层
  • 从Event Loop谈JS的运行机制

    • 事件循环机制进一步补充
    • 单独说说定时器
    • setTimeout而不是setInterval
  • 事件循环进阶:macrotask与microtask
  • 写在最后的话

区分进程和线程

线程和进程区分不清,是很多新手都会犯的错误,没有关系。这很正常。先看看下面这个形象的比喻:

- 进程是一个工厂,工厂有它的独立资源

- 工厂之间相互独立

- 线程是工厂中的工人,多个工人协作完成任务

- 工厂内有一个或多个工人

- 工人之间共享空间

再完善完善概念:

- 工厂的资源 -> 系统分配的内存(独立的一块内存)

- 工厂之间的相互独立 -> 进程之间相互独立

- 多个工人协作完成任务 -> 多个线程在进程中协作完成任务

- 工厂内有一个或多个工人 -> 一个进程由一个或多个线程组成

- 工人之间共享空间 -> 同一进程下的各个线程之间共享程序的内存空间(包括代码段、数据集、堆等)

然后再巩固下:

如果是windows电脑中,可以打开任务管理器,可以看到有一个后台进程列表。对,那里就是查看进程的地方,而且可以看到每个进程的内存资源信息以及cpu占有率。

所以,应该更容易理解了:进程是cpu资源分配的最小单位(系统会给它分配内存)

最后,再用较为官方的术语描述一遍:

  • 进程是cpu资源分配的最小单位(是能拥有资源和独立运行的最小单位)
  • 线程是cpu调度的最小单位(线程是建立在进程的基础上的一次程序运行单位,一个进程中可以有多个线程)

tips

  • 不同进程之间也可以通信,不过代价较大
  • 现在,一般通用的叫法:单线程与多线程,都是指在一个进程内的单和多。(所以核心还是得属于一个进程才行)

浏览器是多进程的

理解了进程与线程了区别后,接下来对浏览器进行一定程度上的认识:(先看下简化理解)

  • 浏览器是多进程的
  • 浏览器之所以能够运行,是因为系统给它的进程分配了资源(cpu、内存)
  • 简单点理解,每打开一个Tab页,就相当于创建了一个独立的浏览器进程。

关于以上几点的验证,请再第一张图

图中打开了Chrome浏览器的多个标签页,然后可以在Chrome的任务管理器中看到有多个进程(分别是每一个Tab页面有一个独立的进程,以及一个主进程)。
感兴趣的可以自行尝试下,如果再多打开一个Tab页,进程正常会+1以上

注意:在这里浏览器应该也有自己的优化机制,有时候打开多个tab页后,可以在Chrome任务管理器中看到,有些进程被合并了
(所以每一个Tab标签对应一个进程并不一定是绝对的)

浏览器都包含哪些进程?

知道了浏览器是多进程后,再来看看它到底包含哪些进程:(为了简化理解,仅列举主要进程)

  1. Browser进程:浏览器的主进程(负责协调、主控),只有一个。作用有

    • 负责浏览器界面显示,与用户交互。如前进,后退等
    • 负责各个页面的管理,创建和销毁其他进程
    • 将Renderer进程得到的内存中的Bitmap,绘制到用户界面上
    • 网络资源的管理,下载等
  2. 第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建
  3. GPU进程:最多一个,用于3D绘制等
  4. 浏览器渲染进程(浏览器内核)(Renderer进程,内部是多线程的):默认每个Tab页面一个进程,互不影响。主要作用为

    • 页面渲染,脚本执行,事件处理等

强化记忆:在浏览器中打开一个网页相当于新起了一个进程(进程内有自己的多线程)

当然,浏览器有时会将多个进程合并(譬如打开多个空白标签页后,会发现多个空白标签页被合并成了一个进程),如图

另外,可以通过Chrome的更多工具 -> 任务管理器自行验证

浏览器多进程的优势

相比于单进程浏览器,多进程有如下优点:

  • 避免单个page crash影响整个浏览器
  • 避免第三方插件crash影响整个浏览器
  • 多进程充分利用多核优势
  • 方便使用沙盒模型隔离插件等进程,提高浏览器稳定性

简单点理解:如果浏览器是单进程,那么某个Tab页崩溃了,就影响了整个浏览器,体验有多差;同理如果是单进程,插件崩溃了也会影响整个浏览器;而且多进程还有其它的诸多优势。。。

当然,内存等资源消耗也会更大,有点空间换时间的意思。

重点是浏览器内核(渲染进程)

重点来了,我们可以看到,上面提到了这么多的进程,那么,对于普通的前端操作来说,最终要的是什么呢?答案是渲染进程

可以这样理解,页面的渲染,JS的执行,事件的循环,都在这个进程内进行。接下来重点分析这个进程

请牢记,浏览器的渲染进程是多线程的(这点如果不理解,请回头看进程和线程的区分

终于到了线程这个概念了?,好亲切。那么接下来看看它都包含了哪些线程(列举一些主要常驻线程):

  1. GUI渲染线程

    • 负责渲染浏览器界面,解析HTML,CSS,构建DOM树和RenderObject树,布局和绘制等。
    • 当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行
    • 注意,GUI渲染线程与JS引擎线程是互斥的,当JS引擎执行时GUI线程会被挂起(相当于被冻结了),GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。
  2. JS引擎线程

    • 也称为JS内核,负责处理Javascript脚本程序。(例如V8引擎)
    • JS引擎线程负责解析Javascript脚本,运行代码。
    • JS引擎一直等待着任务队列中任务的到来,然后加以处理,一个Tab页(renderer进程)中无论什么时候都只有一个JS线程在运行JS程序
    • 同样注意,GUI渲染线程与JS引擎线程是互斥的,所以如果JS执行的时间过长,这样就会造成页面的渲染不连贯,导致页面渲染加载阻塞。
  3. 事件触发线程

    • 归属于浏览器而不是JS引擎,用来控制事件循环(可以理解,JS引擎自己都忙不过来,需要浏览器另开线程协助)
    • 当JS引擎执行代码块如setTimeOut时(也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等),会将对应任务添加到事件线程中
    • 当对应的事件符合触发条件被触发时,该线程会把事件添加到待处理队列的队尾,等待JS引擎的处理
    • 注意,由于JS的单线程关系,所以这些待处理队列中的事件都得排队等待JS引擎处理(当JS引擎空闲时才会去执行)

  4. 定时触发器线程

    • 传说中的setIntervalsetTimeout所在线程
    • 浏览器定时计数器并不是由JavaScript引擎计数的,(因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确)
    • 因此通过单独线程来计时并触发定时(计时完毕后,添加到事件队列中,等待JS引擎空闲后执行)
    • 注意,W3C在HTML标准中规定,规定要求setTimeout中低于4ms的时间间隔算为4ms。
  5. 异步http请求线程

    • 在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
    • 将检测到状态变更时,如果设置有回调函数,异步线程就产生状态变更事件,将这个回调再放入事件队列中。再由JavaScript引擎执行。

看到这里,如果觉得累了,可以先休息下,这些概念需要被消化,毕竟后续将提到的事件循环机制就是基于事件触发线程的,所以如果仅仅是看某个碎片化知识,
可能会有一种似懂非懂的感觉。要完成的梳理一遍才能快速沉淀,不易遗忘。放张图巩固下吧:

再说一点,为什么JS引擎是单线程的?额,这个问题其实应该没有标准答案,譬如,可能仅仅是因为由于多线程的复杂性,譬如多线程操作一般要加锁,因此最初设计时选择了单线程。。。

Browser进程和浏览器内核(Renderer进程)的通信过程

看到这里,首先,应该对浏览器内的进程和线程都有一定理解了,那么接下来,再谈谈浏览器的Browser进程(控制进程)是如何和内核通信的,
这点也理解后,就可以将这部分的知识串联起来,从头到尾有一个完整的概念。

如果自己打开任务管理器,然后打开一个浏览器,就可以看到:任务管理器中出现了两个进程(一个是主控进程,一个则是打开Tab页的渲染进程)
然后在这前提下,看下整个的过程:(简化了很多)

  • Browser进程收到用户请求,首先需要获取页面内容(譬如通过网络下载资源),随后将该任务通过RendererHost接口传递给Render进程
  • Renderer进程的Renderer接口收到消息,简单解释后,交给渲染线程,然后开始渲染

    • 渲染线程接收请求,加载网页并渲染网页,这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染
    • 当然可能会有JS线程操作DOM(这样可能会造成回流并重绘)
    • 最后Render进程将结果传递给Browser进程
  • Browser进程接收到结果并将结果绘制出来

这里绘一张简单的图:(很简化)

看完这一整套流程,应该对浏览器的运作有了一定理解了,这样有了知识架构的基础后,后续就方便往上填充内容。

这块再往深处讲的话就涉及到浏览器内核源码解析了,不属于本文范围。

如果这一块要深挖,建议去读一些浏览器内核源码解析文章,或者可以先看看参考下来源中的第一篇文章,写的不错

梳理浏览器内核中线程之间的关系

到了这里,已经对浏览器的运行有了一个整体的概念,接下来,先简单梳理一些概念

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的,如果在修改这些元素属性同时渲染界面(即JS线程和UI线程同时运行),那么渲染线程前后获得的元素数据就可能不一致了。

因此为了防止渲染出现不可预期的结果,浏览器设置GUI渲染线程与JS引擎为互斥的关系,当JS引擎执行时GUI线程会被挂起,
GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系,可以推导出,JS如果执行时间过长就会阻塞页面。

譬如,假设JS引擎正在进行巨量的计算,此时就算GUI有更新,也会被保存到队列中,等待JS引擎空闲后执行。
然后,由于巨量计算,所以JS引擎很可能很久很久后才能空闲,自然会感觉到巨卡无比。

所以,要尽量避免JS执行时间过长,这样就会造成页面的渲染不连贯,导致页面渲染加载阻塞的感觉。

WebWorker,JS的多线程?

前文中有提到JS引擎是单线程的,而且JS执行时间过长会阻塞页面,那么JS就真的对cpu密集型计算无能为力么?

所以,后来HTML5中支持了Web Worker

MDN的官方解释是:

Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面

一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 

这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window

因此,使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误

这样理解下:

  • 创建Worker时,JS引擎向浏览器申请开一个子线程(子线程是浏览器开的,完全受主线程控制,而且不能操作DOM)
  • JS引擎线程与worker线程间通过特定的方式通信(postMessage API,需要通过序列化对象来与线程交互特定的数据)

所以,如果有非常耗时的工作,请单独开一个Worker线程,这样里面不管如何翻天覆地都不会影响JS引擎主线程,
只待计算出结果后,将结果通信给主线程即可,perfect!

而且注意下,JS引擎是单线程的,这一点的本质仍然未改变,Worker可以理解是浏览器给JS引擎开的外挂,专门用来解决那些大量计算问题。

其它,关于Worker的详解就不是本文的范畴了,因此不再赘述。

WebWorker与SharedWorker

既然都到了这里,就再提一下SharedWorker(避免后续将这两个概念搞混)

  • WebWorker只属于某个页面,不会和其他页面的Render进程(浏览器内核进程)共享

    • 所以Chrome在Render进程中(每一个Tab页就是一个render进程)创建一个新的线程来运行Worker中的JavaScript程序。
  • SharedWorker是浏览器所有页面共享的,不能采用与Worker同样的方式实现,因为它不隶属于某个Render进程,可以为多个Render进程共享使用

    • 所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序,在浏览器中每个相同的JavaScript只存在一个SharedWorker进程,不管它被创建多少次。

看到这里,应该就很容易明白了,本质上就是进程和线程的区别。SharedWorker由独立的进程管理,WebWorker只是属于render进程下的一个线程

简单梳理下浏览器渲染流程

本来是直接计划开始谈JS运行机制的,但想了想,既然上述都一直在谈浏览器,直接跳到JS可能再突兀,因此,中间再补充下浏览器的渲染流程(简单版本)

为了简化理解,前期工作直接省略成:(要展开的或完全可以写另一篇超长文)

- 浏览器输入url,浏览器主进程接管,开一个下载线程,
然后进行 http请求(略去DNS查询,IP寻址等等操作),然后等待响应,获取内容,
随后将内容通过RendererHost接口转交给Renderer进程

- 浏览器渲染流程开始

浏览器器内核拿到内容后,渲染大概可以划分成以下几个步骤:

  1. 解析html建立dom树
  2. 解析css构建render树(将CSS代码解析成树形的数据结构,然后结合DOM合并成render树)
  3. 布局render树(Layout/reflow),负责各元素尺寸、位置的计算
  4. 绘制render树(paint),绘制页面像素信息
  5. 浏览器会将各层的信息发送给GPU,GPU会将各层合成(composite),显示在屏幕上。

所有详细步骤都已经略去,渲染完毕后就是load事件了,之后就是自己的JS逻辑处理了

既然略去了一些详细的步骤,那么就提一些可能需要注意的细节把。

这里重绘参考来源中的一张图:(参考来源第一篇)

load事件与DOMContentLoaded事件的先后

上面提到,渲染完毕后会触发load事件,那么你能分清楚load事件与DOMContentLoaded事件的先后么?

很简单,知道它们的定义就可以了:

  • 当 DOMContentLoaded 事件触发时,仅当DOM加载完成,不包括样式表,图片。

(譬如如果有async加载的脚本就不一定完成)

  • 当 onload 事件触发时,页面上所有的DOM,样式表,脚本,图片都已经加载完成了。

(渲染完毕了)

所以,顺序是:DOMContentLoaded -> load

css加载是否会阻塞dom树渲染?

这里说的是头部引入css的情况

首先,我们都知道:css是由单独的下载线程异步下载的。

然后再说下几个现象:

  • css加载不会阻塞DOM树解析(异步加载时DOM照常构建)
  • 但会阻塞render树渲染(渲染时需等css加载完毕,因为render树需要css信息)

这可能也是浏览器的一种优化机制。

因为你加载css的时候,可能会修改下面DOM节点的样式,
如果css加载不阻塞render树渲染的话,那么当css加载完之后,
render树可能又得重新重绘或者回流了,这就造成了一些没有必要的损耗。
所以干脆就先把DOM树的结构先解析完,把可以做的工作做完,然后等你css加载完之后,
在根据最终的样式来渲染render树,这种做法性能方面确实会比较好一点。

普通图层和复合图层

渲染步骤中就提到了composite概念。

可以简单的这样理解,浏览器渲染的图层一般包含两大类:普通图层以及复合图层

首先,普通文档流内可以理解为一个复合图层(这里称为默认复合层,里面不管添加多少元素,其实都是在同一个复合图层中)

其次,absolute布局(fixed也一样),虽然可以脱离普通文档流,但它仍然属于默认复合层

然后,可以通过硬件加速的方式,声明一个新的复合图层,它会单独分配资源
(当然也会脱离普通文档流,这样一来,不管这个复合图层中怎么变化,也不会影响默认复合层里的回流重绘)

可以简单理解下:GPU中,各个复合图层是单独绘制的,所以互不影响,这也是为什么某些场景硬件加速效果一级棒

可以Chrome源码调试 -> More Tools -> Rendering -> Layer borders中看到,黄色的就是复合图层信息

如下图。可以验证上述的说法

如何变成复合图层(硬件加速)

将该元素变成一个复合图层,就是传说中的硬件加速技术

  • 最常用的方式:translate3dtranslateZ
  • opacity属性/过渡动画(需要动画执行的过程中才会创建合成层,动画没有开始或结束后元素还会回到之前的状态)
  • will-chang属性(这个比较偏僻),一般配合opacity与translate使用(而且经测试,除了上述可以引发硬件加速的属性外,其它属性并不会变成复合层),

作用是提前告诉浏览器要变化,这样浏览器会开始做一些优化工作(这个最好用完后就释放)

  • <video><iframe><canvas><webgl>等元素
  • 其它,譬如以前的flash插件

absolute和硬件加速的区别

可以看到,absolute虽然可以脱离普通文档流,但是无法脱离默认复合层。
所以,就算absolute中信息改变时不会改变普通文档流中render树,
但是,浏览器最终绘制时,是整个复合层绘制的,所以absolute中信息的改变,仍然会影响整个复合层的绘制。
(浏览器会重绘它,如果复合层中内容多,absolute带来的绘制信息变化过大,资源消耗是非常严重的)

而硬件加速直接就是在另一个复合层了(另起炉灶),所以它的信息改变不会影响默认复合层
(当然了,内部肯定会影响属于自己的复合层),仅仅是引发最后的合成(输出视图)

复合图层的作用?

一般一个元素开启硬件加速后会变成复合图层,可以独立于普通文档流中,改动后可以避免整个页面重绘,提升性能

但是尽量不要大量使用复合图层,否则由于资源消耗过度,页面反而会变的更卡

硬件加速时请使用index

使用硬件加速时,尽可能的使用index,防止浏览器默认给后续的元素创建复合层渲染

具体的原理时这样的:
**webkit CSS3中,如果这个元素添加了硬件加速,并且index层级比较低,
那么在这个元素的后面其它元素(层级比这个元素高的,或者相同的,并且releative或absolute属性相同的),
会默认变为复合层渲染,如果处理不当会极大的影响性能**

简单点理解,其实可以认为是一个隐式合成的概念:如果a是一个复合图层,而且b在a上面,那么b也会被隐式转为一个复合图层,这点需要特别注意

另外,这个问题可以在这个地址看到重现(原作者分析的挺到位的,直接上链接):

http://web.jobbole.com/83575/

从Event Loop谈JS的运行机制

到此时,已经是属于浏览器页面初次渲染完毕后的事情,JS引擎的一些运行机制分析。

注意,这里不谈可执行上下文VOscop chain等概念(这些完全可以整理成另一篇文章了),这里主要是结合Event Loop来谈JS代码是如何执行的。

读这部分的前提是已经知道了JS引擎是单线程,而且这里会用到上文中的几个概念:(如果不是很理解,可以回头温习)

  • JS引擎线程
  • 事件触发线程
  • 定时触发器线程

然后再理解一个概念:

  • JS分为同步任务和异步任务
  • 同步任务都在主线程上执行,形成一个执行栈
  • 主线程之外,事件触发线程管理着一个任务队列,只要异步任务有了运行结果,就在任务队列之中放置一个事件。
  • 一旦执行栈中的所有同步任务执行完毕(此时JS引擎空闲),系统就会读取任务队列,将可运行的异步任务添加到可执行栈中,开始执行。

看图:

看到这里,应该就可以理解了:为什么有时候setTimeout推入的事件不能准时执行?因为可能在它推入到事件列表时,主线程还不空闲,正在执行其它代码,
所以自然有误差。

事件循环机制进一步补充

这里就直接引用一张图片来协助理解:(参考自Philip Roberts的演讲《Help, I'm stuck in an event-loop》)

上图大致描述就是:

  • 主线程运行时会产生执行栈,

栈中的代码调用某些api时,它们会在事件队列中添加各种事件(当满足触发条件后,如ajax请求完毕)

  • 而栈中的代码执行完毕,就会读取事件队列中的事件,去执行那些回调
  • 如此循环
  • 注意,总是要等待栈中的代码执行完毕后才会去读取事件队列中的事件

单独说说定时器

上述事件循环机制的核心是:JS引擎线程和事件触发线程

但事件上,里面还有一些隐藏细节,譬如调用setTimeout后,是如何等待特定时间后才添加到事件队列中的?

是JS引擎检测的么?当然不是了。它是由定时器线程控制(因为JS引擎自己都忙不过来,根本无暇分身)

为什么要单独的定时器线程?因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确,因此很有必要单独开一个线程用来计时。

什么时候会用到定时器线程?当使用setTimeoutsetInterval,它需要定时器线程计时,计时完成后就会将特定的事件推入事件队列中。

譬如:

setTimeout(function(){
    console.log('hello!');
}, 1000);

这段代码的作用是当1000毫秒计时完毕后(由定时器线程计时),将回调函数推入事件队列中,等待主线程执行

setTimeout(function(){
    console.log('hello!');
}, 0);

console.log('begin');

这段代码的效果是最快的时间内将回调函数推入事件队列中,等待主线程执行

注意:

  • 执行结果是:先beginhello!
  • 虽然代码的本意是0毫秒后就推入事件队列,但是W3C在HTML标准中规定,规定要求setTimeout中低于4ms的时间间隔算为4ms。

(不过也有一说是不同浏览器有不同的最小时间设定)

  • 就算不等待4ms,就算假设0毫秒就推入事件队列,也会先执行begin(因为只有可执行栈内空了后才会主动读取事件队列)

setTimeout而不是setInterval

用setTimeout模拟定期计时和直接用setInterval是有区别的。

因为每次setTimeout计时到后就会去执行,然后执行一段时间后才会继续setTimeout,中间就多了误差
(误差多少与代码执行时间有关)

而setInterval则是每次都精确的隔一段时间推入一个事件
(但是,事件的实际执行时间不一定就准确,还有可能是这个事件还没执行完毕,下一个事件就来了)

而且setInterval有一些比较致命的问题就是:

  • 累计效应(上面提到的),如果setInterval代码在(setInterval)再次添加到队列之前还没有完成执行,

就会导致定时器代码连续运行好几次,而之间没有间隔。
就算正常间隔执行,多个setInterval的代码执行时间可能会比预期小(因为代码执行需要一定时间)

  • 譬如像iOS的webview,或者Safari等浏览器中都有一个特点,在滚动的时候是不执行JS的,如果使用了setInterval,会发现在滚动结束后会执行多次由于滚动不执行JS积攒回调,如果回调执行时间过长,就会非常容器造成卡顿问题和一些不可知的错误(这一块后续有补充,setInterval自带的优化,不会重复添加回调)
  • 而且把浏览器最小化显示等操作时,setInterval并不是不执行程序,

它会把setInterval的回调函数放在队列中,等浏览器窗口再次打开时,一瞬间全部执行时

所以,鉴于这么多但问题,目前一般认为的最佳方案是:用setTimeout模拟setInterval,或者特殊场合直接用requestAnimationFrame

补充:JS高程中有提到,JS引擎会对setInterval进行优化,如果当前事件队列中有setInterval的回调,不会重复添加。不过,仍然是有很多问题。。。

事件循环进阶:macrotask与microtask

这段参考了参考来源中的第2篇文章(英文版的),(加了下自己的理解重新描述了下),
强烈推荐有英文基础的同学直接观看原文,作者描述的很清晰,示例也很不错,如下:

https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

上文中将JS事件循环机制梳理了一遍,在ES5的情况是够用了,但是在ES6盛行的现在,仍然会遇到一些问题,譬如下面这题:

console.log('script start');

setTimeout(function() {
    console.log('setTimeout');
}, 0);

Promise.resolve().then(function() {
    console.log('promise1');
}).then(function() {
    console.log('promise2');
});

console.log('script end');

嗯哼,它的正确执行顺序是这样子的:

script start
script end
promise1
promise2
setTimeout

为什么呢?因为Promise里有了一个一个新的概念:microtask

或者,进一步,JS中分为两种任务类型:macrotaskmicrotask,在ECMAScript中,microtask称为jobs,macrotask可称为task

它们的定义?区别?简单点可以按如下理解:

  • macrotask(又称之为宏任务),可以理解是每次执行栈执行的代码就是一个宏任务(包括每次从事件队列中获取一个事件回调并放到执行栈中执行)

    • 每一个task会从头到尾将这个任务执行完毕,不会执行其它
    • 浏览器为了能够使得JS内部task与DOM任务能够有序的执行,会在一个task执行结束后,在下一个 task 执行开始前,对页面进行重新渲染
(`task->渲染->task->...`)
  • microtask(又称为微任务),可以理解是在当前 task 执行结束后立即执行的任务

    • 也就是说,在当前task任务后,下一个task之前,在渲染之前
    • 所以它的响应速度相比setTimeout(setTimeout是task)会更快,因为无需等渲染
    • 也就是说,在某一个macrotask执行完后,就会将在它执行期间产生的所有microtask都执行完毕(在渲染前)

分别很么样的场景会形成macrotask和microtask呢?

  • macrotask:主代码块,setTimeout,setInterval等(可以看到,事件队列中的每一个事件都是一个macrotask)
  • microtask:Promise,process.nextTick等

__补充:在node环境下,process.nextTick的优先级高于Promise__,也就是可以简单理解为:在宏任务结束后会先执行微任务队列中的nextTickQueue部分,然后才会执行微任务中的Promise部分。

参考:https://segmentfault.com/q/1010000011914016

再根据线程来理解下:

  • macrotask中的事件都是放在一个事件队列中的,而这个队列由事件触发线程维护
  • microtask中的所有微任务都是添加到微任务队列(Job Queues)中,等待当前macrotask执行完毕后执行,而这个队列由JS引擎线程维护

(这点由自己理解+推测得出,因为它是在主线程下无缝执行的)

所以,总结下运行机制:

  • 执行一个宏任务(栈中没有就从事件队列中获取)
  • 执行过程中如果遇到微任务,就将它添加到微任务的任务队列中
  • 宏任务执行完毕后,立即执行当前微任务队列中的所有微任务(依次执行)
  • 当前宏任务执行完毕,开始检查渲染,然后GUI线程接管渲染
  • 渲染完毕后,JS线程继续接管,开始下一个宏任务(从事件队列中获取)

如图:

另外,请注意下Promisepolyfill与官方版本的区别:

  • 官方版本中,是标准的microtask形式
  • polyfill,一般都是通过setTimeout模拟的,所以是macrotask形式
  • 请特别注意这两点区别

注意,有一些浏览器执行结果不一样(因为它们可能把microtask当成macrotask来执行了),
但是为了简单,这里不描述一些不标准的浏览器下的场景(但记住,有些浏览器可能并不标准)

20180126补充:使用MutationObserver实现microtask

MutationObserver可以用来实现microtask
(它属于microtask,优先级小于Promise,
一般是Promise不支持时才会这样做)

它是HTML5中的新特性,作用是:监听一个DOM变动,
当DOM对象树发生任何变动时,Mutation Observer会得到通知

像以前的Vue源码中就是利用它来模拟nextTick的,
具体原理是,创建一个TextNode并监听内容变化,
然后要nextTick的时候去改一下这个节点的文本内容,
如下:(Vue的源码,未修改)

var counter = 1
var observer = new MutationObserver(nextTickHandler)
var textNode = document.createTextNode(String(counter))

observer.observe(textNode, {
    characterData: true
})
timerFunc = () => {
    counter = (counter + 1) % 2
    textNode.data = String(counter)
}

对应Vue源码链接

不过,现在的Vue(2.5+)的nextTick实现移除了MutationObserver的方式(据说是兼容性原因),
取而代之的是使用MessageChannel
(当然,默认情况仍然是Promise,不支持才兼容的)。

MessageChannel属于宏任务,优先级是:MessageChannel->setTimeout
所以Vue(2.5+)内部的nextTick与2.4及之前的实现是不一样的,需要注意下。

这里不展开,可以看下https://juejin.im/post/5a1af88f5188254a701ec230

写在最后的话

看到这里,不知道对JS的运行机制是不是更加理解了,从头到尾梳理,而不是就某一个碎片化知识应该是会更清晰的吧?

同时,也应该注意到了JS根本就没有想象的那么简单,前端的知识也是无穷无尽,层出不穷的概念、N多易忘的知识点、各式各样的框架、
底层原理方面也是可以无限的往下深挖,然后你就会发现,你知道的太少了。。。

另外,本文也打算先告一段落,其它的,如JS词法解析,可执行上下文以及VO等概念就不继续在本文中写了,后续可以考虑另开新的文章。

最后,喜欢的话,就请给个赞吧!

附录

博客

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

http://www.dailichun.com/2018/01/21/js_singlethread_eventloop.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

参考资料

查看原文

赞 823 收藏 946 评论 101

认证与成就

  • 获得 97 次点赞
  • 获得 29 枚徽章 获得 0 枚金徽章, 获得 7 枚银徽章, 获得 22 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2016-06-20
个人主页被 1.7k 人浏览