北京小程序开发：三个容易被忽略的性能细节

做小程序这些年，我越来越觉得性能问题不是靠某个大招解决的，而是藏在几个容易被跳过的细节里。知码客在北京接项目，客户从国贸的金融团队到中关村的创业公司都有，网络环境、机型分布差异很大，这几个细节如果没处理好，上线后反馈会很集中。

一、setData 不是越多越好，是越准越好

很多人习惯把整个 data 对象一把梭更新，图省事。但在北京这种地铁通勤场景下，用户经常在信号切换的瞬间操作页面，一次全量 setData 的序列化开销会被放大。

我的做法是按路径更新，只传变化的那一小块：

// 不推荐
this.setData({ list: newList, total: newList.length });

// 推荐
this.setData({
  'list[2].status': 1,
  'total': newTotal
});

另外长列表别一次性渲染。北京做小程序时遇到过一个房源列表页，首屏塞了 200 条，低端安卓机直接卡住。改成虚拟列表加分段加载后，滑动明显顺了。

二、图片和分包，是启动速度的两道坎

• 图片统一走 CDN，加尺寸参数，别把原图直接丢上去。首屏 banner 用 webp，兜底 jpg。
• 主包只放 tabBar 页面和公共组件，业务页全部丢分包，配合分包预下载。
• tabBar 图标别用大图，几十 KB 就够了，很多人这里能省出几百 KB。

我们给北京一家做社区团购的客户改版时，光是把主包从 1.8MB 压到 900KB 出头，冷启动时间就肉眼可见地缩短了。这种收益在 4G 弱网下尤其明显。

三、别忽略生命周期里的清理

定时器、事件监听、长连接，页面 onUnload 时该清就清。小程序页面栈有限，用户来回跳转几次，没清掉的定时器会一直跑，内存慢慢涨上去，最后表现为“用一会儿就卡”。

性能优化不是上线前冲刺一把的事，而是写每一行代码时的习惯。

知码客的信念是“知码识途、匠心铸客”，代码是我们和用户沟通的语言。北京小程序开发、北京APP开发的需求节奏快，但越是这样，越要在这些细节上稳住。如果你也在北京做小程序，欢迎交流踩过的坑。