上个月接到一个需求把团队现有的动漫社区应用 AnimeHub 移植到 OpenHarmony 设备上第一个要交付的页面就是收藏页面。这个页面看起来不复杂——展示用户收藏过的动漫列表支持取消收藏、下拉刷新、点击进详情页。但真正动手之后才发现RN for OpenHarmony 这六个字背后藏着一整条链路的问题选型、环境、桥接、性能、生态差异每一步都可能翻车。这篇文章我就把自己做 AnimeHub 收藏页面这段实战经历完整记录下来包括为什么选 React Native 而不是 ArkTS 原生收藏页面的需求到底该怎么拆RN 工程怎么跑上 OpenHarmony数据层和 UI 层怎么落地以及真机调试时踩到的坑。如果你正准备在 OpenHarmony 上做 RN 开发或者单纯好奇这条技术路线现在到底能不能用这篇应该能帮你省不少时间。1. 选型复盘为什么是RN而不是ArkTS原生开发1.1 OpenHarmony应用的三种主流开发路线先说结论在 OpenHarmony 上做应用目前主要就三条路——ArkTS/ArkUI 原生、Flutter、React Native。每条路背后都有一批人在踩坑也都有各自适合的场景但很多人一开始就陷入了sologan 之争原生党说跨平台性能差跨平台党说原生开发慢。实际做项目的时候这个争论毫无意义你只需要看自己的约束条件。ArkTS/ArkUI 是 OpenHarmony 官方主推的原生方案性能确实最好平台能力也是最新的菜单、弹窗、安全控件这些系统能力都是第一时间支持。但问题是ArkTS 这语言太新了团队里没几个人写过从零开始学再加业务开发工期根本压不住。而且你如果有 Web 端或者安卓端的存量业务ArkTS 一套代码完全没法复用。Flutter 在 OpenHarmony 上也有社区适配渲染性能很能打Dart 语言也相对好上手。但 Flutter 的 OpenHarmony 适配版本滞后比较明显很多插件都要自己改遇到平台能力缺口的时候排查问题的难度比 RN 更高。React Native 这条路最初我是犹豫的因为它在安卓和 iOS 上的老架构性能一直被诟病。但后来我仔细盘了一下自家团队的情况前端工程师占大头React 技术栈非常熟公司还有一套跑在安卓上的 RN 业务代码可以抽取复用。RN for OpenHarmony 虽然不是官方出品但社区迭代速度肉眼可见已经有完整的组件映射和桥接方案。综合下来RN 是这三条路里最能用现有团队、保现有资产、控交付周期的路线。1.2 RN for OpenHarmony 的生态现状摸底决定走 RN 之后我先花了两天时间把社区适配情况摸了个底。目前主流的适配项目是 react-native-openharmony它通过 OpenHarmony 侧的组件映射和桥接层把 RN 的 JS 运行时、渲染指令和原生组件翻译成鸿蒙的 ArkUI 组件。也就是说你写的View最后会映射成 ArkUI 的Column或者StackText映射成TextImage映射成Image。需要冷静看待的是它的版本跟进速度。RN 官方现在都推到 0.78 了但 OpenHarmony 适配版还停留在 0.72 左右的基线新架构 Fabric 的适配也只在早期验证阶段。这意味着你在 npm 上看到的最新版 RN 组件很多都没法直接用得在 0.72 这个生态里找兼容版本。不过对我这个 AnimeHub 收藏页面来说这个限制影响不大。我要用的核心组件无非就是 View、Text、Image、FlatList、TouchableOpacity这些都是最基础的映射组件适配成熟度已经很高不用整天跟原生层缠斗。真正要小心的是一些需要原生能力支撑的三方库比如图片缓存、网络请求、本地存储这部分我后面单独讲。1.3 当时做的技术决策清单为了让自己事后不后悔我把决策依据写成了清单这里直接分享给你参考团队技术栈前端 8 人有 5 人熟练 React/RNArkTS 只有 1 人看过文档。选 RN 意味着全员可以立刻进入开发状态选原生意味着要先花 3-4 周培训。业务复用AnimeHub 已经有 Web 端管理后台收藏列表的数据结构、图片裁剪规则、分页协议都是现成的RN 可以直接复用相同的接口设计。页面性能要求收藏页是一个典型的长列表页面不涉及高频刷新的复杂动画。RN 的 FlatList 在优化到位的情况下完全能保障每秒 60 帧的滚动体验。交付周期整个 AnimeHub 项目第一版要求 6 周内出可演示的 Demo收藏页面只是其中一个模块。RN 的开发效率在这里是决定性优势。生态风险RN for OpenHarmony 目前还不支持新架构的完整能力所以我把新架构落地标记为长期观察项而不是当前阻塞项。2. 需求拆解收藏页面到底要解决哪些问题2.1 收藏场景的业务闭环分析收藏页面的第一个坑就是把它当成一个单纯列表页来做。实际上收藏是一个典型的业务闭环入口和出口都比表面上多。用户从动漫详情页点击收藏按钮数据写入收藏列表然后这个列表被带到收藏页面展示用户在这里再次点击取消收藏数据要从列表移除。这个闭环里还夹着登录态、收藏数统计、服务端同步等问题。我在 AnimeHub 里把收藏闭环拆成了四个环节收藏动作详情页写入、数据存储本地和服务端双写、列表呈现收藏页拉取和渲染、取消动作用户操作和状态回写。每个环节都有自己的异常场景写入失败怎么办服务端同步失败本地要不要保留取消收藏时接口超时怎么提示如果不把这个闭环想清楚收藏页很容易做成只读死列表连基本的操作反馈都没法保证。2.2 交互细节用户真正在意的是什么做开发的人往往盯着功能能不能跑通但用户在意的是手感。我访谈了团队里几个重度二次元用户总结出收藏页最在意的四个交互点点击卡片任意区域都能进详情但收藏按钮区域不能误触跳转必须做事件拦截。取消收藏要有即时反馈按钮状态从已收藏变回未收藏最好配合一个缩出的动画让用户明确感知到操作生效了。空状态不能是一片白板要有插画、文案和跳转引导把用户从我什么都没有的低落情绪里拉出来。下拉刷新不要重置滚动位置用户看到第 30 条的时候刷新一下结果跳回顶部谁都会崩溃。这些细节看着不起眼但决定了这个页面到底是一个能用的列表还是一个好用的收藏中心。2.3 数据模型设计与详情页联动数据模型是整个页面的地基。我在 AnimeHub 里定义了这样的结构interface AnimeItem { id: string; title: string; coverUrl: string; lastEpisode: number; // 用户看到的最新一集 totalEpisodes: number; // 动漫总集数 tags: string[]; // 类型标签如热血科幻 isFavorite: boolean; // 收藏状态 updatedAt: number; // 服务端最近更新时间用于排序 }这里有个关键决策lastEpisode必须单独存不能每次从详情页现查。因为收藏列表要展示你追到第几集了这个信息如果用户详情页只看了一集回到列表页它必须立刻反映出来不能等重新拉接口。这个字段会让收藏页和详情页产生联动详情页更新了观看进度收藏页下次进入时要同步显示。分页参数也在这个环节定下来我用的是基于游标的分页协议每页 20 条响应里带有nextCursor没有nextCursor就代表没有下一页了。相比传统的page/pageSize游标分页在收藏数据频繁增删的时候更稳不会因为新插入的数据导致翻页重复或遗漏。3. 环境搭建与工程联调让RN跑在开源鸿蒙上3.1 项目初始化与依赖版本选择先说版本。RN for OpenHarmony 的适配版本和 RN 官方版本是绑定的我用的组合是{ react-native: 0.72.15, react-native-openharmony: 0.72.5, react-native-async-storage/async-storage: 1.19.3, react-native-gesture-handler: 2.12.1 }这里要特别强调不要直接安装最新版的 RN。我见过有人用npx react-native init直接拉了一个 0.76 的工程然后去配 OpenHarmony 适配包结果依赖冲突排了一下午。正确做法是先看 react-native-openharmony 官方仓库的 version mapping 表它明确写了支持哪个 RN 版本然后按那个版本初始化工程。初始化完成之后按照仓库的集成文档把 OpenHarmony 原生工程放到harmony子目录下同时配置metro.config.js让 Metro 打包器能找到鸿蒙侧的入口文件。这个入口文件路径和安卓的不一样我一开始漏配了Metro 直接报Unable to resolve module react-native-openharmony/turboModule排查了很久才发现是路径匹配的顺序问题。3.2 桥接层基础JS侧与OHOS原生模块的通信逻辑说一个很多初学者不理解的概念为什么 RN 在 OpenHarmony 上跑还需要一个桥接层因为 RN 的 JS 引擎本身没有能力直接调用 OpenHarmony 的系统 API比如读取本地文件、获取设备信息、弹一个系统的 Toast。这些能力都在 OHOS 原生侧JS 侧必须通过桥接模块发一个消息过去原生侧处理完再回调结果。这个模型和安卓上的Bridge本质上是一样的。在 react-native-openharmony 里桥接模块用 ArkTS 写在原生工程里。比如我写了一个获取设备型号的模块import { TurboModule } from ohos/ReactNativeBridge; export class DeviceInfoModule extends TurboModule { getDeviceModel(): string { return deviceInfo.marketName; } }JS 侧调用的时候import { TurboModuleRegistry } from react-native; const DeviceInfo TurboModuleRegistry.get(DeviceInfoModule); const model DeviceInfo.getDeviceModel();理解了这个机制后面遇到某个 RN 原生模块在 OHOS 上不能用的时候你就知道应对思路了自己写一个桥接模块把系统能力暴露给 JS。收藏页面里拨打电话和读取本地缓存就是这么干的后面踩坑章具体讲。3.3 一次成功的构建过程示范搭建环境最容易卡壳的就是构建。我记录了一次完整成功的构建链路你可以照着走安装 DevEco Studio并配置 OpenHarmony SDK我用的是 API 10 的 SDK。把harmony原生工程导入 DevEco Studio这个工程在项目初始化/集成步骤里生成不要手动新建。配置entry模块的module.json5把包名、版本号和应用图标按实际项目改掉。配置签名。真机调试必须签名模拟器调试可以跳过。我一开始图省事没配签名结果 HAP 包装不上真机报错信息又很隐晦浪费了半小时。执行 hvigor 构建。DevEco Studio 里直接点运行按钮即可它会自动编译原生侧、打包 HAP、然后通过 hdcOpenHarmony 的调试工具类似 adb安装到设备。启动 Metro 服务。在项目根目录执行npm startMetro 会监听 8081 端口提供 JS bundle 给设备加载。在真机上确认 Metro 连接。进入 App 后开发者菜单里检查 bundle 来源是不是你本机 IP:8081。第一次连接必须确认这一步否则页面渲染不出来大概率是网络或来源配置问题。我建议把以上步骤保存成一个BUILD.md文档因为团队成员各自搭建环境时卡的点五花八门但基本都是这里面的某一环节。4. 数据层落地收藏列表的存储、分页与状态同步4.1 本地持久化选型与封装收藏数据需要本地持久化原因很朴素如果用户断网打开 App他至少还能看到上次缓存的收藏列表而不是一个空白页。RN 生态里最常用的持久化方案是 AsyncStorage但它在 OpenHarmony 上不是开箱即用的。我踩过的坑是react-native-async-storage/async-storage这个包虽然声明支持 OpenHarmony但我在真机上测试时发现部分版本在系统重启后数据会丢失怀疑是底层实现没有正确调用 Preferences 的 flush 机制。后来我果断换方案自己写一个桥接模块底层用 OpenHarmony 的 Preferences 存储 API。这个库是同步落盘的可靠性比 AsyncStorage 的异步写入更稳。封装后的调用方式很简单JS 侧不需要关心底层逻辑// storageHelper.ts import { NativeModules } from react-native; const StorageBridge NativeModules.OHOSStorageBridge; export const StorageHelper { async getItem(key: string): Promisestring | null { return StorageBridge.getItem(key); }, async setItem(key: string, value: string): Promisevoid { return StorageBridge.setItem(key, value); }, async removeItem(key: string): Promisevoid { return StorageBridge.remove(key); }, };4.2 分页拉取与加载中/加载失败状态机收藏列表要有分页拉取但真正重要的是把状态定义清楚。我见过太多人只在 state 里放一个data数组然后loading一个布尔值结果一遇到加载失败就卡在没有提示也没有重试的死角。我在 AnimeHub 收藏页里定义了完整的状态机type FetchState | { status: idle } | { status: loading; isInitial: boolean } | { status: success; data: AnimeItem[]; nextCursor: string | null } | { status: error; message: string; retryable: boolean };isInitial字段用来区分首屏加载和分页加载首屏加载显示全屏 Loading分页加载只在列表底部显示一个加载中的行。retryable字段决定错误提示是重试还是返回上一页。这个状态机写清楚之后后续任何 UI 联动都变得非常简单——只需要根据status分支渲染对应组件。分页参数我会在每次请求时带上cursor服务端返回nextCursor。收藏数据本身是高频变动的用户上一秒取消收藏下一秒服务端列表就变了用游标分页可以避免分页错位。4.3 取消收藏的乐观更新与失败回滚取消收藏这个动作常见的做法是等接口返回成功后再更新列表。但这在弱网环境下体验很差用户点了取消转圈两秒才有反应而且要是接口挂了用户以为取消了其实没有。我采用乐观更新点击按钮的瞬间先把本地列表里该项的isFavorite置为 false并从列表中移除然后发起接口请求。请求成功就完事请求失败就把该项插回原位同时弹 Toast 提示取消失败请检查网络。代码结构大概是这样const removeFavorite useCallback(async (item: AnimeItem) { // 记录原位置用于失败回滚 const prevData dataRef.current; const removedIndex prevData.findIndex((d) d.id item.id); // 乐观更新 updateData((d) d.filter((it) it.id ! item.id)); try { await api.removeFavorite(item.id); } catch (err) { updateData((d) { const next [...d]; next.splice(removedIndex, 0, item); return next; }); Toast.show(取消失败请检查网络); } }, []);关键点是记录原位置因为分页列表可能已经滚动过了直接插回数组末尾位置就不对了。用removedIndex能保证数据回到它原来所在的位置视觉上不会产生跳跃感。5. UI实现把收藏卡片做出手感5.1 卡片布局的关键取舍收藏卡片我用的是单列大卡布局而不是双列瀑布流。原因很直接收藏列表要展示的信息量比普通内容流大得多。卡片上要有封面、标题、追更进度、标签、最近更新时间。双列模式下这些信息挤在一起用户阅读效率反而下降。单列卡片的竖向长度我控制在 120 物理像素左右封面尺寸固定为 84x1123:4 比例标题最多两行截断进度信息放在卡片底部整个视觉重心保持稳定。这里有个细节封面图的裁剪模式用resizeModecover并且封面容器隐藏溢出部分这样服务端返回的图片无论什么尺寸都不会撑破卡片布局。5.2 FlatList列表性能配置细节收藏列表理论上可以上千条用 ScrollView 渲染是灾难必须用 FlatList。但默认配置的 FlatList 在低端 OpenHarmony 设备上滚动还是会卡顿需要针对性地调参。我最终采用的配置是FlatList data{favorites} keyExtractor{(item) item.id} renderItem{renderCard} getItemLayout{(_, index) ({ length: CARD_HEIGHT, offset: CARD_HEIGHT * index, index, })} initialNumToRender{6} maxToRenderPerBatch{8} windowSize{7} removeClippedSubviews onEndReachedThreshold{0.3} onEndReached{loadMore} ListEmptyComponent{EmptyState} ListFooterComponent{FooterLoading} showsVerticalScrollIndicator{false} /逐项说下理由getItemLayout最关键它让 FlatList 可以直接计算每个 item 的位置省去动态测量滚动跳转性能提升非常明显。initialNumToRender{6}控制首屏渲染数量避免一次性渲染 20 条导致首帧卡顿。maxToRenderPerBatch{8}控制每帧最多渲染 8 个新 item避免长列表滚到底部时一次性渲染大量组件造成掉帧。windowSize{7}是渲染窗口的高度倍数过大会浪费内存过小会导致快速滚动时白屏7 是实践下来的平衡值。5.3 空状态与骨架屏的取舍很多团队喜欢一上来就做骨架屏但骨架屏只对快速渲染内容的场景有意义。收藏页面的首屏数据如果 200ms 内能返回骨架屏一闪而过用户根本注意不到反而浪费开发工时。我最终只做了全屏 Loading 和空状态两个互补组件。空状态组件我花的心思最多。收藏是用户主动积累的内容如果收藏列表为空用户情绪通常是我怎么没有收藏东西这时文案要正向引导而不是冷冰冰一句暂无数据。我用的文案是喜欢的番剧还没收藏哦配一个手绘风格的看板娘插画下面一个去发现好番按钮。这个按钮结合了收藏页面的深层需求——把用户带回推荐流重新激活收藏业务闭环。5.4 交互动效实现路径取消收藏的动效我用的是 RN 内置的Animated库没有引入额外的动画框架。原因很简单一个缩移动效而已引入 reanimated 还要处理新架构兼容问题在 OpenHarmony 上风险更高。动效逻辑是用户点击取消按钮时卡片先做一次透明度淡出和缩放从 1 缩到 0.85同时卡片 X 轴向右偏移 24 个像素然后才真正从数据源中移除。动画时长 150ms不长不短用户能感知到操作生效但不会觉得拖沓。const scale useRef(new Animated.Value(1)).current; const handleRemove () { Animated.parallel([ Animated.timing(scale, { toValue: 0.85, duration: 150, useNativeDriver: true }), Animated.timing(translateX, { toValue: 24, duration: 150, useNativeDriver: true }), ]).start(() { removeFavorite(item); }); };这里有个细节动画用useNativeDriver: true把动画执行放到原生侧JS 侧只发一次指令性能远好于 JS 驱动动画。OpenHarmony 上 RN 对useNativeDriver的支持已经比较稳定可以放心用。6. 真机调试踩坑实录OHOS独占的那些问题6.1 图片加载被拦网络安全配置的坑第一个让我抓狂的坑是图片加载。模拟器上封面图渲染得好好的一上真机全部变成空白图控制台也没有报错。我一开始以为是图片地址的问题单独在 WebView 里打开那个 URL又能正常显示。排查过程是这样的先确认接口请求有没有发出去在 Metro 面板看到网络请求是发了的说明不是接口层的问题。接着怀疑是 RN 的 Image 组件映射异常把图片换成本地资源测试本地图片能显示说明映射没坏。最后才想到是不是网络安全策略的问题——我用的封面图地址是http://开头OpenHarmony 默认禁止明文流量。在安卓上这个策略叫 cleartext trafficOpenHarmony 也有类似机制需要在module.json5里配置网络安全策略。解决方案是在entry/src/main/resources/base/profile/network_config.json里放行明文流量或者更稳妥的办法把所有封面图换成 HTTPS 地址。我最终选择的是强制 HTTPS因为配置明文流量放开等于降低了全 App 的安全性不值得为图片加载妥协。6.2 拨打电话功能的桥接差异收藏列表里有一个电联催更的入口用户点击可以直接拨打客服电话。这个需求在安卓上写起来很轻松RN 的Linking模块直接调Linking.openURL(tel:10086)就行。但在 OpenHarmony 上RN 适配版的Linking模块对tel:协议支持不完全调用后毫无反应也没有报错。我当时的排查思路是先用Linking.canOpenURL(tel:10086)检测系统是否能处理这个协议返回 false说明系统层面不支持。这就不是 RN 的问题了而是 OHOS 没有把tel:协议映射到电话应用。解决办法只能自己写桥接模块调用系统 API 打开拨号界面。ArkTS 侧的核心代码import { featureAbility } from ohos.abilityFeatureAbility; import { wantConstant } from ohos.abilityWantConstant; export function dialPhone(phoneNumber: string): void { const want { action: wantConstant.Action.dial, uri: tel:${phoneNumber}, parameters: {}, }; featureAbility.startAbility(want); }JS 侧通过自建桥接模块调用效果和原生一致。这个坑给我的教训是在 OpenHarmony 上做 RN 开发任何依赖系统能力的功能都要先在真机验证一遍不能默认安卓怎么跑这里就怎么跑。6.3 本地文件资源与FTP场景的适配AnimeHub 的运营后台会把番剧封面和预告片素材同步到云存储但也有一些素材是放在内部资源服务器上的比如局域网内的 FTP 服务。收藏页有一步下载缓存封面到本地的需求涉及到从 FTP 访问文件的场景。OpenHarmony 访问本地文件或者 FTP 资源时权限模型和安卓不太一样。你需要先在module.json5里声明ohos.permission.READ_MEDIA或ohos.permission.INTERNET等权限而且运行时还要动态弹窗授权不能在后台静默访问存储空间。另外如果图片组件要加载 FTP 或者自定义协议的资源RN 的 Image 组件默认不支持ftp://这类的 URI不能直接塞进 source 里。正确做法是先把远端文件下载到应用沙箱目录再把本地文件路径交给 Image 渲染。我封装了一个downloadFileToCache(url)的工具函数底层用 OHOS 的ohos.request模块下载完了返回本地路径。6.4 热更新与调试端口问题最后一个高频坑是调试连接。RN 开发最爽的是改代码后 CtrlS 页面自动刷新这个能力依赖 Metro 和设备的局域网连接。但 OpenHarmony 真机的网络环境比安卓复杂设备连的 Wi-Fi 和开发机不在同一个网段时Metro 的localhost:8081根本访问不到。我的习惯是启动 Metro 时强制指定 hostnpx react-native start --host 0.0.0.0同时在设备的开发者菜单里手动设置 Debug server host 为开发机的局域网 IP形如192.168.x.x:8081。如果设备无法直连开发机网络还有一个备选方案通过 hdc 做端口映射把设备的 8081 端口映射到开发机的 8081 端口这样设备上的 App 就可以通过localhost:8081访问 Metro 了。这个映射写法是hdc fport tcp:8081 tcp:8081做完映射后再确认设备上 App 的 Debug 地址设为localhost:8081。热更新卡住、页面转菊花的时候九成是这层网络问题没打通。7. 性能优化结合RN新老架构谈OHOS现状7.1 老架构在OpenHarmony上的瓶颈谈到性能优化绕不开 RN 的新老架构对比。老架构也就是 RN 0.72 及之前的版本的核心问题是所有 JS 和原生通信都要经过 Bridge 消息队列走 JSON 序列化异步传递。你以为调用了一个原生模块实际上这条消息要先被序列化跨过 Bridge再被反序列化原生执行完再走同样的流程回来。这个过程在低端 OpenHarmony 设备上的延迟比较明显尤其是滚动列表中频繁触发图片加载、事件上报这种高频操作掉帧是常态。OpenHarmony 适配版目前基本还是基于老架构的桥接模型所以我做收藏页时对 Bridge 调用非常克制。能合并的原生调用就合并比如存储读取我封装成批量接口避免每次滚动都触发一次原生异步调用。7.2 新架构Fabric适配进度与选择建议新架构Fabric JSI TurboModule是对老架构的彻底重构。它的核心变化有两个一是 JS 可以直接通过 JSI 同步调用原生方法不再需要 JSON 序列化和异步桥二是渲染管线从 Shadow Tree 变成事件驱动的同步渲染布局和提交效率大幅提升。直观效果是启动速度更快、列表滚动更流畅、原生模块调用开销趋近于零。但 OpenHarmony 适配版的新架构还处于早期验证阶段社区主线版本都还没把 Fabric 完整跑通。我当时的评估是生产环境继续用老架构新架构作为技术调研跟进。如果项目对列表性能有极端要求优先通过优化 FlatList 配置、图片缓存和减少 Bridge 调用来解决而不是铤而走险切换新架构。7.3 列表流畅度的几项实测优化最后列一下我在 AnimeHub 收藏页上实测有效的几项优化这些都是直接改在代码里的图片缓存收藏列表封面的图片缓存是最大性能提升点。OpenHarmony 上默认的 Image 组件不带磁盘缓存每次滚动到某个 item 都要重新下载图片。我给 Image source 包了一层自研缓存组件下载完成后复用本地路径实测滚动掉帧率从 45% 降到 12%。React.memo 包裹卡片组件收藏列表的数据经常更新比如取消收藏、进度变化如果列表里 500 个 item 全都需要重渲染那性能就废了。用React.memo包住卡片配合稳定的 props 引用数据更新时只有真正变化的 item 会重渲染。避免匿名函数传递renderItem里不要直接写onPress{() ...}每次都创建新函数会让 memo 失效。我把点击处理写成useCallback包裹的稳定函数再传给子组件。onEndReached防重复触发分页加载时onEndReached在边界位置很容易连续触发多次。我在loadMore里加了if (isFetching || !nextCursor) return的守卫避免重复请求。最终在 OpenHarmony 真机设备是四核 A55内存 4GB上测试收藏列表 500 条数据快速滚动帧率稳定在 50-60fps满足上线标准。说实话这个表现比我预期的好。很多说RN 在 OpenHarmony 上不能用的人大概率是没做性能优化就直接下结论了。这个项目做下来我的体会是RN for OpenHarmony 这路目前确实蛮荒很多能力要靠自己造轮子但核心渲染链路和基础组件的成熟度已经能支撑真实业务了。收藏页面只是 AnimeHub 的第一块拼图后面还有播放页、个人中心、评论区每一步翻车留下的经验都会成为下一次重建时的垫脚石。
上个月接到一个需求把团队现有的动漫社区应用 AnimeHub 移植到 OpenHarmony 设备上第一个要交付的页面就是收藏页面。这个页面看起来不复杂——展示用户收藏过的动漫列表支持取消收藏、下拉刷新、点击进详情页。但真正动手之后才发现RN for OpenHarmony 这六个字背后藏着一整条链路的问题选型、环境、桥接、性能、生态差异每一步都可能翻车。这篇文章我就把自己做 AnimeHub 收藏页面这段实战经历完整记录下来包括为什么选 React Native 而不是 ArkTS 原生收藏页面的需求到底该怎么拆RN 工程怎么跑上 OpenHarmony数据层和 UI 层怎么落地以及真机调试时踩到的坑。如果你正准备在 OpenHarmony 上做 RN 开发或者单纯好奇这条技术路线现在到底能不能用这篇应该能帮你省不少时间。1. 选型复盘为什么是RN而不是ArkTS原生开发1.1 OpenHarmony应用的三种主流开发路线先说结论在 OpenHarmony 上做应用目前主要就三条路——ArkTS/ArkUI 原生、Flutter、React Native。每条路背后都有一批人在踩坑也都有各自适合的场景但很多人一开始就陷入了sologan 之争原生党说跨平台性能差跨平台党说原生开发慢。实际做项目的时候这个争论毫无意义你只需要看自己的约束条件。ArkTS/ArkUI 是 OpenHarmony 官方主推的原生方案性能确实最好平台能力也是最新的菜单、弹窗、安全控件这些系统能力都是第一时间支持。但问题是ArkTS 这语言太新了团队里没几个人写过从零开始学再加业务开发工期根本压不住。而且你如果有 Web 端或者安卓端的存量业务ArkTS 一套代码完全没法复用。Flutter 在 OpenHarmony 上也有社区适配渲染性能很能打Dart 语言也相对好上手。但 Flutter 的 OpenHarmony 适配版本滞后比较明显很多插件都要自己改遇到平台能力缺口的时候排查问题的难度比 RN 更高。React Native 这条路最初我是犹豫的因为它在安卓和 iOS 上的老架构性能一直被诟病。但后来我仔细盘了一下自家团队的情况前端工程师占大头React 技术栈非常熟公司还有一套跑在安卓上的 RN 业务代码可以抽取复用。RN for OpenHarmony 虽然不是官方出品但社区迭代速度肉眼可见已经有完整的组件映射和桥接方案。综合下来RN 是这三条路里最能用现有团队、保现有资产、控交付周期的路线。1.2 RN for OpenHarmony 的生态现状摸底决定走 RN 之后我先花了两天时间把社区适配情况摸了个底。目前主流的适配项目是 react-native-openharmony它通过 OpenHarmony 侧的组件映射和桥接层把 RN 的 JS 运行时、渲染指令和原生组件翻译成鸿蒙的 ArkUI 组件。也就是说你写的View最后会映射成 ArkUI 的Column或者StackText映射成TextImage映射成Image。需要冷静看待的是它的版本跟进速度。RN 官方现在都推到 0.78 了但 OpenHarmony 适配版还停留在 0.72 左右的基线新架构 Fabric 的适配也只在早期验证阶段。这意味着你在 npm 上看到的最新版 RN 组件很多都没法直接用得在 0.72 这个生态里找兼容版本。不过对我这个 AnimeHub 收藏页面来说这个限制影响不大。我要用的核心组件无非就是 View、Text、Image、FlatList、TouchableOpacity这些都是最基础的映射组件适配成熟度已经很高不用整天跟原生层缠斗。真正要小心的是一些需要原生能力支撑的三方库比如图片缓存、网络请求、本地存储这部分我后面单独讲。1.3 当时做的技术决策清单为了让自己事后不后悔我把决策依据写成了清单这里直接分享给你参考团队技术栈前端 8 人有 5 人熟练 React/RNArkTS 只有 1 人看过文档。选 RN 意味着全员可以立刻进入开发状态选原生意味着要先花 3-4 周培训。业务复用AnimeHub 已经有 Web 端管理后台收藏列表的数据结构、图片裁剪规则、分页协议都是现成的RN 可以直接复用相同的接口设计。页面性能要求收藏页是一个典型的长列表页面不涉及高频刷新的复杂动画。RN 的 FlatList 在优化到位的情况下完全能保障每秒 60 帧的滚动体验。交付周期整个 AnimeHub 项目第一版要求 6 周内出可演示的 Demo收藏页面只是其中一个模块。RN 的开发效率在这里是决定性优势。生态风险RN for OpenHarmony 目前还不支持新架构的完整能力所以我把新架构落地标记为长期观察项而不是当前阻塞项。2. 需求拆解收藏页面到底要解决哪些问题2.1 收藏场景的业务闭环分析收藏页面的第一个坑就是把它当成一个单纯列表页来做。实际上收藏是一个典型的业务闭环入口和出口都比表面上多。用户从动漫详情页点击收藏按钮数据写入收藏列表然后这个列表被带到收藏页面展示用户在这里再次点击取消收藏数据要从列表移除。这个闭环里还夹着登录态、收藏数统计、服务端同步等问题。我在 AnimeHub 里把收藏闭环拆成了四个环节收藏动作详情页写入、数据存储本地和服务端双写、列表呈现收藏页拉取和渲染、取消动作用户操作和状态回写。每个环节都有自己的异常场景写入失败怎么办服务端同步失败本地要不要保留取消收藏时接口超时怎么提示如果不把这个闭环想清楚收藏页很容易做成只读死列表连基本的操作反馈都没法保证。2.2 交互细节用户真正在意的是什么做开发的人往往盯着功能能不能跑通但用户在意的是手感。我访谈了团队里几个重度二次元用户总结出收藏页最在意的四个交互点点击卡片任意区域都能进详情但收藏按钮区域不能误触跳转必须做事件拦截。取消收藏要有即时反馈按钮状态从已收藏变回未收藏最好配合一个缩出的动画让用户明确感知到操作生效了。空状态不能是一片白板要有插画、文案和跳转引导把用户从我什么都没有的低落情绪里拉出来。下拉刷新不要重置滚动位置用户看到第 30 条的时候刷新一下结果跳回顶部谁都会崩溃。这些细节看着不起眼但决定了这个页面到底是一个能用的列表还是一个好用的收藏中心。2.3 数据模型设计与详情页联动数据模型是整个页面的地基。我在 AnimeHub 里定义了这样的结构interface AnimeItem { id: string; title: string; coverUrl: string; lastEpisode: number; // 用户看到的最新一集 totalEpisodes: number; // 动漫总集数 tags: string[]; // 类型标签如热血科幻 isFavorite: boolean; // 收藏状态 updatedAt: number; // 服务端最近更新时间用于排序 }这里有个关键决策lastEpisode必须单独存不能每次从详情页现查。因为收藏列表要展示你追到第几集了这个信息如果用户详情页只看了一集回到列表页它必须立刻反映出来不能等重新拉接口。这个字段会让收藏页和详情页产生联动详情页更新了观看进度收藏页下次进入时要同步显示。分页参数也在这个环节定下来我用的是基于游标的分页协议每页 20 条响应里带有nextCursor没有nextCursor就代表没有下一页了。相比传统的page/pageSize游标分页在收藏数据频繁增删的时候更稳不会因为新插入的数据导致翻页重复或遗漏。3. 环境搭建与工程联调让RN跑在开源鸿蒙上3.1 项目初始化与依赖版本选择先说版本。RN for OpenHarmony 的适配版本和 RN 官方版本是绑定的我用的组合是{ react-native: 0.72.15, react-native-openharmony: 0.72.5, react-native-async-storage/async-storage: 1.19.3, react-native-gesture-handler: 2.12.1 }这里要特别强调不要直接安装最新版的 RN。我见过有人用npx react-native init直接拉了一个 0.76 的工程然后去配 OpenHarmony 适配包结果依赖冲突排了一下午。正确做法是先看 react-native-openharmony 官方仓库的 version mapping 表它明确写了支持哪个 RN 版本然后按那个版本初始化工程。初始化完成之后按照仓库的集成文档把 OpenHarmony 原生工程放到harmony子目录下同时配置metro.config.js让 Metro 打包器能找到鸿蒙侧的入口文件。这个入口文件路径和安卓的不一样我一开始漏配了Metro 直接报Unable to resolve module react-native-openharmony/turboModule排查了很久才发现是路径匹配的顺序问题。3.2 桥接层基础JS侧与OHOS原生模块的通信逻辑说一个很多初学者不理解的概念为什么 RN 在 OpenHarmony 上跑还需要一个桥接层因为 RN 的 JS 引擎本身没有能力直接调用 OpenHarmony 的系统 API比如读取本地文件、获取设备信息、弹一个系统的 Toast。这些能力都在 OHOS 原生侧JS 侧必须通过桥接模块发一个消息过去原生侧处理完再回调结果。这个模型和安卓上的Bridge本质上是一样的。在 react-native-openharmony 里桥接模块用 ArkTS 写在原生工程里。比如我写了一个获取设备型号的模块import { TurboModule } from ohos/ReactNativeBridge; export class DeviceInfoModule extends TurboModule { getDeviceModel(): string { return deviceInfo.marketName; } }JS 侧调用的时候import { TurboModuleRegistry } from react-native; const DeviceInfo TurboModuleRegistry.get(DeviceInfoModule); const model DeviceInfo.getDeviceModel();理解了这个机制后面遇到某个 RN 原生模块在 OHOS 上不能用的时候你就知道应对思路了自己写一个桥接模块把系统能力暴露给 JS。收藏页面里拨打电话和读取本地缓存就是这么干的后面踩坑章具体讲。3.3 一次成功的构建过程示范搭建环境最容易卡壳的就是构建。我记录了一次完整成功的构建链路你可以照着走安装 DevEco Studio并配置 OpenHarmony SDK我用的是 API 10 的 SDK。把harmony原生工程导入 DevEco Studio这个工程在项目初始化/集成步骤里生成不要手动新建。配置entry模块的module.json5把包名、版本号和应用图标按实际项目改掉。配置签名。真机调试必须签名模拟器调试可以跳过。我一开始图省事没配签名结果 HAP 包装不上真机报错信息又很隐晦浪费了半小时。执行 hvigor 构建。DevEco Studio 里直接点运行按钮即可它会自动编译原生侧、打包 HAP、然后通过 hdcOpenHarmony 的调试工具类似 adb安装到设备。启动 Metro 服务。在项目根目录执行npm startMetro 会监听 8081 端口提供 JS bundle 给设备加载。在真机上确认 Metro 连接。进入 App 后开发者菜单里检查 bundle 来源是不是你本机 IP:8081。第一次连接必须确认这一步否则页面渲染不出来大概率是网络或来源配置问题。我建议把以上步骤保存成一个BUILD.md文档因为团队成员各自搭建环境时卡的点五花八门但基本都是这里面的某一环节。4. 数据层落地收藏列表的存储、分页与状态同步4.1 本地持久化选型与封装收藏数据需要本地持久化原因很朴素如果用户断网打开 App他至少还能看到上次缓存的收藏列表而不是一个空白页。RN 生态里最常用的持久化方案是 AsyncStorage但它在 OpenHarmony 上不是开箱即用的。我踩过的坑是react-native-async-storage/async-storage这个包虽然声明支持 OpenHarmony但我在真机上测试时发现部分版本在系统重启后数据会丢失怀疑是底层实现没有正确调用 Preferences 的 flush 机制。后来我果断换方案自己写一个桥接模块底层用 OpenHarmony 的 Preferences 存储 API。这个库是同步落盘的可靠性比 AsyncStorage 的异步写入更稳。封装后的调用方式很简单JS 侧不需要关心底层逻辑// storageHelper.ts import { NativeModules } from react-native; const StorageBridge NativeModules.OHOSStorageBridge; export const StorageHelper { async getItem(key: string): Promisestring | null { return StorageBridge.getItem(key); }, async setItem(key: string, value: string): Promisevoid { return StorageBridge.setItem(key, value); }, async removeItem(key: string): Promisevoid { return StorageBridge.remove(key); }, };4.2 分页拉取与加载中/加载失败状态机收藏列表要有分页拉取但真正重要的是把状态定义清楚。我见过太多人只在 state 里放一个data数组然后loading一个布尔值结果一遇到加载失败就卡在没有提示也没有重试的死角。我在 AnimeHub 收藏页里定义了完整的状态机type FetchState | { status: idle } | { status: loading; isInitial: boolean } | { status: success; data: AnimeItem[]; nextCursor: string | null } | { status: error; message: string; retryable: boolean };isInitial字段用来区分首屏加载和分页加载首屏加载显示全屏 Loading分页加载只在列表底部显示一个加载中的行。retryable字段决定错误提示是重试还是返回上一页。这个状态机写清楚之后后续任何 UI 联动都变得非常简单——只需要根据status分支渲染对应组件。分页参数我会在每次请求时带上cursor服务端返回nextCursor。收藏数据本身是高频变动的用户上一秒取消收藏下一秒服务端列表就变了用游标分页可以避免分页错位。4.3 取消收藏的乐观更新与失败回滚取消收藏这个动作常见的做法是等接口返回成功后再更新列表。但这在弱网环境下体验很差用户点了取消转圈两秒才有反应而且要是接口挂了用户以为取消了其实没有。我采用乐观更新点击按钮的瞬间先把本地列表里该项的isFavorite置为 false并从列表中移除然后发起接口请求。请求成功就完事请求失败就把该项插回原位同时弹 Toast 提示取消失败请检查网络。代码结构大概是这样const removeFavorite useCallback(async (item: AnimeItem) { // 记录原位置用于失败回滚 const prevData dataRef.current; const removedIndex prevData.findIndex((d) d.id item.id); // 乐观更新 updateData((d) d.filter((it) it.id ! item.id)); try { await api.removeFavorite(item.id); } catch (err) { updateData((d) { const next [...d]; next.splice(removedIndex, 0, item); return next; }); Toast.show(取消失败请检查网络); } }, []);关键点是记录原位置因为分页列表可能已经滚动过了直接插回数组末尾位置就不对了。用removedIndex能保证数据回到它原来所在的位置视觉上不会产生跳跃感。5. UI实现把收藏卡片做出手感5.1 卡片布局的关键取舍收藏卡片我用的是单列大卡布局而不是双列瀑布流。原因很直接收藏列表要展示的信息量比普通内容流大得多。卡片上要有封面、标题、追更进度、标签、最近更新时间。双列模式下这些信息挤在一起用户阅读效率反而下降。单列卡片的竖向长度我控制在 120 物理像素左右封面尺寸固定为 84x1123:4 比例标题最多两行截断进度信息放在卡片底部整个视觉重心保持稳定。这里有个细节封面图的裁剪模式用resizeModecover并且封面容器隐藏溢出部分这样服务端返回的图片无论什么尺寸都不会撑破卡片布局。5.2 FlatList列表性能配置细节收藏列表理论上可以上千条用 ScrollView 渲染是灾难必须用 FlatList。但默认配置的 FlatList 在低端 OpenHarmony 设备上滚动还是会卡顿需要针对性地调参。我最终采用的配置是FlatList data{favorites} keyExtractor{(item) item.id} renderItem{renderCard} getItemLayout{(_, index) ({ length: CARD_HEIGHT, offset: CARD_HEIGHT * index, index, })} initialNumToRender{6} maxToRenderPerBatch{8} windowSize{7} removeClippedSubviews onEndReachedThreshold{0.3} onEndReached{loadMore} ListEmptyComponent{EmptyState} ListFooterComponent{FooterLoading} showsVerticalScrollIndicator{false} /逐项说下理由getItemLayout最关键它让 FlatList 可以直接计算每个 item 的位置省去动态测量滚动跳转性能提升非常明显。initialNumToRender{6}控制首屏渲染数量避免一次性渲染 20 条导致首帧卡顿。maxToRenderPerBatch{8}控制每帧最多渲染 8 个新 item避免长列表滚到底部时一次性渲染大量组件造成掉帧。windowSize{7}是渲染窗口的高度倍数过大会浪费内存过小会导致快速滚动时白屏7 是实践下来的平衡值。5.3 空状态与骨架屏的取舍很多团队喜欢一上来就做骨架屏但骨架屏只对快速渲染内容的场景有意义。收藏页面的首屏数据如果 200ms 内能返回骨架屏一闪而过用户根本注意不到反而浪费开发工时。我最终只做了全屏 Loading 和空状态两个互补组件。空状态组件我花的心思最多。收藏是用户主动积累的内容如果收藏列表为空用户情绪通常是我怎么没有收藏东西这时文案要正向引导而不是冷冰冰一句暂无数据。我用的文案是喜欢的番剧还没收藏哦配一个手绘风格的看板娘插画下面一个去发现好番按钮。这个按钮结合了收藏页面的深层需求——把用户带回推荐流重新激活收藏业务闭环。5.4 交互动效实现路径取消收藏的动效我用的是 RN 内置的Animated库没有引入额外的动画框架。原因很简单一个缩移动效而已引入 reanimated 还要处理新架构兼容问题在 OpenHarmony 上风险更高。动效逻辑是用户点击取消按钮时卡片先做一次透明度淡出和缩放从 1 缩到 0.85同时卡片 X 轴向右偏移 24 个像素然后才真正从数据源中移除。动画时长 150ms不长不短用户能感知到操作生效但不会觉得拖沓。const scale useRef(new Animated.Value(1)).current; const handleRemove () { Animated.parallel([ Animated.timing(scale, { toValue: 0.85, duration: 150, useNativeDriver: true }), Animated.timing(translateX, { toValue: 24, duration: 150, useNativeDriver: true }), ]).start(() { removeFavorite(item); }); };这里有个细节动画用useNativeDriver: true把动画执行放到原生侧JS 侧只发一次指令性能远好于 JS 驱动动画。OpenHarmony 上 RN 对useNativeDriver的支持已经比较稳定可以放心用。6. 真机调试踩坑实录OHOS独占的那些问题6.1 图片加载被拦网络安全配置的坑第一个让我抓狂的坑是图片加载。模拟器上封面图渲染得好好的一上真机全部变成空白图控制台也没有报错。我一开始以为是图片地址的问题单独在 WebView 里打开那个 URL又能正常显示。排查过程是这样的先确认接口请求有没有发出去在 Metro 面板看到网络请求是发了的说明不是接口层的问题。接着怀疑是 RN 的 Image 组件映射异常把图片换成本地资源测试本地图片能显示说明映射没坏。最后才想到是不是网络安全策略的问题——我用的封面图地址是http://开头OpenHarmony 默认禁止明文流量。在安卓上这个策略叫 cleartext trafficOpenHarmony 也有类似机制需要在module.json5里配置网络安全策略。解决方案是在entry/src/main/resources/base/profile/network_config.json里放行明文流量或者更稳妥的办法把所有封面图换成 HTTPS 地址。我最终选择的是强制 HTTPS因为配置明文流量放开等于降低了全 App 的安全性不值得为图片加载妥协。6.2 拨打电话功能的桥接差异收藏列表里有一个电联催更的入口用户点击可以直接拨打客服电话。这个需求在安卓上写起来很轻松RN 的Linking模块直接调Linking.openURL(tel:10086)就行。但在 OpenHarmony 上RN 适配版的Linking模块对tel:协议支持不完全调用后毫无反应也没有报错。我当时的排查思路是先用Linking.canOpenURL(tel:10086)检测系统是否能处理这个协议返回 false说明系统层面不支持。这就不是 RN 的问题了而是 OHOS 没有把tel:协议映射到电话应用。解决办法只能自己写桥接模块调用系统 API 打开拨号界面。ArkTS 侧的核心代码import { featureAbility } from ohos.abilityFeatureAbility; import { wantConstant } from ohos.abilityWantConstant; export function dialPhone(phoneNumber: string): void { const want { action: wantConstant.Action.dial, uri: tel:${phoneNumber}, parameters: {}, }; featureAbility.startAbility(want); }JS 侧通过自建桥接模块调用效果和原生一致。这个坑给我的教训是在 OpenHarmony 上做 RN 开发任何依赖系统能力的功能都要先在真机验证一遍不能默认安卓怎么跑这里就怎么跑。6.3 本地文件资源与FTP场景的适配AnimeHub 的运营后台会把番剧封面和预告片素材同步到云存储但也有一些素材是放在内部资源服务器上的比如局域网内的 FTP 服务。收藏页有一步下载缓存封面到本地的需求涉及到从 FTP 访问文件的场景。OpenHarmony 访问本地文件或者 FTP 资源时权限模型和安卓不太一样。你需要先在module.json5里声明ohos.permission.READ_MEDIA或ohos.permission.INTERNET等权限而且运行时还要动态弹窗授权不能在后台静默访问存储空间。另外如果图片组件要加载 FTP 或者自定义协议的资源RN 的 Image 组件默认不支持ftp://这类的 URI不能直接塞进 source 里。正确做法是先把远端文件下载到应用沙箱目录再把本地文件路径交给 Image 渲染。我封装了一个downloadFileToCache(url)的工具函数底层用 OHOS 的ohos.request模块下载完了返回本地路径。6.4 热更新与调试端口问题最后一个高频坑是调试连接。RN 开发最爽的是改代码后 CtrlS 页面自动刷新这个能力依赖 Metro 和设备的局域网连接。但 OpenHarmony 真机的网络环境比安卓复杂设备连的 Wi-Fi 和开发机不在同一个网段时Metro 的localhost:8081根本访问不到。我的习惯是启动 Metro 时强制指定 hostnpx react-native start --host 0.0.0.0同时在设备的开发者菜单里手动设置 Debug server host 为开发机的局域网 IP形如192.168.x.x:8081。如果设备无法直连开发机网络还有一个备选方案通过 hdc 做端口映射把设备的 8081 端口映射到开发机的 8081 端口这样设备上的 App 就可以通过localhost:8081访问 Metro 了。这个映射写法是hdc fport tcp:8081 tcp:8081做完映射后再确认设备上 App 的 Debug 地址设为localhost:8081。热更新卡住、页面转菊花的时候九成是这层网络问题没打通。7. 性能优化结合RN新老架构谈OHOS现状7.1 老架构在OpenHarmony上的瓶颈谈到性能优化绕不开 RN 的新老架构对比。老架构也就是 RN 0.72 及之前的版本的核心问题是所有 JS 和原生通信都要经过 Bridge 消息队列走 JSON 序列化异步传递。你以为调用了一个原生模块实际上这条消息要先被序列化跨过 Bridge再被反序列化原生执行完再走同样的流程回来。这个过程在低端 OpenHarmony 设备上的延迟比较明显尤其是滚动列表中频繁触发图片加载、事件上报这种高频操作掉帧是常态。OpenHarmony 适配版目前基本还是基于老架构的桥接模型所以我做收藏页时对 Bridge 调用非常克制。能合并的原生调用就合并比如存储读取我封装成批量接口避免每次滚动都触发一次原生异步调用。7.2 新架构Fabric适配进度与选择建议新架构Fabric JSI TurboModule是对老架构的彻底重构。它的核心变化有两个一是 JS 可以直接通过 JSI 同步调用原生方法不再需要 JSON 序列化和异步桥二是渲染管线从 Shadow Tree 变成事件驱动的同步渲染布局和提交效率大幅提升。直观效果是启动速度更快、列表滚动更流畅、原生模块调用开销趋近于零。但 OpenHarmony 适配版的新架构还处于早期验证阶段社区主线版本都还没把 Fabric 完整跑通。我当时的评估是生产环境继续用老架构新架构作为技术调研跟进。如果项目对列表性能有极端要求优先通过优化 FlatList 配置、图片缓存和减少 Bridge 调用来解决而不是铤而走险切换新架构。7.3 列表流畅度的几项实测优化最后列一下我在 AnimeHub 收藏页上实测有效的几项优化这些都是直接改在代码里的图片缓存收藏列表封面的图片缓存是最大性能提升点。OpenHarmony 上默认的 Image 组件不带磁盘缓存每次滚动到某个 item 都要重新下载图片。我给 Image source 包了一层自研缓存组件下载完成后复用本地路径实测滚动掉帧率从 45% 降到 12%。React.memo 包裹卡片组件收藏列表的数据经常更新比如取消收藏、进度变化如果列表里 500 个 item 全都需要重渲染那性能就废了。用React.memo包住卡片配合稳定的 props 引用数据更新时只有真正变化的 item 会重渲染。避免匿名函数传递renderItem里不要直接写onPress{() ...}每次都创建新函数会让 memo 失效。我把点击处理写成useCallback包裹的稳定函数再传给子组件。onEndReached防重复触发分页加载时onEndReached在边界位置很容易连续触发多次。我在loadMore里加了if (isFetching || !nextCursor) return的守卫避免重复请求。最终在 OpenHarmony 真机设备是四核 A55内存 4GB上测试收藏列表 500 条数据快速滚动帧率稳定在 50-60fps满足上线标准。说实话这个表现比我预期的好。很多说RN 在 OpenHarmony 上不能用的人大概率是没做性能优化就直接下结论了。这个项目做下来我的体会是RN for OpenHarmony 这路目前确实蛮荒很多能力要靠自己造轮子但核心渲染链路和基础组件的成熟度已经能支撑真实业务了。收藏页面只是 AnimeHub 的第一块拼图后面还有播放页、个人中心、评论区每一步翻车留下的经验都会成为下一次重建时的垫脚石。
