先说说这段迁移经历。团队要把已有的React Native应用搬到鸿蒙设备上最开始我们想的很简单代码大部分能复用改改配置、跑通桥接就行。结果真到联调才发现第一个卡住的不是原生模块不是页面跳转而是状态管理。项目里原本用的是Redux Toolkit加MobX混着用在iOS和Android上跑了快两年没出过什么大问题。可同一套代码放进鸿蒙侧的RN运行环境里问题开始冒出来了跨线程通信后状态更新经常慢半拍页面已经切过去了数据还是旧的MobX的响应式代理在某些真机上会莫名失效页面不报错只是不刷新。排查一圈下来团队里有人提了一句“要不试试Jotai那个是原子状态管理模型足够小说不定在鸿蒙上反而更稳。”于是就有了这篇文章。Jotai这个词在日语里是“状态”的意思它提供的是一套基于原子atom的状态管理方案把每个独立的状态拆成最小单位用React自身的调度机制驱动更新。写法和心智负担都比Redux轻得多也不依赖MobX那种深层Proxy魔法。实际跑下来它确实成了我们鸿蒙适配过程中最省心的部分之一。这篇文章就从选型对比、核心概念、接入步骤、真机踩坑到目录设计完整聊聊我们是怎么在RN鸿蒙工程里落地这套原子状态管理的。1. 为什么我在鸿蒙适配里把状态管理换成了Jotai先交代一下背景。我们的React Native应用要跑上鸿蒙设备走的是社区主流的鸿蒙侧RN适配层方案。架构上JS代码跑在鸿蒙提供的JS运行时里UI渲染和原生能力通过桥接层跟ArkTS侧通信整体可以理解为“JS业务逻辑 原生桥接 ArkTS容器”的组合。这种架构下状态管理库跑在JS侧但它的每次setState最终要穿过桥接、触发React Reconciler、再驱动原生视图更新。链路比纯Android/iOS环境更长而且鸿蒙侧的RN运行时对JS引擎做了一定限制和裁剪。很多在Android上跑得飞快的库到这里就会暴露兼容性问题。1.1 Redux、MobX和Jotai在鸿蒙侧的真实表现我们先看当时在鸿蒙真机上遇到的问题。Redux那边问题主要集中在异步时序上。业务里大量使用了Redux Toolkit的createAsyncThunk在Android上一切正常。鸿蒙侧联调时dispatch一个异步action后pending和fulfilled状态有时候会乱序尤其是快速切换页面时可能出现“先发的请求后返回把新状态覆盖成旧状态”的情况。另外Redux的connect高阶组件在鸿蒙的引擎下需要额外做batchedUpdates适配否则连续dispatch多次时中间状态会被渲染到界面上造成明显闪烁。MobX的问题更隐蔽。MobX的核心是Proxy响应式代理通过拦截对象属性访问来收集依赖。鸿蒙侧RN运行时对Proxy的支持虽然存在但在某些系统版本和机型组合下代理失效的偶发率不低。表现就是数据确实改了组件不重渲染。这类问题最难排查因为它不像报错那么明显而是“偶尔不动、刷新一下又好了”的诡异状态。反观Jotai它的实现思路完全不同——状态是用atom()创建出的普通对象依赖关系通过原子的读取路径来追踪底层使用React的useSyncExternalStore与组件同步。整个过程没有任何全局事件总线也不需要多层Provider嵌套跨桥接链路时状态流转路径很短。实际用下来的第一感觉就是“这个东西小到没有地方可以出问题。”1.2 三个方案的核心差异对比为了方便选型我做了一张表格记录我们在鸿蒙真机上对三个方案的实际观察。对比维度Redux ToolkitMobXJotai状态模型单Store Action派发多Store 响应式代理原子对象 依赖追踪依赖追踪方式手动selectorProxy自动追踪读取路径自动订阅需要Provider吗必须要必须或注入默认不需要鸿蒙侧桥接表现异步action偶发时序错乱Proxy代理偶发失效状态流转路径最短表现稳定包体积增量中等中等极小学习成本高中低调试方式DevTools成熟DevTools较成熟可兼容Redux DevTools或手动日志这不是说Redux或MobX“不好”而是它们的复杂度在鸿蒙RN运行环境里会被放大。Jotai的优势在于够简单没有action、没有reducer、没有复杂的中间件一个atom就是一个状态useAtom钩子直接拿到值和更新函数。它的设计哲学是“状态就应该尽可能靠近使用它的组件”这种思路跟我们适配鸿蒙时“减少跨层依赖、降低链路复杂度”的目标高度一致。2. Jotai的原子模型从atom到useAtom的核心机制聊完了选型接下来把Jotai最核心的几个概念拆开讲清楚。理解这些后面在鸿蒙上写业务时才能心里有底遇到问题也知道往哪个方向排查。2.1 什么是“原子”atom的概念可以理解成一个状态的最小单元。它不像Redux那样集中在一个Store里也不像MobX那样把整个对象变成响应式。每个atom就是一个独立的、可订阅的“状态格子”创建方式极其简单import { atom } from jotai; // 基础原子保存一个数字 const countAtom atom(0); // 派生原子依赖其他原子自动计算 const doubleCountAtom atom((get) get(countAtom) * 2); // 可写派生原子既能读也能更新来源原子 const incrementAtom atom( (get) get(countAtom), (get, set) set(countAtom, get(countAtom) 1) );基础原子保存原始值派生原子根据依赖自动计算。它们之间的关系是一张有向图Jotai内部会维护这张依赖图任何上游原子变化时下游消费它的组件都会自动重渲染。用生活化的类比来解释把atom想象成一个Excel单元格。countAtom是A1单元格值写死成0。doubleCountAtom是B1单元格公式是A1*2。A1变了B1自动跟着变。Jotai做的就是实时监控A1有没有被修改一旦修改就通知所有能看到B1的人刷新。2.2 useAtom连接状态和组件在组件里读写原子使用的是useAtom钩子import { useAtom } from jotai; import { View, Text, Button } from react-native; function Counter() { const [count, setCount] useAtom(countAtom); return ( View Text当前值{count}/Text Button title1 onPress{() setCount(count 1)} / /View ); }useAtom返回一个元组格式跟useState完全一样。count是当前值setCount是更新函数。更新函数既可以接收新值也可以接收函数式的更新逻辑setCount((prev) prev 1);这种设计与React原生状态API对齐学习成本几乎为零。在鸿蒙侧RN环境里组件点击按钮、状态变化、UI刷新这条链路短不容易出现Android上那种“这边状态变了、那边UI还没反应”的错位感。2.3 派生原子和异步原子在鸿蒙侧的应用实际业务里我们大量使用了派生原子。一个典型的场景是购物车角标页面头部显示商品总数购物车列表页显示明细。两者其实共享同一个基础原子但展示逻辑不同。// store/cart.ts import { atom } from jotai; export interface CartItem { id: string; name: string; price: number; count: number; } export const cartItemsAtom atomCartItem[]([]); // 派生原子总数量 export const cartTotalCountAtom atom((get) get(cartItemsAtom).reduce((total, item) total item.count, 0) ); // 派生原子总价 export const cartTotalPriceAtom atom((get) get(cartItemsAtom).reduce( (total, item) total item.price * item.count, 0 ) );页面头部只订阅cartTotalCountAtom列表页订阅cartItemsAtom。上游cartItemsAtom变化时两个派生原子的依赖者都会被精确通知而不是像集中式Store那样整个页面全量刷新。异步原子则用来处理接口数据import { atom } from jotai; export interface UserInfo { id: string; name: string; avatar: string; } export const userIdAtom atomstring | null(null); export const userInfoAtom atomUserInfo | null(async (get) { const id get(userIdAtom); if (!id) return null; const response await fetch(/api/user/${id}); return response.json(); });这个写法在Web端很简洁但在鸿蒙真机上我们踩了坑第三节会专门讲。2.4 为什么Jotai的依赖追踪更适合受限JS引擎再补充一个细节。MobX的依赖追踪依赖Proxy拦截需要在对象属性访问层面做大量hook操作。鸿蒙侧RN运行时的JS引擎对Proxy的支持并非全场景无死角尤其在对象被多次封装、跨桥接传值后拦截链路容易断掉。Jotai虽然内部也有读取追踪但它的追踪是建立在函数调用路径上的派生原子通过get()函数读取上游值时Jotai记录依赖关系组件通过useAtom读取原子值时依赖关系被React的useSyncExternalStore捕获。整个过程不涉及对象代理因此对引擎特性依赖更少在资源受限的鸿蒙运行环境里更稳。3. 从零接入在RN鸿蒙工程里配好Jotai的完整路径这一节讲具体接入步骤。我们的工程是标准的React Native工程鸿蒙侧通过适配层把RN页面挂载到原生容器里这里会涉及一些鸿蒙侧配置但核心逻辑都在JS侧。3.1 环境准备与安装环境方面我们使用的RN版本是0.7x鸿蒙SDK是较新的API版本IDE使用鸿蒙官方提供的开发工具。Jotai本身不挑版本也不需要额外配置Babel插件这是它在鸿蒙工程里最大的优势之一。很多状态管理库在鸿蒙构建链路上需要额外编译插件走不通就得自己改构建配置而Jotai装完就能用。安装命令npm install jotai或者用yarnyarn add jotai安装完成后不需要在入口文件做Provider包裹。Jotai默认使用全局Store这是它区别于Redux的关键一点。如果你希望某个子树的状态隔离可以用Provider包裹import { Provider } from jotai; import { ReactNode } from react; export function AppProvider({ children }: { children: ReactNode }) { return Provider{children}/Provider; }默认情况下所有atom共享同一个全局Store页面间天然互通省去了Redux那一套connect或hooks selector的黏合代码。3.2 鸿蒙侧工程的最小配置在鸿蒙工程里加载RN页面通常需要先在ArkTS侧创建一个原生组件容器再通过桥接加载JS侧入口。这一步每个适配方案的写法略有差异但大致流程是固定的在鸿蒙工程里创建Fragment或Page承载RN渲染视图初始化RN运行时环境注册JS入口文件通过桥接把RN生成的视图添加到原生布局中。JS侧入口文件保持正常写法即可import { AppRegistry } from react-native; import { App } from ./App; import { name as appName } from ./app.json; AppRegistry.registerComponent(appName, () App);Jotai不参与原生桥接过程它只运行在JS侧。这一点很重要——我们不需要为它编写任何原生Module也不需要关心ArkTS侧的依赖注入。状态管理完全收敛在JS层跨端复用成本很低。3.3 第一个Jotai原子在鸿蒙页面上的运行链路下面是一个最小可运行示例包含状态定义、组件消费和更新// App.tsx import React from react; import { View, Text, Button } from react-native; import { atom, useAtom } from jotai; const greetingAtom atom(欢迎来到鸿蒙); function Greeting() { const [greeting, setGreeting] useAtom(greetingAtom); return ( View style{{ padding: 20 }} Text{greeting}/Text Button title更新消息 onPress{() setGreeting(状态更新成功)} / /View ); } export function App() { return Greeting /; }这段代码跑通后你就已经完成了Jotai在RN鸿蒙工程里的最小接入。点击按钮时状态更新、组件重渲染、UI刷新整个过程不涉及额外配置。如果这一步遇到问题优先检查RN运行时是否能正常加载JS以及桥接是否通——跟Jotai本身关系不大。3.4 接入过程中的几个注意点实际接入时有几个容易被忽略的细节不要重复创建atom。如果某个atom在组件内部用useMemo创建卸载重挂载后会丢失状态。正确方式是把atom定义在组件外部或模块顶层。全局Store默认持久存在于JS运行时生命周期里。页面关闭不代表store销毁除非你显式清理。如果业务要求页面级状态随页面销毁用Provider包一层做隔离。Jotai在鸿蒙上跑的是微任务调度连续多次setAtom时React会自动批量更新。不需要像Redux那样手动做batchedUpdates适配。4. 真机实测踩坑异步原子不触发Suspense和组件内定义atom的状态抖动这部分是全文最有价值的一节。我们在鸿蒙真机上踩了两个跟Jotai相关的坑排查过程走了不少弯路讲清楚能帮你省好几个小时。4.1 异步原子 Suspense 在鸿蒙上不显示降级UI第一个坑出现在异步原子配合React Suspense的场景。业务需求是用户进入个人中心页时先展示骨架屏接口返回后展示完整用户信息。按照Jotai官方文档推荐我们使用了异步原子配合Suspense方案// 官方推荐写法之一 import { Suspense, useEffect } from react; import { View, Text } from react-native; import { useAtom } from jotai; import { userInfoAtom } from ../stores/user; function UserProfile() { const [userInfo] useAtom(userInfoAtom); return Text{userInfo?.name}/Text; } export function ProfileScreen() { return ( Suspense fallback{Text加载中.../Text} UserProfile / /Suspense ); }这段代码在Web端和Android上都能正常显示“加载中...”的fallback。到了鸿蒙真机上表现诡异页面白屏fallback不出来数据其实已经加载完了界面却一直停在那里。控制台也没有任何报错看起来像是Suspense被“卡住”了。排查过程我们分了几步第一步确认异步原子本身是否正常。把Suspense去掉改成手动读取状态并打印日志发现userInfoAtom的promise确实resolve了数据能拿到。第二步单独测试Suspense基础能力。写了一个永远不会resolve的异步原子希望它能触发fallback结果鸿蒙上依然白屏。到这里基本锁定了问题鸿蒙侧RN运行时下React的Suspense抛出的“挂起”信号没有被正确传递到渲染器层面导致fallback机制失效。第三步查询社区资料发现当时鸿蒙适配层对React并发特性包括Suspense的支持存在裁剪。React Native的Fabric渲染器在鸿蒙侧的实现并未完整支持所有并发渲染路径Suspense的降级显示依赖这个机制因此表现异常。最终的解决方案是绕开Suspense使用Jotai的loadable工具手动管理加载态import { atom, useAtom } from jotai; import { loadable } from jotai/utils; import { View, Text, ActivityIndicator } from react-native; // 异步原子 const userInfoAtom atom(async () { const response await fetch(/api/user/profile); return response.json(); }); // loadable包装将异步状态转为普通值 const userInfoLoadableAtom loadable(userInfoAtom); function UserProfile() { const [userInfoLoadable] useAtom(userInfoLoadableAtom); return ( View style{{ padding: 20 }} {userInfoLoadable.state loading ( ActivityIndicator sizelarge / )} {userInfoLoadable.state hasData ( Text{userInfoLoadable.data?.name}/Text )} {userInfoLoadable.state hasError ( Text加载失败/Text )} /View ); }loadable会把异步原子包装成一个同步状态对象包含loading、hasData、hasError三种状态。这样不用Suspense也能完整表达加载、成功、失败三种UI分支。改动量不大但在鸿蒙真机上的表现立刻恢复正常。这是我建议所有鸿蒙RN项目直接采用loadable方式处理异步状态的原因——不仅绕开了Suspense兼容问题代码可读性也更明确。4.2 组件内定义原子导致列表页状态抖动第二个坑更难察觉。现象是一个商品列表页页面结构是FlatList 多选功能。勾选某个商品后列表会闪一下滚动位置跳动有时勾选状态还会自己消失。排查链路是这样的第一步怀疑是FlatList的extraData问题。检查后发现extraData传入的是派生原子计算出的数组每次setState都会生成新引用FlatList重渲染属正常行为但状态不应该丢失。第二步怀疑是useCallback依赖问题。检查后发现不是。第三步打印日志追踪勾选状态。发现每次勾选时对应商品项的选中原子被重置成了初始值。这里的信息量就大了——哪个地方会重置原子最终定位到问题代码function ProductItem({ product }: { product: Product }) { // 错误示例在组件内部创建原子 const selectedAtom useMemo( () atom(false), [product.id] ); const [selected, setSelected] useAtom(selectedAtom); return ( TouchableOpacity onPress{() setSelected(!selected)} Text{product.name}/Text /TouchableOpacity ); }看似合理用useMemo缓存了atom实例。问题是当FlatList滚动、item卸载重挂载或者父组件setState导致ProductItem重新渲染时useMemo的依赖如果没有变化缓存应该还在。但实际场景中product.id如果来自列表接口且每次刷新后是同一个值按理不会重置。进一步排查发现FlatList在鸿蒙上的滑动回收机制比Android更激进。item组件会被频繁卸载和重挂载useMemo的缓存是否保留取决于组件实例是否保留。一旦组件实例被销毁useMemo重新执行atom(false)就被重新创建勾选状态自然丢失。这在Android上偶发但在鸿蒙侧回收策略更积极触发概率极高。解决方案很简单把每个商品项的选中状态放进一个模块级的atomFamily里。import { atomFamily } from jotai/utils; // 模块顶层定义atomFamily按商品ID独立管理选中状态 export const productSelectedAtom atomFamily((productId: string) atom(false) );组件内只需要function ProductItem({ product }: { product: Product }) { const [selected, setSelected] useAtom(productSelectedAtom(product.id)); return ( TouchableOpacity onPress{() setSelected(!selected)} Text{product.name}/Text /TouchableOpacity ); }atomFamily会为每个product.id创建并缓存独立的原子无论组件怎么卸载重挂载状态都保存在全局Store里不会再丢失。这个坑的启示是Jotai虽然允许在组件附近定义原子但为了适配鸿蒙激进的组件回收策略全局性的、依赖业务ID的状态一定要用模块级atomFamily管理。5. 从单个原子到状态目录鸿蒙RN项目的Jotai模块化实践单组件用Jotai很简单但一个大型RN鸿蒙项目要跑得稳得在工程层面做好目录规划和状态职责划分。这里分享我们最终沉淀下来的实践方案。5.1 状态目录的推荐结构我们的业务状态按域拆分每个域一个文件统一从index.ts导出。src/ ├── stores/ │ ├── index.ts │ ├── auth.ts │ ├── cart.ts │ ├── product.ts │ └── settings.ts ├── screens/ ├── components/ └── App.tsx以auth.ts为例// stores/auth.ts import { atom } from jotai; import { atomWithStorage } from jotai/utils; export interface AuthState { token: string | null; userId: string | null; nickname: string; } export const authStateAtom atomWithStorageAuthState( auth-state, { token: null, userId: null, nickname: , }, createAsyncStorage() );index.ts里统一导出// stores/index.ts export * from ./auth; export * from ./cart; export * from ./product; export * from ./settings;这样业务页面只从stores/index.ts引入自己需要的原子依赖路径清晰不会出现状态定义散落各处的情况。5.2 atomWithStorage在鸿蒙侧的自定义存储适配Jotai自带的atomWithStorage默认使用本地存储接口。在Web端是localStorage在RN端会尝试适配AsyncStorage。鸿蒙侧的RN运行时对AsyncStorage的兼容性取决于原生模块是否配套如果项目里没有安装对应的原生存储模块默认的存储适配会失效状态刷新后丢失。我们的做法是自定义一个存储适配器底层对接鸿蒙的持久化能力// stores/storage.ts import { createJSONStorage } from jotai/utils; interface StorageLike { getItem: (key: string) string | null | Promisestring | null; setItem: (key: string, value: string) void | Promisevoid; removeItem: (key: string) void | Promisevoid; } export function createAsyncStorage(): StorageLike { // 这里对接鸿蒙侧通过桥接透传的持久化接口 return { getItem: async (key: string) { const value await NativeModules.HarmonyStorage.getItem(key); return value; }, setItem: async (key: string, value: string) { await NativeModules.HarmonyStorage.setItem(key, value); }, removeItem: async (key: string) { await NativeModules.HarmonyStorage.removeItem(key); }, }; }然后把它传给atomWithStorage的第三个参数export const authStateAtom atomWithStorageAuthState( auth-state, initialAuthState, createAsyncStorage() );这样登录态就能持久化到鸿蒙本地App重启后自动恢复。5.3 与现有Redux共存的渐进式迁移策略如果你现有的RN鸿蒙工程已经大规模使用Redux不建议一次性推倒重来。我们的做法是分阶段迁移第一阶段新页面和新的业务模块使用Jotai。页面内部的状态用基础原子接口数据用异步原子加loadable跨页面共享状态用模块级原子。第二阶段把Redux Store里相对独立的一部分状态迁移到Jotai。优先选择“不依赖其他Redux状态”的模块比如用户设置、本地偏好。通过在一个自定义Hook里同时读取Redux和Jotai状态平稳过渡。第三阶段当Redux里的状态只剩少量跨模块依赖时再集中处理。整个过程可以并行工作新页面开发不受旧架构阻塞。用Jotai管理新状态用Redux管理老状态两者之间通过组件桥接这在鸿蒙上跑了一个多月没有出现兼容性问题。5.4 团队开发约定项目稳定之后我们在团队里定了三条规则原子定义必须放在模块顶层或单独的状态文件里禁止在组件render过程中创建原子涉及业务实体的状态必须使用atomFamily以业务ID为参数拆分原子异步状态统一使用loadable包装避免依赖Suspense特性。这三条规则执行之后因为状态管理引起的bug数量下降得非常明显。6. 性能观察与工具链高频更新、调试和包体积最后聊几个跟运行性能相关的问题。Jotai本身很轻量但用得不合理同样会卡顿。开发体验方面也有一些和传统Redux项目不同的地方。6.1 高频更新场景下的原子粒度控制和selectAtom我们的应用里有一个实时库存监控页面每秒从推送通道接收新的库存数据。每个商品显示可售数量、价格、预约状态。最初我们把整个页面状态合并到一个大atom里然后用useAtom订阅结果发现每秒一次的更新导致整个页面重渲染滑动列表时明显掉帧。优化方式是拆细原子粒度import { atom } from jotai; // 库存数据按SKU拆分 export const stockBySkuAtom atomFamily((sku: string) atom({ available: 0, price: 0, status: onsale, }) ); // 页面只需要订阅当前可见的若干SKU const visibleSkuListAtom atomstring[]([]);每个商品组件只订阅自己的stockBySkuAtom(sku)推送数据到达时只有对应组件更新其他组件完全不受影响。实测把页面帧率从卡顿恢复到了流畅。对于订阅大原子中某一片段的需求用selectAtom筛选import { selectAtom } from jotai/utils; // 只订阅总价字段价格变化时才重渲染 const totalPriceAtom selectAtom(cartItemsAtom, (items) items.reduce((sum, item) sum item.price * item.count, 0) );selectAtom内置了值比较逻辑下游读取到的值没变时不会触发重渲染。这和Redux的selector优化是同一个思路但写法更贴合React的直觉。6.2 调试工具鸿蒙环境下的两套方案Jotai官方推荐使用jotai-devtools但在鸿蒙侧RN环境里它的浏览器扩展和自定义hook支持并不完整。我们实际采用的调试方式是第一业务日志埋点。在关键派生原子和异步原子内部打印状态流转信息观察依赖图是否正确。第二兼容Redux DevTools。Jotai提供了传统的debug模式可以暴露内部状态到统一的调试面板。如果项目里已经接了Redux DevTools这套兼容方案可以复用现有调试面板不用额外引入新工具。真机调试时最常用的是在入口文件做全局状态快照import { useAtomValue } from jotai; import { authStateAtom } from ./stores/auth; function DebugPanel() { const authState useAtomValue(authStateAtom); return null; // 开发模式下打日志用 }这种方式简单直接不依赖额外工具出错时一眼能看出当前所有关键状态。6.3 包体积增量与启动耗时引入Jotai后我们特意测了一下包体积变化。整个Jotai库的生产包体积很小压缩后约几KB量级相比Redux加相关中间件节约了十几KB甚至更多。加上我们移除了部分MobX装饰器代码后包体积下降更明显。启动耗时方面Jotai没有初始化Store的额外步骤原子是按需创建的因此几乎不影响启动速度。这在鸿蒙设备上特别重要阿童木这类低配置设备上任何多余JS执行时间都会被用户感知。6.4 是否需要担心“太灵活”带来的约束不足Jotai的自由度确实比Redux高团队里刚上手的人可能会问“没有强制规范代码会不会写乱”我的看法是规范应该由团队制定而不是由框架强制。Redux的强约束换来的往往是样板代码成本。Jotai把状态管理回归到“普通变量 订阅”的本质配合合理的目录约定和代码评审完全能控制住复杂度。最终我个人的体会是在鸿蒙RN适配这个特殊场景下状态管理库的选择标准不是“功能多强大”而是“依赖多简单”。Jotai恰好把复杂度降到了最低。现在团队的新需求默认都用Jotai写老模块里的Redux也在逐步替换。如果你的项目正在做鸿蒙适配或者打算新起一个RN鸿蒙工程我会建议直接试试Jotai。它的学习成本很低跑通一个demo只需要十分钟。真到了鸿蒙真机上踩过异步状态的坑、理顺了atomFamily的使用方式之后你会觉得整套方案确实省心。