React Native for OpenHarmony实战：Steam特惠游戏跨端开发全攻略

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，否则编译阶段就会撞上一堆莫名其妙的错误。

所以我在这篇文章里反复强调“以项目实战为核心”，就是因为这类跨端移植项目，最大的成本不在于功能本身，而在于工程适配和问题排查。接下来我会把特惠游戏模块从数据到界面的完整实现路径拆开讲，该给代码的地方给代码，该给经验的地方给经验。

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_price": 1400,
        "currency": "CNY",
        "large_capsule_image": "https://cdn.akamai.steamstatic.com/steam/apps/570/capsule_616x353.jpg",
        "small_capsule_image": "https://cdn.akamai.steamstatic.com/steam/apps/570/capsule_231x87.jpg"
      }
    ]
  }
}

注意几个细节：价格单位是“分”，不是“元”，2800表示28元；如果original_price和final_price都是0，表示免费游戏；封面图URL是完整可访问的HTTPS地址，可以交给React Native的Image组件直接加载。为了不让这些细节影响UI层，我在数据解析层就做了兜底处理，后面会贴代码。

2.3 缓存策略：快速首屏 vs 实时性

特惠列表有一个业务特性：数据不是每秒钟都在变的。Steam的打折活动通常持续几天甚至几周，所以没必要每次都从网络拉最新数据。但如果完全不刷新，用户又可能看到已经失效的促销，体验也不好。所以我的缓存策略是：本地持久化 + 短TTL + 后台静默刷新。

具体做法是，第一次进入特惠页时，先检查本地有没有缓存数据，如果有且缓存时间在10分钟以内，直接渲染缓存，这样首屏秒开；同时后台继续向Steam接口发起一次请求，拿到新数据后覆盖缓存并刷新界面。这样既保证了首屏速度，也保证了数据的实时性。

这个方案还有一个额外的好处：降低对Steam接口的调用频率。这类公开接口虽然没有在文档里写明严格的限流，但如果你在高频调用下触发风控，请求会被拒绝。缓存机制让我们在用户频繁进出页面时，不会每次都打一次接口。

在存储方案上，我用的是AsyncStorage，它在RNOH里也有对应实现，读写简单，适合存JSON字符串。也有人建议用MMKV这类高效存储，但特惠列表数据量并不大，用AsyncStorage就足够了，没必要为了一个小列表引入一个重量级依赖。

3. 特惠游戏核心功能实现

3.1 接口对接与数据解析

这一节直接上代码。首先定义好数据结构，这里我把接口返回的原始字段映射成前端友好的字段名，同时做类型对齐：

typescript复制// models/SpecialOffer.ts
export interface SpecialOfferItem {
  appId: string;
  name: string;
  discountPercent: number;
  originalPrice: string;
  finalPrice: string;
  coverUrl: string;
}

// services/steamApi.ts
const FEATURED_API = 'https://store.steampowered.com/api/featuredcategories';

export async function fetchSpecialOffers(): Promise<SpecialOfferItem[]> {
  const response = await fetch(`${FEATURED_API}?cc=cn&l=schinese`);
  if (!response.ok) {
    throw new Error(`Steam API error: ${response.status}`);
  }
  const json = await response.json();
  return parseSpecialOffers(json);
}

function parseSpecialOffers(raw: any): SpecialOfferItem[] {
  if (!raw || typeof raw !== 'object') {
    return [];
  }
  const special = raw['0'];
  const items = special?.items;
  if (!Array.isArray(items)) {
    return [];
  }
  return items
    .filter((item: any) => item && item.type === 'app')
    .map((item: any) => ({
      appId: String(item.id),
      name: item.name ?? '未知游戏',
      discountPercent: item.discount_percent ?? 0,
      originalPrice: formatPrice(item.original_price, item.currency),
      finalPrice: formatPrice(item.final_price, item.currency),
      coverUrl: item.large_capsule_image ?? item.header_image ?? '',
    }));
}

function formatPrice(value: number | undefined, currency: string): string {
  if (!value || value <= 0) {
    return '免费';
  }
  const amount = (value / 100).toFixed(2);
  const symbol = currency === 'CNY' ? '¥' : '$';
  return `${symbol}${amount}`;
}

这段代码把我在2.2节里提到的三个坑全堵上了：分区缺失返回空数组、item字段为空时给默认值、价格单位做了从分到元的转换。formatPrice里对“免费游戏”做了处理，价格为0的时候显示“免费”，而不是“¥0.00”，体验上更自然。

有一点需要注意：在OpenHarmony上，fetch的底层网络栈是系统提供的，RNOH已经封装好了，JS端不需要额外处理。但工程配置里必须申请INTERNET权限，否则所有请求都会在原生层直接失败，返回的错误也不够直观，排查起来容易让人一头雾水。这个我在第4节工程配置部分还会展开。

3.2 特惠卡片UI与关键视觉细节

数据解析好后，接下来是UI展示。特惠列表我用FlatList来渲染，每个item是一个游戏卡片。卡片布局大致是：上方封面图，图上左上角折扣角标，图下方信息区显示游戏名、原价、折后价。

核心组件代码：

tsx复制import React from 'react';
import {
  View,
  Text,
  Image,
  StyleSheet,
  TouchableOpacity,
} from 'react-native';

interface GameCardProps {
  item: SpecialOfferItem;
  onPress: (appId: string) => void;
}

const GameCard: React.FC<GameCardProps> = ({ item, onPress }) => {
  const hasDiscount = item.discountPercent > 0;
  return (
    <TouchableOpacity
      style={styles.card}
      onPress={() => onPress(item.appId)}
      activeOpacity={0.8}
    >
      <View>
        <Image
          source={{ uri: item.coverUrl }}
          style={styles.cover}
          resizeMode="cover"
        />
        {hasDiscount && (
          <View style={styles.discountBadge}>
            <Text style={styles.discountText}>-{item.discountPercent}%</Text>
          </View>
        )}
      </View>
      <View style={styles.info}>
        <Text style={styles.name} numberOfLines={1}>
          {item.name}
        </Text>
        <View style={styles.priceRow}>
          {hasDiscount && (
            <Text style={styles.originalPrice}>{item.originalPrice}</Text>
          )}
          <Text style={styles.finalPrice}>{item.finalPrice}</Text>
        </View>
      </View>
    </TouchableOpacity>
  );
};

这里有几个视觉细节，我特意在样式上做处理：

• 折扣角标使用绝对定位，放在封面图左上角，背景色用红色，文字白色，这样用户扫一眼就能看到优惠力度；
• 原价使用textDecorationLine: 'line-through'加删除线，折后价用更大的字号和鲜明的颜色，对比更清晰；
• 封面图如果没有加载出来，Image组件的背景色设为浅灰色，避免破图时出现尴尬的白块。

在OpenHarmony上，TouchableOpacity是可以正常工作的，但Android上常见的ripple水波纹反馈在RNOH里暂时还不可用。如果追求点击反馈，可以自己用scale做缩放动画，这个在RNOH上表现稳定。

3.3 折扣倒计时的取舍

特惠游戏模块还有一个常见需求，就是展示优惠倒计时。理想状态下，每张卡片右上角有一个“剩余2天3小时”的标签，增加紧迫感。但这里有一个现实问题：Steam的featuredcategories接口并不直接返回优惠截止时间，它只给discount_percent和final_price。换句话说，接口层面拿不到“还剩多久”这个信息。

我当时想了两条路：

第一条路是用appdetails接口尝试获取折扣信息。我去翻了Steam的appdetails接口，它的字段里确实有一个price_overview对象，包含discount_percent、final_formatted等字段，但同样没有优惠结束时间。也就是说，从公开API层面，拿不到倒计时的数据源。

第二条路是从Steam商店网页源码里去解析。网页端有用户可以看到促销倒计时的页面，数据就在页面HTML的某个Script标签里，类似于“discount_expiration_time”这样的字段。但这种方案实现成本高，要引入HTML解析逻辑，而且Steam网页结构升级后解析代码就会失效，维护成本很高。

所以我的最终取舍是：以“限时特惠”静态标签代替精确倒计时。这样既向用户传递了“这是促销活动”的信息，又避免了不准确的倒计时给用户造成误导。这个决策我想放到文章里说，是因为很多开发者在做这类功能时，容易陷入“必须搞个倒计时才算完整”的执念，但实际上要结合数据源能力去判断哪些功能是能低成本实现的。如果以后有更可靠的数据来源，再倒计时也不迟。

3.4 图片加载与列表性能

特惠列表的封面图是典型的高清大图，有的尺寸达到616x353，加载慢不说，滑动时还会引发频繁的图片解码。在Android/iOS上，这个问题通常交给FastImage这类原生图片加载库处理，但RNOH对FastImage的支持目前不理想，直接引入很容易在编译或运行时出问题。

我的替代方案是组合拳：

第一，内存缓存。在JS层维护一个URL到图片地址的缓存表，同一张图片在列表里重复出现时直接复用。实际上React Native的Image组件自带内存缓存，所以这一步主要是为了减少滚动时的重复请求。

第二，可视区懒加载。用FlatList的onViewableItemsChanged计算当前正在屏幕内的卡片，只对可视区的图片做网络加载，屏幕外的图片先不加载，滚动进入可视区后再加载。这个优化对首屏速度提升非常明显。

tsx复制const viewabilityConfig = {
  viewAreaCoveragePercentThreshold: 30,
};

const handleViewableItemsChanged = useRef(
  ({ viewableItems }: { viewableItems: Array<{ item: SpecialOfferItem }> }) => {
    const visibleUrls = new Set<string>();
    viewableItems.forEach((elem) => {
      const item = elem.item;
      if (item.coverUrl) {
        visibleUrls.add(item.coverUrl);
      }
    });
    setVisibleUrls(visibleUrls);
  }
).current;

// 在renderItem中判断
const isVisible = visibleUrls.has(item.coverUrl);

第三，固定行高。给FlatList设置getItemLayout，指定每个卡片的高度固定，这样FlatList就不需要动态测量每一项的高度，滚动时的计算量会大幅度下降。

这一套组合下来，即使是在RK3568这种性能一般的开发板上，列表滚动也比较跟手，没有明显的掉帧。

4. 从RN项目到OpenHarmony应用：工程落地全流程

4.1 环境准备与版本对齐

RNOH的工程环境是我在项目启动时踩坑最多的地方，所以这里详细说一遍。要在一个OpenHarmony设备上跑起RNOH应用，你需要准备下面这些工具：

版本匹配是RNOH项目里最容易被忽视的一环。我强烈建议：先到RNOH官方文档确认它当前支持的React Native版本，再决定初始化什么样的RN工程，绝对不要一上来就npx react-native init去装最新版。RNOH的发布节奏比RN官方慢，RN版本太新的话，原生代码编译时会报一堆找不到模块的错误，最后你还得回退版本重来一遍。

正确的流程是：

1. 用@react-native-community/cli初始化指定版本的React Native项目；
2. 在根目录安装与RN版本匹配的@react-native-oh/react-native-harmony；
3. 执行RNOH提供的初始化命令，在项目根目录生成鸿蒙工程目录（通常叫harmony/）；
4. 用DevEco Studio打开鸿蒙工程进行编译；
5. 通过hdc把应用部署到OpenHarmony设备上。

到这里工程基础就算打好了，接下来就是业务代码的迁移。因为React Native项目本身的代码是跨端通用的，所以我在Android上写好的特惠列表组件，几乎原封不动地挪到了鸿蒙工程里。

4.2 鸿蒙工程配置与权限声明

把RN代码写好之后，需要在鸿蒙工程侧做一些配置，否则应用会面临两个很常见的问题：没有网络权限和无法访问设备存储。

网络权限在module.json5里配置，也就是鸿蒙应用模块的配置文件。我贴一个最小示例：

json5复制{
  module: {
    name: "entry",
    type: "entry",
    requestPermissions: [
      {
        name: "ohos.permission.INTERNET"
      }
    ],
    srcEntry: "./ets/entryability/EntryAbility.ets",
    ...
  }
}

需要注意的是，OpenHarmony的权限名和Android的权限名不一样。Android是android.permission.INTERNET，OpenHarmony是ohos.permission.INTERNET，写错一个字母，运行时不会有直观报错，但所有网络请求都会静默失败。排查起来很耗时间，最好在工程搭建阶段就认真检查权限配置。

除了网络权限，如果你的特惠游戏模块还需要读写图片缓存、发送通知等能力，也要在requestPermissions里逐一声明。这块和AndroidManifest.xml类似，但作用域和字段名有差异，建议在真机测试时根据实际报错再补充权限。

另外有一点值得提：在OpenHarmony上，如果你修改过设备的产品名称，也就是系统的const.product.name字段，可能会导致应用在某些设备上无法正确匹配签名信息，安装阶段会报错。这个在RK3588开发板上特别容易出现，后来我是通过重新生成签名证书解决的。这个问题不太常见，但真遇到会让人很头大。

4.3 真机部署：RK3568/RK3588调试链路

真机调试是RNOH项目里最需要耐心的一环。我手上的测试设备是RK3568和RK3588两款开发板，它们都是OpenHarmony官方适配过的硬件平台，整体的调试流程大致是：

1. 用USB线连接开发板和电脑，确保开发板处于USB调试模式；
2. 在终端执行hdc list targets，确认设备是否被识别；
3. 如果识别不到，先检查USB驱动是否安装、hdc服务是否启动（用hdc start启动）；
4. 识别正常后，在DevEco Studio里点击Run，就会把应用编译并部署到开发板上；
5. 应用启动后，通过hdc shell命令查看运行日志，排查JS层或原生层的报错。

这里有一个很关键的排查点：开发板的设备序列号（serial）和应用调试时看到的deviceuid并不一定一致。很多人第一次接触OpenHarmony开发板时，在DevEco里看不到设备，或者看到设备但无法参与构建，就是因为这两个标识对不上。解决办法是：

• 用hdc shell bm get --udid命令查看设备的UDID；
• 在DevEco的设备管理里重新注册设备；
• 如果反复失败，清理掉本机hdc的证书缓存文件，重新建立连接。

我之前在RK3568上就卡在这个问题上，折腾了一个多小时才发现是hdc缓存了旧证书，清理之后一切正常。

另外，OpenHarmony开发板大多支持USB和网络两种连接方式。USB方式稳定，适合前期调试；如果开发板已经连接了局域网，也可以通过hdc tconn IP:端口进行网络连接，部署时不用一直插着USB线。这个在做长时间稳定性测试时特别好用。

5. 启动白屏：RNOH上最典型的一道坎

5.1 白屏是怎么产生的

特惠游戏模块在RK3568上跑起来后，我发现一个非常影响体验的问题：应用从点击图标到页面真正渲染出来，中间会有明显的白屏，短则几百毫秒，长则超过两秒。这个现象在低配开发板上尤其明显，一度让我以为RNOH的性能有大问题。

后来我逐步排查，发现白屏的本质是RN应用启动过程的一个必然阶段。RN的应用启动分三个阶段：

1. 原生壳启动：应用进程被创建，OpenHarmony的EntryAbility加载，然后创建RN宿主容器；
2. JS引擎初始化和Bundle加载：React Native应用需要加载一个index.bundle文件，这个文件包含了业务JS代码和React运行时，加载之后还需要对JS代码进行解析和执行；
3. React渲染：JS引擎执行完bundle、创建出第一个原生视图之后，界面才会真正显示出来。

白屏就出现在第2阶段和第3阶段之间。此时原生壳已经启动，但JS侧还没有渲染出任何内容，Window上只能显示默认背景色，这个背景色通常就是白色。

导致白屏时间过长的原因有三类：第一是bundle体积太大，业务代码全量打在一个文件里，解析和执行耗时自然高；第二是JS引擎初始化耗时，RNOH在启动时需要初始化Hermes或JSC引擎，这个初始化过程本身就要占用几百毫秒；第三是Debug模式下bundle文件可能放在PC端，通过USB传输或网络加载，速度不稳定。在RK3568这类性能有限的设备上，这几个因素叠加，白屏时间就会非常可观。

5.2 实测有效的优化方案

针对白屏，我试了几种方案，最终形成了一套组合优化策略。先说结论：

最推荐组合：SplashScreen + Hermes + 精简bundle体积。

SplashScreen的思路是在原生层启动时先展示一张品牌启动图，等RN的RootView创建好之后再切换过去。这一步虽然不能真正缩短RN的加载时间，但能把白屏从用户视野里抹掉，感知层面黑屏和白屏瞬间变成“启动图到首页”的流畅过渡。

具体做法很简单：在OpenHarmony原生EntryAbility中，先loadContent一个SplashPage页面，在页面onPageShow或者onWindowStageCreate回调里，等到RN宿主初始化完成后，再通过路由或容器切换进入RN页面。代码大致是这样：

typescript复制// EntryAbility.ets
onWindowStageCreate(windowStage: window.WindowStage): void {
  // 先加载启动图页面
  windowStage.loadContent('pages/SplashPage', (err) => {
    if (err.code) {
      return;
    }
    // 在SplashPage显示后，初始化RN宿主
    this.initRNHost(windowStage);
  });
}

开启Hermes的效果也很直接。Hermes是以执行速度著称的JS引擎，早期版本主要用在Android端，现在RNOH也支持了。开启后JS解析和首帧渲染明显加快，白屏时间大约缩短了20%到30%。我在RK3568上实测，效果非常直观。

精简bundle体积这块，我做了两个动作：一是把特惠列表模块单独打包，不把整个App的页面都打进同一个bundle；二是把一些非首屏用到的库，比如详情页的轮播图组件，改成异步加载。这样首屏加载的JS代码量大幅减少，解析时间随之下降。

5.3 列表滚动性能的延伸优化

白屏问题解决之后，我还顺手做了特惠列表在低配设备上的滚动优化。FlatList在RK3568上滚动时，偶尔会有掉帧，主要原因是renderItem内部的计算和图片加载消耗了太多主线程资源。

优化措施有三个：

第一，减少renderItem内的计算量。不要在渲染时做价格格式化、折扣计算这些事，这些操作在数据解析层就全部处理完，renderItem里只做纯展示。

第二，合理设置FlatList渲染参数。initialNumToRender控制在首屏展示的卡片数，比如8个，maxToRenderPerBatch设置为10，这样每次渲染批次不会太大，避免一次性加载过多组件导致主线程卡顿。

第三，用getItemLayout固定卡片高度。这样FlatList在滚动时不需要动态测量每一项的实际高度，计算量会大幅减少。对于特惠列表这种卡片高度比较规整的场景，这个优化性价比非常高。

这些优化做完之后，即使在一台性能并不算好的RK3568开发板上，特惠列表的滚动也基本稳定在接近60帧的水平，和Android中端机的体验差距不大。

6. 常见问题排障速查表

6.1 真机与构建问题

这一节我把项目开发中实际遇到的问题整理成一张速查表，方便你对照排查。这些问题都是我在RK3568/RK3588真机调试时真实遇到的，其中有些问题非常隐蔽，不记录下来的话，下次大概率还会踩一遍。

6.2 网络与数据问题

这一节的问题集中在数据链路和网络请求上，也是特惠游戏模块最容易出问题的部分。

这里单独强调一下第三项。特惠列表图片加载不出来，是最容易被误判成RN代码问题的一个坑。实际上大多数时候是因为OpenHarmony设备的系统时间不正确，导致HTTPS证书校验失败。RK3568这类开发板如果断过电，又没有配置网络时间同步，系统时间很容易停留在生产固件的出厂时间。这时图片请求虽然发出去了，但证书校验过不了，图片就会加载失败。校准时间之后，所有图片恢复正常。

6.3 开发调试的体验优化

最后提两个调试体验上的小技巧。

第一个是善用日志。RNOH应用的日志分为JS层和原生层，JS层console.log会输出到DevEco的HiLog里，原生层用HiLog打日志。在特惠列表模块开发阶段，我习惯在数据解析