Emotiona 轻尘1. 项目从哪儿来：需求与定位
1.1 特惠游戏模块到底要做什么
先把这个项目说清楚。这是一个基于React Native的跨端应用，目标平台之一是OpenHarmony，项目内容是一个Steam游戏资讯类App，而我负责的重点模块是“特惠游戏”——也就是把Steam商店里正在打折、有促销活动的游戏，整理成一个列表展示给用户。用户在列表里能直接看到折扣百分比、原价、折后价、封面图，点击卡片还能进入游戏详情页。
听起来好像就是一个列表页加上详情页，但在实际开发里，这个模块要处理的东西比想象中多。Steam的公开接口有一套自己的数据规范，返回的JSON结构并不是开箱即用的；价格字段的单位是“分”而不是“元”，处理不好就会在界面上摆出离谱的数字；图片资源又是典型的高清大图，加载速度直接决定首屏体验。更要命的是，在OpenHarmony这类新兴平台上，React Native的表现和Android/iOS并不完全一致，很多在移动端习以为常的能力，到了OpenHarmony上要么不支持，要么行为有差异。
所以这篇文章里的“特惠游戏实现”，我打算从需求分析开始，一路讲到架构设计、数据链路、UI实现、工程配置，最后落到启动白屏优化和真机调试。不管你是准备在OpenHarmony上跑RN，还是纯粹想看看Steam资讯类应用怎么落地，我觉得这篇文章都能提供一份比较完整的参考答案。
1.2 为什么选React Native for OpenHarmony
很多人在选型阶段会纠结：OpenHarmony上做应用，到底是直接用ArkTS原生开发，还是用React Native for OpenHarmony（后面我统一叫RNOH）这种跨端框架？这个问题没有标准答案，取决于团队背景和项目约束。
我们团队的情况比较典型：前端和移动端都已经深度使用React技术栈，Android和iOS端已经有一个基于React Native的资讯类App在运行。现在要新增OpenHarmony版本，如果用ArkTS从头写，等于把整个App再实现一遍，UI要重写，业务逻辑要重跑测试，数据层也要重新对接，周期至少翻倍。而RNOH提供了一条路径：把现有React Native代码尽可能复用，然后通过鸿蒙工程接入。
RNOH本质上就是React Native的OpenHarmony端实现。它的原理是把React Native的C++核心、JS引擎、组件渲染管线都移植到OpenHarmony的运行时环境上，JS代码和React组件照常运行，原生UI由鸿蒙的系统组件接管。这带来的直接收益就是：团队不用学一门新语言，业务代码不用大规模改动，跨端一致性有保障。特惠游戏这个模块从开始规划到能跑在开发板上，前后大概两周时间，其中很大一部分功劳就是代码复用。
1.3 技术路线的优势与风险
当然，RNOH也有它现阶段的问题。最直观的一点是第三方生态还不完善，很多在React Native生态里好用的库，在RNOH上要么编译不过，要么运行时行为异常。举个例子，我在特惠列表里想用一个卡片滑动删除组件，npm上找了一个在Android/iOS上很成熟的库，但装到RNOH工程里直接报错，最后只能自己用RN基础组件封装一个简化版。
另一个问题是版本对齐非常敏感。RNOH对React Native官方版本的支持是滞后的，RN已经升级到0.7x、0.8x，RNOH往往还停留在某个固定版本上。这就要求你在创建工程时，必须严格参照RNOH官方文档给出的版本组合，不能直接去装最新版React Native，否则编译阶段就会撞上一堆莫名其妙的错误。
所以我在这篇文章里反复强调“以项目实战为核心”，就是因为这类跨端移植项目，最大的成本不在于功能本身，而在于工程适配和问题排查。接下来我会把特惠游戏模块从数据到界面的完整实现路径拆开讲，该给代码的地方给代码，该给经验的地方给经验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构与数据链路设计
2.1 三层架构：把平台差异挡在门外
项目启动之前，我先把代码结构梳理了一遍。特惠游戏模块要同时跑在Android/iOS和OpenHarmony上，如果业务代码里到处都夹杂着平台判断，后续维护就是一场灾难。所以我采用了经典的三层结构：业务UI层、数据服务层、原生桥接层。
业务UI层就是React组件，负责页面渲染和交互。特惠列表页、游戏卡片、折扣角标、倒计时文本，全部用React Native基础组件实现。这一层尽量不依赖任何平台特有API，这样RNOH和RN之间几乎不用改代码。
数据服务层负责和网络打交道。拉取Steam接口、解析JSON、格式化价格、缓存列表数据，都在这一层完成。数据层对外只暴露干净的TypeScript接口，UI层不关心数据是从网络来的还是从缓存来的。
原生桥接层是把OpenHarmony特有的系统能力暴露给JS端。比如获取设备信息、读取本地存储、推送通知等。这个桥接层是RNOH和RN之间最容易出现差异的地方，所以我把所有平台相关调用集中到这个目录里，万一以后RNOH版本升级导致API变化，只改这一个地方就行。
这个架构的好处是，在开发特惠游戏模块时，我大部分时间都只关注业务UI和数据逻辑，平台差异被隔离到了最底层。实际开发中，这一层结构帮我避免了很多麻烦，比如后面要说的启动白屏优化，只需要在原生桥接层和鸿蒙原生工程上做文章，JS端几乎不用动。
2.2 Steam公开接口的数据模型与坑
特惠游戏的数据来源是Steam商店的公开接口，不需要API Key，也不限频（当然不建议高频调用）。最常用的有两个接口：
第一个是featuredcategories，返回首页推荐的分区数据，其中有一个分区是“Special Offers”，也就是特惠区。这个接口能直接拿到当前正在促销的游戏列表、折扣百分比、原价、折后价、封面图URL等核心信息。第二个是appdetails，按appid获取游戏详情，包括类型、发行商、简介、截图等，列表页点击进入详情页时使用。
这两个接口都是RESTful风格，返回JSON，在React Native里直接使用fetch请求即可。但接口返回的结构有一个很典型的坑：featuredcategories返回的顶层不是数组，而是一个以分区ID为key的对象，“0”通常代表特惠区，但这个key并不是稳定的，接口调整时可能不存在。而items数组里的每个元素，字段也有可能缺失，比如某些游戏没有折扣，discount_percent就是0，或者价格字段为null。
我贴一下featuredcategories接口的核心数据结构，实际返回大概是这个样子：
json复制{
"0": {
"id": 0,
"name": "Special Offers",
"items": [
{
"id": "570",
"type": "app",
"name": "Dota 2",
"discount_percent": 50,
"original_price": 2800,
"final_