大前端通用性能优化（高频场景专项）

一、前言

1. 适用场景

本文聚焦大前端复杂页面性能优化，覆盖本地持久化存储、IM 高频数据处理、SQL 优化、内存分层优化四大核心场景，具体落地场景包括：

• 首屏加载 100 + 最近聊天会话
• 好友聊天详情（含文本、视频、地图、引用、会议卡片等复杂消息类型）
• 3000 人大型会议界面渲染
• 200QPS 高频弹幕、实时消息推送

说明：

1. 大前端定义：覆盖微信小程序、PC 端（Electron）、安卓、iOS、H5 五大端
2. 优化重点：以端上（小程序、PC、安卓、iOS）为主，H5 因缓存、磁盘、IPC 能力有限，部分优化方案不适用

2. 术语约定

为统一表述，以下将绑定页面 UI 的内存数据操作 ，统称setState，涵盖各端对应技术实现：

• 安卓：MVVM 双向绑定、MVI 单向响应、Compose State
• Flutter：State 管理
• 前端（React/Vue/ 小程序）：React State/Props、Vue Data、微信小程序 setData
• JS 状态管理库：Zustand、Redux、Mobx、Provide

3. 核心思想（重中之重）

大前端性能优化的核心，本质是 简化setState中的数据大小、削弱setState的调用频率。

补充说明：

• 该思想对简单页面影响不明显，但在高并发 QPS 数据刷新、长列表加载等复杂场景（尤其 JS 编写的页面），影响极大 ------ 处理不当会导致页面卡顿、甚至卡死（详细原因见 "渲染流程分析" 章节）。
• 本文重在传递优化思想，代码以生产级 JS 示例为主，各端可根据自身技术栈，对应实现同类优化逻辑。

二、核心优化方案（按优先级排序）

1. State 瘦身：精简数据，降低基础开销

核心目标：让setState中的数据轻量化，减少 JS Hooks、VDOM 对比、数据传输的性能损耗，从源头降低卡顿风险。

1.1 仅存储 UI 必需数据

setState中的数据直接关联 UI 渲染，数据量越大，渲染链路开销越高。

解决方案：将非 UI 相关数据，从页面绑定内存中移除，优先采用磁盘或非响应式内存存储，避免冗余数据占用setState资源。

核心原则：只有数据变化需要触发界面渲染时，才放入setState。

// 错误：混淆UI数据与非UI数据，冗余数据占用setState资源
const viewData = {
  userName: "zhangsan", // UI需展示（必要）
  id: 123, // 非UI展示（冗余）
  timestamp: 111, // 非UI展示（冗余）
  clientTime: 111, // 非UI展示（冗余）
  uuid: 111, // 非UI展示（冗余）
};
this.setData({ viewData });

// 正确：仅保留UI渲染必需数据，冗余数据存非响应式内存/磁盘
const viewData = {
  userName: "zhangsan", // 仅UI需展示的数据
};
this.setData({ viewData });
// 冗余数据存储到非响应式内存（示例）
window.messageMeta = { id: 123, timestamp: 111, clientTime: 111, uuid: 111 };

1.2 以 ID 传递数据，避免全量传输

场景：IM 会话跳转详情、列表点击查看详情等场景，若传递全量数据（尤其 IM 消息、商品详情等大数据），会导致数据传输卡顿（微信小程序中此问题尤为明显）。

解决方案：仅传递唯一标识（如conversationId、spuId），详情页面通过标识从内存 / 磁盘中获取全量数据（此类全量数据称为 "元数据"）。

核心优势：

1. 上下文传递极轻量，减少数据传输开销；
2. 数据源唯一，避免多页面数据同步不一致问题。

实际参考案例：

• SQL 查询：仅传入 ID 即可查询整条记录，无需传递全量字段；
• API 设计：查询商品详情仅传入spuId，全量数据从服务端 / 本地缓存获取；
• 影视网站元数据：片名、封面、导演等基础信息（元数据）统一存储，各页面仅传递影视 ID，避免重复传输；
• JS 规范化工具：normalizr库，将嵌套 JSON 转为扁平化结构，用 ID 关联数据，减少冗余。

// 非规范化（嵌套冗余，传递全量数据）
{
  messages: [
    {
      id: 1,
      user: { id: 1, name: 'A' }, // 嵌套用户信息，冗余
      content: 'xxx'
    }
  ]
}

// 规范化后（扁平结构，仅用ID关联）
{
  messages: { 
    byId: { 1: { id: 1, userId: 1, content: 'xxx' } }, 
    allIds: [1] 
  },
  users: { 
    byId: { 1: { id: 1, name: 'A' } }, 
    allIds: [1] 
  }
}

// 数据查询方式（简洁高效）
const message = messages.byId[1]; // 查消息
const user = users.byId[1]; // 查用户
const messageSender = users.byId[message.userId]; // 查消息发布者

2. State 降频：减少调用，降低渲染压力

JS 中每次setState调用，都会触发 Hooks 检测、Memo 对比、VDOM Diff 等一系列重操作，调用频率过高会直接导致页面卡顿。核心目标：将setState调用频率控制在合理范围，避免无效渲染。

2.1 降频、节流

根据场景使用节流（throttle） 、防抖（debounce） ，限制高频触发的setState执行频率，避免 UI 频繁刷新导致卡顿。

适用场景：页面滚动监听、搜索框输入、手势滑动、列表快速滑动、标题悬浮切换等高频事件。

安卓原生示例：页面滚动标题悬浮（节流优化）

场景：RecyclerView 滚动时，监听滚动距离动态控制标题栏悬浮效果，未节流会频繁触发 UI 刷新。

// 1. 定义节流工具类（固定时间内仅执行一次）
object ThrottleUtil {
    private const val DEFAULT_INTERVAL = 100L // 100ms 节流间隔
    private val lastTimeMap = mutableMapOf<String, Long>()

    fun doThrottle(key: String, interval: Long = DEFAULT_INTERVAL, action: () -> Unit) {
        val currentTime = System.currentTimeMillis()
        val lastTime = lastTimeMap[key] ?: 0L
        if (currentTime - lastTime >= interval) {
            action()
            lastTimeMap[key] = currentTime
        }
    }
}

// 2. RecyclerView 滚动监听（标题悬浮）
recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
    override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) {
        super.onScrolled(recyclerView, dx, dy)
        // 滚动事件节流：100ms 内只更新一次标题状态
        ThrottleUtil.doThrottle("scroll_title") {
            // 获取滚动距离，判断是否悬浮标题
            val isShowFloatTitle = recyclerView.computeVerticalScrollOffset() > 200
            // 更新UI（减少 setState/setValue 频率）
            titleViewModel.setFloatTitleVisible(isShowFloatTitle)
        }
    }
})

优化效果：

滚动事件从高频连续触发 → 100ms 仅触发一次，大幅降低 UI 刷新频率，滑动更流畅。

2.2 合并操作：减少无效调用

• 末尾合并setState：禁止连续多次调用setState，将多次更新合并为单次，减少通信与渲染开销。

// 错误：多次连续调用，触发多次渲染
this.setData({ unread: 1 });
this.setData({ latestMsg: 'xxx' });

// 正确：合并为单次调用，仅触发一次渲染
this.setData({ unread: 1, latestMsg: 'xxx' });

• 缓存池缓冲：高频数据先存入非响应式内存缓存池，定时 / 按需批量同步到setState，减少 UI 触发次数（适配 200QPS 弹幕、IM 消息等高频场景）。

class DataBufferPool<T> {
  // 单例实例，全局唯一
  private static instance: DataBufferPool<any>;
  private buffer: T[] = []; // 数据缓冲池
  private flushInterval: number = 1000; // 默认刷新间隔（1s）
  private onFlush!: (data: T[]) => void; // 批量刷新回调
  private timer: NodeJS.Timeout | null = null; // 定时刷新计时器

  // 私有化构造，禁止外部new
  private constructor() {}

  // 获取单例入口
  public static getInstance<T>(): DataBufferPool<T> {
    if (!DataBufferPool.instance) {
      DataBufferPool.instance = new DataBufferPool<T>();
    }
    return DataBufferPool.instance as DataBufferPool<T>;
  }

  // 初始化配置（全局仅调用一次）
  public init(flushInterval: number, onFlush: (data: T[]) => void) {
    this.flushInterval = flushInterval;
    this.onFlush = onFlush;
  }

  // 推入单条数据
  public push(data: T) {
    this.buffer.push(data);
    this.startTimer();
  }

  // 推入数组（适配批量消息、弹幕场景）
  public pushList(dataList: T[]) {
    this.buffer.push(...dataList);
    this.startTimer();
  }

  // 启动定时刷新（避免重复创建计时器）
  private startTimer() {
    if (this.timer) return;
    this.timer = setTimeout(() => this.flush(), this.flushInterval);
  }

  // 批量刷新数据到setState
  private flush() {
    const data = [...this.buffer];
    this.buffer = [];
    this.timer = null;
    if (data.length > 0) {
      this.onFlush(data); // 触发批量更新回调
    }
  }
}

export default DataBufferPool;

// 实际使用（适配IM消息、弹幕高频推送场景）
const buffer = DataBufferPool.getInstance<MessageItem>();
// 初始化：100ms刷新一次，批量更新消息列表
buffer.init(100, (list) => addMessageList(list));
// 高频推送时，先推入缓冲池（不直接触发setState）
buffer.push({
  ...messageItem,
  id: uuid(),
  isSelf,
  timestamp: Date.now(),
});

2.3 数据校验：无变化不更新

从 "无脑调用setState" 改为 "有门槛调用"，对比前后数据，若内容无变化，则不触发setState，避免无效渲染。

// React Class组件：通过shouldComponentUpdate校验
shouldComponentUpdate(nextProps, nextState) {
  // 仅当date变化时，才允许更新
  return this.state.date !== nextState.date;
}

// React Hook组件：通过React.memo缓存组件，浅比较props
const MemoComponent = React.memo(PicElemItem);

// 小程序/ Vue：手动对比数据，无变化不调用setData/setState
const newData = { unread: 1 };
if (this.data.unread !== newData.unread) {
  this.setData(newData);
}

2.4 局部刷新：隔离高频更新组件

将高频更新的组件（如验证码倒计时、弹幕 item、实时计数器）独立拆分，避免其更新时影响整个页面渲染，缩小渲染范围。

// Flutter示例：将倒计时组件独立拆分，不影响主干页面
child: Column(
  crossAxisAlignment: CrossAxisAlignment.center,
  children: [
    const SizedBox(height: 50),
    // 独立拆分的高频更新组件
    CircleProgressView(
      key: progressViewKey,
      callback: () {
        this.setState(() {
          loadingTitle = '取消成功';
        });
      },
    ),
    // 其他非高频更新组件
    // ...
  ],
),

2.5 适配设备刷新率：避免刷新溢出

高频刷新场景（如弹幕、实时图表），需适配设备刷新率，避免刷新频率超过设备承载上限，导致主线程阻塞。

• 分帧渲染：使用requestAnimationFrame，按浏览器 / 设备刷新率（通常 60fps）分批渲染，确保每帧渲染时间控制在 16ms 内；
• 频率限制：设备刷新率为 60Hz 时，setState调用频率不应超过 60QPS，避免无效刷新。

2.6 组件 / DOM 复用：减少销毁重建开销

避免频繁销毁、重建组件 / DOM，通过复用机制降低性能损耗：

• 安卓：TabBar+ViewPager 缓存 Fragment，避免切换时重复创建；
• 前端 / 小程序：使用hidden、display:none、v-show替代v-if/wx:if，保留 DOM 节点，仅控制显示 / 隐藏；
• Flutter：TabBarView 缓存页面，减少页面切换时的重建开销。

// Flutter示例：TabBarView缓存页面组件
body: TabBarView(controller: _tabController, children: _tabChildren()));

2.7 计算记忆化：缓存计算结果

内存读写速度远快于磁盘 / IPC 通信，对于高频调用的计算逻辑、数据查询，可通过内存缓存结果，减少重复计算开销。

// 示例：缓存IM Token，减少跨进程通信次数
let token = getUserInfo().token || imTokenCache;
if (!token) {
  // memoryStore.get(IM_TOKEN)为跨进程通信，开销较大
  imTokenCache = memoryStore.get(IM_TOKEN) || "";
  token = imTokenCache;
}

3. 数据存储分层：按优先级存放，降低核心链路压力

核心思想：按 "存储速度从慢到快、性能开销从高到低" 分层存放数据，将高频数据、核心数据放在高效存储层，减少磁盘 IO、渲染链路的压力。

3.1 各层级存储特点（核心表格）

存储层级	存储位置	持久化	速度	适合数据量	高频 push 是否卡顿	形象理解
磁盘	硬盘、文件	是	极慢	极大（10w+）	非常卡	仓库
无状态内存	内存	否	极快	中（百条级）	不卡	工作台
State 内存	内存 + 渲染	否	慢	极小（十条级）	非常卡	手里正在用的

各层级具体说明：

• 磁盘：包括 SQLite、文件系统、SharePreference 等，适合存储历史聊天记录、附件、老消息等无需实时展示、数据量极大的内容，特点是持久化、容量大，但读写慢，高频操作易卡顿；
• 无状态内存：包括全局内存缓存、页面内存，存储非响应式数据（如最近 200 条聊天消息），读写速度极快（<0.01ms），200QPS 高频 push 无压力，缺点是断电丢失；
• State 内存：绑定 UI 的响应式内存，仅存储当前屏幕可见的 10~20 条数据，核心作用是触发 UI 刷新，数据量越大、更新越频繁，卡顿越明显。

3.2 分层目的

核心目标：不让高频数据直接进 "仓库"（磁盘），也不直接拿在 "手里"（State 内存），先放在 "工作台"（无状态内存） ，具体原因：

1. 直接读磁盘：磁盘 IO + 序列化开销大，高频操作会导致主线程卡顿；
2. 直接放 State 内存：会触发频繁渲染、VDOM Diff，高频更新会直接卡死页面。

3.3 分层存储顺序（必遵循）

数据存放优先级（从低开销到高开销，从慢到快）：

磁盘 → 无状态内存（本地缓存） → 页面内存 → 全局状态 → 视图绑定（State 内存）

4. 计算与渲染分离：开启子线程，避免主线程阻塞

核心思想：将复杂计算、耗时操作移到子线程，避免占用主线程（渲染线程）资源，确保 UI 渲染流畅。

• 原生 App（安卓 /iOS）：开启子线程（Thread）、协程（Coroutine），处理数据解析、排序、加密等耗时操作；
• Electron / 前端：将复杂计算（如消息解析、弹幕排序、大数据筛选）移到 WebWorker、NodeJS 主进程，不阻塞渲染进程；
• 补充：子线程仅处理计算逻辑，不直接操作 UI，计算完成后通过回调将结果同步到主线程，再触发setState。

5. 序列化 / 反序列化优化（JS 专项）

JS 中 JSON 序列化 / 反序列化开销较大，尤其高频场景下，会导致内存频繁分配、GC 压力激增，需重点优化（其他语言如 Java、Kotlin 序列化开销极小，可忽略）。

核心原因：

1. JS 对象本质是散列表，结构不固定，序列化时需动态解析；
2. JSON.stringify本质是拼接字符串，而 JS 字符串不可变，每次拼接都会生成新字符串，高频调用会导致内存暴涨、GC 频繁。

优化方案：

• 避免高频场景下的 JSON 序列化 / 反序列化，优先使用Buffer/ArrayBuffer传输二进制数据；
• 全局统一序列化，避免组件内部频繁调用；
• 缓存序列化结果，减少重复解析开销。

// 示例：缓存序列化结果，减少重复解析
const metadataCache: Record<string, any> = {}; // 纯对象缓存，读取速度快于Map
export const getMetadata = (participant: Participant) => {
  const metadata = participant?.metadata ?? "";
  if (!metadata) return {};
  // 命中缓存，直接返回，避免重复解析
  const cached = metadataCache[metadata];
  if (cached) return cached;
  // 未命中缓存，解析后存入缓存
  const result = tryParse(metadata) || {};
  metadataCache[metadata] = result;
  return result;
};

说明：内存读写极快，对于小体积数据，缓存几万条序列化结果的内存波动可忽略，但能显著降低 JS 序列化的性能开销。

6. 避免异常路径：减少高频场景下的异常开销

try/catch在高频场景下（如 200QPS 消息推送），若频繁进入catch分支，会产生极大的性能损耗，甚至导致卡顿。

优化方案：

• 前置判空、参数校验，避免异常触发，减少catch执行次数；
• 若高频场景下频繁走到catch，需排查逻辑设计问题（如数据格式不规范、接口返回异常），而非单纯依赖try/catch兜底。

7. 渲染优先级：优先使用原生能力，降低渲染开销

核心结论：渲染页面的 CPU 算力消耗，远大于跨进程通信开销，复杂渲染、重型任务优先交给原生层处理，提升性能。

7.1 各层级算力对比（从高到低）

C/C++ 层、Linux 系统调用层 > 原生框架层（安卓 /iOS） > JS 页面层

各层级特点：

• JS 层：重、耗 CPU、易阻塞，VDOM Diff、Hooks 检测等操作开销大；
• 桥通信：追求轻量、快速，适合传输指令、ID、简单字符串、小 JSON；
• 原生层：适合处理复杂列表、地图、相机、音视频、动画等重型任务（Electron 中对应 C++ 层）；
• C/C++/ 系统调用层：极快、硬件级效率，无 GC，适合处理哈希计算、视频转码等底层任务。

7.2 实际落地示例

• Electron：哈希计算、视频转码、大数据处理，交给 C++ 层或 NodeJS 主进程；
• RN/Uniapp：地图、声纹图、Camera 流数据处理，调用原生组件，避免 JS 层渲染；
• 安卓 /iOS：复杂列表（如 3000 人会议列表），使用原生 RecyclerView/UICollectionView，避免跨端框架渲染。

8. 定时器优化：避免多定时器阻塞主线程

场景：电商页面多商品倒计时、多弹幕定时器、多组件定时刷新等，若每个组件单独创建定时器，会导致主线程阻塞（JS 页面尤为明显）。

解决方案：使用全局统一时钟，批量管理所有定时任务，减少定时器数量。

import _ from "underscore";

// 定时任务模型
class FilterItem {
  constructor(key, callback, timeout) {
    this.key = key; // 任务唯一标识
    this.callback = callback; // 任务回调
    this.timeout = timeout; // 倒计时时间（可选）
    this.once = !!timeout; // 是否为一次性倒计时任务
  }
}

// 全局定时器工具（单例）
class TimerUtils {
  constructor() {
    this.interval = null; // 全局唯一定时器
    this.intervalList = {}; // 定时任务列表
  }

  // 添加定时任务（倒计时/循环任务）
  addTimeCountDown(key, callback, timeout) {
    this.intervalList[key] = new FilterItem(key, callback, timeout);
    this._registerTimer(); // 注册全局定时器
  }

  // 移除定时任务
  removeTimeCountDown(key) {
    delete this.intervalList[key];
  }

  // 注册全局定时器（避免重复创建）
  _registerTimer() {
    if (this.interval) return;
    // 1秒执行一次，批量处理所有定时任务
    this.interval = setInterval(() => {
      const filters = _.values(this.intervalList);
      // 无任务时，销毁定时器，释放资源
      if (filters.length === 0) {
        clearInterval(this.interval);
        this.interval = null;
        return;
      }
      // 批量执行所有任务
      _.map(filters, (filter) => {
        if (filter.once) {
          // 一次性倒计时任务
          filter.timeout--;
          if (filter.timeout === 0) {
            this.removeTimeCountDown(filter.key);
            filter.callback();
          }
        } else {
          // 循环任务
          filter.callback();
        }
      });
    }, 1000);
  }
}

// 全局单例导出
const timerUtils = new TimerUtils();
export default timerUtils;

// 实际使用（多商品倒计时场景）
// 商品1倒计时
timerUtils.addTimeCountDown('goods1', () => {
  // 刷新商品1倒计时UI
});
// 商品2倒计时
timerUtils.addTimeCountDown('goods2', () => {
  // 刷新商品2倒计时UI
});
// 无需时移除任务
timerUtils.removeTimeCountDown('goods1');

9. IPC 性能优化：共享内存，突破通信瓶颈

IPC（跨进程通信）本身性能有限，高频、大数据量通信（如 200QPS 消息推送、实时流数据）会导致通信卡顿，核心优化方案：共享内存，实现零拷贝通信。

9.1 通信方式对比（核心表格）

通信方式	数据流向	拷贝次数	内存占用	延迟	适用场景
普通postMessage	序列化 → 拷贝 → 反序列化	≥2 次	2× 数据量	毫秒级	小数据、低频通信
NAPI Buffer 共享	传递内存引用	0 次（零拷贝）	1× 数据量	微秒级	高频、大数据、实时流

9.2 安卓与 ElectronIPC 能力对比

场景	安卓	Electron	核心特点
普通轻量通信	Bundle / Intent	ipcRenderer / postMessage	拷贝数据，小数据传输快
高频大数据	Ashmem/SharedMemory	NAPI + Buffer 共享	零拷贝，不阻塞 UI
调用底层能力	JNI	NAPI	桥接 JS 与原生层
后台计算	子线程	WebWorker / 子进程	不阻塞主线程

三、渲染流程深度分析（为什么 JS 页面更易卡顿？）

以 "列表dataList新增一条数据，触发界面刷新" 为例，对比原生 App 与 JS 页面的渲染流程差异，明确卡顿根源。

1. 原生 App（安卓 /iOS/Flutter）渲染流程

// 原生App示例（安卓）
dataList.push(newItem); // 数据原地修改，内存地址不变
adapter.notifyItemInserted(dataList.size - 1); // 精准通知单个item刷新

核心特点：

• 数据原地修改，内存地址不变，无需生成新对象；
• UI 精准点对点更新，仅刷新新增的 item，不影响其他组件；
• 无 VDOM Diff、无 Hooks 检测、无依赖遍历，仅执行控件自身的onDraw方法；
• 哪怕是TextView.setText("Hello World")（内容不变），系统也会通过equals判断，内容相同则直接返回，不执行绘制，开销可忽略不计；
• 整体属于轻量级更新，高频更新无压力。

2. JS 页面（React/Vue/ 小程序）渲染流程

// JS页面示例（React/小程序）
dataList.push(newItem); // 数据修改（若为不可变更新，需生成新数组）
this.setState({ dataList }); // 触发渲染

核心特点：

• JS 框架（React/Vue）强制要求数据不可变，更新时必须生成新对象 / 新数组（内存地址改变）；
• 无论修改多少数据，都会触发完整渲染链路：组件函数执行 → 生成新 VNode → VDOM Diff → Memo 对比 → useEffect 检测 → 真实 DOM 操作 → 浏览器样式计算 / 布局 / 绘制；
• 哪怕只修改一条数据，也需要生成新的数组 / 对象，触发整套链路，前置开销远大于真实 DOM 操作；
• 高频更新时，大量新对象会导致 JS GC 频繁，进一步阻塞主线程。

3. 核心差异总结

对比维度	原生 App	JS 页面（React/Vue/ 小程序）
数据更新方式	原地修改，地址不变	不可变更新，地址必变
渲染范围	控件级点对点刷新	组件级 + VDOM 全量对比
核心开销	极小（仅控件绘制）	极大（链路长、GC 频繁）
高频适配性	强（轻松支撑百级 QPS）	弱（十级 QPS 即卡顿）

结论：JS 页面性能脆弱，核心原因是不可变数据要求 + 冗长的渲染链路；但通过本文的优化方案（瘦身、降频、分层等），可大幅提升性能，实现接近原生 App 的体验，同时保留 JS 快速开发、热更新的优势。

四、QPS 阈值参考（工程级落地标准）

QPS（Queries Per Second）：此处特指 1 秒内setState数据更新到状态库（如 Zustand、Redux、ViewModel）的次数，是判断页面是否卡顿的核心指标。

1. 卡顿阈值速览表（核心参考）

1.1 JS 页面（React/Vue/ 小程序 / Electron）

场景	Electron PC（i9/M2）	移动端（中高端）	体感反馈
不绑定 UI（纯状态更新）	300--400 QPS	150--250 QPS	轻微卡顿 → 明显卡顿
绑定 UI（触发组件渲染）	30--50 QPS	15--30 QPS	明显卡顿 → 页面卡死

实测补充：MacBook Pro i9 + Electron 环境下，Zustand 不绑定 UI，200QPS 已出现轻微卡顿，核心原因：

• Zustand 内部需执行发布订阅、浅比较操作；
• 高频set会产生大量临时对象，导致 JS GC 频繁，占用 CPU 资源。

1.2 原生 App 页面（安卓 MVVM/MVI）

平台架构	不绑 UI 卡顿 QPS	绑 UI 卡顿 QPS	适用设备
安卓 MVVM	2000～5000	150～500	中 / 高端手机
安卓 MVI	1500～4000	120～400	中 / 高端手机
安卓低端机（4 年以上）MVVM	1000～2000	80～120	低端手机
安卓低端机（4 年以上）MVI	800～1500	60～100	低端手机

2. 性能差距核心原因

安卓原生比 JS 页面强 5～10 倍性能，核心差异的：

1. 无 JS 引擎开销，JVM GC 效率远高于 JS GC；
2. 无 VDOM Diff、无 Hooks 检测，渲染链路极短；
3. 无大量闭包、浅比较、记忆化操作，数据流更轻；
4. 不可变更新成本极低（结构共享、增量拷贝，而非全量拷贝）。

补充：前后端不可变更新成本对比

平台	不可变更新核心流程	整体成本
JS 页面	浅拷贝数组 → 发布订阅遍历 → 组件重渲染 → VDOM Diff → GC 清扫	极高
安卓原生	结构共享生成新列表 → StateFlow 发射 → 控件局部刷新	极低

3. 工程级安全线（直接落地参考）

为避免页面卡顿，建议将setState调用频率控制在以下安全范围内：

平台架构	不绑 UI 安全 QPS	绑 UI 安全 QPS	聊天列表场景安全 QPS
Web / Electron (Zustand/Redux)	<200	<20	<5
安卓 MVVM	<1000	<100	<50