跳到主要内容

线上/发版问题

部署发版文件缓存问题/小程序缓存解决方法​

原因： 一些文件，比如配置文件，每次修改，部署发版，都导致因为缓存，拿不到最新的文件，可能会报错或者拿不到最新的数据 最主要的目的就是为了让微信小程序识别出，当前的文件和缓存的不同，重新清除缓存，拿到最新的数据。

  • 1、打包的静态文件，生成随机数hash
  • 2、配置文件加上参数随机数，每次发版部署请求文件都会是拿到最新的文件

如下例子：

  • privateConfig是配置文件
js
 <script
      type="text/javascript"
      src="privateConfig.js?t=<%=+new Date()%>"
    ></script>

privateConfig.js

  • 通过配置文件，生成配置，修改配置可发布多个不同配置的包
    • 即一次发版 可兼容 多个不同环境
js
window.privateConfig = {
    BACKEND_BASE:'后端地址',
    APP_KEY:'应用key'
}

ci缓存问题​

Cache 机制的引入就是为了加快 job 执行的时间

  • 有时候发现上线的发布版本 和本地的 效果不一致，改的代码在线上依旧是以前的，这可能是ci缓存问题，可清理缓存

首屏渲染慢问题​

首屏渲染优化

兼容问题​

移动端底部安全区域问题​

  • 适配底部tabbar
  • 可通过css去设置，css有个函数 env() 和 constant() 去设定安全区域与边界的距离

页面自动检查更新【检测版本更新】​

开发过程中，经常遇到页面更新、版本发布时，需要告诉使用人员刷新页面的情况

  • 场景：当用户在浏览器中打开某 web 应用很长时间且未刷新页面, 在应用有新版本更新或问题修复时, 用户会无法及时知道有新版发布, 导致用户继续使用旧的版本, 影响用户体验和后端数据准确性。
  • 效果: 会实时检测应用版本, 当发现新版本时, 展示版本更新提示弹窗, 提示用户刷新页面来更新应用。

方案： 优化：可以使用Web Worker API 来做监测轮询，不会影响浏览器渲染进程。 方式一 （WebSocket） WebSocket是需要后端配合的

  • 使用WebSocket，这是最实时的方案了，一有更新马上就会通知，像开发环境的热更新就是利用WebSocket
  • 不过使用WebSocket是很消耗服务端资源的，增加服务端的压力
  • 只是一个小功能，没必要使用WebSocket
  • 一个用户一个连接，用户量大的话，对服务器造成的压力是很大的

方式二 （轮询 生成的版本json文件）

  • 每次打包的生产的时候，可以生成一个版本的json文件
    • 定义一个version字段，根据时间戳来生成version
  • 在入口文件上，轮询的去请求这个版本的json文件，检测到变化后提醒用户并自动刷新页面

方式三 （轮询 首页的index.html） 轮询方式是，纯前端实现

  • 轮询去判断服务端的index.html是否跟当前的index.html的脚本hash值
    • 定义一个旧的script脚本数组，新的script脚本数组，用于比较
    • 使用fetch去读取index.html内容
    • 使用正则去匹配script脚本
  • 在入口文件，导入这个轮询的脚本，就可以了
    • 如果轮询脚本判断有更新，就调用location.reload重新加载页面，或者用户手动去刷新