React Native for OpenHarmony 实战：三方库 react-native-device-uptime 的鸿蒙化适配指南

50084

88人浏览 · 2026-09-30 14:50:09

50084 · 2026-09-30 14:50:09 发布

react-native-device-uptime 只做一件事：读设备自启动以来的运行时长。埋点上报"本次开机多久"、诊断异常重启、统计设备稳定性时会用到。

它的公开 API 只有一个方法，但有两个特点让这个适配值得单独写一篇：

JavaScript 只是壳——上游入口只有三行，真正的实现在 iOS 与 Android 的原生代码里，没有鸿蒙实现，所以必须补一个原生模块；
返回的是"随时间变化的量"——这让验证变得有意思：只断言"是数字"毫无意义，得想办法卡住单位和语义。

本文会把这两件事都讲清楚，还会揭示一个上游原本就存在的跨平台差异：iOS 返回秒、Android 返回毫秒，两者相差 1000 倍且串格式不同。

环境准备：本文不重复环境搭建步骤。RNOH（React Native for OpenHarmony）开发环境的完整配置见官方开发者指南：
https://atomgit.com/CPF-RN/docs/blob/main/开发者指南/02-搭建准备/环境初始化.md

在这里插入图片描述

一、先说结论

项	结论
需要原生适配吗	✅ 需要
适配要补什么	一个鸿蒙原生模块（HAR + ArkTS TurboModule）
补的体量	ArkTS 侧 5 行（核心 1 行）；HAR 源码工程 9 个文件、预编译产物 2.6 KB
需要权限吗	❌ 不需要
公开 API	只有 1 个：`getUptime(): Promise<string>`
返回值	自启动以来的毫秒数，以字符串形式返回

二、判定过程：怎么确认必须做原生适配

选库阶段就能判断，不用先装进来。

第一步：看 `package.json` 有没有 `harmony` 字段

npm view <包名> harmony --json

有 harmony.autolinking（ohPackageName / etsPackageClassName / cppPackageClassName / cmakeLibraryTargetName 四个名字）的，一定是带原生实现的适配包。

第二步：看上游包里有哪些平台的实现

$ npm pack react-native-device-uptime@1.0.0
$ tar -xzf react-native-device-uptime-1.0.0.tgz
$ ls package
android/  ios/  lib/  react-native-device-uptime.podspec  ...

android/ 和 ios/ 都在，没有 harmony/ —— 这就是"必须补一个鸿蒙实现"的直接证据。

第三步：读编译后的 JS 入口，看它在做什么

// package/lib/commonjs/index.js —— 上游的全部 JS
var _reactNative = require("react-native");
const { DeviceUptime } = _reactNative.NativeModules;
var _default = DeviceUptime;
exports.default = _default;

入口里没有任何计算，只是在取一个原生模块。 这类库的"本体"是原生实现——换个平台，就必须有一个新的原生模块顶上去。

反过来，如果入口里是完整的业务逻辑（字符串处理、编解码、状态机），只是偶尔按平台分叉一下——那属于"纯 JS 库 + 平台差异"，优先考虑在 JS 侧解决，不一定要写原生。

三、适配实现：取值方式与三层接线

交付版新增的 harmony/device_uptime/ 结构：

harmony/device_uptime/
├── Index.ets                                   # 导出 DeviceUptimePackage
├── oh-package.json5                            # 声明包名 @react-native-ohos/react-native-device-uptime
├── build-profile.json5
└── src/main/
    ├── module.json5
    ├── cpp/                                    # CAPI 架构下的 C++ 侧（只是个注册壳）
    │   ├── CMakeLists.txt
    │   ├── DeviceUptimePackage.h               # Package + TurboModule 工厂 + methodMap
    │   └── DeviceUptimePackage.cpp
    └── ets/
        ├── DeviceUptimePackage.ets             # 把 TurboModule 交给 RNOH
        └── DeviceUptimeTurboModule.ts          # ★ 全部实现逻辑（5 行）

ArkTS 侧的全部实现：

import systemDateTime from '@ohos.systemDateTime';
import {UITurboModule} from '@rnoh/react-native-openharmony/ts';

export class DeviceUptimeTurboModule extends UITurboModule {
  async getUptime(): Promise<string> {
    return String(systemDateTime.getUptime(systemDateTime.TimeType.STARTUP, false));
  }
}

三个参数/选项各有含义：

部分	含义
`TimeType.STARTUP`	以系统启动为计时起点（不是进程创建时间、不是墙上时间）
`isNan = false`	返回毫秒；传 `true` 会返回纳秒
`String(...)`	保持上游 `Promise<string>` 契约——上游返回的就是字符串，不是数字

最后这一点很重要：上游的契约是字符串，所以不能"顺手"返回 number。接口形状一旦变了，调用方可能要改代码。

C++ 侧只是个注册壳，一行业务逻辑都没有：

class DeviceUptime : public ArkTSTurboModule {
 public:
  DeviceUptime(const ArkTSTurboModule::Context ctx, const std::string& name) : ArkTSTurboModule(ctx, name) {
    methodMap_ = {
      ARK_ASYNC_METHOD_METADATA(getUptime, 0),
    };
  }
};

ARK_ASYNC_METHOD_METADATA(getUptime, 0) —— 方法名、0 个参数、返回 Promise。方法名或参数个数写错，表现是"编译过了但调用报方法不存在"。

JS 侧的改动：把 `undefined` 隐患换成"早失败"

import {TurboModuleRegistry, type TurboModule} from 'react-native';
export interface Spec extends TurboModule {getUptime(): Promise<string>}
export default TurboModuleRegistry.getEnforcing<Spec>('DeviceUptime');

上游是 const { DeviceUptime } = NativeModules——模块没注册时得到 undefined，要等到第一次调用才炸。交付版用 TurboModuleRegistry.getEnforcing，模块缺失时在导入阶段就抛出明确错误。

四、一个容易踩的地方：上游各平台的返回格式并不一致

这是本次适配最值得记的一条。从上游 tarball 里可以看到两个平台的实现完全不同：

iOS（ios/DeviceUptime.m）：

NSTimeInterval uptime = [[NSProcessInfo processInfo] systemUptime];
resolve([NSString stringWithFormat:@"%f", uptime]);

systemUptime 是秒（NSTimeInterval 是 Double），%f 输出小数串，例如 "4393.710000"。

Android（.../DeviceUptimeModule.kt）：

var uptime = SystemClock.elapsedRealtime().toString()

elapsedRealtime() 是毫秒（Long），.toString() 输出整数串，例如 "4393710"。

鸿蒙（本交付）：String(getUptime(STARTUP, false)) → 毫秒整数串，与 Android 一致。

⇒ 三件事必须说清楚：

平台	单位	串格式	举例
iOS	秒	小数	`"4393.710000"`
Android	毫秒	整数	`"4393710"`
鸿蒙	毫秒	整数	`"4393710"`

iOS 与 Android 的单位相差 1000 倍，串格式也不同。 这不是本交付引入的——是上游本来就存在的跨平台差异。交付版明确对齐了 Android 语义，并在 README 里把单位（毫秒）、计时起点（自启动）、边界（“不是墙上时间，也不是应用进程创建时间；设备重启后重新计数”）都写明了。

实践影响：如果调用方是照着 iOS 行为写的（把返回值当"秒"用），迁移到鸿蒙会得到 1000 倍的数值——4393710 会被当成 439 万秒（约 50 天）。同一份 JS 代码在不同平台行为不一致，是这类"薄壳库"最典型的坑。

五、接入宿主：三处改动面（外加一处自动生成的）

库本身不能独立运行，必须有一个 RNOH 宿主 App。这里用 RNOH084Demo（RNOH 0.84.3 的多库验证宿主），它自带 rnAppKey 机制，一个宿主可以挂很多独立测试页：

hdc shell aa start -b com.rnoh084.demo -a EntryAbility --ps rnAppKey DeviceUptimeTestApp

接入要改的地方

第一处：package.json。

"react-native-device-uptime": "file:../react-native-device-uptime"

第二处：两级 oh-package.json5 都要写 HAR。

"@react-native-ohos/react-native-device-uptime":
  "file:../node_modules/react-native-device-uptime/harmony/device_uptime.har",

harmony/oh-package.json5 管工程级、harmony/entry/oh-package.json5 管模块级，两处都要加。只加一处会出现"能找到包但链接不上"。

这里有个很容易漏的点：跑 link-harmony 时，它只会自动更新工程级那一份，模块级那份要你自己加。

第三处：在 ETS 侧注册 Package。

// harmony/entry/src/main/ets/RNOHPackagesFactory.ets
import type { RNPackageContext, RNOHPackage } from '@rnoh/react-native-openharmony';
import DeviceUptimePackage from '@react-native-ohos/react-native-device-uptime';

export function createRNOHPackages(ctx: RNPackageContext): RNOHPackage[] {
  return [
    new DeviceUptimePackage(ctx),
  ];
}

代码写在哪，这里说清楚：手工改动面就是这三个文件（外加 metro.config.js 的 watchFolders）。C++ 侧不用手改——CAPI 架构下 PackageProvider.cpp 会自动消费 autolinking 生成的 RNOHPackagesFactory.h。

那"自动生成的一处"是什么？ 执行 link-harmony 时，它会一次性重写这四个文件：

• harmony/entry/src/main/cpp/RNOHPackagesFactory.h   # C++ 侧注册
• harmony/entry/src/main/cpp/autolinking.cmake       # add_subdirectory + 链接
• harmony/entry/src/main/ets/RNOHPackagesFactory.ets # ETS 侧注册
• harmony/oh-package.json5                           # 工程级 HAR 依赖

这四个文件头部都写着 DO NOT modify it manually, your changes WILL be overwritten.——别手改。

接入成功的两个自检信号

$ node_modules\.bin\react-native link-harmony --verbose
[link] react-native-device-uptime
[skip] @react-native-oh/react-native-harmony
...
info updated 4 file(s), linked 7 libraries, skipped 1 library

打包时 Metro 也会把它列进重定向清单：

[INFO] Redirected imports to 7 harmony-specific third-party package(s):
[INFO] • react-native-device-uptime → react-native-device-uptime
…

这两个信号对这个库是"必须出现"：有原生实现的包要被解析到它的鸿蒙实现，列表里没有它就说明没接通。

（harmony/entry/src/main/module.json5 未改动——本库只读系统启动时长，不需要任何权限。）

六、构建与运行

# 1) 装 JS 依赖 + 自动链接
npm install
./node_modules/.bin/react-native link-harmony

# 2) 生成调试签名 + 装 ohpm 依赖
cd harmony
devecocli signature generate
ohpm install --all

# 3) 打包 JS bundle（输出到 harmony/entry/src/main/resources/rawfile/）
cd ..
npm run dev

# 4) 编译 HAP
cd harmony
hvigorw --mode module -p product=default -p module=entry@default assembleHap --no-daemon

# 5) 安装 + 启动测试页
hdc install -r entry/build/default/outputs/default/entry-default-signed.hap
# 换页参数只在「冷启动」时生效：先 force-stop 再起
hdc shell aa force-stop com.rnoh084.demo
hdc shell aa start -b com.rnoh084.demo -a EntryAbility --ps rnAppKey DeviceUptimeTestApp

耗时：在已有原生编译缓存的宿主上增量加入这个库，assembleHap 用了 6 分 42 秒；HAP 从 80.23 MB 涨到 80.39 MB（约 +152 KB）。

如果宿主是全新 clone（没有原生编译缓存），首次构建会到 30–40 分钟量级；只改 JS 重新打包也要 6–7 分钟，所以别把 UI 微调留到最后做。

看日志：

hdc shell "hilog -x | grep -i 'TM created'"
hdc shell "hilog -x | grep -i 'device-uptime-test'"

按文本点击（页面高度会随结果卡片变化，别记固定坐标）：

. E:\rnoh-work\click-label.ps1
Click-Label -Pattern '读取运行时长并跑全部断言'

七、验证设计：随时间变化的返回值怎么验

这个库只有一个方法，返回值随时间变化。只断言"是数字"或"非空"等于没验证——任何数字都能过。

要真正卡住它，得从三个方向来：

方向	回答什么问题	怎么验
契约与格式	接口形状对不对	返回 Promise、类型是 string、是纯整数串、安全整数、正数、严格递增
单位与语义	数字是什么单位、什么含义	故意等待一段已知时间，看增量；再看数值量级是否落在"自启动以来"的合理区间
绝对值对照	具体数值对不对	与设备自己的时间源交叉核验（期望值从外部独立读出）

关键一步：用"已知等待"卡住单位

单位是这类接口最容易搞错的地方（秒 / 毫秒 / 微秒 / 纳秒，差 1000 倍）。不用去猜，制造一个已知时间间隔就行：

const before = await DeviceUptime.getUptime();
const beforeWall = Date.now();
await sleep(3000);                       // 故意等 3 秒
const after = await DeviceUptime.getUptime();
const afterWall = Date.now();

const deltaUptime = Number(after) - Number(before);
const deltaWall = afterWall - beforeWall;

实测结果：

等待期间：uptime 增量 3002 ms，墙上时间增量 3003 ms

3002 对 3003 的 1:1 对应，一次性确认了两件事：

单位是毫秒——如果单位是秒，增量会是 3 而不是 3002；
返回的是真实流逝的时间——不是某个固定值、不是被量化过的粗粒度值。

断言写成 deltaUptime ∈ [1500, 6000]：容差放得足够宽（允许调度抖动），但仍然能干净地区分"毫秒"与"秒"（秒的话是 3，差三个数量级）。

绝对值对照：期望值从哪来

/proc/uptime 在设备上对 shell 是 Permission denied，hdc file recv 也取不到。能用的独立来源是 uptime 命令：

$ hdc shell date +%s
1790750119                                    → 参考墙上时间

$ hdc shell uptime
14:35:19 up  1:04,  0 users,  load average: ...   → 参考上电时长

up 1:04 是分钟级精度——实际值落在 [64, 65) 分钟区间，取中点 64.5 分钟 = 3,870,000 ms，容差取 ±90 秒（含 ±30 秒量化误差 + 60 秒余量）。

期望值 = 参考上电时长 + 从参考时刻到现在的经过时间：

期望 4383682 ms，实际 4396768 ms，偏差 13086 ms

偏差 13 秒，远小于 30 秒的量化误差上界。这条确认了：

值确实是"自启动以来"——不是进程年龄（那只有几分钟）、不是墙上时间（那是 1.79e12 量级）；
绝对数值与系统自己的 uptime 一致。

八、真机验证

验证环境：Pura X View 模拟器，HarmonyOS 7.0.0(26.0.0) Beta2，API 26，ohos-x64。

TurboModule 注册

RNInstance::TurboModuleProvider  TM created: DeviceUptime

在这里插入图片描述

断言结果：11 / 11 全部通过

A 组：契约与格式（6 项）

断言	结果
返回 Promise（`typeof .then === 'function'`）	✅
返回类型是 `string`	✅
是纯整数串（`/^\d+$/`，无小数点/符号/空格）	✅
`Number()` 是安全整数	✅
大于 0	✅
连续两次读取严格递增	✅

B 组：单位与语义（4 项）

断言	结果
单位是毫秒（3 秒等待的增量在 `[1500, 6000]`）	✅ 增量 3002 ms
增量与墙上时间差值吻合（±1000 ms）	✅ 墙上时间增量 3003 ms
落在「自启动以来(ms)」量级（1 小时 ~ 30 天）	✅ 4,396,768 ms
不是墙上时间量级（< 1e12）	✅

C 组：与外部参考对照（1 项）

断言	结果
与外部参考一致（偏差 ≤ 90 秒）	✅ 偏差 13,086 ms

完整读数

[device-uptime-test] getUptime() = 4396768　= 1 小时 13 分 16 秒
[device-uptime-test] 等待期间：uptime 增量 3002 ms，墙上时间增量 3003 ms
[device-uptime-test] 外部对照：参考上电 up 1:04（约 3870000 ms）+ 经过 513682 ms
                     = 期望 4383682 ms，实际 4396768 ms，偏差 13086 ms
[device-uptime-test] A + B + C（契约 / 单位语义 / 外部对照） -> 11/11 全部通过

（页面显示的首读值是 4393710，与末次读取 4396768 相差约 3 秒，与等待时间吻合。）

在这里插入图片描述

能力对照

能力	结果
`getUptime()` 返回 Promise	✅
返回值是毫秒整数串	✅ 增量 3002 ms 对 3003 ms 的 1:1 对应
计时起点是"系统启动"	✅ 绝对数值与设备 `uptime` 偏差 13 秒
单调递增	✅ 连续两次严格递增
需要权限	✅ 不需要
TurboModule 注册	✅ `TM created: DeviceUptime`

九、已知限制

一、返回值的单位是毫秒，与 iOS 不一致。 上游 iOS 返回秒（小数串），Android 与鸿蒙返回毫秒（整数串），相差 1000 倍。从 iOS 迁移到鸿蒙时必须显式确认单位，不要假设"同一份 JS 在各平台行为一致"。

二、计时起点是系统启动，不是应用进程创建。 值反映的是"设备开了多久"，不是"应用跑了多久"。如果需要应用自身的运行时长，得自己在 JS 侧记录起始时间。

三、设备重启后会重新计数。 这是语义的一部分，不是缺陷——但意味着这个值不能用作单调递增的全局时间戳，跨重启会倒退。本次未实测重启场景（需要重启设备）。

四、isNan 参数被固定为 false。 交付版写死了毫秒。上游契约是字符串，没有暴露单位选择的入口——要纳秒精度得改库或另找接口。

五、深度睡眠（doze）期间是否计入未验证。 TimeType.STARTUP 的语义是否包含休眠时间，本次没有设备侧证据。

六、精度未做长时漂移验证。 只验证了一次 3 秒增量与一次绝对对照，没有验证长时间运行后的偏差累积。

七、交付包有两处可补的缺口。 不影响运行时正确性，但影响可追溯性与验证可信度：

spec.json 没有 upstream 字段、也没有 upstreamCommit —— 交付包无法自证"对应上游哪份代码"；
契约测试 __tests__/uptime.test.cjs 里 const value = String(12345); assert.match(value, /^\d+$/) ——断言的是字面量，没有 import 本库、没有调用 getUptime。这个测试无论库是否可用都会通过，不构成验证。

八、上游 tarball 体积异常。 上游包 216,559 字节，其中 android/build/ 里塞了构建产物（单个 R.jar 就有 197,268 字节）。这是上游 .npmignore 配置问题，不是交付方引入的，但会让安装体积膨胀。

九、其他 ROM / 真机未验证。 适配方记录的是 OpenHarmony-7.0.0.105；本次在 HarmonyOS 7.0.0(26.0.0) Beta2 模拟器上通过。

十、常见问题

Q：这个库为什么必须做原生适配？
A：它的 JS 入口只有"取 NativeModules.DeviceUptime"这几行，本体在原生侧。上游只提供了 iOS 与 Android 实现，没有鸿蒙实现。不补一个鸿蒙原生模块，NativeModules.DeviceUptime 就是 undefined，调用必然失败。

Q：怎么快速判断一个库要不要做原生适配？
A：三步。① npm view <包名> harmony --json 看有没有 harmony.autolinking；② 上游包里有哪些平台的实现目录（只有 ios/ + android/ 而没有 harmony/ → 要补一个鸿蒙实现）；③ 读入口文件——如果里面只有"取原生模块"而没有任何业务逻辑，那它天生依赖原生。

Q：返回值是秒还是毫秒？
A：鸿蒙侧是毫秒（整数串）。注意上游iOS 返回的是秒（小数串），差 1000 倍。交付版对齐的是 Android 语义，README 里写明了"毫秒数"。

Q：为什么返回的是字符串而不是数字？
A：因为上游契约就是 Promise<string>。适配时保持接口形状不变很重要——改成数字会让调用方代码需要跟着改。业务侧自己 Number(...) 转换即可。

Q：怎么验证一个"随时间变化"的返回值？
A：三个方向。① 格式：Promise / string / 纯整数串 / 安全整数 / 正数 / 严格递增；② 单位：制造一个已知等待（例如 3 秒），看增量是不是约 3000——这一步能直接区分毫秒与秒；③ 绝对值：找一个外部独立来源算期望值（本例用 hdc shell uptime + date +%s），而不是从被测库取。只断言"是数字"等于没验证。

Q：设备上的 /proc/uptime 能读吗？
A：不能。hdc shell cat /proc/uptime 返回 Permission denied，hdc file recv /proc/uptime 也失败。可用的独立来源是 uptime 命令——分钟级精度，所以绝对对照的容差要按 ±30 秒的量化误差来取。

Q：设备重启后这个值会怎样？
A：会从 0 重新计数。这是"自启动以来"的语义决定的。所以它不能当单调递增的全局时间戳，跨重启会倒退。本次没有实测重启场景。

Q：能拿到纳秒精度吗？
A：交付版把 isNan 写死为 false，只返回毫秒；上游契约是字符串、没有暴露单位选择。要纳秒精度得改库或另找接口。

Q：为什么我在模拟器上编译要这么久？
A：宿主已有原生编译缓存时，增量加一个库约 6–7 分钟（hvigor 会把整套流水线走一遍）；全新克隆的宿主首次编译要 30–40 分钟。只改 JS 重新打包也是 6–7 分钟。

Q：怎么确认这个适配版本是对的？
A：四条证据：① TM created: DeviceUptime（模块真的注册了）；② 契约与格式断言全过；③ 3 秒等待的增量是 3002 ms（确认单位是毫秒、且是真实流逝时间）；④ 与设备 uptime 的绝对对照偏差只有 13 秒（确认计时起点是系统启动）。后两条是关键——前两条只能说明"接口能调通"。

小结

这个库的适配体量是"一行取值 + 三层接线"，但有两件事值得记：

第一件是那个跨平台差异。 上游 iOS 返回秒、Android 返回毫秒，两者相差 1000 倍，串格式也不同（一个小数、一个整数）。这说明一个常被忽略的事实：同名的接口在不同平台上语义可能并不一致。适配一个新平台时，"对齐哪个平台"是一个必须显式做的决定——本交付选了 Android 语义，并把单位写进了 README。如果调用方是照着 iOS 行为写的，迁移到鸿蒙会差 1000 倍，而且不会报错，只会悄悄算错。

第二件是"随时间变化的量"该怎么验。 这类返回值最容易被敷衍过去——“它返回了一个数字，看起来合理”。可验证的做法是三个方向一起上：

格式：接口形状（Promise / string / 整数串 / 递增）；
单位：制造一个已知时间间隔，看增量。这是最有效的一招——等待 3 秒后增量是 3002 还是 3，一眼就能判断单位，不需要猜；
绝对值：找一个外部独立来源算期望值。本例用的是设备自己的 uptime 命令。

三条合起来，结论就不是"接口能调通"，而是"单位是毫秒、语义是自启动以来、数值与系统时间源一致"。

最后如实记了交付包的两处缺口：spec.json 缺上游 commit、契约测试断言的是字面量（没 import 库、没调用方法，怎么跑都会通过）。一个永远不会失败的测试不是测试——这一点在验证别人的交付物时，比自己写测试更容易被忽略。

本篇用到的库

项	内容
三方库	`react-native-device-uptime`（上游 1.0.0 的鸿蒙适配版）
交付仓库	https://atomgit.com/oh-react-native/react-native-device-uptime
适配 TAG	`1.0.0-ohos-1.0.0`
ohpm 包名	`@react-native-ohos/react-native-device-uptime`
HAR	`harmony/device_uptime.har`（2.6 KB）
原生模块名	`DeviceUptime`
是否需要权限	不需要
上游仓库	`https://github.com/Luke-Rogerson/react-native-device-uptime`
宿主工程	`RNOH084Demo`（测试页 `rnAppKey = DeviceUptimeTestApp`）

"react-native-device-uptime": "git+https://atomgit.com/oh-react-native/react-native-device-uptime.git#1.0.0-ohos-1.0.0"

// harmony/oh-package.json5 与 harmony/entry/oh-package.json5 都要加
"@react-native-ohos/react-native-device-uptime":
  "file:../node_modules/react-native-device-uptime/harmony/device_uptime.har",

import DeviceUptime from 'react-native-device-uptime';

// 返回值是「自启动以来的毫秒数」的字符串（鸿蒙与 Android 语义）
const uptimeMs = Number(await DeviceUptime.getUptime());   // 例如 4393710

// 注意：上游 iOS 返回的是「秒」的小数串，跨平台迁移时务必确认单位
const seconds = uptimeMs / 1000;

# 换页启动测试页（force-stop 不能省，换页参数只在冷启动生效）
hdc shell aa force-stop com.rnoh084.demo
hdc shell aa start -b com.rnoh084.demo -a EntryAbility --ps rnAppKey DeviceUptimeTestApp

验证环境

项	版本
React Native	`0.84.1`
React	`19.2.3`
RNOH（npm / ohpm）	`@react-native-oh/react-native-harmony` / `@rnoh/react-native-openharmony` `0.84.3`
Node.js	`v24.14.0`
DevEco Studio	`26.0.0.621`
HarmonyOS SDK	API 26（`26.0.0.32`）
设备	HarmonyOS 7.0.0(26.0.0) Beta2 模拟器 `Pura X View`（ohos-x64）
外部参考	`hdc shell uptime` = `up 1:04`；`hdc shell date +%s` = `1790750119`
宿主 HAP 产物	`entry-default-signed.hap`（80.39 MB）
本次增量构建	`assembleHap` 6 分 42 秒
验证规模	设备侧 11 项断言全通过；单位验证增量 3002 ms 对 3003 ms；绝对对照偏差 13,086 ms

欢迎加入 CPF-RN 鸿蒙社区：https://atomgit.com/CPF-RN

React Native for OpenHarmony 组织：https://atomgit.com/oh-react-native

RN 三方库鸿蒙适配清单：https://atomgit.com/oh-react-native/rn-ohos-adaptation-overview