1. 在鸿蒙适配版 RN 里跨组件通信为什么先想到 useContext1.1 它不是把状态“广播”出去而是让状态沿着组件树流动如果你接手过一个从普通 React Native 工程迁到鸿蒙适配版 RN 的仓库大概率会和我有同感编译问题其实不难解决真正磨人的是运行时的状态表现。跨组件通信在教程里往往被压缩成“父传子、子传父、全局状态”三句话可真放到鸿蒙设备上跑业务你会发现useContext的价值被严重低估了。鸿蒙适配版 RN 保留了 JS 侧的 React 组件树同时把视图映射到系统侧的原生组件。也就是说组件与组件之间的状态共享仍然发生在 React 这一层。除非你去接系统级的事件总线、共享存储或者全局单例否则最常见、最可控的跨组件通信手段就是useContext。很多人容易把useContext理解成“把数据广播给所有人”这是不对的。它更准确的描述是数据沿着组件树从Provider往下流动只有真正调用useContext的组件才会订阅这份数据。中间没有调用useContext的组件即使嵌在Provider里面也不会因为 context 变化而主动重绘。这一点在鸿蒙适配场景里尤其重要因为一次多余的 JS 重渲染最终可能转换成多一条原生 view 更新指令积少成多就是肉眼可见的卡顿。1.2 什么场景用 Context什么场景立刻刹车在鸿蒙版 RN 项目里useContext适合处理低频但又是全局必需的“骨架状态”登录态、用户基础信息、会话 token语言、主题、字体缩放等展示类配置功能开关、灰度配置首页 Tab、购物车角标这类跨页面共享但更新频率不高的数据不适合的场景也很明确传感器数据、下载进度、播放进度、实时打点这类高频更新某个超大列表内部每个 cell 的局部选中态跨多个独立原生页面容器共享状态且容器之间没有共同 React 父组件判断的方法很朴素你问自己“这个状态一分钟内最多变化几次”。如果每秒几十次优先考虑把数据放在useRef或者外部 Store 里通过节流、防抖再进入 context。如果只是用户登录后设置一次、切主题时变更一次那就非常适合放进 context。2. 搭建 Context 仓库的第一件事决定 Provider 挂在哪2.1 一个够用的 GlobalContext 文件长什么样很多项目习惯把所有状态塞进一个AppContext.tsx起步确实快但后续维护会越来越难受。我建议从一开始就按领域拆成多个 context 文件每个文件自成一套 Provider 和自定义 Hook。下面是一个最小可用的代码骨架你可以直接抄到鸿蒙版 RN 工程里import React, { createContext, useContext, useMemo, useState } from react; interface UserInfo { id: string; nickname: string; token?: string; } interface GlobalState { userInfo: UserInfo | null; theme: light | dark; updateUser: (user: UserInfo | null) void; updateTheme: (theme: light | dark) void; } const GlobalContext createContextGlobalState | null(null); export function GlobalProvider({ children }: { children: React.ReactNode }) { const [userInfo, setUserInfo] useStateUserInfo | null(null); const [theme, setTheme] useStatelight | dark(light); const value useMemoGlobalState( () ({ userInfo, theme, updateUser: setUserInfo, updateTheme: setTheme, }), [userInfo, theme] ); return GlobalContext.Provider value{value}{children}/GlobalContext.Provider; } export function useGlobalContext() { const ctx useContext(GlobalContext); if (!ctx) { throw new Error(useGlobalContext 必须在 GlobalProvider 内部使用); } return ctx; }几个细节说下。createContext的初始值我直接传了null而不是给一个假对象。这样useGlobalContext可以做非空判断组件一旦被放到 Provider 外面立刻抛错避免“看起来没报错实际拿到的全是默认值”这种隐藏故障。updateUser和updateTheme我直接暴露了setUserInfo和setTheme。useState返回的 setter 本身是稳定的不会因为组件重新渲染而改变。这比写一个内联箭头函数再包一层useCallback干净得多。value用useMemo包裹只有当userInfo或theme真正变化时才生成新对象。这一步不是性能洁癖是后面所有重绘优化能不能生效的前提。2.2 Provider 放在根组件还是页面入口答案会直接影响状态生命周期同一个Provider放在根组件和放在页面入口行为完全不同。放在根组件比如这样function App() { return ( GlobalProvider MainNavigator / /GlobalProvider ); }那么整个导航栈里的页面都共享同一份状态。页面 A 更新了用户信息页面 B、C 在返回或切换时都能拿到最新值。如果放到某个页面内部比如function ProfileScreen() { return ( GlobalProvider ProfileDetail / /GlobalProvider ); }那么这份状态会随页面卸载而彻底消失。页面切走Provider 销毁状态归零。对于登录态这种必须全局存在的状态这是灾难。我的建议是全局跨页面状态一律放根组件只有页面内部、多个局部组件之间需要共享的状态才放页面级 Provider。后一种做法还能顺便控制状态的作用域避免页面 A 的局部状态污染页面 B。2.3 把领域状态拆成多个 Provider而不是一个大而全的 GlobalContext很多人会问我是不是应该把所有东西都放进一个GlobalProvider省得再建文件我的经验是不要。一个 Provider 管理登录态、主题、购物车、网络状态、消息未读数……听起来很方便但任何一个字段变化都会让所有消费这个 context 的组件重新执行。哪怕你的消费者里只有一个组件订阅了网络状态其他消费用户信息的组件也会被“连带重绘”。拆成多个 Provider 的收益从第一天起就能体现出来function App() { return ( AuthProvider ThemeProvider CartProvider{/* 页面栈 */}/CartProvider /ThemeProvider /AuthProvider ); }这样AuthProvider更新时只有依赖用户信息的组件重绘CartProvider更新时主题相关的组件不会跟着遭殃。Provider 之间如果需要互相读取可以在嵌套关系中自然拿到外层 context因为内层的 Provider 组件本身也处在 React 组件树上。我见过一个比较顺手的组织方式每个工程目录下建一个contexts文件夹里面按领域命名如AuthContext.tsx、ThemeContext.tsx、CartContext.tsx。每个文件只做三件事定义类型、创建 context、导出 Provider 和自定义 Hook。不塞业务逻辑逻辑留在页面和调用方。3. useContext 链路里真正被低估的部分value 引用与重渲染3.1 从 setState 到消费者组件重新执行的完整路径如果用一句话解释useContext的工作过程那就是setState让 Provider 所在组件重新渲染生成新的 context valueReact 拿这个新 value 和旧 value 做比较所有调用useContext的消费者如果发现 context 引用变了就重新执行一次渲染函数。听起来简单但很多人忽略了最后一步的“引用变了”。React 判断 context 变化用的是Object.is。哪怕你实际数据内容完全相同只要对象引用地址变了该重绘的组件照样重绘。放到鸿蒙版 RN 的场景里完整路径是这样的JS 侧某个组件调用setUserInfoProvider 组件重渲染重新计算 valueReact 沿组件树找出所有订阅GlobalContext的消费者每个消费者函数组件重新执行生成新的 React 元素RN 的 diff 逻辑对比前后视图树变化的部分通过桥接层更新到系统侧原生组件第 1 步到第 4 步完全发生在 JS 侧但从第 5 步开始就会产生跨端通信成本。鸿蒙低端机上这一步的耗时比高端 Android 机更容易暴露。所以 operation 上优先减少“无辜消费者”比什么都管用。3.2 让 value 保持稳定useMemo 不是锦上添花是救命来看一个反例function GlobalProvider({ children }: { children: React.ReactNode }) { const [userInfo, setUserInfo] useState(null); const [theme, setTheme] useState(light); return ( GlobalContext.Provider value{{ userInfo, theme, updateUser: setUserInfo, updateTheme: setTheme }} {children} /GlobalContext.Provider ); }这段代码的问题在于只要 Provider 所在组件发生了任意一次重渲染value就是一个全新的对象。哪怕userInfo和theme都没变只是父组件因为别的原因重绘了所有消费者依然会认为“context 更新了”然后全部重绘一遍。在鸿蒙版 RN 里这种现象很难用肉眼第一时间发现因为页面看起来没有变化CPU 和功耗却默默上去了。等出现掉帧通常已经不是一两个没写useMemo的问题而是全面铺开的依赖。改法就是前面代码里的useMemo。依赖数组里只放真正参与 value 计算的变量[userInfo, theme]。只要这两个不变value 引用就永远不变消费者就不会无脑重渲染。还有个容易被忽略的点如果你在代码里写的是switchTheme: () setTheme(nextTheme)那么这个函数对象每次渲染都不同哪怕你把整个对象包进useMemo如果useMemo的依赖数组没有包含这个函数引用React 就会一直认为 value 要变。最省事的做法是像第一版代码那样直接暴露setTheme本身因为useState的 setter 引用是稳定的。3.3 消费端的校验习惯宁可抛异常不要给假默认值useContext的默认值参数只在“找不到 Provider”时才会被用到。很多人图省事会写const GlobalContext createContext({ userInfo: null });然后在子组件里const { userInfo } useContext(GlobalContext);这样写的问题在于如果哪天这段代码被挪到了 Provider 外面它不会报错而是静默拿到默认值。userInfo永远是null登录态永远丢失排查起来非常难定位。所以我在公司内部定了一条规则context 文件里必须导出一个带断言的自定义 Hook禁止业务组件直接使用useContext。业务侧只写import { useGlobalContext } from ../contexts/AuthContext; function ProfileScreen() { const { userInfo } useGlobalContext(); // ... }这样一旦组件脱离 Provider抛错信息会直接告诉你“必须在 Provider 内部使用”而不是给你一个内存里的假数据。4. 鸿蒙真机上最容易出现卡顿的三种 Context 设计4.1 一个 Provider 管所有状态更新一次全校重绘我在排查一个模拟项目 X 的卡顿问题时发现首页有一个非常隐蔽的性能陷阱业务方把用户信息、购物车商品列表、网络状态、消息未读数全部放进了同一个GlobalProvider。页面结构大概是这样的顶部导航栏消费用户头像购物车 Tab 消费商品数量网络状态条消费连接状态。看起来每个组件只订阅了自己需要的字段但实际上它们订阅的是同一个 context。只要购物车数量有变化顶部导航栏和网络状态条都会重新渲染因为value的引用变了。这种问题的排查口是在消费组件里加一条临时输出打印自己从 context 里拿到的字段然后故意去更新另一个不相关的状态。如果你发现组件也重绘了就说明它们共用了同一个 context 对象而且 value 的结构粒度太大了。解决办法就是前面说的拆 Provider。不要嫌文件多一个 context 只装“变化频率和业务域都相近”的一组状态。下面是我常用的对照表状态建议存放位置原因登录态、用户信息AuthContext低频、跨页面、全局必需主题、语言ThemeContext低频、同时影响大量展示组件购物车角标数量CartContext更新频率中等和其他逻辑无关网络状态NetworkContext高频单独放且尽量节流表单临时值页面级 Context 或 State不跨页面没必要放全局4.2 高频回调状态持续涌入 Context有些场景下你会从系统侧拿高频数据比如下载进度、录音音量、设备传感器数据。这些数据如果每隔几十毫秒setState一次并且通过 context 分发那就是典型的“渲染风暴”。消费者组件重渲染本身可能只要几毫秒但鸿蒙版 RN 里一次渲染还可能触发原生视图属性更新。高频几百次叠加主线程就会被占满页面开始掉帧甚至出现触摸延迟。我的处理方式是分两层第一层高频数据停留在useRef或者一个轻量外部 Store 里只用于“需要时读取”不触发渲染第二层只有跨组件必须感知的“状态节点”比如从下载中变成下载完成、百分比从 10% 变到 11% 这种粗粒度变化才进入 context并且要做节流。代码示意const [progress, setProgress] useState(0); const latestProgress useRef(0); function onProgressUpdate(value: number) { latestProgress.current value; const rounded Math.round(value); setProgress(prev (prev rounded ? prev : rounded)); }这样 100 次回调可能最终只触发 10 次状态更新消费者的重绘次数就控制住了。4.3 上下文被弹窗或独立页面隔离没有跨容器能力鸿蒙系统上的某些弹窗、悬浮窗或者独立页面容器可能并不在你 JS 的 React 组件树里面。它们是系统侧的原生视图甚至对应一个单独的原生页面实例。这种情况下你在业务页面里通过useContext读到的数据弹窗里是拿不到的因为两者根本不属于同一个 Provider 树。这不是 bug而是 context 的天然边界。跨组件通信这个词容易被误解成“整个应用都能访问”实际上useContext的前提是“大家有同一个 React 祖先节点”。弹窗如果是通过系统能力弹出的独立窗口就要走另外的路要么在创建弹窗时把必要数据作为参数传进去要么让弹窗内容本身也是 React 渲染出来的只在原生层面做窗口容器。这里最容易踩的坑是本地调试一切正常因为弹窗在模拟器/开发模式下是 React 组件渲染的一旦切到独立窗口能力或者用系统侧海报、通知类组件时useContext就静默失效。建议在架构设计阶段就明确凡是“可能跳出 React 树”的内容一律不要指望 context 能直接喂进去。5. 同场竞技useContext、集中式状态库、系统侧存储的取舍5.1 useContext 与集中式状态库的选择分界项目落到鸿蒙版 RN 之后总有人问既然已经有useContext为什么还要引入 Redux 这类集中式状态库我的回答是useContext解决的是“跨层级传递和订阅”它不负责“业务逻辑编排”。如果你的状态更新链路很复杂比如登录成功后要同时清理本地缓存、推送埋点、刷新多个页面、处理错误回滚那光靠 context 会很散因为逻辑分散在各个调用方。Redux 这类方案把“状态变化”集中到一个地方通过 action 描述意图通过 reducer 计算新状态。好处是逻辑可追踪、可回放。代价是样板代码多团队每个人都要遵守同一套写法。对于中小型鸿蒙版 RN 应用我的建议是全局跨组件状态先用 context别一上来就引全局状态库。等页面多了、状态流转复杂了再把那部分真正复杂的状态迁移到集中式库里和 context 共存而不是拿一个方案消灭另一个。5.2 轻量外部 Store 的优势与适用位这几年流行的轻量状态库走的是另一条路状态存在 React 外部组件通过自定义 Hook 订阅。它不需要 Provider 包裹也不需要useMemo维护 context value 的引用稳定性。这种方案在两种场景下比 context 舒服一是你有非常多的全局状态字段更新频繁且组件订阅粒度很细二是你不想为“每个模块建一个 Provider 文件”这种维护成本买单。但轻量外部 Store 也有自己的学习成本而且一旦组件脱离 React 渲染流程你需要自己控制订阅更新时机。如果你只是让用户信息在几个页面间共享没必要为了避开 “useContext 必须包 Provider” 这一条而引入额外依赖。我的态度是把 context 当作默认值把外部 Store 当作“射频状态”或“复杂异步状态”的方案。两者可以并存不要互相排斥。5.3 系统侧持久化和原生事件作为兜底浏览器端做全局状态没人考虑“内存被系统回收”的问题因为页面存在JS 上下文就存在。但鸿蒙设备上应用在后台被系统回收、页面容器被销毁重建是非常正常的事。Context 作为内存态进程没了就没了。所以“登录态、必要配置”这类必须跨生命周期存在的状态不能只放在 context 里。Provider 初始化时要主动从系统侧存储里读取一份“初始值”作为 context 的起点。简单实现function AuthProvider({ children }: { children: React.ReactNode }) { const [userInfo, setUserInfo] useStateUserInfo | null(() loadUserFromLocal() ); // ... }loadUserFromLocal可以读系统侧轻量存储。这里的核心思想是context 是运行时的状态镜像不是持久化数据库。凡是“应用杀掉再打开还要记住”的东西都必须有系统存储兜底。系统侧的原生事件比如网络切换、电量变化、蓝牙连接状态也建议在 Provider 内注册监听转成 context 状态再分发。这样业务组件不需要直接感知系统 API只依赖useXxxContext就可以了。6. 几轮真机调试后我留下的 Context 使用纪律6.1 后台回收与冷启动数据恢复在鸿蒙真机上调试时最容易遇到的问题不是代码逻辑错而是状态生命周期比预期短。把应用切到后台隔一段时间再回来你以为 context 里的用户信息还在结果发现已经变成了null。原因不是useContext失效而是整个 JS 执行环境或原生页面容器被系统回收了。重新进入时虽然热启动但 React 组件树是从头创建的Provider 里的useState初始值自然回到默认值。解决思路有两个。第一个是 Provider 初始化时立即从系统存储读取状态而不是等异步回调第二个是把“恢复状态”放到 Provider 的 mount 过程中页面在显示加载态等数据回来后统一渲染。两种都不能解决“所有字段全部恢复”的问题但这已经能让大部分登录态、主题设置不再丢。排查这类问题有个技巧在GlobalProvider里输出 provider 是首次创建还是内部状态更新导致的重新渲染。export function GlobalProvider({ children }: { children: React.ReactNode }) { const mountRef useRef(false); useEffect(() { if (!mountRef.current) { console.log(GlobalProvider mount); mountRef.current true; } else { console.log(GlobalProvider re-render); } }); // ... }如果你发现冷启动时根本没有打印 mount状态却没了那大概率是原生侧页面被重建而 JS 是另一份全新实例。这种情况下就算 Provider 写在组件根节点也没有办法挽救上一个实例里的内存数据只能靠持久化恢复。6.2 弹窗与独立窗口的跨组件通信隐患我踩过的另一个坑是弹窗组件拿不到 context。业务上很常见某个页面需要弹一个权限确认框弹窗里面要显示用户昵称我直接从业务页面把userInfo通过 props 传下去没问题但后来需求改成弹窗内部自己调useGlobalContext()读取结果在部分机型上稳定复现“昵称为空”。查到最后发现那个弹窗在系统层使用了独立窗口能力渲染容器已经不在 React 组件树的渲染范围内了。React 组件树和原生窗口是两套东西context 的订阅关系根本没法穿透。我的建议是任何可能脱离 React 组件树的 UI都不要依赖 context 做数据获取。统一用 props 显式传入或者从系统侧存储直接读取。宁可在调用处多写两行传参也别赌它一定还在组件树里。6.3 调试轨迹用渲染计数确认更新范围最后分享一个很土但很有效的调试习惯。当怀疑 context 导致过多重渲染时我会在消费者组件里加一个计数器import { useRef } from react; function ProfileHeader() { const { userInfo } useGlobalContext(); const renderCount useRef(0); renderCount.current 1; console.log(ProfileHeader render: ${renderCount.current}); // ... }然后故意触发另一个无关状态更新再看这个组件有没有重新打印。如果没有说明拆分到位如果有就说明这个组件订阅的 context 粒度太粗或者value引用不稳定。根据我的实际体验绝大多数 context 导致的卡顿都不是 React 本身逻辑错误而是“共享范围过大”和“引用不稳定”叠加出来的。把 Provider 拆小把 value 用useMemo稳下来鸿蒙真机上的改善通常立竿见影。我会在每个 context 文件里都遵守“只导出 Provider 和自定义 Hook不导出 context 原始对象”这条规则。这样将来如果要换成外部 Store只需要改动自定义 Hook 内部实现页面层的调用代码可以保持不变。这个习惯陪我走过了好几个 RN 项目每次排错都省了不少时间。