【免费下载链接】react-native-mmkv⚡️ The fastest key/value storage for React Native. ~30x faster than AsyncStorage!项目地址https://gitcode.com/gh_mirrors/re/react-native-mmkv点击查看免费下载本文基于仓库文档 docs/WRAPPER_REDUX.md 展开讲解如何把 react-native-mmkv 接入 redux-persist实现 Redux 状态的持久化。读完你将掌握官方 Storage 封装对象的完整写法、三个接口方法与 MMKV 原生 API 的映射关系以及如何通过Configuration为持久化实例定制 ID、加密与写入策略并理解其在 Web 端与测试环境下的实际行为。为什么 redux-persist 需要自定义 Storageredux-persist 的持久化机制被抽象成一个Storage接口只要求实现三个方法setItem(key, value)写入一个键值对getItem(key)读取指定键的值removeItem(key)删除指定键。三个方法都返回 Promise或字符串值redux-persist 在persistStore启动时会调用getItem完成 rehydration状态回水此后每次被持久化的 reducer 状态变化都会触发setItem。默认生态中普遍搭配 AsyncStorage但 AsyncStorage 是异步 I/O状态恢复路径上要经过多次 Promise 往返。react-native-mmkv 的卖点正在于同步读写——项目 README 将其定位为最快的 React Native key/value 存储方案。由于 MMKV 的所有读写都是同步完成的把它包一层 Promise 即可无缝替换 AsyncStorage 的位置这也是 README.md 在 Use with Redux 部分指向 redux-persist 文档 的原因见 README.md#L299。官方最小封装完整可复制的 storage 对象按照 docs/WRAPPER_REDUX.md 给出的示例创建如下storage对象即可import { Storage } from redux-persist import { createMMKV } from react-native-mmkv const storage createMMKV() export const reduxStorage: Storage { setItem: (key, value) { storage.set(key, value) return Promise.resolve(true) }, getItem: (key) { const value storage.getString(key) return Promise.resolve(value) }, removeItem: (key) { storage.remove(key) return Promise.resolve() }, }逐行说明这段封装的关键点createMMKV()不带参数创建的是默认实例。从 createMMKV.ts#L19 可以看到缺省配置为{ id: factory.defaultMMKVInstanceId }而默认 ID 常量是mmkv.default见 MMKVFactory.nitro.ts#L139-L143。也就是说 redux-persist 的数据会落在mmkv.default这个 MMKV 文件中与应用里其他默认实例的键共享命名空间——键名需自行避免冲突。setItem内部调用storage.set(key, value)。redux-persist 序列化的状态是 JSON 字符串而set的签名是set(key: string, value: boolean | string | number | ArrayBuffer)见 MMKV.nitro.ts#L44字符串是受支持的类型。由于set同步执行完毕Promise.resolve(true)只是为适配Storage接口的异步签名。getItem用getString(key)读取。getString的返回类型是string | undefined见 MMKV.nitro.ts#L56键不存在时返回undefined这正是 redux-persist 期望的尚无持久化数据语义。removeItem调用storage.remove(key)该同步方法本身返回是否删除成功的布尔值见 MMKV.nitro.ts#L77封装里未使用该返回值直接 resolve 空值。值得强调的是这三个方法里没有任何 await 或平台通道往返Promise 是立即兑现的假异步。这意味着 redux-persist 的 rehydration 路径可以完全同步完成这是相对 AsyncStorage 方案的核心收益。底层实现createMMKV 到底做了什么上面封装中的createMMKV()并非简单的工厂调用其内部流程可以从源码确认createMMKV.ts#L10-L39测试环境短路若检测到 jest 环境isTest()直接返回内存 mock 实例createMockMMKV。因此你在单元测试中 import 上面的reduxStorage时读写全部落在内存里不会触碰原生模块懒加载原生工厂首次创建时通过NitroModules.createHybridObject(MMKVFactory)创建 C HybridObject并用平台上下文的基础目录调用initializeMMKV一次性初始化 MMKV 库见 getMMKVFactory.ts#L18-L27iOS App Group 处理在 iOS 上如果Info.plist配置了 App Group 且未显式指定path会自动改用 App Group 目录存储使 Widget、App Extension 可共享同一份持久化数据见 createMMKV.ts#L21-L31生命周期钩子实例创建后会自动注册内存告警监听收到系统内存告警时触发trim()和前台内容变更检查从 App Extension / App Clip / 后台服务写回时重新加载见 createMMKV.ts#L35-L38。这些副作用对 redux-persist 是透明的但解释了为什么官方示例不需要用户做任何额外初始化——createMMKV()一行就覆盖了库初始化、平台适配与生命周期管理。定制持久化实例Configuration 参数详解createMMKV(configuration?)接受一个 Configuration 对象。对于 redux-persist 场景最有用的参数如下默认值取自 MMKVFactory.nitro.ts 中的注释参数类型默认值对 redux-persist 场景的意义idstringmmkv.default多个 MMKV 实例互相隔离。建议为持久化状态单独指定 ID如redux-persist-store避免与普通业务键混在同一文件pathstring?undefined默认$(Documents)/mmkv/自定义存储根目录Web 端不支持encryptionKeystring?undefined对存储文件整体加密。若 Redux 状态中可能包含敏感数据token、用户资料建议启用encryptionTypeAES-128 \| AES-256AES-128指定加密算法AES-128 密钥须 16 字节AES-256 须 32 字节modesingle-process \| multi-processsingle-process若持久化数据需要被 Widget 等扩展进程读取应设为multi-processreadOnlybooleanfalseredux-persist 需要写入保持falsecompareBeforeSetbooleanfalse写入前比较新旧值相同则跳过落盘。redux-persist 在状态高频抖动时可能重复写入相同内容打开此项可减少无谓写盘recoveryStrategydiscard-on-error \| recover-on-errorundefined检测到 CRC/文件长度错误时的恢复策略持久化用户数据时可考虑recover-on-error示例为持久化状态建立独立、加密、抗抖动的实例import { Storage } from redux-persist import { createMMKV } from react-native-mmkv const storage createMMKV({ id: redux-persist-store, encryptionKey: my-encryption-key!, // 16 字节AES-128 encryptionType: AES-256 as const, // 若用 AES-256 则密钥需 32 字节 compareBeforeSet: true, }) export const reduxStorage: Storage { setItem: (key, value) { storage.set(key, value) return Promise.resolve(true) }, getItem: (key) Promise.resolve(storage.getString(key)), removeItem: (key) { storage.remove(key) return Promise.resolve() }, }注意compareBeforeSet的取舍它会引入一次值比较换取值未变化时不落盘。从 MMKVFactory.nitro.ts#L96-L103 的注释看官方将其定位为可选的性能优化对 redux-persist 这类每次 dispatched 相关 action 都可能触发持久化的写入模式比较契合。接入 Redux storepersistStore 的典型用法封装好reduxStorage后按 redux-persist 的常规方式接入即可。下面是一个与本文封装配套的典型接线示例redux-persist 侧的用法属于该库的标准 APIimport { legacy_createStore as createStore } from redux import { persistStore, persistReducer, FLUSH, REHYDRATE, PAUSE, PERSIST, PURGE, REGISTER } from redux-persist import { reduxStorage } from ./reduxStorage // 上文封装出的 Storage const persistConfig { key: root, storage: reduxStorage, // 只持久化需要落盘的 reducer 分支 whitelist: [settings, session], } const rootReducer combineReducers({ settings: settingsReducer, session: sessionReducer, transient: transientReducer, // 不进入白名单不会被持久化 }) const persistedReducer persistReducer(persistConfig, rootReducer) const store createStore(persistedReducer) const persistor persistStore(store)两个与 MMKV 直接相关的细节persistConfig.key上例为root就是最终传给reduxStorage.setItem的 key它会被写入mmkv.default或你自定义 ID 的实例文件whitelist/reducerWhitelist控制哪些 reducer 的状态参与序列化。MMKV 单实例的键空间是扁平的把整个 Redux 树压缩成一个 JSON 字符串存于单一 key正是 redux-persist 的设计如需拆分多个 key可自行扩展封装让setItem按state.storage分片写入不同键——这属于在官方封装之上的自由发挥官方文档未涉及。配合PersistGate可以在 rehydration 完成前阻塞渲染。由于 MMKV 读取是同步的persistor的REHYDRATE事件几乎立即触发冷启动时等待持久化数据基本没有可感知的延迟。Web 端与测试环境的行为差异Web。react-native-mmkv 在 Web 上有独立的 localStorage 实现createMMKV.web.ts上面的封装代码无需修改即可运行。该实现的关键限制createMMKV.web.ts#L10-L28encryptionKey与path两个配置项会直接抛错Web 端不支持加密与自定义路径每个 MMKV 实例的键都会加上${id}\\前缀keyPrefix以此在 localStorage 中模拟多实例隔离key本身不允许包含反斜杠trim、checkContentChanged为空操作encrypt/decrypt/recrypt不可用。因此跨端项目若为持久化实例配置了encryptionKey在 Web 端构建时会失败需要按平台条件化传参。测试环境。createMMKV在 jest 下返回内存 mockcreateMMKV.ts#L11-L14配合仓库中的 mock 模块mocks/react-native-nitro-modules.js你可以在单测中直接断言reduxStorage.getItem/setItem的存取一致性而无需 mock 原生层。小结react-native-mmkv 与 redux-persist 的集成路径非常短createMMKV()拿到同步实例用三个一行式方法包成Storage对象交给persistStore即可。官方文档 docs/WRAPPER_REDUX.md 只给出了最小封装而真正的工程价值在于利用Configuration把持久化实例从默认命名空间中隔离出来独立id、按需加密encryptionKeyencryptionType并用compareBeforeSet抑制重复写盘。所有相关实现均可在 packages/react-native-mmkv/src 下按本文给出的路径逐一核对。赞分享【免费下载链接】react-native-mmkv⚡️ The fastest key/value storage for React Native. ~30x faster than AsyncStorage!项目地址https://gitcode.com/gh_mirrors/re/react-native-mmkv点击查看免费下载相关推荐Redux-Thunk与Redux-Persist异步状态持久化Redux Thunk与Redux Persist异步状态持久化 你是否在开发React应用时遇到过这样的问题页面刷新后Redux存储的用户登录状态消失了前端PDF补丁丁3个核心功能帮你彻底解决PDF编辑难题PDF补丁丁3个核心功能帮你彻底解决PDF编辑难题 你是否曾经为PDF文档的书签编辑而头疼是否因为无法批量处理多个PDF文件而加班到深夜PDF补丁丁作为一桌面应用文档ServerEngine Supervisor机制揭秘确保服务器24/7不间断运行的终极指南 ServerEngine Supervisor机制揭秘确保服务器24/7不间断运行的终极指南 ServerEngine Supervisor机制是构建后端上一篇抖音视频批量下载终极指南douyin-downloader让内容创作效率提升300%下一篇5分钟快速部署Python微信机器人WechatBot终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】react-native-mmkv⚡️ The fastest key/value storage for React Native. ~30x faster than AsyncStorage!项目地址https://gitcode.com/gh_mirrors/re/react-native-mmkv点击查看免费下载本文基于仓库文档 docs/WRAPPER_REDUX.md 展开讲解如何把 react-native-mmkv 接入 redux-persist实现 Redux 状态的持久化。读完你将掌握官方 Storage 封装对象的完整写法、三个接口方法与 MMKV 原生 API 的映射关系以及如何通过Configuration为持久化实例定制 ID、加密与写入策略并理解其在 Web 端与测试环境下的实际行为。为什么 redux-persist 需要自定义 Storageredux-persist 的持久化机制被抽象成一个Storage接口只要求实现三个方法setItem(key, value)写入一个键值对getItem(key)读取指定键的值removeItem(key)删除指定键。三个方法都返回 Promise或字符串值redux-persist 在persistStore启动时会调用getItem完成 rehydration状态回水此后每次被持久化的 reducer 状态变化都会触发setItem。默认生态中普遍搭配 AsyncStorage但 AsyncStorage 是异步 I/O状态恢复路径上要经过多次 Promise 往返。react-native-mmkv 的卖点正在于同步读写——项目 README 将其定位为最快的 React Native key/value 存储方案。由于 MMKV 的所有读写都是同步完成的把它包一层 Promise 即可无缝替换 AsyncStorage 的位置这也是 README.md 在 Use with Redux 部分指向 redux-persist 文档 的原因见 README.md#L299。官方最小封装完整可复制的 storage 对象按照 docs/WRAPPER_REDUX.md 给出的示例创建如下storage对象即可import { Storage } from redux-persist import { createMMKV } from react-native-mmkv const storage createMMKV() export const reduxStorage: Storage { setItem: (key, value) { storage.set(key, value) return Promise.resolve(true) }, getItem: (key) { const value storage.getString(key) return Promise.resolve(value) }, removeItem: (key) { storage.remove(key) return Promise.resolve() }, }逐行说明这段封装的关键点createMMKV()不带参数创建的是默认实例。从 createMMKV.ts#L19 可以看到缺省配置为{ id: factory.defaultMMKVInstanceId }而默认 ID 常量是mmkv.default见 MMKVFactory.nitro.ts#L139-L143。也就是说 redux-persist 的数据会落在mmkv.default这个 MMKV 文件中与应用里其他默认实例的键共享命名空间——键名需自行避免冲突。setItem内部调用storage.set(key, value)。redux-persist 序列化的状态是 JSON 字符串而set的签名是set(key: string, value: boolean | string | number | ArrayBuffer)见 MMKV.nitro.ts#L44字符串是受支持的类型。由于set同步执行完毕Promise.resolve(true)只是为适配Storage接口的异步签名。getItem用getString(key)读取。getString的返回类型是string | undefined见 MMKV.nitro.ts#L56键不存在时返回undefined这正是 redux-persist 期望的尚无持久化数据语义。removeItem调用storage.remove(key)该同步方法本身返回是否删除成功的布尔值见 MMKV.nitro.ts#L77封装里未使用该返回值直接 resolve 空值。值得强调的是这三个方法里没有任何 await 或平台通道往返Promise 是立即兑现的假异步。这意味着 redux-persist 的 rehydration 路径可以完全同步完成这是相对 AsyncStorage 方案的核心收益。底层实现createMMKV 到底做了什么上面封装中的createMMKV()并非简单的工厂调用其内部流程可以从源码确认createMMKV.ts#L10-L39测试环境短路若检测到 jest 环境isTest()直接返回内存 mock 实例createMockMMKV。因此你在单元测试中 import 上面的reduxStorage时读写全部落在内存里不会触碰原生模块懒加载原生工厂首次创建时通过NitroModules.createHybridObject(MMKVFactory)创建 C HybridObject并用平台上下文的基础目录调用initializeMMKV一次性初始化 MMKV 库见 getMMKVFactory.ts#L18-L27iOS App Group 处理在 iOS 上如果Info.plist配置了 App Group 且未显式指定path会自动改用 App Group 目录存储使 Widget、App Extension 可共享同一份持久化数据见 createMMKV.ts#L21-L31生命周期钩子实例创建后会自动注册内存告警监听收到系统内存告警时触发trim()和前台内容变更检查从 App Extension / App Clip / 后台服务写回时重新加载见 createMMKV.ts#L35-L38。这些副作用对 redux-persist 是透明的但解释了为什么官方示例不需要用户做任何额外初始化——createMMKV()一行就覆盖了库初始化、平台适配与生命周期管理。定制持久化实例Configuration 参数详解createMMKV(configuration?)接受一个 Configuration 对象。对于 redux-persist 场景最有用的参数如下默认值取自 MMKVFactory.nitro.ts 中的注释参数类型默认值对 redux-persist 场景的意义idstringmmkv.default多个 MMKV 实例互相隔离。建议为持久化状态单独指定 ID如redux-persist-store避免与普通业务键混在同一文件pathstring?undefined默认$(Documents)/mmkv/自定义存储根目录Web 端不支持encryptionKeystring?undefined对存储文件整体加密。若 Redux 状态中可能包含敏感数据token、用户资料建议启用encryptionTypeAES-128 \| AES-256AES-128指定加密算法AES-128 密钥须 16 字节AES-256 须 32 字节modesingle-process \| multi-processsingle-process若持久化数据需要被 Widget 等扩展进程读取应设为multi-processreadOnlybooleanfalseredux-persist 需要写入保持falsecompareBeforeSetbooleanfalse写入前比较新旧值相同则跳过落盘。redux-persist 在状态高频抖动时可能重复写入相同内容打开此项可减少无谓写盘recoveryStrategydiscard-on-error \| recover-on-errorundefined检测到 CRC/文件长度错误时的恢复策略持久化用户数据时可考虑recover-on-error示例为持久化状态建立独立、加密、抗抖动的实例import { Storage } from redux-persist import { createMMKV } from react-native-mmkv const storage createMMKV({ id: redux-persist-store, encryptionKey: my-encryption-key!, // 16 字节AES-128 encryptionType: AES-256 as const, // 若用 AES-256 则密钥需 32 字节 compareBeforeSet: true, }) export const reduxStorage: Storage { setItem: (key, value) { storage.set(key, value) return Promise.resolve(true) }, getItem: (key) Promise.resolve(storage.getString(key)), removeItem: (key) { storage.remove(key) return Promise.resolve() }, }注意compareBeforeSet的取舍它会引入一次值比较换取值未变化时不落盘。从 MMKVFactory.nitro.ts#L96-L103 的注释看官方将其定位为可选的性能优化对 redux-persist 这类每次 dispatched 相关 action 都可能触发持久化的写入模式比较契合。接入 Redux storepersistStore 的典型用法封装好reduxStorage后按 redux-persist 的常规方式接入即可。下面是一个与本文封装配套的典型接线示例redux-persist 侧的用法属于该库的标准 APIimport { legacy_createStore as createStore } from redux import { persistStore, persistReducer, FLUSH, REHYDRATE, PAUSE, PERSIST, PURGE, REGISTER } from redux-persist import { reduxStorage } from ./reduxStorage // 上文封装出的 Storage const persistConfig { key: root, storage: reduxStorage, // 只持久化需要落盘的 reducer 分支 whitelist: [settings, session], } const rootReducer combineReducers({ settings: settingsReducer, session: sessionReducer, transient: transientReducer, // 不进入白名单不会被持久化 }) const persistedReducer persistReducer(persistConfig, rootReducer) const store createStore(persistedReducer) const persistor persistStore(store)两个与 MMKV 直接相关的细节persistConfig.key上例为root就是最终传给reduxStorage.setItem的 key它会被写入mmkv.default或你自定义 ID 的实例文件whitelist/reducerWhitelist控制哪些 reducer 的状态参与序列化。MMKV 单实例的键空间是扁平的把整个 Redux 树压缩成一个 JSON 字符串存于单一 key正是 redux-persist 的设计如需拆分多个 key可自行扩展封装让setItem按state.storage分片写入不同键——这属于在官方封装之上的自由发挥官方文档未涉及。配合PersistGate可以在 rehydration 完成前阻塞渲染。由于 MMKV 读取是同步的persistor的REHYDRATE事件几乎立即触发冷启动时等待持久化数据基本没有可感知的延迟。Web 端与测试环境的行为差异Web。react-native-mmkv 在 Web 上有独立的 localStorage 实现createMMKV.web.ts上面的封装代码无需修改即可运行。该实现的关键限制createMMKV.web.ts#L10-L28encryptionKey与path两个配置项会直接抛错Web 端不支持加密与自定义路径每个 MMKV 实例的键都会加上${id}\\前缀keyPrefix以此在 localStorage 中模拟多实例隔离key本身不允许包含反斜杠trim、checkContentChanged为空操作encrypt/decrypt/recrypt不可用。因此跨端项目若为持久化实例配置了encryptionKey在 Web 端构建时会失败需要按平台条件化传参。测试环境。createMMKV在 jest 下返回内存 mockcreateMMKV.ts#L11-L14配合仓库中的 mock 模块mocks/react-native-nitro-modules.js你可以在单测中直接断言reduxStorage.getItem/setItem的存取一致性而无需 mock 原生层。小结react-native-mmkv 与 redux-persist 的集成路径非常短createMMKV()拿到同步实例用三个一行式方法包成Storage对象交给persistStore即可。官方文档 docs/WRAPPER_REDUX.md 只给出了最小封装而真正的工程价值在于利用Configuration把持久化实例从默认命名空间中隔离出来独立id、按需加密encryptionKeyencryptionType并用compareBeforeSet抑制重复写盘。所有相关实现均可在 packages/react-native-mmkv/src 下按本文给出的路径逐一核对。赞分享【免费下载链接】react-native-mmkv⚡️ The fastest key/value storage for React Native. ~30x faster than AsyncStorage!项目地址https://gitcode.com/gh_mirrors/re/react-native-mmkv点击查看免费下载相关推荐Redux-Thunk与Redux-Persist异步状态持久化Redux Thunk与Redux Persist异步状态持久化 你是否在开发React应用时遇到过这样的问题页面刷新后Redux存储的用户登录状态消失了前端PDF补丁丁3个核心功能帮你彻底解决PDF编辑难题PDF补丁丁3个核心功能帮你彻底解决PDF编辑难题 你是否曾经为PDF文档的书签编辑而头疼是否因为无法批量处理多个PDF文件而加班到深夜PDF补丁丁作为一桌面应用文档ServerEngine Supervisor机制揭秘确保服务器24/7不间断运行的终极指南 ServerEngine Supervisor机制揭秘确保服务器24/7不间断运行的终极指南 ServerEngine Supervisor机制是构建后端上一篇抖音视频批量下载终极指南douyin-downloader让内容创作效率提升300%下一篇5分钟快速部署Python微信机器人WechatBot终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
