OpenHarmony上React Native搜索历史记录管理实战

最近在搞 OpenHarmony 上的 React Native 适配，有个活儿让我印象挺深：给搜索页做一个带历史记录管理的 SearchBar。看着不起眼，真做起来才发现坑不少。跨端框架、新的系统容器、存储方案选型、数据去重逻辑，还有那个臭名昭著的启动白屏，全都搅在一起。但做完之后回头再看，这套东西的价值其实远超“一个搜索框”本身，它几乎把 RN 在 OpenHarmony 上落地要走的流程都过了一遍。

这篇就围绕“React Native + OpenHarmony：SearchBar历史记录管理”这个任务，把我实际踩过的坑、验证过的方案、最终的代码结构都摊开讲。想直接抄作业的，重点看第三部分的实现；想搞明白为什么这么设计的，从头读更好。

1. 核心方案与整体设计思路

1.1 为什么在 OpenHarmony 上选 React Native

先聊聊技术选型。现在做 OpenHarmony 应用，原生语言是 ArkTS 和 ArkUI，这个组合本身挺好用，声明式 UI 写起来也顺手。但问题在于，很多团队不是只做 OpenHarmony 一个平台，手里可能还压着 Android 和 iOS 的存量业务，不可能为了一套系统单独养一个原生团队。

React Native 的价值在这里就体现出来了——它提供了一层相对成熟的跨平台抽象，业务代码写一遍，渲染层在 Android 上走原生组件，在 OpenHarmony 上通过适配层映射到 ArkUI 组件。这样搜索页这套逻辑，包括历史记录管理，就只需要维护一份代码，三个平台共用。

OpenHarmony 社区现在对 React Native 的支持已经走过了“能跑”的阶段，很多基础组件像 Text、TextInput、ScrollView 都有对应的适配实现。当然，第三方原生模块的生态还比较薄，后面我会专门说怎么自己补。

1.2 历史记录管理的核心难点拆解

搜索历史这个功能，表面看就是“用户搜完，把关键词存起来，下次打开显示”。但真正落地的时候，难点集中在下面这几个地方：

第一是存储方案选型。历史记录这种数据，量不大，单条就是一行字符串，但读写频率不低——每次搜索都要追加，每次打开页面都要读取。既要稳定，又要快，还要能持久化。在 OpenHarmony 的 RN 环境下，到底用 AsyncStorage、MMKV 还是数据库，需要仔细掂量。

第二是数据结构和去重策略。存下来的关键词不能无限膨胀，要给个上限。用户反复搜同一个词，不能存两条。这里还涉及一个细节：匹配时是区分大小写，还是忽略大小写？全角半角要不要统一？做过的人都知道，这一步不处理好，后面数据就乱了。

第三是跨组件通信和状态同步。搜索页里，搜索框是输入组件，历史记录展示区是另一个组件。用户点击历史里的某条记录，搜索框要立刻回填；用户清空历史，展示区要马上消失。这种同步关系如果靠手动处理事件，代码会越写越乱。

第四是和 OpenHarmony 生命周期的配合。RN 页面在 OpenHarmony 上运行，本质上还是托管在一个原生容器里。页面切换、应用退后台、容器回收，这些时机如果没处理好，会出现数据还没存完就被杀掉的情况。

1.3 方案选型对比：本地存储还是后端接口

历史记录有两种主流实现路线。一种是把历史数据上报到后端，每次搜索时通过接口拉取。另一种是纯本地存储，全部逻辑都留在端上。

这两条路线我第一次做的时候犹豫了很久，后来果断选了本地存储，原因很直接：

延迟方面，本地异步读取大概十几毫秒就完事，走接口的话，服务器再快也得有个网络往返，搜索页首屏会明显变慢。

隐私方面，搜索记录算比较敏感的个人数据，上报到服务器就得考虑脱敏、加密、合规这些问题，本地存储直接绕开了这一层。

离线可用方面，本地存储不管有没有网都能正常工作，这在 OpenHarmony 目前常见的一些行业终端场景里特别重要，比如工业平板、医疗设备，网络环境并不稳定。

当然，本地存储也有代价——数据不出端，就没法做到多设备同步。如果你做的是类似电商 App 那种需要“手机搜完，平板上接着显示”的业务，那就要再加一层云同步逻辑。单就 SearchBar 历史记录管理这个需求来说，本地存储是性价比最高的方案。

2. 核心细节解析：数据模型、存储选型与状态管理

2.1 历史记录的数据模型设计

先定义清楚存什么。一个完整的历史记录项，只存一个关键词字符串是不够的，后面会没法做“时间倒序展示”和“删除单条记录”。所以我给每条记录加了时间戳：

typescript复制export interface SearchHistoryItem {
  keyword: string;
  timestamp: number;
}

export interface SearchHistoryStore {
  capacity: number;
  updatedAt: number;
  items: SearchHistoryItem[];
}

解释一下这个设计：

keyword 是核心，但存的时候我会先做一次处理——trim 掉首尾空格。我见过很多搜索记录里混着"\n"和连续空格，都是用户从其他地方复制粘贴过来的，不处理干净后面做关键词匹配会很痛苦。

timestamp 用的是 Date.now() 毫秒级时间戳。历史记录展示时一般会做“今天”“昨天”“更早”的分类，这个时间戳要足够精确。

capacity 是容量上限，存进数据本身里。为什么要存？因为每次写入都要做“超上限就裁剪”的逻辑，如果这个上限值是 hardcode 在代码里的，以后想调整就得发版。存在数据里，以后可以做设置项动态调。

还有一个容易忽略的点：格式化校验。从 AsyncStorage 读出来的 JSON 字符串，转成对象后，不能假设每个字段都在。版本升级、数据损坏、手动改过存储，都可能出现缺字段的情况。所以封装读取方法时，我一定会做一层字段校验，缺了就返回空列表，而不是直接崩溃。

2.2 三种存储方案实测对比

OpenHarmony 的 RN 环境下，本地存储的主流选择有三个：AsyncStorage、MMKV、还有直接调系统偏好存储。

AsyncStorage 是我这次实际用的方案。它是社区基准库，RN 官方文档里也常出现。原理上它是把数据序列化成 JSON 后，在原生层写入一个本地维护的数据库中。接口设计简单，getItem、setItem 字面意思就能懂。在 OpenHarmony 适配层上，已经有可用的实现，配合 RN OHOS 的应用容器可以直接跑通。

MMKV 是腾讯开源的高性能 key-value 组件，核心优势在性能——写入是 mmap 内存映射，理论上会比 AsyncStorage 快不少。但问题在于，MMKV 需要原生模块支持，OpenHarmony 上虽然有移植版本，但我实测时发现某些 RN 版本下原生模块的链接会出现符号找不到的情况，需要手工改构建配置。如果不是对写入性能有极端要求，不建议在 OpenHarmony 上首选它。

系统偏好存储 指的是直接通过 OpenHarmony 的轻量级偏好数据库来做。RNC 的适配层提供了对应桥接接口，但用法上不够通用，Android 和 iOS 上没法用同一套代码。

三个方案我整理成一个对比表：

| 方案 | 性能 | OpenHarmony 适配 | 跨端一致性 | 推荐度 |