项目准备

star法则

Situation: 事情是在什么情况下发生

Target: 你是如何明确你的目标的

Action: 针对这样的情况分析，你采用了什么行动方式

Result: 结果怎样，在这样的情况下你学习到了什么

项目难点推动

S

• 本部门web和客户端对接需求比较耗时；
  1， 产品单独对接都需要较长工作量，
  ws库文件各自产品业务维护，不便于管理和使用
  2， 相同功能接口不一致；（下载、跳转等）
  3， 网页贴片视频播放业务场景不满足！

T

• 1. 轻量化客户端形成统一对接入口；

2. 完成通用接口封装（登录，登出，保活），以及内嵌基础功能（录像、实时、画面增强、下载等）

   • websocket
   • reconnect js库
   • 兼容bs和 cs（pc app）

A

• 和客户端进行websocket对接，确定我们的目标功能，自己支持的浏览器版本以及场景！ 新增npm库@psi/dss

• 收集各个产品的基础功能，筛选出哪些进行库内部支持

• 自动裁剪

  • 选择器dom传入处理，有默认的！

计算剪切区域，碰撞交叉区域！ requestAnimationFrame更新

• 贴片计算位置？ requestAnimationFrame 处理

  • 最大的优势是由浏览器来决定回调函数的执行时机，即紧跟浏览器的刷新步调；能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，自然不会导致动画的卡顿
  • CPU节能：使用setTimeout实现的动画，当页面被隐藏（隐藏的<iframe>）或最小化（后台标签页）时，setTimeout仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，而且还浪费 CPU 资源和电池寿命。而requestAnimationFrame则完全不同，当页面处于未激活的状态下，该页面的屏幕绘制任务也会被浏览器暂停，因此跟着浏览器步伐走的

requestAnimationFrame也会停止渲染，当页面被激活时，动画就从上次停留的地方继续执行，有效节省了 CPU 开销，提升性能和电池寿命。
- setTimeout问题

    - setTimeout仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，而且还浪费 CPU 资源和电池寿命
    - 针对屏幕刷新频率不一致

• 交互性升级；针对客户端进行版本检测、版本升级、安装以及卸载检测等等；

R

• 推广公安产品使用，最终使得和客户端对接工作量降低至1人天；

• 交互性得到质的提升

• 问题：
  后续还会针对iframe等内嵌进行兼容处理； 存在部分问题

  • 第三方嵌入还有哪些方案？

    • 微前端

项目新技术执行

lowcode

微前端singleSpa & 乾坤

• 关键问题1

  • 1 子应用如何定义和使用？

  • 2 如何动态加载？

  • 3 如何隔离？

    • js

      • Proxy沙箱 sandbox
      • 快照沙箱

    • css

      • shadow DOM
      • 前缀约定式隔离BEM
      • CSS module
      • css in js

• single-SPA

  • 解决问题 1

    • 兼容各种技术栈

    • 更优的性能

      • 每个独立模块的代码可做到按需加载,不浪费额外资源

    • 无需重构现有代码

    • 每个独立模块可独立运行

• qiankun

  • 解决问题 1-2-3

    • 根据约定，子应用需要暴露声明周期方法，Qiankun 会去加载资源然后根据约定拿到方法，这里官方的推荐是通过 webpack 的 umd 输出格式来做
    • 在执行 js 资源时通过 eval，会将 window 绑定到一个 Proxy 对象上，以防污染全局变量，并方便对脚本的 window 相关操作做劫持处理，达到子应用之间的脚本隔离

• 鲸落

  • 为啥选用自己鲸落？ qiankun不满足吗？
  • 做了哪些定制需求？

nobundle

• vite

学习的途径

github、掘金、简书等

阅读源码

子主题 3

流程推动

S

• 前端整个项目开发流程缺陷，

1. 在项目开发后，开发人员有部分功能造成丢失或者测试，ui，开发认为需求不一致；
2. 部分轻微样式问题，屡次提到，产品中仍然不少

T

• 1. 确保前端开发整个流程闭环，
     保证/确保产品，ui，测试感知到的需求一致性；保障产品风险可控

2. 产品转侧前，进行有效的代码评审，有效降低bug量

A

• 主动推动项目开发整体流程；完善流程；

1. 增加模块前端设计文档，文档确保涉及的前端/地图/后端/客户端等相关开发功能无遗漏；该模块组件拆分，以及难点方案解析，确保整体项目风险可控；
2. 需求开发完后，拉通测试/产品/开发进行模块需求反串讲，确保需求一致性；
3. 产品确定修改需求，及时同步开发/ui
4. 转侧前必定保障模块进行组内代码评审，或者组长评审

R

• 推广公安线前端团队，各个产品开发中整体完成模块设计和思想；最终确保模块需求完善；
  需求一致性提升，争议点降低80%；
• 通过完善流程，推出整体流程文档并进行相关培训

代码重构

S

• 1. 接手实战项目，局点项目需求需要改动局部逻辑点较多；会有很多问题，一一列举
     代码中 ----> 单vue组件，js相关代码，template相关代码量过多，造成代码维护性差，可阅读性差；

2. 函数功能不单一，影响较大

3. 服务层未分离；多处维护可靠性不高

T

• 目标：

1. 首先对单个模块进行重构，确定单模块工作量（需求迭代风险）；
2. 后续推动产品/项目确定重构代码优先级，表明重构后收益（主要包括：新成员维护成本，局点项目开发成本，降低代码bug量）

A

• 完成单模块重构，
  紧随其后 推动完成整体产品重构

  • 如何重构模块

    • 提取重复代码，封装成函数
    • 拆分功能太多的函数
    • 变量/函数改名 -- 可读性
    • 替换算法
    • 以函数调用取代内联代码
    • 移动语句
    • 折分嵌套条件表达式
    • 将查询函数和修改函数分离

  • 怎么拆分组件颗粒度

    • 布局组件
    • 结果view组件展示，自适应

  • 逻辑处理在哪里维护

    • container.vue
    • 拆分视图组件

  • service层抽离

R

• 重构后有明显收益，依据工作量安排

新成员熟悉维护成本 ---> 降低33% （工作量从3d，到2d）

局点项目开发成本 ---> 局部功能开发工作量降低40%（5人天 --> 3人天）

降低代码bug量 ---> 降低38%（46 -->28）

学习到哪些？
组件拆分颗粒度；
形成模块开发规范；
公安行业公共组件推出；

项目优化相关

• 首屏优化

  • 提升30%（500ms）

  • 懒加载

    • 长页面加载过程时，先加载关键内容，延迟加载非关键内容
    • 图片懒加载
    • 路由懒加载
    • 滚动加载

  • 缓存

    • 资源缓存

  • 离线化

  • 并行化

  • 预先加载 prefetch

    • dns-prefetch

    • Preconnect

      • TCP握手和TLS

    • prefetch

  • webpack开启gzip压缩，文件小速度快

  • CDN

• webpack打包优化

  • 开发环境

    • DLLPlugin 动态链接库

    • 减少执行构建的模块

      • 按需引入类库模块

        • lodash-es.js

      • IgnorePlugin

    • Externals

    • 提升单个模块构建的速度

      • 配置babel-loader中的 include/exclude,

      • Resolve

        • 置制定的是在构建时指定查找模块文件的规则

      • noParse

        • 省略了使用默认 js 模块编译器进行编译的时间

      • Source Map

    • 并行构建以提升总体效率

      • HappyPack 与 thread-loader

  • 生产环境

    • 面向 JS 的压缩工具

      • Terser 和 UglifyJS 插件中的效率优化

    • 面向 CSS 的压缩工具

      • CSSMinimizerWebpackPlugin

        • 支持缓存和多进程

    • Split Chunks

      • 路由懒加载，分包
      • 多入口
      • 抽取公共代码，也会提取出一个chunk

    • Tree Shaking

• 提取公共组件

• svg/国际化/tree优化

  • 细化介绍下

XMind - Trial Version