这两年跨端技术圈最热闹的话题除了 Flutter 的持续扩张就是 React Native 在国内鸿蒙化过程中的重新起飞。我在某个大型电商项目里正好完整经历了从 React Native 写商城业务再到适配 HarmonyOS NEXT 的全过程。这篇文章不聊虚的就讲讲商城这种重度业务场景下React Native 究竟怎么架构、怎么优化列表、怎么处理商家和推荐这类复杂模块以及最后一步——鸿蒙跨端适配——到底适配的是什么、坑埋在哪里。适合谁来读如果你正准备用 React Native 搭建一个正经的电商 App或者你手里的 RN 项目正准备往鸿蒙上迁移这篇文章可以帮你省掉至少两周的调研时间。我默认你有一定的 RN 基础但不要求你熟悉鸿蒙开发后面的适配部分我会把前置知识讲清楚。1. 为什么电商类 App 是验证跨端框架的试金石很多人觉得电商 App 不就是商品列表加购物车吗真做起来才知道商城业务几乎把移动端能遇到的复杂场景全占了。商品展示牵扯图文混排和价格样式分类导航要处理多级联动推荐系统需要埋点和个性化请求商家模块有独立店铺页和评分体系再加购物车、订单、支付结果回调——这些模块交织在一起对跨端框架的渲染性能、内存管理、原生能力调度都是极限测试。1.1 商城业务的复杂度到底藏在哪里我先列一下当时我们业务梳理出来的模块清单你感受一下首页信息流Banner、金刚区、秒杀位、瀑布流推荐、榜单卡片一个页面六种以上异构卡片分类体系两级分类联动左侧类目右侧商品网格还要支持搜索联想商品详情图片轮播、SKU 弹窗、规格选择、库存联动、店铺卡片进入商家页商家中心店铺装修、商品橱窗、优惠券领取、店铺评分雷达图购物车全选反选、数量步进器、失效商品分组、价格试算订单流程确认订单、地址选择、支付渠道、结果页倒计时每个模块都是“看着简单、做着繁琐”的类型。比如 SKU 规格选择前端要处理的是多维规格组合和库存映射稍有不慎就会出现“有货显示无货”“价格算错”这类致命 Bug。跨端框架在这里的考验是JavaScript 侧的运算效率能不能撑起规格组合的实时计算原生组件能不能在弹窗里流畅渲染商品图片。1.2 React Native 在商城场景的优势与代价选 React Native 而不是 Flutter 或纯原生我们有自己的考量。RN 最大的优势是热更新——电商业务的运营活动变更极其频繁如果每次上 Banner 都要走应用商店审核活动排期根本排不过来。RN 的 JS Bundle 可以远程下发运营位、活动页、甚至部分业务逻辑都能动态更新这一点对商城来说是刚需。代价也很明显。RN 的长列表性能在复杂卡片场景下需要做大量优化否则商品瀑布流能直接卡成 PPT图片加载在弱网环境下需要精心设计降级策略还有大量原生 UI 组件需要封装桥接。说白了RN 不是拿来即用的银弹它只是帮你把跨平台成本降下来了剩下的性能工程和原生能力封装一个都跑不掉。2. 商城模块的架构拆分与数据流设计商城项目最忌讳的就是把所有页面塞进一个巨大的组件树里。我们采用的是“业务模块隔离 数据流集中”的架构每个一级模块首页、分类、购物车、商家是一个独立的业务包内部自管状态跨模块的数据登录态、购物车数量、地址才走全局 Store。2.1 模块划分的实践按业务域而非页面划分很多团队按页面来组织目录我觉得这是思路上的偷懒。商城页面之间的数据复用非常频繁商品卡片在首页、搜索页、商家页都出现如果按页面划分同样的 UI 组件要在三个地方各自维护一份改个价格标签样式能改到怀疑人生。我们按业务域划分大致长这样src/ modules/ home/ # 首页 category/ # 分类 product/ # 商品详情 cart/ # 购物车 order/ # 订单 merchant/ # 商家 common/ # 跨模块通用组件 ProductCard/ # 商品卡片是重点 PriceTag/ # 价格组件 CountStepper/# 数量步进器 store/ # 全局Store services/ # 接口层 native/ # 原生桥接封装商品卡片做成一个高度配置化的组件入参是商品数据和展示模式列表、网格、横滑内部根据模式自动切换布局。这样首页瀑布流、搜索列表、商家橱窗里的商品卡片是同一套逻辑运营位想要加个角标改一处就全端同步。2.2 状态管理的选型最后我们选了 ZustandRedux 和 MobX 我都用过但在商城这个场景里最终选的是 Zustand。原因有三点第一Redux 的样板代码太多了。一个商品加入购物车这种高频操作在 Redux 里要写 Action、Reducer、Selector一个简单状态变更要跨三个文件。商城的状态变更极其频繁样板代码直接拖慢开发效率。第二Zustand 的性能更可控。它基于发布订阅模式只有订阅了某个状态切片State Slice的组件才会触发重渲染。商城页面大而复杂如果用 Redux 加全局 Store一个购物车数量变更可能引发十几个无关组件重渲染这在低端安卓机上就是肉眼可见的掉帧。第三Zustand 支持在 React 组件外部读取状态。这个能力对商城特别重要——比如网络请求拦截器里要读取登录态回调函数里要修改购物车数量这类场景不需要 Hooks直接调用 Store 方法即可。核心的 Store 设计如下购物车是典型的全局状态import { create } from zustand; interface CartState { items: CartItem[]; totalCount: number; addItem: (item: CartItem) void; removeItem: (skuId: string) void; updateQuantity: (skuId: string, quantity: number) void; } export const useCartStore createCartState((set, get) ({ items: [], totalCount: 0, addItem: (item) { const items [...get().items]; const existing items.find((i) i.skuId item.skuId); if (existing) { existing.quantity item.quantity; } else { items.push(item); } set({ items, totalCount: items.reduce((sum, i) sum i.quantity, 0), }); }, }));注意一个细节购物车数量要单独剥离成一个字段totalCount而不是让每个页面自己去累加items。因为首页右上角的购物车角标、TabBar 的徽标、购物车页的总价都要监听这个数字如果每次都去遍历数组既浪费性能又容易出错。2.3 推荐系统的客户端拉取与渲染策略推荐系统在客户端要做的事其实不复杂向后端请求推荐流然后渲染。复杂的是“沉浸式”体验和“无限加载”的实现。我们的做法是分页游标方案。首页底部推荐区采用FlatList的onEndReached触发下一页请求请求参数携带上一页返回的cursor后端返回新一批商品数据和新的cursor。这里有个容易踩的坑onEndReached的触发阈值设太小会导致连续请求设太大又会让用户滑到底部后等半天。我们最终将onEndReachedThreshold设为 0.5并在请求状态上加了一个loading锁防止重复请求。推荐流的商品埋点也不能忽视。每次请求会返回一个recommendId推荐位批次 ID每条商品带itemId和position。客户端需要在卡片曝光和点击时上报这些参数否则后端的推荐算法无法调优。3. 商品列表性能优化从 FlatList 到虚拟化长列表的极限压榨商城 App 里最核心的流量承载体就是列表页。首页信息流、搜索列表、分类商品页全部是长列表。RN 官方说 FlatList 自带虚拟化但实际用下来不经过调优的 FlatList 在复杂商品卡片场景下照样卡。3.1 FlatList 初见为什么还是卡第一次做性能测试时我们在中端安卓机上滑首页信息流帧率只有不到 30 帧滑动明显粘滞。用自带性能监测工具一看JS 线程每帧的执行时间经常超过 100ms这意味着 JavaScript 在图片解码、样式计算、组件渲染上耗掉了大量时间。原因是商城商品卡片太“重”了。一张卡片里有商品主图、价格标签、标题、店铺信息、优惠券标记、评分还可能嵌套一个横滑推荐模块。FlatList 默认的虚拟化机制是窗口化渲染但每个 Item 自身的渲染成本太高窗口内的 10 个 Item 也能把 JS 线程压垮。3.2 从 FlatList 优化到列表项瘦身我们做了三件事来降低单卡渲染成本。第一件把商品卡片改为纯原生优先的组件。图片用FastImage替代内置 Image并设置resizeMode为cover避免图片在 JS 侧做复杂布局计算。价格标签用纯文本拼装而非多个 Text 嵌套——商城价格有删价格、现价、货币符号三个视觉元素很多开发者用三个 Text 嵌套实现但每多一个 Text 节点就多一次布局计算我们直接用Text的children数组拼接并设定基准字号。第二件把横滑推荐模块从商品卡片中拆出去。首页的横滑“猜你喜欢”其实是一个独立的FlatList嵌套在竖向FlatList的 Item 里。嵌套虚拟化列表天生难优化我们干脆把它抽成单独的原生组件封装用原生RecyclerView的横向模式承载JS 侧只负责传数据。第三件是最关键的一步——记忆化 Item 渲染。我们用React.memo包裹商品卡片组件并通过对比productId和price等关键字段来决定是否重渲染。这里一定要做浅比较不要在 Item 组件内部接收整个列表数据否则memo就失效了。const ProductCard memo( ({ product, onPress }: { product: Product; onPress: () void }) { return ( View style{styles.card} FastImage source{{ uri: product.mainImage }} style{styles.image} / Text style{styles.title} numberOfLines{2}{product.title}/Text PriceTag price{product.price} originalPrice{product.originalPrice} / Text style{styles.sales}已售 {product.sales}/Text /View ); }, (prev, next) prev.product next.product );3.3 图片加载、缓存与降级的工程化方案商城列表 70% 以上的流量都是图片。图片加载做不好列表优化做得再好都是白搭。我们使用的图片方案分为三层CDN 裁剪、本地两级缓存、弱网降级。CDN 端在图片 URL 上拼接宽高参数让服务端按需返回合适尺寸的图片——列表页只请求 300px 宽的缩略图商品详情页才请求 750px 的大图而不是所有场景共用一张原图这样能省掉大量带宽和内存开销。本地缓存用的是FastImage自带的磁盘缓存它基于原生图片加载框架实现磁盘缓存命中率很高再次滑动时不需要重新下载。弱网降级是我们自己封装的逻辑当图片加载失败或超时超过 3 秒时展示一张内置的占位图并在下次进入网络状态良好时自动重试。千万不能让图片加载失败的区域白屏商城列表一旦出现白块用户第一反应就是卸载 App。3.4 加购、收藏、点赞的交互优化与异步处理商城里加购和收藏是最高频的交互之一处理不好会直接影响转化率。核心原则是先乐观更新再请求接口。比如用户点击加购我们先把购物车 Store 里的数量加 1立刻刷新角标同时发起网络请求。如果请求失败再回滚。这样用户感知到的响应是即时的不会因为网络延迟而反复点击按钮。收藏按钮同理点击后立即切换心形图标状态后续请求失败才恢复原状并弹 Toast 提示。这里的细节是防重复提交。加购接口的幂等性很差用户快速点两次加购可能生成两条重复订单记录。我们用一个简单的内存锁解决let addingToCart false; async function addToCart(skuId: string) { if (addingToCart) return; addingToCart true; try { await requestAddToCart(skuId); } finally { addingToCart false; } }注意这个锁要在模块级别定义不能放在组件内部否则组件重新渲染时锁会丢失防重复逻辑就失效了。4. 鸿蒙跨端适配从旧架构到 HarmonyOS NEXT 的迁移实录终于到了文章标题里的重头戏——鸿蒙适配。先纠正一个误区很多人以为鸿蒙适配就是把 JS Bundle 塞进鸿蒙的 WebView 或者套个壳这是完全错误的做法。RN 要真正跑在 HarmonyOS NEXT 上必须让 JS 引擎、渲染层、原生模块调度都跑在鸿蒙自家的运行环境里而不是 Android 兼容层。4.1 鸿蒙适配到底适配什么RN 的技术栈包含三个核心层JavaScript 引擎、Bridge/异步调度、原生 UI 渲染。Android 上跑 RN依赖的是 Android 的 JSCore 或 Hermes 引擎 原生 View 系统。而 HarmonyOS NEXT 不再兼容 Android 的 APK 格式也不提供 Android 的 View 体系所以 RN 社区必须为鸿蒙单独实现一套运行时支撑。具体来说鸿蒙适配要解决四件事第一JS 引擎的移植。HarmonyOS NEXT 使用自研的 ArkTS 运行时。RN 的 Hermes 引擎需要在鸿蒙的运行时环境上运行这一层已经由社区的 OpenHarmony 版本解决了你不需要自己去编译 JS 引擎但要确认你用的 RN 版本对应的鸿蒙适配包版本。第二原生组件的映射。RN 的View在 Android 上映射到 Android ViewGroup在鸿蒙上要映射到鸿蒙的Component体系。这就是为什么必须引入专为鸿蒙适配的 RN 包而不是直接用默认的 RN 依赖。第三API 桥接层。RN 调用相机、定位、登录等原生能力在 Android 上通过找出原生模块接口获取在鸿蒙上则需要调用鸿蒙的系统接口。第四样式体系的对齐。鸿蒙的布局系统跟 Android 不完全一致部分 CSS 属性比如某些阴影、圆角、渐变方案在两个平台上的渲染效果会存在肉眼可见的差异。4.2 桥接旧代码与新框架的迁移路径我们项目的 RN 版本从旧版本直接升级到同时支持鸿蒙的版本迁移路径大致如下。第一步将 JS 侧的依赖包统一升级到鸿蒙适配版本。重点不是你自己写的业务代码而是第三方库。比如我们用了视觉解决方案、图片缓存库、动画库导航框架这些库在鸿蒙上不一定有对应的适配版本。原则是能换原生鸿蒙版就换不能换的找到社区维护的替代品。第二步处理原生模块。我们有一批自建的原生桥接模块比如支付SDK、推送通道、统计SDK。鸿蒙适配时这些原生模块全部要用鸿蒙的 ArkTS 语言重新写一遍JS 侧调用接口保持不变。说白了就是保持 JS 侧的 API 面不变把底层的原生实现换成鸿蒙的。第三步是样式和布局核对。我们在质检环节跑了一轮全量截图对比把 Android 端和鸿蒙端的商城各页面截图并排比对逐个处理间距、圆角、字体偏移的差异。这个环节很费时间但必须做。4.3 鸿蒙端的组件兼容与样式差异复盘分享几个我们实际遇到的鸿蒙端样式差异。第一个是阴影效果。Android 端shadow相关属性在鸿蒙上的表现偏淡电商卡片常用悬浮阴影来表现层级迁移后你会发现卡片像贴纸一样平。解决办法是给鸿蒙环境单独加一层原生阴影配置或者改用边框加背景色模拟。第二个是安全区适配。鸿蒙的SafeAreaView和 Android 的行为有细微差异尤其是带底部导航条的老款鸿蒙设备。我们最后是手动检测设备底部高度给页面底部加上相应的padding而不是依赖系统组件自动适配。第三个是字体渲染。同样的字号鸿蒙的中文渲染比 Android 略宽这会导致价格标签、按钮文字出现换行。解决方案是给关键文本组件设置adjustsFontSizeToFit或者minimumFontScale让它在极限情况下缩小字号而不是换行。5. 适配过程中最容易踩的五个坑及完整排查链路鸿蒙适配期的 Bug 往往有一个特点不是必现的而是在特定页面、特定交互下才出现。下面这五个坑是我们真刀真枪踩过的每一个我都尽量给出完整的排查思路希望你能直接绕过。5.1 坑一商品图片在鸿蒙上偶发不显示现象用户在鸿蒙设备上浏览首页时偶尔出现某个商品图片加载不出来的情况滚动一下又正常了。Android 端从未出现过。排查链路我们首先怀疑是图片库的鸿蒙适配问题把图片库的日志打开发现报错集中在decode失败。继续跟踪发现失败请求的图片 URL 都带 CDN 参数。进一步用抓包工具对比发现鸿蒙端的图片库在底层拼接参数时把?x-oss-processimage/resize,w_300这类处理参数错误地进行了 URL 编码导致 CDN 识别不了。问题出在图片库的鸿蒙适配版本对 URL 解析逻辑处理不一致。修复方案在请求图片前对 URL 做一次显式的清洗把所有查询参数用原生 API 重新拼接避免库底层的隐式编码问题。5.2 坑二购物车数量角标延迟更新现象用户加购成功后首页右上角的购物车角标偶尔需要好几秒才刷新。排查链路角标组件采用的是全局 Store 数据驱动。我们最初认为是 Store 的订阅更新在鸿蒙上被延迟了。后来加日志发现setState执行后 Store 数据确实已更新但 TabBar 的角标组件没有重渲染。进一步检查发现TabBar 的角标组件被一个传入的navigation对象包裹而该对象在鸿蒙端每次导航时都会生成新的引用导致React.memo的浅比较失效。更奇怪的是这个问题只在特定页面路径下出现——从详情页返回首页时导航对象重建角标组件的 memo 判断失灵。修复方案把角标组件外层包裹的navigation对象剥离让它只依赖 Store 数据。组件层级越深越要小心不要接收容易变化的对象作为 prop。5.3 坑三横滑推荐模块的滑动卡顿现象鸿蒙端首页的横滑推荐模块滑动时明显有掉帧尤其在图片较多的场景下。排查链路我们起初以为又是图片问题但把图片全部换成占位图后仍然卡顿。后来分析发现该横滑模块虽然已经是原生组件封装但我们在原生层每渲染一个 Item 都会创建一个新的视图容器。鸿蒙的组件树对频繁创建销毁的开销比 Android 更敏感。改为在原生层复用容器Item 变化时只更新内容卡顿立即解决。经验总结鸿蒙原生层对视图复用的要求比 Android 更严格任何高频列表中的原生组件都要遵循“容器复用 内容更新”的模式不能想着用完就丢。5.4 坑四安全区底部按钮被手势区遮挡现象确认订单页的“提交订单”底部按钮在鸿蒙设备上有一半被手势条区域遮挡。排查链路页面用了全屏沉浸式布局底部按钮通过position: absolute定位到底部。Android 上系统会自动避开手势条区域鸿蒙上这种定位方式没有自动规避。我们在鸿蒙端不能依赖系统默认行为必须自己获取底部安全区高度。修复方案通过鸿蒙原生模块获取安全区高度将其作为全局常量注入 JS 侧所有绝对布局的底部按钮都动态加上这个 padding。import { NativeModules } from react-native; const { SafeAreaModule } NativeModules; export const BOTTOM_SAFE_AREA SafeAreaModule?.getBottomInset?.() ?? 0;5.5 坑五支付回调丢失导致订单状态卡住现象鸿蒙端拉起支付后部分用户支付成功但 App 内订单状态一直显示“待支付”。排查链路Android 端我们是在原生层通过监听 Activity 的onActivityResult获取支付结果回调。鸿蒙端没有这个机制鸿蒙的支付回调走的是异步事件总线需要在页面挂载时主动注册监听。最初的代码只在 App 启动时注册了一次App 被系统回收或长时间后台运行后监听就失效了。修复方案在订单确认页的useEffect中重新注册支付结果监听并在页面卸载时移除保证每次发起支付前都有一份新鲜的监听在运行。这个修完后再也没有出现过支付状态卡住的情况。6. 上线前的稳定性加固与后续扩展思路鸿蒙适配不是说代码跑起来就完了商城类 App 对稳定性要求极高任何一个闪退都可能直接导致用户流失。我们花了大概两周的时间专门做稳定性加固核心是三个方向异常监控、数据一致性、性能回归。6.1 异常监控与日志采集的鸿蒙化改造Android 端我们原来的异常监控体系在鸿蒙上不生效因为底层采集原理依赖的是 Android 的崩溃机制。鸿蒙端的 RN 层 JS 异常可以复用同一套上报通道但原生层崩溃必须依赖鸿蒙的系统崩溃日志接口。我们花了大半天把一个自家的轻量日志上报库用 ArkTS 重新实现了一遍并接入到 RN 的NativeModules中。这样做的好处是线上用户出现崩溃时我们能同时拿到 JS 侧和原生侧的日志并且能定位到具体是哪个页面、哪个操作触发的。商城业务的排查效率大幅提升。6.2 性能回归的量化指标上线前我们定了一套量化性能标准低于标准的改动不允许发布首页信息流滑动帧率 Android 端不低于 55 帧鸿蒙端不低于 50 帧详情页秒开冷启动到首图渲染不超过 2.5 秒购物车全选/反选操作在 200ms 内完成 UI 刷新图片加载成功率不低于 99%这些指标我们通过两个平台同步跑自动化测试来保证。每次 CI 构建都会跑一遍关键页面的核心路径任何一个指标跌破阈值就会拉爆流水线从机制上倒逼团队重视性能问题。6.3 后续还能怎么扩展商城应用做完了鸿蒙适配这个项目本身的架构也就沉淀下来了。后面我们打算做两件事第一把推荐流的渲染容器进一步下沉到原生层让纯 JS 只负责数据组装进一步压榨性能空间第二探索鸿蒙端上 RN 和原子化服务的混合集成把商城里的高频工具功能拆成可直接触达的服务卡片。如果你也在做类似的跨端商城我的建议是不要等到鸿蒙适配完成才开始考虑架构。早期的模块划分、状态管理选型、组件设计直接决定了后期适配的工作量。商城业务本身就是大型应用的最佳练兵场把列表性能、状态管理、动态化发布、多端适配这一套打下来你在移动端领域能走的路就宽很多了。