Uni-app性能优化：分包与长列表实战

既然昨天我们搭建好了健壮的"请求基石"，今天我们要面对的是 Uni-app 开发中最影响用户体验的难题------性能优化。

当你的项目越来越大、列表越来越长时，App 可能会出现滑动卡顿、白屏时间长、甚至内存溢出崩溃 。今天我们重点分享两招"杀手锏"：分包加载 与长列表优化。

🚀 今日份：性能优化的"快"与"省"

1. 分包加载（Subpackaging）：解决"包体积"痛点

小程序和 App 都有包体积限制（如微信小程序单个包不能超过 2MB）。当业务模块多起来后，主包会迅速膨胀，导致首屏加载极慢。

🛠️ 实战操作：

在 pages.json 中配置 subPackages：

json 复制代码

{
    "pages": [
        { "path": "pages/index/index" } // 只有启动页、TabBar页放在主包
    ],
    "subPackages": [
        {
            "root": "pages/user/", // 分包根目录
            "pages": [
                { "path": "userInfo/userInfo" },
                { "path": "setting/setting" }
            ]
        }
    ],
    // 分包预下载配置
    "preloadRule": {
        "pages/index/index": {
            "network": "all",
            "packages": ["pages/user/"] // 进首页后，自动静默下载用户分包
        }
    }
}

2. 长列表优化：拒绝"肉眼可见"的卡顿

当你有几千条数据时，如果直接用 v-for 渲染，DOM 节点过多会导致内存暴涨。

常规优化 ：使用 uni-load-more 组件配合分页加载，这是基础。
黑科技：虚拟列表（Virtual List）：只渲染用户当前屏幕能看到的几十个节点，滑出屏幕的节点直接销毁。
**Uni-app 专属武器：z-paging 或 mescroll**：这两个插件在插件市场非常成熟，自带虚拟列表优化，能极大提升流畅度。

3. 核心性能准则：减少 `setData` 频率

在 Uni-app 中，逻辑层和视图层是分离的。每次修改 this.data 都会触发数据传输，这是性能损耗的大头。

不要频繁 setData ：不要在 onPageScroll 这种高频函数里直接通过 this.xxx = yyy 修改状态。
局部更新：如果只是修改列表里的一项，不要重置整个数组，要精确定位修改。
wxs (微信) / renderjs (App/H5) ：如果涉及复杂的交互动画（如跟随手指滑动），务必使用 wxs 或 renderjs，让逻辑直接运行在视图层，避免通信卡顿。

📝 今日性能排查清单 (Checklist)

图片优化 ：图片是否都经过了压缩？是否使用了 CDN 裁剪参数（如 @100w_100h.webp）？
清理无用资源 ：static 目录下没用到的图标和代码插件是否及时删除了？
减少 DOM 层级：HTML 结构是否嵌套过深？（超过 10 层会导致渲染性能骤降）。
关闭不必要的监听 ：uni.$on 关了吗？定时器清了吗？

💡 核心总结

分包是项目做大的必经之路，越早做，后期迁移成本越低。
首屏加载看体积，滑动体验看渲染。
善用插件市场的成熟方案，不要尝试用 v-for 硬扛万级数据。