osakadorisss这活儿我接了快两周才敢说真正摸透了。阿拉伯语适配本身不新鲜，但你要是把它放到 React Native + OpenHarmony 这个组合里，事情就变得特别拧巴：RN 社区那套成熟的 RTL 方案，在 OpenHarmony 上不一定完全生效；OpenHarmony 自己的 ArkUI 布局规则，RN 的 JS 层又不一定能直接感知。两边各有一套逻辑，中间的桥接层还没被验证过几轮，这个时候做阿拉伯语适配，就是在两头找平衡。这篇文章我不打算写那种"三步搞定 RTL"的标题党，就实打实记录我在 rk3568 开发板上把带阿拉伯语的 RN 应用跑起来、跑对方向的整个过程，包括怎么用 hdc 排查白屏、怎么确认 RTL 真的生效、怎么处理轮播图和弹窗这些边缘场景。
1. 这活儿难在哪：RN、OpenHarmony、阿拉伯语三件事互相咬合
1.1 现状：RN 在 OpenHarmony 上能跑，但细节都在"坑里"
先说一下背景。React Native for OpenHarmony（社区里常叫 RNOH）现在是能用的，核心 JS 引擎、组件映射、原生模块桥接这些大骨架都已经落地。但你真拿它做业务，尤其是做国际化的业务，就会发现很多东西是"能用，但不完全能用"。官方文档和 demo 覆盖的都是 Hello World 级别的场景，真正到阿拉伯语这种 RTL 语言，没人给你兜底。
阿拉伯语适配最特殊的地方在于，它不是把文字改成从右往左读那么简单。整个 UI 的坐标系都要翻转：导航栏返回按钮要跑到右边去、列表的滑动方向要反过来、轮播图要从右边开始、图文混排的阅读起点要换边。这就意味着你得同时控制 RN 布局引擎的排布方向、组件的内边距逻辑、还有用户手势的惯用方向。这不是加一个 direction: 'rtl' 样式就能收工的活。
1.2 为什么单独讲阿拉伯语：RTL 不是简单的文字右对齐
很多从没接触过 RTL 的开发者会有一个误解，觉得做阿拉伯语就是把文字右对齐，再把 flexDirection 改成 row-reverse。但 RTL 语言真正影响的是整个页面结构的镜像感。阿拉伯语用户看一个页面，书写的起点在右侧，所以他们希望第一个看到的内容出现在屏幕右侧，返回手势是从右往左滑，Tab 栏的顺序也应该整体反转。
在 React Native 里，Facebook 官方给了一套方案，核心是 I18nManager 和 I18nManager.isRTL，这套机制在 OpenHarmony 上大部分是可用的。但问题在于 RNOH 对这套机制的实现深度。我实测下来，组件样式的翻转基本正常，但一些第三方库、原生弹窗、还有手势响应器的行为，并没有完全继承 RTL 语义。这也是后面我花了很多时间去排查的原因。
1.3 准备清单：硬件、固件、工具链
在进细节之前，先把手头的东西列清楚，省得你做到一半发现环境不对：
- 开发板：我用的 rk3568，OpenHarmony 4.0 Release 固件。有条件上 rk3588 更好，内存和 GPU 都宽裕一些，RN 应用跑起来没那么喘。
- 开发工具：DevEco Studio，用来构建 OpenHarmony 的 HAR 包和应用外壳；RNOH 的脚手架工程一套。
- 命令行工具：hdc（OpenHarmony Device Connector），它是 OpenHarmony 世界的 adb，后面所有排查都靠它。
- RN 版本：我当前验证的是 RN 0.72 系的 RNOH 移植版，原生模块用社区提供的
@react-native-oh-tpl前缀包。
这一套东西表面上看起来就是普通 RN 开发环境加一个真机/开发板，但实际操作中，启动白屏、hdc 拿不到设备、RTL 开关不生效这些问题，能把一个正常开发节奏拖垮三天。下面我把这些坑一个个摊开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搭建调试环境：开发板、hdc 与启动白屏的三重坑
2.1 开发板选型与系统确认
如果你只是想验证 RN + OpenHarmony 的可行性，rk3568 是目前资料最多、踩坑记录最全的选择。OpenHarmony 官方和社区大量 demo 都是在 rk3568 上跑的，你搜问题的时候命中率会高很多。rk3588 性能强，但部分板子的 BSP 固件更新更激进，反而不如 rk3568 稳。我建议先用 rk3568 跑通全流程，再考虑换更强的硬件。
拿到开发板第一件事是确认系统版本和产品信息，别急着装应用。OpenHarmony 不像手机厂商的 ROM 会给你一个明确的"关于本机"，很多时候你得靠 hdc 去问设备：
bash复制hdc shell param get const.product.name
hdc shell param get const.product.version
hdc shell param get const.product.model
如果这几条命令能返回正常信息，说明 hdc 通道是通的。如果 const.product.name 返回空，通常意味着固件里的产品信息没写全，这种情况后续做应用签名或者安装包匹配的时候会出问题。
2.2 hdc 连接与系统信息确认
hdc 连接 OpenHarmony 设备有两种方式，一种是 USB 直连，一种是网络调试。USB 直连最稳，但有些开发板的 USB 接口供电不稳，会导致连到一半设备掉线。我遇到的典型情况是：hdc list targets 能看到设备，但一执行 hdc shell 就卡住。后来发现是 USB 线材的问题——换了一根带屏蔽层的短线就好了。这个细节看起来不值一提，但它能卡你一下午。
网络调试适合开发板放在桌上、不方便一直插 USB 的场景，操作方式：
bash复制hdc tconn 192.168.x.x:5555
hdc shell
注意 OpenHarmony 的 hdc 和 Android 的 adb 是两套体系，不要混用。有些人习惯性地敲 adb shell，发现连不上，就以为设备坏了，其实只是工具不对。
另外要养成检查系统参数的习惯，尤其是做 RTL 验证的时候，因为 RTL 的最终渲染效果和系统语言的设置强相关。你需要查看系统当前语言和地区：
bash复制hdc shell settings get system locale_zone
hdc shell param get const.product.os.fullname
如果系统的 locale 不支持阿拉伯语，你就算在应用层开了 RTL，部分系统组件（比如输入法、日期选择器）还是会用默认的 LTR 表现。后面我会专门讲这条链路。
2.3 启动白屏的完整排查链路
热词里挂着"react native 启动白屏"，这几乎是我在 OpenHarmony 上跑 RN 遇到的第一个大坑。白屏的根因排序大概是这样的（按照我实际排查的先后顺序）：
第一步：确认 JS Bundle 有没有被加载。 白屏最常见的原因是 Metro 打包完的 bundle 没被原生容器拿到。我在 DevEco Studio 的 Log 面板里搜 "ReactNative" 关键词，如果能看到类似 "Loading JS bundle" 或者 "Running application" 的日志，说明原生侧已经走到加载逻辑了，白屏问题在别处；如果连日志都没有，那问题在原生入口的配置。
第二步：检查 Metro 地址和网络权限。 开发阶段你大概率跑的是 Metro dev server，也就是从开发板通过网络去拉 bundle。OpenHarmony 应用默认的网络权限没有放开，需要在 module.json5 里显式加：
json5复制{
"module": {
"requestPermissions": [
{ "name": "ohos.permission.INTERNET" }
]
}
}
我当时漏了这一步，Metro 日志里能看到请求进来，但应用侧拿不到数据，界面就永远白着。
第三步：确认原生 so 库是否完整打包。 RNOH 依赖一些 C++ 编译出来的动态库，如果打包时漏了 .so，应用启动时不会直接崩溃，而是在加载 JS 引擎那一步静默失败。你可以通过 hdc 看一眼应用目录下的 lib 文件夹：
bash复制hdc shell
cd /data/app/el2/100/base/<packageName>
ls lib/arm
建议对照 RNOH 的构建产物清单，逐个核对 libreactnative.so 这些关键文件是否存在。一旦缺失，重新构建 HAR 包，不要手动拷。
第四步：上 log 抓崩溃。 如果前三步都没问题，那就抓崩溃日志：
bash复制hdc shell hilog | grep -i "ReactNative\|JS ERROR\|FATAL"
RN 的 JS 层异常和原生层异常都会走 hilog，尤其注意 "JS ERROR" 开头的日志，那就是 JS 代码在初始化阶段抛了异常。这一步能帮你定位到是某个原生模块没有正确注册，还是业务代码在启动时就出错了。
2.4 确认 RTL 开关的调试手段
环境通了之后，不要急着写业务代码，先在空页面上验证 RTL 开关到底能不能生效。我的验证方式是在启动入口写这么一段：
typescript复制import { I18nManager } from 'react-native';
I18nManager.allowRTL(true);
I18nManager.forceRTL(true);
然后在首页放两个并排的色块，一个红色一个蓝色。如果 RTL 生效，红块应该出现在右侧。这个简单实验比任何文档都管用，因为它能直接告诉你 RNOH 对 I18nManager 的实现程度。
我当时做这个实验发现：色块确实翻转了，但 Text 组件默认的 textAlign 并没有跟着变。这个现象很典型，它说明 RNOH 把布局方向的翻转做了，但组件内部继承 RTL 语义的粒度不够细。后面我写样式的时候，凡是文本类组件都做了显式对齐处理，绝对不依赖默认值。
3. RTL 适配原理：RN 的 I18nManager 在 OpenHarmony 上干了什么
3.1 从 flexDirection 说起：RTL 布局翻转的底层逻辑
RTL 布局翻转不是简单的镜像，而是一整套布局引擎的坐标变化。在 Flexbox 模型里，flexDirection: 'row' 默认从左往右排，justifyContent: 'flex-start' 默认靠左对齐。当布局方向变为 RTL 时，主轴起点变成右侧，flex-start 自然就变成靠右。这就是为什么很多不做适配的页面在 RTL 下会出现"整体镜像"的效果——因为 RN 把主轴方向翻转了。
但这里有个非常隐蔽的问题：布局引擎翻转不等于业务逻辑翻转。 比如一个横向滚动的 Tab 栏，在 LTR 下你从左边第一个 Tab 开始；切到 RTL 后布局引擎可以把 Tab 项从右往左排，但如果你用 ScrollView 并设置了 contentOffset，计算逻辑可能还是 LTR 的。这就是为什么轮播图、Tab 栏这类组件经常要专门处理。
更深一层的问题是，OpenHarmony 的 ArkUI 对 RTL 布局有一套自己的实现，RNOH 的桥接层只是把 RN 的布局结果告诉 ArkUI，并按 UI 方向做了一次坐标转换。这个转换在简单布局上没问题，但一旦你把组件放到 Modal、Popup 或者自定义的原生容器里，RNOH 不一定能感知到那个容器的方向语义。所以你会遇到"页面主体都右对齐了，但弹窗还是从左往右"这种精神分裂的现象。
3.2 I18nManager.allowRTL / forceRTL 的行为差异
React Native 的 RTL 控制其实分两个开关：allowRTL 和 forceRTL。很多人以为把它俩都设为 true 就万事大吉，其实行为差很多。
allowRTL(true)：只允许应用支持 RTL，但不会强制切换。最终方向由系统的语言环境决定。forceRTL(true)：强制覆盖系统设置，让应用无论系统是什么语言都按 RTL 布局渲染。
对于出海阿语市场的应用，我的建议是用 forceRTL(true)，因为你要确保在阿语地区之外的测试设备上也能看到阿语布局效果，方便开发和 QA 验证。但注意：forceRTL 不能保证系统组件（比如输入法、日期选择器等原生 UI）也跟着翻转，那些东西还得靠系统语言切换。
在实际代码里，我习惯在入口处做一次判断：
typescript复制import { I18nManager, Platform } from 'react-native';
if (I18nManager.isRTL) {
// 业务里需要感知方向的地方
} else {
// 非 RTL 逻辑
}
不要试图用 I18nManager.isRTL 去切换所有样式，那样代码会爆炸。更好的方式是把方向相关的样式抽象成一个 useDirection() 的 hook，或者干脆用样式对象统一管理。后面第 4 节我会给具体的写法。
注意：
I18nManager.forceRTL(true)这个 API 在运行期切换后，RN 官方建议重新加载应用才能让布局完全生效。RNOH 在这点上和原生 RN 行为一致，别指望切完立刻看到变化。
3.3 OpenHarmony 侧 ArkUI 的 RTL 支持与桥接要求
要做到阿拉伯语适配，不能只盯着 RN 侧，OpenHarmony 的 ArkUI 也有自己的方向设置。ArkUI 的组件布局默认是 LTR，你要在应用级或者页面级设置 RTL，通常是在 EntryAbility 或页面根节点配置布局方向。
在我实际测试的 RNOH 版本里，RN 的 RTL 布局和 ArkUI 的布局方向是两套独立体系，RNOH 只负责把 RN 的布局结果渲染到 ArkUI 的 Surface 上。这意味着：如果你在 ArkUI 侧把页面方向设成 RTL，但 RN 侧没有开 forceRTL，两边就会出现渲染结果和触摸区域不一致的情况。这个 bug 非常难查，因为视觉上看起来已经右对齐了，但点击响应区域还在左侧。
最稳的做法是：RN 侧和 ArkUI 侧的 RTL 保持同步。 具体来说，有两种方案：
- 在 RN 入口用
forceRTL(true)，同时也在 ArkUI 的页面配置里设置方向为 RTL。 - 让应用完全跟随系统语言，RN 侧用
allowRTL(true)，ArkUI 侧用系统级设置自动翻转。
对于大多数出海应用，方案 1 更可控。方案 2 适合系统语言本身就切成阿拉伯语的场景，但调试成本更高。
4. 从布局到组件的阿拉伯语适配实践
4.1 全局开启 RTL 与样式改造
先把全局开关打开：
typescript复制import { I18nManager } from 'react-native';
I18nManager.allowRTL(true);
I18nManager.forceRTL(true);
然后你会进入一个非常痛苦的阶段：之前写的所有带方向假设的样式都会出问题。比如：
typescript复制// 以前这样写，LTR 下没问题
const styles = StyleSheet.create({
header: {
flexDirection: 'row',
justifyContent: 'flex-start',
},
closeIcon: {
marginLeft: 8,
},
});
这些代码在 RTL 下会呈现镜像效果，但语义不一定对：justifyContent: 'flex-start' 会变成从右开始排，marginLeft 不会自动变成 marginRight，所以视觉上元素会挤到一起。正确的做法是抽象的"逻辑语义"样式：
typescript复制import { I18nManager } from 'react-native';
const isRTL = I18nManager.isRTL;
const styles = StyleSheet.create({
header: {
flexDirection: 'row',
justifyContent: 'flex-start',
// 不要硬编码 marginLeft，改用 gap 或 padding
},
closeIcon: {
marginStart: 8,
marginEnd: 0,
},
text: {
textAlign: 'left',
// RTL 下需要手动切换
...(isRTL ? { textAlign: 'right' } : null),
},
});
RN 从 0.71 开始支持逻辑属性 marginStart/marginEnd，这套属性在 RNOH 上也是可用的。能用逻辑属性的地方，尽量用逻辑属性，比手动判断强多了。
4.2 文本、数字与货币格式
阿拉伯语最折磨人的地方不只是方向，而是数字和货币格式。阿拉伯语区域的用户习惯使用"东阿拉伯数字"（٠١٢٣٤٥٦٧٨٩），而不是西方数字（0123456789）。如果你直接渲染价格，就会出现"100 迪拉姆"这种完全不符合当地阅读习惯的显示。
JS 侧可以用 Intl.NumberFormat 处理：
javascript复制const priceFormatter = new Intl.NumberFormat('ar-AE', {
style: 'currency',
currency: 'AED',
});
console.log(priceFormatter.format(1000)); // ١٬٠٠٠٫٠٠ د.إ.
但要注意，Intl 的完整 ICU 数据需要 JS 引擎支持。RNOH 用的是 QuickJS 或 V8 引擎（取决于构建配置），对 Intl 的支持程度不一。如果发现 Intl.NumberFormat 输出异常，建议降级方案：后端直接下发格式化好的字符串，前端只做显示。
文本方向也要单独注意。当同一段文本里既有阿拉伯语又有英文字母/数字时，浏览器/RN 会做双向文本算法（BiDi）。大多数情况下 RN 的 Text 组件能正确渲染，但如果遇到混合排版错乱，可以给 Text 设置 writingDirection: 'rtl' 或者反过来包裹一层方向标记：
typescript复制<Text style={{ writingDirection: 'rtl' }}>
{"订单号 OrderNo: 12345"}
</Text>
4.3 图标与图片的镜像处理
图标在 RTL 下也分两种情况。一种是"方向性图标"——比如返回箭头、左右翻页的 chevron、播放器里的上一首/下一首，在 RTL 下必须整体镜像，否则语义就反了。另一种是"通用图标"——比如设置齿轮、购物车、用户头像，这些不需要镜像。
RN 里做一个图标镜像很简单，用 transform：
typescript复制{
transform: [{ scaleX: I18nManager.isRTL ? -1 : 1 }],
}
但你必须知道哪些图标需要镜像。经验法则：图标本身暗含水平方向语义的就需要镜像，没有方向语义的不用动。 比如返回按钮，LTR 下是从左往右指，RTL 下要从右往左指，但字体图标本身只有一个字符，所以一个 scaleX(-1) 就搞定了。
如果整个应用用的是一套 SVG 图标库，OpenHarmony 有自己的图标选择，热词里提到了"openharmony 官方 lucide 图标库"。我建议 RTL 场景下优先用能拿到原始 SVG 的图标库，因为你可以直接对 <Svg> 的根节点做 scaleX(-1) 镜像，而不用去改每个图标文件。
4.4 常见第三方库的 RTL 表现
这是我踩坑的重灾区。很多第三方 RN 组件库没有做过 RTL 适配，到了 RTL 环境下要么布局怪怪，要么手势方向反了。我列举几个常见的：
| 组件库 | LTR 场景 | RTL 场景实测表现 | 解决办法 |
|---|---|---|---|
| react-native-swiper | 正常 | 轮播默认从左边开始，方向反了 | 自己包一层，检测 RTL 后手动改 index 和循环方向 |
| @react-navigation 底部 Tab | 正常 | 大多数操作正常 | 基本不用改 |
| react-native-linear-gradient | 正常 | 渐变方向不会自动镜像 | 手动把 start/end 对调 |
| 自定义 Modal / Popup | 看实现 | 弹窗内容可能不跟随 RTL | 在弹窗根组件上加 style={{ direction: 'rtl' }} |
| 侧滑删除的列表项 | 正常 | 手势方向反 | 根据 RTL 切换滑动动作的起点和终点 |
这些库的问题不是 bug，而是第三方作者在写手势逻辑和动画逻辑时，没有抽象出方向概念。遇到这种情况，我的建议是别去改第三方库的内部实现（因为升级就完蛋），而是在业务层做方向判断，用一层薄薄的包装组件把 RTL 差异包住。
5. 最容易被忽视的排查链路：RTL 失效、轮播方向与原生弹窗
5.1 RTL 开关不生效时的定位顺序
RTL 不生效这个问题，我排查了很久才明白根源。现象是：明明调用了 I18nManager.forceRTL(true)，但页面里一部分组件翻转过来了，另一部分没有。定位顺序如下：
第一，确认调用时机。 forceRTL 不能放在某个页面组件的 componentDidMount 里，应该在应用入口，也就是 index.js 里，React 组件树渲染之前调用。如果你在页面里调用，RN 内部会发一个配置更新事件，但已经挂载的组件不会重新走一遍布局流程。
第二，确认你改的是 RN 的 I18nManager，而不是某个组件库自己的 context。 有些 UI 库会缓存自己的方向状态，比如某些表格库、日历库。需要在调用 forceRTL 之后，重新触发一次组件的重挂载。
第三，检查是不是某个原生组件拦截了布局方向。 这个是 RNOH 特有的问题。RNOH 有一些自定义的原生容器，比如 Modal、Dialog、VideoPlayer 等，它们可能有自己的方向管理逻辑，不跟随 RN 的布局引擎。这时你需要在 ArkUI 侧同步设置 RTL，或者在 RN 侧给这个原生组件手动传 isRTL 属性。
我用一个表格总结我的排查步骤：
| 步骤 | 检查动作 | 通过标准 |
|---|---|---|
| 1 | 确认 I18nManager.isRTL 返回 true |
返回 true 才继续 |
| 2 | hdc shell hilog 里搜 RTL 或 direction |
能看到 RNOH 打出的方向日志 |
| 3 | 检查纯 RN 组件（View+Text）是否翻转 |
没有翻转则 RN 布局层有问题 |
| 4 | 检查第三方容器/原生组件 | 没翻转则在该组件边界做方向适配 |
| 5 | 检查 ArkUI 侧页面方向 | 与 RN 侧一致 |
5.2 轮播组件方向反转
轮播图是阿拉伯语应用里最显眼的组件，我直接给出我在 react-native-swiper 上的处理方式。
核心思路：在 RTL 下，把初始 index 设置为最后一张，并且把展示顺序反转。最简单的办法是数据层面反转数组：
typescript复制const banners = isRTL ? [...bannersData].reverse() : bannersData;
然后 Swiper 初始下标：
typescript复制const [index, setIndex] = useState(isRTL ? banners.length - 1 : 0);
但这样处理有一个副作用：如果后端字段带 id，你在点击跳转时拿到的是反转数组里的位置，需要映射回原数据。所以更稳妥的方式是只反转循环方向，不反转数据：
typescript复制const onIndexChanged = (newIndex: number) => {
// RTL 时 Swiper 的 index 是按视觉顺序走的
const realIndex = isRTL ? bannersData.length - 1 - newIndex : newIndex;
setCurrentIndex(realIndex);
};
这个方案只处理点击的回调，感知上还是有点别扭。后来我把轮播图换成了自己写的 FlatList，通过 pagingEnabled + horizontal + RTL 判断来维护方向，反而更可控。如果你对轮播图有严格的方向要求，我建议直接用 FlatList 平铺实现，组件库只能解决 80% 的场景。
5.3 原生弹窗和 Toast 的方向与文案
弹窗这种场景，RN 的 Modal 组件在 RNOH 上渲染的其实是 ArkUI 的原生弹窗容器。它不会自动继承 RN 页面的 RTL 方向。我遇到过的情况是：页面主体已经完美 RTL 了，但每弹出一个确认框，内容就又回到 LTR 排版，按钮顺序也是反的。
排查链路：
- 先用
Modal的supportedOrientations和onRequestClose排除旋转问题。 - 再检查弹窗背景层有没有包一个
View设置direction: 'rtl'。 - 如果确认是原生侧的问题，只能走自定义弹窗，不要用系统默认的
Alert。
RN 的 Alert 在原生 RN 上是有 RTL 适配的，但在 RNOH 上我测试时不稳定，按钮顺序时而正常时而颠倒。为了绝对可控，我干脆不用。业务里凡是需要弹确认框的地方，全换成了自定义的 Modal 组件，用 RN 的 View 自己搭背景、按钮、标题。这样 RTL 行为完全由自己控制，代价是多写一点样式。
Toast 同理。我最后的方案是在 RN 侧实现一个 Toast 的 JS 组件，基于 Modal 做半透明提示，不再依赖系统 Toast。
这个决策背后的逻辑是：当底层平台对某个系统组件的 RTL 支持不可控时，把该组件上移到 JS 层自绘，是成本最低且最稳妥的长期方案。 原生 RN 的做法是相信平台适配，但 RNOH 还在迭代期，不值得赌。
5.4 用 hdc 导出 UI 布局验证方向
RTL 改完之后，肉眼验证是一回事，但你要在正式提测前有个客观的验证手段。我用的方法是利用 hdc 拉取当前页面的 UI 层级，直接看布局坐标：
bash复制hdc shell uitest dumpLayout
uitest dumpLayout 会输出当前界面的组件树，每个节点带绝对坐标和宽高。你在 LTR 和 RTL 两种状态下各 dump 一次，对比同一个组件的 x 坐标是否发生了左右对调。如果某个关键按钮在 RTL 下 x 坐标反而变小了，说明它没有正确翻转。
再进阶一点，配合截图：
bash复制hdc shell snapshot_display
hdc file recv /data/local/tmp/snapshot.png ./snapshot.png
然后把截图拿到电脑上，跟设计稿做像素级对比。RTL 适配经常出现的"看起来对了但间距差一两个像素"问题，只有截图对比才能发现。
6. 验收清单与后续维护建议
6.1 自动检查：从构建到布局快照
当你适配完一轮之后，最好把验证动作固化下来，别每次手动测。我自己的做法是写了一个简单的 Node 脚本，在 CI 里跑：
- 构建 OpenHarmony 的 HAR 包，确认无原生编译错误。
- 用 hdc 安装到 rk3568 开发板。
- 启动应用，先截图一张 LTR 模式的页面。
- 通过 hdc 调用系统接口切换语言为阿拉伯语，或直接修改应用的 RTL 开关。
- 再截图一张 RTL 模式。
- 对两张截图的关键区域做像素差异分析。
自动化做不到 100% 验证所有细节，但能快速暴露"某块区域完全没翻转"这种大问题。剩下的视觉细节还是需要人工过一遍。
6.2 手动验收要点
以下是我在手动验收时固定检查的几个点位，每次发版前必过：
- 返回箭头方向：左上角还是右上角。
- 列表的 item 内容顺序：从右往左阅读是否符合预期。
- 文案里的电话号码、订单号、英文字段：不被 BiDi 算法拆得七零八落。
- 底部 Tab 的选中态和图标顺序。
- 横向滚动容器：惯性滑动的方向是否与阅读方向一致。
- 输入框：光标起始位置、文字对齐、placeholder 对齐。
- 时间选择器：是否出现"从右往左滑但日期反过来"的诡异交互。
- 多语言切换后：RTL 布局是否需要重启才生效，重启后是否保留正确状态。
这 8 个点位，每一个我都踩过，特别是第 6 个输入框的问题，阿拉伯语输入框在 RNOH 上需要额外设置 keyboardType 和 textAlign，不然会出现字符输入方向错乱。
6.3 关于后续维护的经验
最后分享一个我在这两周里反复验证后得出的结论：RNOH 的 RTL 适配还处于"能用，但需要自己兜底"的阶段。 这意味着你不能把 RN 官方文档里所有 RTL 的能力都默认它是生效的，每用一个原生模块，都得先做一次 RTL 冒烟测试。
如果你要大规模铺阿拉伯语业务，建议成立一个最小的 RTL 专项验证流程：每个涉及方向的 PR，都附一张 RTL 截图，截图里必须包含方向相关的组件。这比任何测试用例都直观。
另外，OpenHarmony 不同版本之间的行为差异也要留意。我之前在 3.2 Release 上验证通过的东西，升到 4.0 之后发现某个原生组件的坐标转换逻辑变了，RTL 布局又错位了。所以 RTL 验证不能只做一次，每次升级 OpenHarmony 版本或者 RNOH 版本，都要把 RTL 验收清单重新跑一遍。
工具层面，hdc 和 hilog 是你最亲密的两个伙伴。遇到任何方向相关的问题，先 hilog | grep -i direction，再 uitest dumpLayout 看坐标，比瞎猜高效得多。