企业官网建设流程全解析

BBPlayer 是一款简约、好用的 BiliBili 音乐播放器，基于 React Native（Expo）构建。本文带你拆解它在 React Native 性能优化上的完整清单：FlashList 长列表虚拟化、Zustand 轻量状态管理、MMKV 同步高速存储，以及进度条动画、页面过渡、启动指标等关键技巧，帮你把 App 做得又快又流畅。

一、为什么音乐播放器特别需要性能优化？

音乐 App 的界面看似简单，实则处处是性能压力点：

• 超长列表：关注列表、歌单、播放历史动辄几千条，滑动卡顿会直接劝退用户；
• 高频更新：播放进度每秒都在变化，若每次都触发整页重渲染，掉帧不可避免；
• 冷启动体验：用户点开的 1~2 秒内，首屏必须快速可用。

BBPlayer 的应对思路可以概括为四句话：列表虚拟化、状态精准订阅、存储走原生同步、动画绕开 React 渲染。下面逐条展开。

二、长列表保持流畅：FlashList 虚拟滚动

核心技巧：只渲染屏幕上可见的条目

React Native 内置的FlatList在数据量大时容易出现内存膨胀和滑动掉帧。BBPlayer 在关键页面引入了 Shopify 开源的 FlashList（@shopify/flash-list），它通过更激进的条目回收与预渲染策略，在内存占用和滑动帧率上都有明显提升。

项目中的典型用法见关注页 following.tsx：

import { FlashList } from '@shopify/flash-list'

配合无限滚动（useInfiniteFollowings分页拉取）与 Skeleton 骨架屏，关注列表哪怕有成千上万人也能保持跟手滑动。

配套细节：过渡动画结束前不渲染列表

一个容易忽略的优化是——页面转场动画播放期间，列表不必提前渲染。BBPlayer 封装了 useScreenTransitionReady：

// 首次进入完成后保持就绪，返回已有页面不会卸载列表、丢失滚动位置

它在原生导航transitionEnd事件后才返回ready = true，把 FlashList 的首次渲染推迟到转场结束，抢回宝贵的首帧时间，同时保留滚动位置。

三、状态不炸屏：Zustand 精准订阅

核心技巧：selector 订阅，避免无关组件重渲染

BBPlayer 用 Zustand 目录下：

以 usePlayerStore.ts 为例，它监听原生播放器的onTrackStarted、onQueueChanged事件后同步状态，并用一个syncRevision版本号丢弃过期异步结果，避免竞态：

const revision = ++syncRevision if (revision !== syncRevision) return

组件侧只通过 selector 订阅自己关心的字段（如useAppStore((state) => state.hasBilibiliCookie())），某块状态变化只触发相关组件更新，而不是整棵组件树重渲染——这是 Zustand 相对传统方案的天然优势，也是"少写代码"与"跑得更快"兼得的关键。

四、启动快、读写快：MMKV 同步高速存储

核心技巧：用原生同步存储替代异步 AsyncStorage

React Native 的AsyncStorage走 JS Bridge 异步读写，启动时"先读设置再渲染"的等待会拖慢首屏。BBPlayer 使用 react-native-mmkv 中创建：

import { createMMKV } from 'react-native-mmkv' export const mmkv = createMMKV()

更妙的是，mmkv.ts 把同一个 MMKV 实例同时适配给了三个消费方：

1. Zustand persist：通过zustandStorage适配器，Store 状态（设置、皮肤等）启动时同步恢复，首帧即用；
2. Legend State 持久化：legendPersistStorage插件；
3. 业务直读：如启动 Profiling 开关storage.getBoolean('enable_startup_profiling')。

createJSONStorage(() => zustandStorage)这一行接进 useAppStore.ts 的persist中间件，就完成了"Zustand 状态 + MMKV 存储"的组合拳。

五、其他被验证有效的性能技巧 🚀

1. 进度条：用 Reanimated Worklet 绕开 React 渲染

播放进度每秒更新几十次，若用setState驱动，React 渲染管线会被拖垮。BBPlayer 在 useSmoothProgress.ts 中用useSharedValue+useFrameCallback，把进度推进放到UI 线程的 worklet中逐帧插值，仅在偏差超过 0.05 秒时才从原生侧校正——进度条丝滑到每帧都在动，而 JS 线程几乎零负担。

2. 数据库：Drizzle ORM 的 Live Query

本地歌单页面 playlist/local/[id].tsx 使用useLiveQuery（Drizzle ORM + expo-sqlite），数据库行变化时自动触发组件更新，省掉手动刷新逻辑。启动迁移则由 useFastMigrations.ts 统一管理，保证升级时不阻塞首屏。

3. 防抖搜索输入

关注页的搜索框用 useDebouncedValue 对关键词做防抖，避免每次击键都发起网络请求。

4. 启动指标：给优化一个"仪表盘"

所有优化都需要可度量的验证。BBPlayer 基于 expo-app-metrics 在 lib/performance.ts 中采集冷启动、Bundle 加载、首帧渲染与 TTI 指标，并在各首页调用markPerfInteractive()标记可交互时刻；App 内的 performance.tsx 页面把数据直接展示给用户，还支持摇一摇抓 Profiler Trace。

六、上手排查：日志工具帮你定位卡顿

优化不是玄学。排查渲染与异步问题时，BBPlayer 的 packages/logs 提供了带作用域、多 Transport（Console / Sentry / Crashlytics / 文件）的结构化日志，各模块通过log.extend('Store.App')这样的 scope 快速过滤归属：

配合 Android Studio Profiler / React DevTools Profiler，基本能覆盖"谁在重渲染、哪里慢"的大部分问题。

七、BBPlayer 性能优化速查清单

给 React Native 新手的最短路径：先上 FlashList 解决列表、再用 Zustand + MMKV 解决状态与存储、把高频 UI 动画交给 Reanimated、最后接入启动指标持续度量——BBPlayer 的这套组合拳，正是可以照搬的完整模板。