企业官网建设流程全解析

最近在给一个跑在OpenHarmony上的React Native跨平台项目做性能优化，最头疼的不是启动速度，而是页面滚着滚着就卡住。长列表、媒体卡片、播放状态联动，这些问题在普通RN环境里也就是掉几帧，但一上OpenHarmony这套技术栈，任何一次多余的渲染和副作用重放都会被放大成肉眼可见的卡顿。排查到最后，锅几乎都指向同一个地方：useEffect的依赖数组写得太随意了。所以这篇就专门聊聊在OpenHarmony上用React Native时，怎么把useEffect依赖数组优化到既不丢更新、又不额外烧性能。文中不会有太多玄学，全是能直接照做的写法、排查顺序和踩坑记录。

1. 为什么在OpenHarmony上跑RN，依赖数组的毛病会被放大

1.1 从列表掉帧这个典型症状说起

我手头这个模拟项目X，页面结构是典型的FlatList加媒体卡片。每张卡片要拉取元数据、上报播放状态、还要响应父组件的选中态变化。一开始掉帧时，我习惯性地以为是renderItem里的组件没加React.memo，或者图片缓存策略不对。结果把这两样都优化了一遍，滚动时依然一顿一顿的。

后来我在每个卡片组件的useEffect开头加了一行日志，滚动一屏发现日志刷了十几条。这说明滚动过程中大量组件在反复执行副作用，而真正需要响应的业务状态根本没有变化。再往下看，问题出在依赖数组里塞了整个props对象和函数引用。比如某个effect依赖的是[item, activeItem]，而activeItem每次切换都会创建一个新对象引用，所有卡片哪怕不相关，也得跟着重新跑一遍effect。

这个现象在普通RN环境里往往不致命，因为副作用本身可能就是几次状态更新，被React批量处理掉了。但在OpenHarmony的适配链路上，JS线程的每一次副作用触发都可能引发跨语言层的调用，最终落到系统原生组件上，频率一高，卡顿立刻显现。

1.2 副作用重放的真实成本：不只是JS那段代码

很多同行对useEffect的理解还停留在“渲染之后执行一段代码”。这句话没错，但在性能优化场景里，我们要看的是完整链路：组件render -> React提交变更 -> effect执行 -> 如果effect里有setState，再引发一轮render -> 再提交 -> 再执行其他effect。

也就是说，每多一次多余的effect重放，不只是多执行几行JS，而是多走了一整轮“提交-更新-再提交”的循环。如果在effect里还做了网络请求、读写AsyncStorage、调用原生模块，那成本就更明显了。OpenHarmony环境下，RN运行时和系统UI层之间往往不是同进程直接共享内存，而是通过适配层做数据交换，提交次数越多，跨层调用就越频繁。

我用一个不严谨但很直观的类比：普通RN环境里，一次多余的effect重放好比多按了一下电梯按钮，最多等一趟；在OpenHarmony上，等于每次都要从一楼爬到顶楼再下来，按十次就明显体感不对劲了。依赖数组优化的本质，就是减少这种无意义的爬楼次数。

1.3 同样一段代码，标准RN环境和OpenHarmony环境的差异

我在模拟项目X里专门做过一组对照，把同一个存在依赖数组问题的组件分别跑在标准RN环境和OpenHarmony环境里，结果差异非常典型。

并不是说OpenHarmony本身性能差，而是RN在这套系统上的运行路径比标准移动平台更长，中间每一层的成本都更贵。依赖数组稍微写得宽一点，浪费就会被指数级放大。所以，在OpenHarmony上做RN开发，useEffect依赖数组优化不是锦上添花，而是直接影响页面能不能流畅跑起来的关键步骤。

2. 依赖数组优化的切入顺序：先认清误区，再动手

2.1 误区一：依赖数组“多写总比少写安全”

我在不少项目里见过这种写法：一个useEffect里要用到七八个值，于是把所有涉及的变量全都塞进依赖数组，生怕漏掉哪个导致不更新。这个出发点可以理解，但忽略了一个关键机制：React比较依赖项时用的是Object.is，也就是引用比较，不是深比较。

只要某个依赖项是对象、数组、函数，并且每次渲染都会创建新引用，那么即使业务数据完全没变，React也会认为依赖变了，effect照样重跑。典型的反例是这样：

// 反例：user 是每次渲染都会新建的对象 const user = getUser(id); useEffect(() => { fetchProfile(user.id); }, [user]); // user 引用每次都变，effect 每次都跑

如果user.id是个字符串，依赖数组写成[user.id]就足够了。对象本身没有变，变的是外面的引用壳子。依赖数组要的是“业务上的变化信号”，不是“引用的变化信号”。

这个误区在OpenHarmony列表页里特别致命，因为列表项动辄上百个，每个组件都因为引用壳子变了而重跑effect，叠加起来就是灾难。

2.2 误区二：见一个函数就包一个useCallback

另一类极端是把所有函数都包上useCallback，以为这样就能解决依赖数组不稳定问题。实际上，过度包裹反而会引入新的问题：useCallback本身有自己的依赖项，如果写不准，函数里读到的永远是旧值，而且还会破坏子组件的memo化判断。

我用一个简单的判断标准来区分该不该包useCallback：这个函数要不要作为prop传给子组件，或者要不要放进某个useEffect的依赖数组？如果都不用，那就没有必要包。函数创建本身成本很低，真正贵的是函数引用不稳定之后引发的副作用重放和子树重渲。

// 只有这个函数会作为依赖项时，才需要稳定引用 const loadMeta = useCallback(async (id) => { const data = await fetchMeta(id); setMeta(data); }, []);

如果这个函数只在effect内部使用，完全可以直接定义在effect里，根本不用管引用稳定性。

2.3 我常用的四步排查法

遇到依赖数组导致的性能问题，我不会上来就改代码，而是按一套固定流程排查，效率很高。

第一步，在useEffect开头加一行日志：console.log('effect-run', dep1, dep2)。然后做一次固定的用户操作，比如滚动20个列表项，统计每个effect跑了多少次。这一步能把“哪些依赖导致了重跑”暴露出来。

第二步，删掉所有“能用基本类型字段替代”的复杂依赖。凡是在effect里只用到obj.id的地方，就把obj整体替换成id本身。这个动作通常能砍掉80%的多余重放。

第三步，检查effect内部引用的外部函数。如果这个函数不是用useCallback包过的，并且确实需要放进依赖数组，那就补一个useCallback，同时确保useCallback的内部依赖也尽量窄。

第四步，用性能工具看JS线程和UI线程的占用率对比。优化前跑一个高负载操作，优化后再跑一次，记录CPU占用和帧率变化。这一步是为了确认优化确实有效，而不是靠感觉说“好像没那么卡了”。

3. 手把手优化一个列表页：从复现到验证

3.1 原始代码：一个“包含一切”的依赖数组

我在模拟项目X里抽了一段很有代表性的代码，结构大概是这样的：

function MediaCard({ item, list, onPlay, playState }) { const [meta, setMeta] = useState({}); useEffect(() => { loadMeta(list, item).then(setMeta); }, [item, list, onPlay, playState]); // 其他渲染逻辑 }

这段代码的业务意图很简单：当item变化时重新加载元数据。但依赖数组里塞了四个值，其中list是数组，onPlay是函数，playState是对象。每次父组件因为滚动位置、播放状态变化而重渲时，这四个里面至少有两三个引用会变，于是每个卡片都在重跑loadMeta。

我在真机上复现时，滚动一屏大约有20个卡片可见，每个卡片每秒可能重跑两三次effect，瞬间就有五六十次网络请求或者本地缓存读取，UI线程被拖住是完全正常的。

3.2 改造动作：解构字段、拆分副作用、稳定回调

优化不是把依赖数组清空，而是让它变得精确。我拆三步来做。

第一步，把复杂对象依赖换成基本类型字段。这个effect真正关心的是item.listId和list.pageLimit，其他都不需要：

const { listId } = item; const pageLimit = list?.pageLimit ?? 20; useEffect(() => { loadMeta(listId, pageLimit).then(setMeta); }, [listId, pageLimit]);

第二步，把没关系的副作用拆开。playState是控制播放高亮的，和加载元数据完全是两件事。硬放在一个effect里，会导致播放状态一变，元数据也跟着重新加载。拆开后，各自只在需要时触发：

useEffect(() => { loadMeta(listId, pageLimit).then(setMeta); }, [listId, pageLimit]); useEffect(() => { reportPlayState(item.id, playState); }, [item.id, playState.isActive]);

第三步，处理onPlay。这个函数在父组件里没有用useCallback包裹，每次父组件重渲都生成新引用。如果它不出现在任何effect的依赖数组里，那就好办；但这里卡片组件需要点击时调用，作为prop传进来，为了保持引用稳定，我在父组件里包了一层useCallback：

const handlePlay = useCallback((mediaId) => { startPlay(mediaId); }, []);

这样MediaCard收到的onPlay引用是稳定的，不会因为父组件重渲而改变，哪怕偶尔出现在依赖数组里也不会引起多余触发。

3.3 如何确认优化有效：测量方法而不是靠感觉

代码改完后，我没有直接提交，而是用之前提到的日志法重新测了一遍。优化前滚动20个卡片，日志打印了大概120次；优化后同一操作，日志只打印了20次左右，每个卡片只在真正需要响应时才跑一次effect。

顺带记录了一下JS线程的CPU占用。同一个中低端测试机上，优化前滚动时的JS线程占用一度到35%，优化后稳定在8%上下，帧率也从偶尔掉到30帧以下变得基本稳定在55帧以上。这个数据不算严谨，但足够说明问题。

还要提醒一句：优化依赖数组后，一定要重新验证业务逻辑完整性。有一次我把依赖项改成[item.id]，结果某个场景下发live状态变化时需要重新拉元数据，被我一刀切掉了，导致页面信息不更新。所以每次改完依赖，都要主动构造“依赖项其实没变但业务上需要重跑”的场景去测试，而不仅仅是看日志数量变少了。

4. 三个高频场景的依赖数组写法，可直接抄

4.1 事件监听：注册与注销要当场实现

RN在OpenHarmony上经常要监听系统级事件，比如网络状态、App前后台切换、某个原生模块的数据推送。这类场景的正确写法是独立useEffect，空依赖数组加清理函数：

useEffect(() => { const subscription = networkStatusModule.addListener((status) => { setNetworkStatus(status); }); return () => { subscription.remove(); }; }, []);

监听回调里如果要用到最新的props或state，不要把它们塞进依赖数组，否则每次变化都会退订再重订。更好的做法是用ref保存最新值：

const statusRef = useRef(currentStatus); statusRef.current = currentStatus; useEffect(() => { const subscription = networkStatusModule.addListener((status) => { // 这里读 statusRef.current 就能拿到最新值 handleStatusChange(status); }); return () => subscription.remove(); }, []);

这样既保持了监听只注册一次，又在回调里能拿到最新数据。OpenHarmony上有些原生事件注册本身开销不小，反复注册注销是很浪费的。

4.2 远端数据加载：避免依赖对象解构后又重新请求

另一个高频场景是根据路由参数或上下文对象拉取远端数据。常见反例是把整个对象放进依赖数组：

// 反例：route.params 引用变化就会重新请求 const { id, page } = route.params; useEffect(() => { fetchList({ id, page }); }, [route.params]);

route.params只要被任何代码重新赋值，引用就会变，哪怕id和page完全没变，也会触发重新请求。改成：

// 正例：只依赖真正参与请求的基本类型 const { id, page } = route.params; useEffect(() => { fetchList({ id, page }); }, [id, page]);

这里有个坑：如果id和page本身是对象里的嵌套字段，解构之后也可能得到新引用。稳妥的做法是先解构到基本类型，再放到依赖数组里。比如const pageNum = Number(page)，确保依赖数组里存的是纯数值。

4.3 滚动联动/多个状态互相触发：用ref绕开活锁

在OpenHarmony的RN页面里，我遇到过滚动位置和激活项互相更新的情况。页面逻辑是：滚动到某个位置时高亮对应卡片，点击卡片时又要把该卡片滚到中间。这两个状态很容易写成互相触发的活锁。

如果直接在useEffect里相互setState，依赖数组里又各包含对方状态，就会出现无限循环或者高频抖动。我的做法是把“跟随滚动”这个低优先级的状态从useEffect里拆出来，只在滚动回调里更新ref，让高亮组件在渲染时读取ref：

const activeIndexRef = useRef(0); const onScroll = (e) => { const index = computeActiveIndex(e.nativeEvent.contentOffset.y); activeIndexRef.current = index; setNeedHighlight(true); }; useEffect(() => { if (!needHighlight) return; setHighlightIndex(activeIndexRef.current); setNeedHighlight(false); }, [needHighlight]);

这样useEffect只依赖一个布尔值needHighlight，触发路径变得单一，不会因为highlightIndex和scrollY互相依赖而形成循环。OpenHarmony上这类联动场景特别容易把调试器卡死，我建议遇到任何“两个状态互相影响”的逻辑，都优先考虑用ref承载其中一个方向的数据流。

5. OpenHarmony环境特有的注意点与自检清单

5.1 两个容易踩的坑：任务时序差异与低端设备表现

第一个坑是副作用执行时机不稳定。在标准RN环境里，useEffect通常是在提交完成后同步执行的，但OpenHarmony的适配层可能对某些任务做异步调度或合并，同一个页面在不同时机进入时，effect的执行顺序可能出现差异。我在某个页面里发现，页面刚加载时，一个依赖原生模块数据的effect会拿到undefined，过几百毫秒再进入才正常。

解决办法是在effect内部做空值保护，同时不要把“页面是否就绪”这件事情交给effect执行顺序去猜。核心数据如果没有准备好，宁可先渲染骨架屏，也不要让effect带着undefined往下跑。

第二个坑来自低端设备。不同OpenHarmony设备的性能差异很大，有些低端机型CPU主频不高，JS线程和UI线程资源争抢严重。一个看起来只要跑一次的effect，乘以100个列表项之后，就可能把整机拖垮。因此在优化依赖数组时，不能只盯着“日志打印次数”，还要多看“最小状态下能不能满足业务需求”。能空依赖数组运行的就别引入依赖，能依赖基本类型的就别依赖对象，这是我在低端设备上摸出来的硬道理。

5.2 自检清单：写完每个useEffect后过一遍

为了不让后续开发再踩坑，我把这套经验沉淀成了一份简短的自检清单，每次写完一个useEffect就过一遍。

• 依赖数组里的每一项，真的是“值变了就必须重跑”的吗？如果有一个值只在effect内部用到，却不在依赖数组里，那就说明effect可能读取了旧值；如果依赖里放了多个引用类型，说明很可能存在无意义重放。
• 依赖项里有没有对象、数组、函数？如果effect内部只使用它们的具体字段，就先把字段解构到基本类型再放依赖。
• effect内部调用外部函数的情况下，这个函数的引用是否稳定？不稳定的话，是包useCallback，还是直接把函数定义挪进effect内部？
• 有没有出现“effect里setState，state又出现在依赖数组”的情况？如果有，要么拆分effect，要么用ref绕开。
• 依赖数组为空或者依赖项很少时，清理函数是否把应该解绑的资源都解绑了？事件监听、定时器、订阅这些，漏掉一个就是内存泄漏。
• 在OpenHarmony真机上，是不是能观察到符合预期的触发次数？如果同一交互下日志数量翻倍，通常说明依赖数组里的某个引用又不稳定了。

我每次给团队评审代码时都会拿着这份清单过一遍，哪怕逻辑完全正确的useEffect，也能顺手找出几处可以收紧依赖的地方。

最后再分享一个实际体会：依赖数组优化这件事，九成靠的不是技巧，而是愿不愿意把一个useEffect的触发条件真正想清楚。尤其在OpenHarmony这条技术路线上，多一次副作用重放，代价都比想象中大。你如果现在也卡在类似的项目里，别急着引入状态管理库，也别全面重写渲染层，先把每个useEffect的开头打一行日志跑一遍，看看到底谁在被反复触发。把日志数量打下来，页面一般就顺了。依赖数组写得越窄，你脑子里的状态模型就越清楚，这句话在哪个平台上都成立，在OpenHarmony上尤其成立。