7.3 性能优化与调试

7.3 性能优化与调试

本节导读：上线之后，性能从"感觉"变成"数字"。本节沿启动速度、渲染帧率、内存水位三条线给出可量化的优化方法，配合调试工具链的用法与一个内存泄漏的完整排查案例，最后把监控上报的地基打好。读完你应当能让每次"有点卡"的反馈落到具体数字与具体代码上。

启动速度：把首屏时间拆开看

"启动慢"要先拆解：冷启动 = 框架初始化 + 首页渲染 + 首屏数据返回，三段分别治理。框架初始化段：App.vue 的 onLaunch 里只留必要逻辑，重初始化（统计 SDK、更新检查）延后到首页 onReady 之后异步跑——4.3 节的生命周期纪律在这里直接变现。首页渲染段：分包（4.5）保证主包轻、首屏组件精简、图片用合适的尺寸与懒加载。数据段：首屏请求在 onLoad 与渲染并行（而非等渲染完再发）、接口聚合（一次请求带回首屏所需，减少串行往返）。量化手段各端有别：微信端用开发工具的性能面板看启动时序，App 端看原生启动日志打点，商城的基线是冷启动到首屏可交互控制在两秒内，超过就按时序图逐段找最长的那一截。

渲染帧率：长列表是主战场

滚动掉帧的头号来源是长列表，治理手段按性价比排序。第一档分页加载：每次只渲染一页，触底加载（4.2 的 scroll-view 阈值参数），绝大多数列表到这一档就够。第二档减少节点与setData 量：列表项精简节点数、更新时只传变化的字段而不是整页数组——小程序端数据通信有成本，一次传几百条更新就是把掉帧写进日程。第三档虚拟列表：只渲染可视区附近的条目（用现成组件），商品瀑布流上万条时上这一档。配合两条基本卫生：v-for 的 key 用业务 id（2.2 的老规则，直接影响 diff 效率）、图片尺寸与显示尺寸匹配（加载与绘制的双重浪费源）。

// 无限滚动的分页骨架：触底加载加 loading 态与到底判断
export default {
  data() {
    return { list: [], page: 1, loading: false, finished: false };
  },
  onReachBottom() {
    if (this.loading || this.finished) return;
    this.loadMore();
  },
  methods: {
    async loadMore() {
      this.loading = true;
      const page = await this.$http.get('/goods/list', { page: this.page });
      this.list = this.list.concat(page.items);
      this.finished = page.items.length < 20;   // 按页大小判断到底
      this.page += 1;
      this.loading = false;
    }
  }
};
​

内存水位：一次泄漏排查的完整过程

商城客服页上线两周后收到"用久了越切越卡"的反馈，排查过程值得全程复盘。第一步复现与量化：真机反复进出客服页五十次，观察系统内存监控，水位阶梯式上涨不回落——泄漏实锤。第二步圈定可疑资源：进出页面还不释放的东西无非几类——定时器、事件监听、长连接、闭包引用。审代码发现客服页为消息刷新注册了 uni.on('ws-message') 监听，**onUnload 里没有对应的 off**，每次进出都多挂一份，监听器连同它闭包引用的页面实例一起滞留。第三步修复与验证：

export default {
  data() { return { handler: null }; },
  onLoad() {
    // 具名函数保存引用，离开时按引用移除
    this.handler = (msg) => this.appendMessage(msg);
    uni.$on('ws-message', this.handler);
  },
  onUnload() {
    uni.$off('ws-message', this.handler);   // 与 $on 严格配对
    clearInterval(this.timer);
  }
};
​

修复后同样操作五十次，水位平稳。提炼成公约：每一对 on 与 off、每一对 setInterval 与 clearInterval、每一个 onShow 里注册的监听都要在 onHide 或 onUnload 有释放动作，评审时成对检查。5.4 的长连接管理器之所以把心跳定时器收在模块内部统一管理，正是这条公约的体现。

调试工具链：三件套各司其职

HBuilderX 调试器：App 端与小程序端的日常主力，断点、console、元素查看俱全；Chrome DevTools：H5 端与 App 端 webview 调试（App 端开调试模式后 chrome 的 inspect 可连），性能面板看渲染帧率；真机日志：小程序端开发工具的远程调试、App 端基座的日志输出，线上问题靠用户端日志回捞。工具之外的习惯更值钱：关键路径打点（启动时序、支付链路）用统一的埋点函数，输出带时间戳与端标识，排查时一眼对齐。

监控上报：让用户替你发现问题的同时你先知道

性能与错误的线上看护靠上报体系的地基：错误上报用全局错误钩子（App.vue 的 onError 与 onPageNotFound）接住未捕获异常，连同端型号、系统版本、页面路径打进上报接口；性能指标按节采集冷启动时长、首屏时长、接口成功率；告警阈值定好（错误率、关键接口延迟），别让用户在应用市场评论区当你的监控。埋点的节制与 5.3 的 silent 参数呼应——监控数据静默上报，绝不为采数打断用户。

性能优化的节奏：先测量后动手

三条优化线之外，把优化的方法论交代清楚。铁律是先测量后动手：没有基线数字的优化是玄学，改前改后各测一次，提升幅度与位置都有数，向团队汇报时才站得住。第二原则是抓大放小：时序图上最长的段、水位图上最陡的段优先，两秒的首屏里花五十毫秒的优化不值得做。第三原则是回归防护：性能修复配一条可重复的测量脚本，纳入发版前检查，防止下一个迭代悄悄退化回去。性能问题最怕的不是难，而是反复——按这三条做，同一个坑不会塌两次。

本节要点回顾

• 冷启动三段治理：onLaunch 瘦身、首屏轻渲染、请求并行加接口聚合；
• 长列表按性价比上三档：分页、精简更新量、虚拟列表；key 用业务 id；
• 泄漏排查三步：量化复现、圈定定时器监听闭包、成对修复验证；
• 监听与定时器严格配对释放，评审成对检查；
• 三件套工具各司其职，关键路径打点与全局错误上报是看护地基。

看护体系就位，最后一节抬头看路：uniCloud 与生态前沿。