用户滑一下卡三秒，再好的留存也扛不住。
刚上线的小程序，功能齐全、界面精美，用户打开后却直接划走——原因很简单，太卡了。页面渲染跟不上手指滑动，列表加载转半天，点击按钮两秒后才反应……这不是小程序，这是PPT。
更扎心的是，很多开发者直到被用户差评刷屏，才意识到性能问题的严重性。而微信小程序的渲染机制，又天生比普通H5更容易踩坑。
别慌。渲染性能优化没那么玄乎，从这三招入手，最快当天就能见效。
第一招：管好你的setData，别什么都往里塞
这是小程序性能优化最核心、最立竿见影的一招。
很多开发者把setData当普通变量赋值用，想塞什么塞什么。但每次调用，都会触发逻辑层到渲染层的跨线程通信，数据会经过序列化、传输、反序列化。数据量越大，频率越高，卡顿越明显。
三个必须养成的习惯：
① 只传需要变化的数据。没变化的字段别跟着凑热闹，接口返回的完整数据里，只挑页面真正用到的部分传进去。
② 单次数据量控制在合理范围内。单次传输数据过大时，iOS和安卓都会出现明显掉帧。接口返回的数据如果太大，考虑分页加载或按需渲染。
③ 高频操作合并更新。滚动监听、输入框实时搜索这类场景，不要每动一下就触发更新，而是控制更新频率，等滚动停下来或每隔几十毫秒统一处理一次。
能少调一次，就少调一次；能少传一点，就少传一点。这是铁律。
第二招：长列表别硬扛，用虚拟滚动
一百条数据渲染没问题，一千条勉强能跑，五千条直接白屏。小程序的视图层是单线程的，节点越多，渲染耗时越长。
虚拟滚动的原理很简单：只渲染屏幕可见区域的那几条，回收不可见的节点。你滑到哪儿就渲染到哪儿，节点数量始终保持稳定。
目前主流的小程序框架和组件库，基本都提供了虚拟滚动方案，直接引入使用即可。需要注意两点：列表项高度尽量固定，动态高度性能会打折扣；图片配合懒加载，首屏速度翻倍。
如果列表项高度不固定又不想大改，至少做分页加载——上拉触底加载下一页。这个方案实现成本低，中小型项目够用了。
第三招：图片不优化，一切都白搭
很多小程序代码逻辑没问题，数据传输也精简了，但依然卡。打开调试器一看——图片占了几十兆内存。大图直接塞进容器，小程序依然会解码完整尺寸，内存爆了，页面能不卡吗？
四步自查清单：
① 尺寸要对得上。显示宽度只有手机屏幕那么宽，就别扔一张几千像素宽的原图。让后端或云存储提供按需裁剪能力。
② 格式选对。图标、纯色图选WebP，体积比PNG小百分之三十以上；复杂照片选JPEG并适度压缩。iOS和安卓都已兼容WebP，放心用。
③ 懒加载必须上。非首屏图片统统开启懒加载，用户滑到哪儿就加载到哪儿。
④ 大图走云处理。现在的云存储基本都支持图片实时处理，链接后加几个参数就能完成裁剪和格式转换，体积立刻大幅下降。
额外赠送一条：别在页面加载时干重活
很多开发者把页面初始加载当成万能入口，一进来就调五六个接口。结果白屏时间直奔三秒以上。
正确思路：首屏必须的数据并行请求，别一个等一个；非首屏数据等页面渲染完成后再加载；复杂计算延后执行。先让页面出来，再慢慢补全剩下的东西。用户看到内容的时间，比所有功能都完整的时间重要得多。
小程序渲染优化的核心思路，总结起来就三句话：数据传输最小化——频率降下来，数据瘦下来；节点数量可控化——长列表只渲染看得见的；资源加载智能化——图片按需加载，格式选对。
别觉得“等出问题了再优化”。在小程序这个赛道，用户不会给你第二次机会。你的页面卡一次，他就去隔壁了。
趁着今天代码还能跑，打开调试器，看看数据传输在传什么，列表有多少节点，图片有多大。现在动手，半小时就能看到变化。
别让你的小程序，变成用户手机里的下一个PPT。
热门跟贴