怎么定义分享的好坏？

分享之前，我在想选择什么样的知识点作为主题，才能让分享具备一定的价值，而不是单纯的分享。
评判标准：

  • 引起团队成员的共鸣、或者让团队成员有所收获。

  • 对自己有一定的提升。

    分享什么？

    与其说是分享，不如说是探讨。探讨如何构建我们自己的前端知识体系，并回馈到日常的工作中。

    怎么分享？

    我会围绕着 url从输入到渲染结束的过程经历了什么 这一个前端经典的面试题进行展开，从面到点，层层细化。众所周知这个流程经历了：

  • DNS解析

    • 浏览器
    • 本地缓存
    • 局域网缓存
    • 根主机
  • Http请求
    • 建立连接
    • 发送请求
    • 返回响应
    • 维持连接
    • 断开连接
  • 浏览器解析
    • DOM树构建
    • CSSOM树构建
    • 两者结合对页面进行绘制

  • 执行对应的脚本任务

    为什么会提到这个经典的面试题呢？

    因为这个问题涵盖了网络协议、网络安全、浏览器渲染页面的原理、进程与线程、任务队列等等，因此我就可以以这个问题为主干，然后向外延伸拓展自身的知识体系。
    例如项目优化。我们可以先了解优化的核心是什么？优化的指标是什么？以项目优化的指标结合 url从输入到渲染结束的过程经历了什么逐一排查可优化的点，然后进行针对性的优化，优化的最终的目的并不是让我们的站点在任何特定设备上都能运行的很快，而是让用户满意，提高用户的转换率。

  • 核心：一切以用户为中心。

  • 指标，这里以 RAIL 性能优化模型的指标进行讲解。

    • R 指的是 Response 响应时间，100ms 内对用户的操作进行响应
    • A 指的是 Animation 动画时间，16ms 内完成每一帧的渲染
    • I 指的是 Idle 空闲时间，当使用 js 主线程的时候，将任务划分到执行时间小于 50ms 的片段中，这样可以释放线程以进行用户交互。
    • 那么 L 指的又是什么呢？ Load 加载时间，应该小于 1s，并且可以进行用户交互，当然移动端受网络限制原因在 5s 内加载出来还是用户的可接受范围内的。

      RAIL 性能优化模型延伸

      由 RAIL 性能优化模型，我们可以引出 OSI 网络层次模型，再由该模型进行拓展延伸，从而将我们的知识体系丰富起来。OSI 网络层次模型的构成：

  • 应用层

    • 应用层
    • 表示层
    • 会话层
  • 传输层
  • 网络层
  • 数据链路层

  • 物理层

    再对 OSI 层进行细分：

  • 应用层

    • Javascript/HTML/CSS
    • 前端框架
      • Vue.js
      • React.js
      • Angular.js
      • Taro.js
      • ……
    • 跨端应用
      • uniapp
      • mpvue
      • weex
      • react native
      • fullter
      • electron
      • ……
    • 前端工程化
      • Grunt
      • Gulp
      • Fis3
      • Generator
      • Webpack
      • Rollup
      • CI/CD
      • ……
    • 微前端
      • 归类
        • npm 式
        • iframe 式
        • 通用中心路由基座式
        • 特定中心路由式
      • 方案
        • 阿里 - 乾坤框架
        • 美团 - 基于 React 的中心路由基座式微前端
        • webpack5 Module Federation
        • ……
    • severless
    • 安全问题
      • XSS
      • CORS
      • DDoS
      • cc
      • ……
  • 传输层
    • http1.0/http1.x／http2/http3
    • TCP/UDP/QUIC
      • websocket
    • ……
  • 网络层：主要为数据在节点之间传输创建逻辑链路，通过路由选择算法为分组选择最佳路径，从而实现拥塞控制、网络互联等功能

  • 数据链路层：确定目标主机位置

    那么讲点什么好呢？

    围绕 RAIL性能优化模型及 OSI 网络层次模型，我们已经构建了一个庞大的前端知识体系，剩下的就是对这个体系中的知识点进行细化，深入了解，接下来简单说一下代码层级优化的内容以及端内优化的处理～

    代码层级优化

    代码层级的优化，主要围绕重绘重排、防抖节流、算法(空间复杂度 + 时间复杂度)、原型链的使用等

  • 代码层级优化的核心是减少真实 DOM 节点的渲染频率，减少虚拟DOM的比对，可以延伸出 vue3 中的静态组件声明提升，react类组件中使用 shouldComponentUpdate 返回 false 来减少重复渲染的次数等

  • 动画开启 GPU 将 z-index 保持在页面最上方，以后对该层进行操作则不会影响其他 dom 的布局。
  • 开发过程中对 key 的绑定，可以延伸出 vue 的 diff 算法(双指针循环)、React 16版本之前的 循环+递归算法、React 16 之后的通过采用循环模拟递归的方式，构建可中断的 Fiber 对象对 Diff 过程中的任务进行分级，Fiber比对的时候会使用到深度遍历算法。
  • 又如 vue 中的 keep-alive 对组件进行缓存，这里又可以学习到 LRU 算法
  • 再如 vue3 中的双向绑定原理，基于 Map、WeakSet、WeakMap实现响应式的依赖收集,这里的话可以通过了解 js 弱引用类型，学习 GC 的运行机制。

  • ……

    端内应用优化

    由于端内优化大部分工作量都在客户端，这边我们仅作为了解学习，为后续遇到问题如何处理做铺垫。

  • 如可预见 APP 一定会使用到某些 web 页面，在启动页的时候可在子线程创建并维护一个不可见的 webview 页面。

  • 域名解析等工作提前到 webview 创建之时进行。
  • 相应的API请求也可以由 APP 发起，通过 APP 统一拦截 web 页面的请求并作出相应的响应。
  • 对于特别大的文件该如何处理呢？如长期使用的，可压缩成压缩包文件，随着APP版本的发布而发布，同样的需要客户端维护一份请求文件与代理文件的映射关系。
  • ……

    其他

    npm 镜像资源的配置，发布及维护，方便我们跨应用使用一些类似的功能组件，避免相同的代码重复写；也可以很好的规避 cv 大法带来的，资源文件更新，依赖该资源的项目也要同步 cv 更新。

结语

那么了解这些对我们有什么好处呢？个人能力的提升，更好的与后端、客户端交流，时间关系暂时就讲这些了，有兴趣的可以私下交流～