想象你在寸土寸金的商业街开了一家“云上餐厅”：后厨（逻辑层）负责备菜、算账，前厅（视图层）负责上菜、摆盘，连接前后场的只有一位跑堂小哥，他的名字叫 setData。客人喊一声“加点辣”，小哥要从后厨跑到前厅一趟；客人说“菜单换三页”，他得一次端出二十个盘子——哪怕真正变化的只有三盘菜。跑得急、端得多，菜会洒（白屏），人会累瘫（卡顿），客人等得不耐烦，转头就进了隔壁店（卸载流失）。 现实中的小程序正是这样：setData 每次调用都是一次“传菜”，数据量越大、调用越频繁，性能就越差。但这门生意并非无解——聪明的餐厅会做整套改造：差量更新让小哥只端变化的那盘菜；虚拟列表让前厅的电子菜单屏只渲染客人眼前看得见的几行；分包加载把菜品分区存放、按需取用；首屏加速让客人进门第一眼就看到招牌菜已经摆好；再加上流水报表（量化评估）和成本红线（性能预算），整家餐厅越跑越顺。接下来，就让我们跟着这位跑堂小哥，把小程序性能优化的十八般武艺逐一学透。

岗位关联

学完本章，你将能从“能跑就行”升级为用数据指标驱动流畅体验的性能优化工程师。掌握 setData 差量更新、虚拟列表、分包加载这一整套“传菜管理术”，是电商、本地生活类小程序岗位中极具差异化的核心竞争力。

目录
  1. 可视化演示
  2. 性能瓶颈认知：跑堂小哥为什么累
  3. 差量更新策略：只端变化的那盘菜
  4. 虚拟列表渲染：菜单屏只显示看得见的菜
  5. 分包加载优化：分区备菜，点了再取
  6. 首屏加速技巧：先把招牌菜摆好
  7. 量化评估体系：流水报表与成本红线
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示setData差量更新对比、虚拟列表视口渲染机制与分包加载首屏加速策略，支持模式切换交互。

本节配有交互动效（进入视口后自动加载，约 3KB）。

setData差量更新 全量setData传输12KB数据，渲染耗时120ms 差量setData仅传2KB变更数据，渲染耗时25ms this.setData({ list[idx]: newVal }) 差量更新减少6倍数据传输量提升渲染性能

性能瓶颈认知：跑堂小哥为什么累

餐厅最忙的时候，后厨出菜口堆满盘子，跑堂小哥一趟趟往返于后厨和前厅。观察久了你会发现，真正让人崩溃的场景只有两种：客人隔几秒就喊一次“加菜”（频繁调用），或者一次要求“把整本菜单都端上来”（数据量过大）。前者让小哥腿脚不停，后者让他寸步难行。

小程序里的 setData 正是那位跑堂小哥。它并不只是改一个变量，而是要把数据对象“翻译”成界面能识别的格式（专业上叫序列化，相当于把每道菜装进打包盒），再通过底层通道送到视图层，最后重新绘制界面。因此，每次 setData 的成本由三部分组成：每条数据固定要付的“翻译费”、数据总条数，以及渲染层重新摆放餐具的耗时。

把一次 setData 的总耗时写成公式，瓶颈一目了然：

跑堂小哥的体力是有限的。认清 setData 的调用频率和数据量才是瓶颈根源之后，我们才能对症下药——不是换一个更快的传菜员，而是从流程上减少“无效传菜”。

TsetData=Cserialize×Ndata+Trender\displaystyle T_{setData} = C_{serialize} \times N_{data} + T_{render}
通俗地说，传菜总时间 = 每道菜的打包成本 × 菜的数量 + 摆盘时间。要缩短时间，要么减少来回次数（降低调用频率），要么减少端上桌的盘数（削减数据量）。
  1. 总耗时 $T_{setData}$从逻辑层发起数据更新，到渲染层完成界面刷新所用的总时间，单位通常是毫秒。它就是我们衡量“小哥累不累”的标尺。
    TsetData\displaystyle T_{setData}
  2. 序列化成本 $C_{serialize}$把 JavaScript 对象转换成可传输格式时，每条数据都要支付的固定“打包费”，无论数据内容多简单，这笔钱都省不掉。
    Cserialize\displaystyle C_{serialize}
  3. 数据条数 $N_{data}$本次 setData 实际携带的字段数量，是决定总开销的核心变量。数据越多，总成本线性上涨，就像盘子越多，小哥越跑不动。
    Ndata\displaystyle N_{data}
  4. 渲染耗时 $T_{render}$视图层拿到数据后，完成布局与绘制所花的时间。页面越复杂、组件越多，这项开销就越高。
    Trender\displaystyle T_{render}

差量更新策略：只端变化的那盘菜

聪明的餐厅会定下规矩：跑堂小哥每次只端客人新点的那几道菜，而不是把桌上所有旧盘子重新端一遍。客人说“第 2 页第 3 行的辣椒面减半”，后厨只需要补一道微调的菜，而不是重做整桌宴席。

小程序同样支持这种“精准上菜”：setData 可以接收数据路径（data path），直接指定要更新哪个字段。比如 this.setData({'user.name': '小明'}) 只更新 user 对象里的 name 字段，其余数据原封不动。这就是差量更新（Diff Update）——把整页数据当成一张大菜单，只把变化的那几行写进去。

差量更新的效果可以用一个简单的公式量化：传输削减率等于“没变化的数据占比”。

实践中有三个常见手法：一是合并多次 setData（把同一帧内的小哥喊话攒成一次传菜）；二是按路径更新深层字段；三是绝不把与本次渲染无关的临时变量塞进 setData。小哥不再西装革履地端 20 个盘子，自然身轻如燕，客人的每一次翻页都跟得上节奏。

η=1−NchangedNtotal(0≤Nchanged≤Ntotal)\displaystyle \eta = 1 - \frac{N_{changed}}{N_{total}} \quad (0 \le N_{changed} \le N_{total})
如果一次 setData 涉及 500 条数据，实际只有 3 条发生变化，差量更新就能省下约 99.4% 的传输量。这正是让传菜小哥从“端 20 盘”变成“端 3 盘”的魔法数字。
  1. 削减率 $\eta$衡量差量更新相比全量更新节省了多少传输成本，值越接近 1，优化越彻底。
    η\displaystyle \eta
  2. 变化条数 $N_{changed}$本次更新中真正被修改的字段数量。差量更新的原则是“一个字段都不多传”。
    Nchanged\displaystyle N_{changed}
  3. 总条数 $N_{total}$当前数据对象包含的全部字段数量。它是分母，也是全量更新时要传的全部内容。
    Ntotal\displaystyle N_{total}
  4. 取 1 相减用 1 减去变化量占比，得到的就是被省掉的那部分数据比例。
    1−NchangedNtotal\displaystyle 1 - \frac{N_{changed}}{N_{total}}

虚拟列表渲染：菜单屏只显示看得见的菜

餐厅前厅有一块电子菜单屏，它不会把 100 道菜一次性全铺在屏幕上——客人根本看不完。屏幕只展示当前视野里的 5～6 道菜，手指一滑，内容立刻换成相邻菜品。客人眼里菜单是连续的，但屏幕实际渲染的，始终只有那几个“看得见的菜位”。

小程序里的长列表也是这样。数据可能有 500 条，但手机屏幕一屏只能显示 10 行。如果一次性渲染 500 个组件节点，渲染层会被密密麻麻的“菜盘”压到卡顿。虚拟列表（Virtual List）的核心思想就是：只把可视区（viewport）内和上下缓冲区的节点创建出来，滚动时复用旧节点、更新内容，而不是销毁重建。同时，用一个占位容器撑起总高度，保证滚动条的长度与真实数据量一致——这就是滚动占位补偿。

渲染节点数的控制公式如下：

虚拟列表是长列表场景的必备技能。无论是商品流、聊天记录还是外卖菜单，只要数据量超过一屏，就该考虑这套“电子菜单屏”方案——把渲染压力从“全部菜都摆上桌”降为“只摆客人看得见的那几盘”。

Nrender=⌈HviewportHitem⌉+Nbuffer\displaystyle N_{render} = \left\lceil \frac{H_{viewport}}{H_{item}} \right\rceil + N_{buffer}
假设屏幕可视高度 600px，每一行高 60px，缓冲 2 行，那么无论列表有 500 行还是 5000 行，实际渲染的节点都只有 12 个。前厅菜单屏永远只画眼皮底下那几道菜，滚得再快也不累。
  1. 渲染节点数 $N_{render}$虚拟列表真正创建出来的组件个数。这个数字决定了渲染层的压力大小。
    Nrender\displaystyle N_{render}
  2. 可视区高度 $H_{viewport}$列表容器在屏幕上占据的高度。只有落在这个范围内的行才值得渲染。
    Hviewport\displaystyle H_{viewport}
  3. 单行高度 $H_{item}$列表每一项的固定高度。如果行高不固定，需要额外做高度估算与补偿。
    Hitem\displaystyle H_{item}
  4. 向上取整 $\lceil \cdot \rceil$除法结果不是整数时，取比它大的最小整数，保证视觉上不露出空白。
    ⌈HviewportHitem⌉\displaystyle \left\lceil \frac{H_{viewport}}{H_{item}} \right\rceil
  5. 缓冲行数 $N_{buffer}$在可视区上下各多渲染几行，用于抵消快速滑动时的“白屏”瞬间。
    Nbuffer\displaystyle N_{buffer}

分包加载优化：分区备菜，点了再取

餐厅后厨不会把所有食材都堆在主操作台上。常备食材放主工作台，时令海鲜养在水族箱，节日套餐存在冷藏柜。客人没点海鲜之前，后厨小哥根本不用去水族箱捞鱼——备菜区分得越清楚，开门迎客就越快。

小程序对包体积有硬性限制（例如微信主包通常不超过 2MB，总包体也有上限）。如果把所有页面、图片、组件全部塞进主包，用户每次启动都要下载完整包体，首屏自然慢得让人抓狂。分包加载（Subpackage Loading）就是把非核心业务页面拆到独立子包中：启动时只加载主包，用户真的访问到某个分包页面时，才去下载对应的子包。

分包的核心约束可以用体积公式表达：

实践中，秒杀页、支付页、会员中心这类低频业务最应该拆成独立分包。店铺想上新菜（新功能），只需放到相应的子包中，老客常点的招牌菜（主包）依旧保持轻量。客人只点招牌菜的时候，备一整套宴席就是浪费。

Vmain+Vsub≤Vlimit,Tlaunch=Tcore+∑Tsub\displaystyle V_{main} + V_{sub} \le V_{limit}, \qquad T_{launch} = T_{core} + \sum T_{sub}
主包体积与各分包体积之和不能超过平台限制；启动耗时只包含主包加载时间，加上用户已触达分包所需的追加下载时间。对大多数用户来说，没逛到“海鲜区”就不用下载“海鲜包”。
  1. 主包体积 $V_{main}$启动小程序时必然要下载的代码与资源大小，是首屏耗时的决定性因素之一。
    Vmain\displaystyle V_{main}
  2. 分包体积 $V_{sub}$按业务拆分的独立子包体积。它不影响首次启动，只在用户进入对应页面时按需加载。
    Vsub\displaystyle V_{sub}
  3. 平台限制 $V_{limit}$微信、支付宝等平台对小程序包体总和的硬性上限，超过则无法通过审核。
    Vlimit\displaystyle V_{limit}
  4. 启动耗时 $T_{launch}$用户点开小程序到首屏可交互的时间，等于主包加载时间与已加载分包时间的总和。
    Tlaunch=Tcore+∑Tsub\displaystyle T_{launch} = T_{core} + \sum T_{sub}

首屏加速技巧：先把招牌菜摆好

餐厅开门前，老板会把门口的招牌擦亮、窗边座位铺好桌布、显著位置摆上今日推荐——客人踏进店门的第 0.5 秒，体验就已经开始了。如果等客人坐下才开始买菜、洗菜、切菜，这顿饭的满意度大概率已经打了五折。

小程序的“开门”同样讲究时序。首屏（First Screen）是用户看到第一屏有意义内容的时间，由网络、数据、渲染三段串联而成。常用加速手段包括：骨架屏（数据没到先用占位图形撑住视觉，相当于门口先立一块“今日推荐”招牌）、数据预拉取（在页面真正加载前，提前把接口数据拉到本地缓存）、渲染时序控制（首屏只渲染最关键组件，非核心部分延迟渲染，比如把轮播图之后的推荐区放到数据到位后再绘制）。

首屏完成时间可以拆解为：

首屏优化本质上是“提前准备”的艺术：招牌先立起来（骨架屏），食材提前备好（数据预拉取），灶台点火顺序合理（渲染时序）。客人进门看到的是井井有条的餐厅，而不是一地鸡毛的后厨。

Tfcp=Tdns+Tconnect+Tdata+Trender\displaystyle T_{fcp} = T_{dns} + T_{connect} + T_{data} + T_{render}
域名解析、建立连接、数据下载、首次渲染，每一环都在消耗用户的耐心。每一项单独看都不大，加起来就是用户决定“留不留下来”的那两三秒。
  1. 首屏时间 $T_{fcp}$从用户点开小程序到第一屏内容可交互的总耗时，是体验优化的总目标。
    Tfcp\displaystyle T_{fcp}
  2. DNS 解析 $T_{dns}$把域名翻译成服务器 IP 地址的时间。预解析、就近 CDN 都能压缩这段耗时。
    Tdns\displaystyle T_{dns}
  3. 连接建立 $T_{connect}$客户端与服务器建立网络连接的时间，复用长连接可以省掉反复握手的开销。
    Tconnect\displaystyle T_{connect}
  4. 数据传输 $T_{data}$请求接口并把数据下载到本地的时间。数据预拉取就是把这一步提前到“客人进门之前”。
    Tdata\displaystyle T_{data}
  5. 首次渲染 $T_{render}$从拿到数据到界面完成首次绘制的时间。骨架屏的作用就是让这一阶段不出现白屏。
    Trender\displaystyle T_{render}

量化评估体系：流水报表与成本红线

一位合格的餐厅老板，每周一定会看三张表：翻台率、单品成本、顾客投诉率。没有报表，改菜单就是拍脑袋；有了报表，每道新菜都要先过一遍成本红线，再决定是否上桌。

小程序性能优化同样不能靠感觉。要做的是三件事：埋点（在关键页面记录性能日志）、指标采集（首屏时间、setData 调用频率、单次数据量、渲染节点数）、性能预算（Performance Budget）。性能预算就像餐厅的成本红线：给每项指标设一个“不得超过”的预算值，比如“首屏必须小于 2.5s”“单次 setData 数据量必须小于 50KB”。每次发版前跑一遍回归对比，指标超标就自动拦截发布。

综合性能得分可以用加权公式表达：

有了流水报表和成本红线，老板就能在“加新菜”和“保品质”之间做理性决策。性能预算让团队不再互相甩锅——数据摆在那里，谁的新功能导致首屏从 2.0s 涨到 3.5s，一目了然。

S=∑i=1nwi×mibi≤1.0\displaystyle S = \sum_{i=1}^{n} w_i \times \frac{m_i}{b_i} \le 1.0
每一项指标的真实值除以预算值得到一个“占用比”，再按权重加权求和。只要综合得分不超过 1，整家餐厅的运营就还在老板规定的“成本红线”之内。
  1. 第 $i$ 项指标当前值 $m_i$通过埋点采集到的真实性能数据，如“实际首屏 3.2s”。
    mi\displaystyle m_i
  2. 第 $i$ 项预算值 $b_i$为该项指标设定的红线，如“首屏预算 2.5s”。真实值超过预算，这一项就超支。
    bi\displaystyle b_i
  3. 指标占用比 $m_i / b_i$真实值与预算值的比值。大于 1 说明超支，小于 1 说明健康。
    mibi\displaystyle \frac{m_i}{b_i}
  4. 权重 $w_i$不同指标的重要性不同，首屏的权重通常高于某个次要页面的渲染节点数。
    wi\displaystyle w_i
  5. 综合得分 $S$所有指标加权后的总分。只有 $S \le 1.0$，才能通过性能门禁。
    S=∑i=1nwi×mibi\displaystyle S = \sum_{i=1}^{n} w_i \times \frac{m_i}{b_i}

AI 应用场景

场景1：AI 商品推荐流的小程序端优化

阶段：渲染与通信优化

解决的问题：AI 推荐引擎每秒生成上千条个性化商品数据，如果小程序端用全量 setData 一次性推给视图层，再全量渲染列表，用户手指一滑就会卡顿甚至白屏。传统上只能靠“删功能”来保流畅，如今用虚拟列表 + 差量更新，既能承载 AI 的丰富推荐，又能保证 60fps 滑动。

具体案例：某电商小程序首页的“猜你喜欢”信息流，数据量从 200 条增长到 2000 条。改为虚拟列表后，实际渲染节点恒定为 12 个；用户点击“喜欢/不喜欢”时，只差量更新对应商品卡片的状态字段，滑动依旧丝滑。

场景2：AI 客服助手的首屏加速

阶段：加载链路优化

解决的问题：AI 客服机器人页面包含语音识别、对话渲染、历史记录等重模块，启动时要加载的代码包很大。如果全部塞进主包，用户等待时间会超过 AI 服务的响应速度，体验直接崩盘。

具体案例：某银行小程序接入 AI 客服，将语音识别与历史会话拆分为独立分包，首屏只保留对话输入框和骨架屏；同时开启数据预拉取，在用户点击“联系客服”前就把问候语与常用问题列表缓存好。启动时间从 3.2s 降到 1.4s。

场景3：性能日志的 AI 自动归因

阶段：可观测性与智能诊断

解决的问题：性能埋点会产生海量日志，人工排查 setData 超频或首屏超标的原因非常低效。通过 AI 对性能日志做聚类与归因分析，自动发现“哪个页面、哪个版本、哪个操作路径”触发了性能劣化。

具体案例：某平台型小程序接入 AI 归因系统后，自动定位到“商品详情页的轮播图组件在 IOS 低端机上导致 setData 单次超过 200KB”，并给出建议：改静态图 + 差量更新。修复后，该页面的性能预算回归测试首次通过。

Python 演示

python37 行
import math  def setdata_cost(strategy, total_items, changed_keys):    """返回一次 setData 传输的数据量"""    if strategy == "full":        return total_items    return len(changed_keys)  def render_count(total_items, viewport_height, item_height, buffer=2):    """虚拟列表实际渲染的节点数"""    visible = math.ceil(viewport_height / item_height)    return min(total_items, visible + buffer)  def main():    total_items = 500    changed_keys = ["item_3", "item_50", "item_200"]    viewport_height = 600    item_height = 60     full_setdata = setdata_cost("full", total_items, changed_keys)    diff_setdata = setdata_cost("diff", total_items, changed_keys)    full_render = render_count(total_items, viewport_height, item_height, buffer=0)    virtual_render = render_count(total_items, viewport_height, item_height, buffer=2)     print("全量 setData 传输:", full_setdata, "条")    print("差量 setData 传输:", diff_setdata, "条")    print("全量渲染节点:", full_render, "个")    print("虚拟列表渲染节点:", virtual_render, "个")    print(f"差量传输节省 {100 - diff_setdata * 100 / full_setdata:.1f}%")    print(f"虚拟列表渲染节省 {100 - virtual_render * 100 / full_render:.1f}%")  if __name__ == "__main__":    main()
目的：用 Python 模拟小程序中差量更新与虚拟列表的数值效果，直观对比优化前后传输量和渲染量的差距。
  1. def setdata_cost(strategy, total_items, changed_keys):定义“传菜策略”函数：全量还是差量。
  2. if strategy == "full": return total_items全量模式把整本菜单 500 条全端上桌。
  3. return len(changed_keys)差量模式只数真正变化的 3 条菜。
  4. visible = math.ceil(viewport_height / item_height)计算屏幕能放下几行菜，600px 高、每行 60px，正好 10 行。
  5. return min(total_items, visible + buffer)加上 2 行缓冲，但绝不渲染超过总行数。
  6. print(f"差量传输节省 {100 - diff_setdata * 100 / full_setdata:.1f}%")输出差量模式省下的传输比例，运行即可看到接近 99% 的降幅。

常见误区

误区很多初学者把 setData 当成普通的变量赋值，以为“反正数据就那几条，多调用几次 setData 也就几毫秒的事”。于是每收到一次用户输入就调一次 setData，一个页面里十几个 setData 全靠散弹枪式乱发。

正解setData 背后是逻辑层到视图层的跨线程通信，每次调用都有序列化、传输、渲染三层开销。这就像跑堂小哥每传一次菜都要从后厨走到前厅，哪怕只端一根牙签，这趟路一步都省不了。频繁调用会让多个更新任务在渲染层排队，最终表现为页面卡顿、动画掉帧。

为何常见：因为在 PC 端 Web 开发里，直接操作 DOM 更新内容往往“感觉很快”，初学者会把这种直觉迁移到小程序，忽略了跨线程通信的成本。

误区有人把虚拟列表理解成“把 500 条数据分成 10 页，一次加载 50 条”。以为只要做了分页，滚动就不会卡。

正解分页加载解决的是“数据从哪来”的问题，数据依然会全部存到内存，并逐步渲染到视图层；而虚拟列表解决的是“渲染多少个节点”的问题——无论数据有多少条，视图层永远只创建可视区附近的十几个节点，其余数据只是“存在”而“不渲染”。两者是数据层与渲染层的不同策略，可以配合使用，但不能互相替代。

为何常见：微信早期生态里很多人用“上拉加载更多”缓解长列表压力，形成了“分批就不卡”的思维定势，忽略了渲染节点数才是卡顿的关键。

误区听到分包能减少启动包体，就疯狂拆包——十几个分包，每个只有几 KB，觉得拆得越细，启动越快。

正解分包过多会让主包管理页面的路由表变复杂，而且用户真正访问分包页面时仍需网络下载，子包过碎反而增加请求次数与磁盘碎片。更合理的做法是按业务边界拆包：高频核心功能留主包，低频大功能（支付、秒杀、会员中心）拆独立分包，让“用户几乎不碰的代码”不要进入启动链路。

为何常见：只看“主包体积变小”这一个指标，忽略了“按需加载”带来的新增网络延时，属于单指标优化的典型误区。

误区有开发者认为 setData 调用太多，用 throttle 或 debounce 把调用频率降下来，比如每隔 300ms 才允许 setData 一次，就万事大吉。

正解节流确实能减少调用次数，但如果每次调用仍然携带整页大数据，传输量并没有降下来。差量更新是“减肥”，节流是“少跑几趟”。一个胖小哥少跑几趟依然气喘吁吁，只有同时让他少端菜、跑更少，才能真正流畅。正确姿势是：节流控制频率上限，差量更新控制单次数据量，双管齐下。

为何常见：很多人从“事件触发过于频繁”的问题出发，本能地用节流去解决，而忽略了数据量这个更大的开销来源。

误区优化完首屏和列表后，团队就松懈了。三个月后新功能上线，首屏从 1.8s 涨到 3.5s，却没人知道是哪次改动的锅。

正解性能优化不是一次性的装修，而是持续的经营。需要建立性能预算和回归对比机制：每次发版自动采集首屏时间、setData 数据量、渲染节点数，超过预算就拦截发布。这就像餐厅老板每周看流水报表，一旦食材成本超红线，立刻找出是哪道菜出了问题。

为何常见：因为性能劣化是逐渐累积的，单次改动可能只慢 50ms，感知不到，但十次改动叠加后体验就崩了。没有量化监控，就看不到渐变。

面试题

Q1. setData 的开销主要与哪两个因素相关？

单选题 · easy

  • A.调用频率与数据体量← 正确答案
  • B.函数名与参数数量
  • C.页面颜色与字体大小
  • D.网络协议与服务器 IP

答案：A。setData 每次调用都要付出序列化、传输与渲染的成本，调用频率越高、携带数据越多，总开销越大。这就像跑堂小哥跑得越勤、端得越多，越累。函数名、页面颜色、网络协议与 setData 本身的通信开销无关。

Q2. 下列哪种做法能直接降低单次 setData 的数据量？

单选题 · easy

  • A.差量更新只传变化字段← 正确答案
  • B.增加每次传输的数据量
  • C.把 setData 换成 request
  • D.减少样式文件的数量

答案：A。差量更新通过数据路径只传输发生变化的字段，是降低单次数据量的核心手段。request 是网络请求接口，不能替代视图更新；减少样式文件与 setData 数据量无关。

Q3. 虚拟列表为何能渲染长列表依然流畅？

单选题 · mid

  • A.只渲染可视区附近的节点← 正确答案
  • B.把所有数据拆分成小文件
  • C.压缩图片视频等媒体资源
  • D.用更高频的定时器强制刷新

答案：A。虚拟列表在视口内只创建可视区（加缓冲）的节点，屏幕外的数据不参与渲染，因此无论总数据量多大，渲染压力都稳定。拆文件、压缩媒体、定时器刷新都无法解决“节点过多”的卡顿根源。

Q4. 虚拟列表滚动时，旧的列表项节点会发生什么？

单选题 · mid

  • A.复用旧节点并更新其内容← 正确答案
  • B.销毁全部节点后重新创建
  • C.暂停列表所有渲染行为
  • D.把列表数据复制一份存储

答案：A。虚拟列表采用节点复用策略，将滚动出可视区的节点“搬运”到新位置，仅更新内容，避免频繁创建销毁组件带来的性能损耗。销毁重建、暂停渲染、复制数据都不是虚拟列表的做法。

Q5. 小程序分包加载的主要目的是？

单选题 · mid

  • A.降低主包体积加快启动← 正确答案
  • B.提升第三方广告的收益
  • C.减少代码中的注释数量
  • D.增大单次 setData 载荷

答案：A。启动时只需下载主包，分包在用户访问对应页面时才按需加载，主包变小直接缩短首屏启动时间。收益、注释、setData 载荷都与分包无关。

Q6. 某低频功能页体积较大且只被少数用户访问，应优先采用？

单选题 · hard

  • A.独立分包按需动态引入← 正确答案
  • B.删除该功能全部代码
  • C.把功能代码复制三份
  • D.改用 textarea 实现页面

答案：A。低频大页面应拆成独立分包，用户真正常用到时才下载，避免其代码进入主包拖慢所有人的启动。删除功能、复制代码、textarea 都是不合理的方案。

Q7. 首屏加速中“骨架屏”的主要作用是什么？

单选题 · easy

  • A.用占位图减少空白等待感← 正确答案
  • B.提前加载用户评论的数据
  • C.压缩页面脚本的整体体积
  • D.减少后端服务器的数量

答案：A。骨架屏在真实数据到达前先绘制灰色占位块，稳定视觉，减少用户等待时的焦虑。预加载数据是数据预拉取，压缩脚本是代码体积优化，都与骨架屏的“视觉占位”本质不同。

Q8. 以下哪些属于 setData 的正确优化手段？

多选题 · mid

  • A.合并多次 setData 为一次← 正确答案
  • B.按数据路径精准更新← 正确答案
  • C.删除全部未使用图片
  • D.用全局变量整体替换

答案：AB。合并调用减少通信次数，按路径更新减少单次数据量，两者都是差量更新的核心操作。删除图片属于资源体积优化；用全局变量绕过 setData 不会触发视图更新，是错误做法。

Q9. 制定性能预算时应重点关注哪些指标？

多选题 · hard

  • A.首次可交互完成时间← 正确答案
  • B.单次 setData 数据量← 正确答案
  • C.主包与分包总体积← 正确答案
  • D.开发者星座与工号

答案：ABC。性能预算覆盖加载、通信、包体三个维度：首屏时间反映整体体验，setData 数据量反映通信开销，包体积反映启动成本。星座与工号属于无效数据，不应进入预算体系。

Q10. 关于差量更新与虚拟列表的组合使用，说法正确的是？

多选题 · extreme

  • A.差量降传输虚拟列表降渲染← 正确答案
  • B.组合后无需做节点回收复用
  • C.数据变化只更新可视区节点← 正确答案
  • D.组合方案依赖骨架屏做复用

答案：AC。差量更新解决“传得少”，虚拟列表解决“渲染得少”，二者互补，组合后数据变化时只需更新可视区内的节点。虚拟列表仍依赖节点回收复用；骨架屏解决的是加载占位而非节点复用，因此 B、D 错误。