React Native 鸿蒙跨平台实战：宠物应用开发踩坑与落地指南

做这套“React Native 鸿蒙跨平台”的宠物应用说实话一开始心里是没有底的。团队手里有一个已经跑了两年的 React Native 项目安卓和 iOS 两头都有线上版本要新增对鸿蒙生态的支持最怕的不是写代码而是“以为能直接跑结果差一堆环境”。我这边负责的是宠物个人资料展示、宠物管理、功能菜单这几个核心模块正好是这套应用最有代表性的部分。整轮做下来最大的感受是React Native 连接鸿蒙这条路已经走得通了但每一步都有“隐藏关卡”网上资料不少能一篇讲透的不多我把我实际踩过的坑和最终落地的东西整理出来。这篇文章不讲大而全的架构就围绕我实际完成的三个核心功能展开穿插环境搭建、状态管理、原生桥接和性能优化的真实经历。如果你手头也有一个 React Native 项目要适配鸿蒙或者说你正准备在鸿蒙上做宠物、会员、物品这类带“档案展示增删改查功能菜单”的业务估计能从里面找到不少能直接抄作业的细节。1. 为什么最终选择“RN 鸿蒙”这条路选型复盘1.1 三个平台、两套代码、一个团队的现实约束项目最初是纯安卓原生写的一套宠物助手后来业务要求覆盖 iOS团队为了不维护两套原生代码用 React Native 重写了主要界面。所谓“跨平台”本质上就是在原生能力外层包一层 JavaScript 引擎让业务代码统一用 JS/TS 写原生 UI 组件通过桥接层和 JS 侧交互。现在要覆盖鸿蒙摆在面前的就两条路一是用 ArkTS 从零重写一遍二是在现有 React Native 工程里把鸿蒙当成一个“新的原生平台”去适配。我们评估了很久核心原因不是技术栈谁好谁坏而是人力和时间都不允许重写。现有 RN 代码里光宠物相关页面就有十几个还有一堆社区组件如果全部用 ArkTS 重新实现不算业务逻辑的迁移成本光是 UI 细节的对齐就够呛。1.2 适配层到底做了什么RN 和 ArkUI 之间怎么“通话”要理解这条路能不能走通得先搞清楚 React Native 在鸿蒙上是怎么运行的。我习惯拿“翻译官”来打比方RN 在安卓上把虚拟 DOM 翻译给安卓的原生控件在 iOS 上翻译给 UIKit 控件而在鸿蒙上翻译目标变成了 ArkUI 组件。具体来说社区提供的适配层用 C 实现了 React Native 的运行时让 JS 代码跑的引擎和一个叫 Fabric 的渲染链路能直接对接鸿蒙的 UI 框架。JS 侧写的View、Text、ScrollView这些组件最终会映射成 ArkUI 侧的对应组件而不是像某些方案那样用 WebView 套壳。这一点非常重要因为这决定了应用能不能拿到真正原生的滚动、动画和触摸交互体验。我实测下来基础组件的映射完成度相当高。像FlatList这种长列表组件在鸿蒙上滚动的手感已经接近原生不再有“网页里滚动”那种笨重感。但前提是别踩到后面我讲的那些细节坑否则体验会瞬间降级。1.3 风险评估哪些地方注定要“额外劳动”选型不能光看美好面。我们在 pre-research 阶段把现有代码里用到的所有 npm 依赖列了一个表逐个看是否兼容鸿蒙。结论是能直接跑的大概七成包括 React Navigation、异步存储、网络请求库这些核心依赖剩下三成要么需要通过 patch 修复要么得用“原生模块包一层”的方式自己解决。举个例子图片选择器在鸿蒙上的表现就和大伙预期的不太一样这属于典型的“社区适配还没跟上”的情况后面我也会详细展开。所以如果你老板跟你说“RN 写一次到处跑鸿蒙肯定也能跑”你可以点头但心里要清楚那句话的准确版本是“业务代码能复用原生能力需要逐个验证”。做选型复盘的时候我把三个核心功能部分拆成了一张表方便自己评估工作量功能模块现有代码复用度鸿蒙适配难点预计工作量宠物资料展示高图片加载、圆角阴影、状态栏适配中宠物管理增删改查中状态管理、键盘弹出、存储中高功能菜单高侧滑返回、原生页面跳转低表格列完结论就很清楚了功能菜单几乎白捡资料展示页和宠物管理是两块硬骨头。整篇文章的重心也就在这两块上。2. 环境搭建里最容易被低估的四个细节2.1 版本对应关系一个“四件套”配合问题跑通 React Native 鸿蒙链路之前我以为无非就是装个 IDE 再跑个脚手架实际上最隐蔽的坑在版本对应关系上。你需要同时关注四个东西鸿蒙系统的 SDK 版本、DevEco Studio鸿蒙的官方 IDE版本、React Native 的版本、以及社区适配层的版本。这四个之间不是“最新就行”而是必须按某个组合锁死否则编译期会报各种莫名其妙的错比如找不到某个头文件、链接器崩溃、甚至干脆无法生成 hap 包。我采用的策略是先去适配层的 release 页面看它明确声明支持的 React Native 版本范围再根据这个范围反推 DevEco Studio 的配置要求。通俗地说适配层是“中间商”它说支持 RN 0.72 的某个小版本那就别手贱升到 0.73否则两个 C 库之间对不上符号排查起来非常痛苦。这里直接给一条经验初始化工程时不要用最新版要用适配层文档里的“测试通过组合”。我当时就是图新装了最新版 IDE结果构建产物一直报一个 C 异常最后全部对齐到文档中的组合才顺利跑起来。2.2 真机调试第一条命令从 adb 切到 hdc如果你之前只做过安卓开发对 adb 那套很熟那到了鸿蒙这边要做的第一件事就是把命令习惯切换一下。鸿蒙真机调试用的不是 adb而是一个叫 hdc 的调试工具很多教程里不会专门强调但它决定了你能不能把应用推到手机上。我遇到的典型场景是按照安卓的思路连上 USB打开开发者模式结果 DevEco Studio 里的设备列表空空如也。后来才发现不仅要授权还得检查 hdc 服务的状态。有一台测试机甚至需要手动把 hdc 的重定向端口做一下映射才能识别。另一个高频问题是用无线调试第一次能连上隔天又不行了后来干脆固定用 USB 调试稳定得多。还有一点Metro 的端口问题也值得一提。RN 开发时需要一个 JS 打包服务真机上的应用会去连接电脑上的 Metro。在安卓上通常是 localhost:8081在鸿蒙上这套机制也保留但如果你用无线调试应用的端口指向就要改成电脑的局域网 IP。这里有个安全相关的点同一个局域网内换 IP 之后别忘记同步修改否则应用会一直白屏或者停在加载界面感觉像是在卡启动实际上是 JS bundle 没拉下来。2.3 调试日志的入口和原生日志的查看方式React Native 开发的习惯是console.log一把梭安卓上有 LogcatiOS 上有 Xcode 控制台鸿蒙这边对应的入口在 DevEco Studio 的 Log 面板里。RN 侧打的日志会统一输出到那里但过滤条件要选对否则会被一堆系统日志淹没。真正麻烦的是原生崩溃日志。所谓“原生崩溃”就是错误发生在 ArkUI 或 C 层JS 侧根本捕获不到。有一次我遇到点击按钮后整个应用无规律退出JS 控制台没有任何报错最后是在 Log 面板里翻到一行带 libarkui 关键词的堆栈才定位到是某个原生组件在特定输入下触发了递归布局错误。所以我的建议是遇到“JS 没事但 app 闪退”的情况不要去 RN 控制台里死磕直接切到原生日志目录定位关键符号速度会快很多。2.4 模拟器和真机的“不一致”比你想的更大如果条件允许优先用真机调试别依赖模拟器。我当时在模拟器上把宠物资料页调得完美——图片圆角正常、阴影正常、滚动跟手结果一上真机全“现原形”圆角渲染丢失、阴影变成难看的黑边、图片加载明显变慢。原因很直白模拟器用的是宿主的 GPU 渲染能力和资源而真机上的硬件能力和系统 UI 渲染策略完全不同。尤其 ArkUI 对图片解码和阴影的渲染路径在模拟器上往往走了简化逻辑。这种东西没法靠代码层面“兼容”只能在调试策略上定死一条功能逻辑可以在模拟器上开发视觉和性能必须真机验收。这条原则我在后面三个模块里贯彻始终。3. 宠物个人资料展示页不只是“头像加昵称”3.1 数据模型设计宠物档案到底该存哪些字段宠物资料展示页是整个应用的门面也是数据模型设计最需要提前想清楚的地方。我最初想得简单以为一个宠物对象就是{ name, avatar, breed }三个字段可真到了做页面的时候才意识到展示和编辑需要的信息远比想象中多。最终我设计的扁平结构大致是这样const petProfile { petId: pet_1001, name: 布丁, avatar: https://cdn.example.com/avatar/pet_1001.jpg, breed: 中华田园猫, category: cat, // cat / dog / other gender: female, // male / female / unknown birthday: 2023-06-15, weight: 4.2, // 单位kg features: [橘猫, 胆小, 爱吃], vaccination: { rabies: 2024-03-01, fvrcp: 2024-03-15, }, isNeutered: true, notes: 捡到的时候三个月大不喜欢陌生人摸肚子, status: healthy, // healthy / ill / recovering };字段设计上我有两条原则。第一能平铺就不要嵌套因为状态管理和接口对接都更省事第二展示型字段和编辑型字段要能区分比如features这种标签数组在资料页只读在编辑页就要变成可增删的标签编辑器。数据来源上这套应用走的是“本地存储 服务端同步”双轨策略。首次登录或接入新设备时从服务端拉取宠物列表之后本地异步存储会保留一份副本即使断网也能打开资料页。这个策略对宠物应用特别重要因为用户经常在户外、在地下室等信号不好的地方打开应用查看宠物免疫记录。3.2 资料卡片的 UI 分层从布局代码看跨平台一致性资料展示页的头部是一张信息卡片我的布局分层是最外层一个圆角容器内部左侧头像右侧上半部分昵称加品种标签中间一行性别、生日、体重的“信息点”底部是疫苗接种状态。用 React Native 的 Flexbox 布局实现这套结构非常顺手因为 Flexbox 在鸿蒙的 ArkUI 里也得到了完整的映射甚至两边对gap属性的支持都一致了这在写间距时代码能少写一多半。不过在鸿蒙上实现“卡片阴影”这件事让我前后折腾了两天。React Native 里的shadowColor、shadowOffset、shadowOpacity、shadowRadius这套属性在安卓上用的是高度加 elevation 模拟在 iOS 上是标准阴影而到了鸿蒙上部分版本对英文版文档里写的这套支持得很有限。我加了四个属性真机上只显示了一个隐约的轮廓非常淡。最后我采取的是一个稳妥方案卡片外层用一层带轻微透明渐变的背景图模拟阴影或者用鸿蒙自己支持的boxShadow写法通过条件样式注入。核心代码先判断平台再决定使用哪套样式虽然难看一点但三个平台显示效果一致。这也是跨平台开发里最常遇到的“一个需求三个实现”的现实。3.3 图片加载占位、缩放和缓存一个都不能少宠物头像在网络状况差的时候能不能优雅展示直接决定用户对应用的耐心。我的做法是统一封装一个PetAvatar组件内部处理四件事加载中态、加载失败态、图片裁剪模式、缓存策略。import React, { useState } from react; import { Image, View, Text, ActivityIndicator, StyleSheet } from react-native; export default function PetAvatar({ uri, size 48, name }) { const [loading, setLoading] useState(true); const [failed, setFailed] useState(false); if (failed) { return ( View style{[styles.fallback, { width: size, height: size }]} Text style{styles.fallbackText}{name.slice(0, 1)}/Text /View ); } return ( View style{{ width: size, height: size }} Image source{{ uri }} style{{ width: size, height: size, borderRadius: size / 2 }} resizeModecover onLoad{() setLoading(false)} onError{() { setLoading(false); setFailed(true); }} / {loading ( View style{[styles.placeholder, { width: size, height: size }]} ActivityIndicator color#8E8E93 / /View )} /View ); } const styles StyleSheet.create({ placeholder: { position: absolute, top: 0, left: 0, justifyContent: center, alignItems: center, backgroundColor: #F2F2F7, borderRadius: 999, }, fallback: { justifyContent: center, alignItems: center, backgroundColor: #D1D1D6, borderRadius: 999, }, fallbackText: { color: #FFFFFF, fontSize: 20, fontWeight: 600, }, });这里有一个鸿蒙特有的坑某些加载失败的图片会在 ArkUI 图片组件内部反复触发onError导致占位组件闪个不停。我的解决办法是在onError回调里加一个标记失败一次后就切换到文字首字母占位不再继续加载原图。这个处理在安卓和 iOS 上不会出问题但鸿蒙上不加就会变成“抖动卡片”当时排查了很久才发现是Image组件对错误响应的缓存逻辑不同。3.4 布局里的跨平台差异状态栏和安全区开发资料页的时候很多细节都藏在这个“页面布局”里。顶部要走状态栏安全区因为 iPhone 有灵动岛安卓这边各厂商的挖孔位置不一样鸿蒙有些机型也有居中挖孔和左上角胶囊孔React Navigation 默认会做一部分适配但我们的应用用的是自定义头部所以必须在页面根容器上手动计算安全区高度。处理方式是在入口处读取StatusBar.currentHeight和SafeAreaView的能力。鸿蒙在 RN 环境下对SafeAreaView的适配已经做到了“基本能看”但部分机型在横屏时还有个隐藏的刘海区域判断问题所以我在资料页禁止了横屏同时也省掉了一大批样式适配的麻烦。如果你做的是视频类或者支持横屏的宠物相机功能这一块就得多测试几台设备了。4. 宠物管理增删改查背后的状态设计4.1 状态管理选型为什么放弃 Redux 换成 Zustand宠物管理模块首先面对的问题是“多个页面共享宠物数据”。列表页要显示所有宠物资料页要显示当前宠物编辑页要修改当前宠物首页可能还要展示“最近更新”的宠物。如果每个页面各自请求、各自存就会出现不同步的坑在编辑页改了名字返回列表页看到的还是旧的。我们早期用 Redux但维护这套宠物数据要写 action、reducer、selector模板代码太多后来新模块统一换成了 Zustand。它的写法更贴近一个“模块级全局变量”但自带状态订阅和更新通知对跨页面同步特别合适。我维护的核心 store 就两个状态宠物列表pets和当前选中的宠物 IDcurrentPetId。列表页展示时订阅pets资料页通过currentPetId从pets里 find 出当前宠物。任何页面执行增删改之后只需要更新pets数组所有订阅了它的页面会自动刷新这就是跨页面同步的核心机制。4.2 新建和编辑的表单处理从受控组件到数据校验新建宠物是一个表单密集型场景我把它设计成一个独立页面包含名字、品种、性别、生日、体重、是否绝育、备注等字段。所有输入框都是受控组件状态集中在页面顶层的formState对象里。对于姓名这种必填字段校验逻辑我坚持“失焦和提交双重触发”。用户还没有填完就点提交会弹出轻提示如果填了但名字超过 20 个字符提交时会被拦下来。体重的校验则更关键因为用户很可能输入负数或者无意义的数字我直接做了一个数字输入组件过滤掉非数字字符同时限制只能有一位小数点。这里要特别提一下键盘弹出在鸿蒙上的表现。安卓上常见的做法是给外层 ScrollView 加keyboardShouldPersistTapshandled和keyboardDismissModeon-drag鸿蒙上我对这两套属性的支持度做了一次实测滚动时收起键盘可以生效但点击空白处收起键盘有时不听话。最后的解决方法是给容器包一个TouchableWithoutFeedback点击空白时手动调用Keyboard.dismiss()。逻辑上更直白也避免了依赖某个属性的实现差异。4.3 删除操作的边界处理二次确认和“删除失败”的还原删除宠物是高风险操作不能做“左滑直接删”。我的交互是在编辑页底部放一个红色“删除宠物”按钮点击后弹出一个模态确认框明确告知“删除后不可恢复”用户必须再次点击“确认删除”才会真正执行动作。删除动作本身是异步的需要调服务端接口。如果网络不好删除请求超时页面上给用户的反馈很重要不能假装“已删除”也不能让用户重复点击导致二次提交。我用的是一个deleting状态标记点击后按钮变 loading 并禁止再次点击。如果删除失败弹 toast 提示“网络异常请重试”同时还原按钮可用状态列表数据不变如果删除成功则更新 store 里的pets数组并返回列表页。这里有个小细节值得说出来删除成功后列表页会找到当前被删宠物的petId从pets中过滤掉但currentPetId仍然指向一个不存在的 ID这时资料页如果 still 订阅着就会渲染出一个空对象导致崩溃。我的处理是在 store 的删除方法里顺带判断如果删的就是当前宠物将currentPetId重置为列表第一个宠物的 ID或者置为空字符串。这个边界条件不加可能只在特定路径下触发但不是每次都能复现很容易测试不出来。4.4 列表刷新策略宁可全量刷新也不要手动拼缓存新增宠物后列表页必须立刻显示新条目。很多新手会犯一个错误在新增页面返回时把新宠物“手动 push 到本地数组头部”这样看起来很快但如果服务端对数据做了排序、过滤或格式校验手动 push 出来的结果和真实数据很可能不一致。比如服务端会把出生日期统一格式化或根据最新体重算出一个“体型等级”这个字段本地根本算不出来。我的策略是任何导致列表变化的操作新增、编辑、删除结束后强制触发一次“静默刷新”也就是重新请求宠物列表接口然后用返回值整体替换本地 store 里的pets。这个策略牺牲了一点点启动速度但保证了三端数据一致性也少了很多“为什么我改完没变”的工单。现在的网络条件几十 K 的 JSON 几乎无感完全值得。5. 功能菜单从静态数组到动态配置5.1 菜单结构设计底部 Tab 和“我的”网格功能菜单在这个应用里承担的是“入口聚合”职责。我采用的是最常见的“底部 Tab 我的页面网格菜单”组合底部两个 Tab一个是“首页”展示宠物列表和最近动态一个是“我的”承载个人资料、设置和一系列功能入口“我的”页面内部是一个两列网格菜单放了“疫苗提醒”“附近医院”“体重记录”“数据导出”“帮助反馈”“关于我们”等六个入口。结构设计的思路是网格菜单的数据不写死而是用一个菜单配置数组渲染。每个菜单项包含id、title、icon、route和needAuth字段。这样做的好处是后续运营想调整入口顺序、隐藏某个功能、或者在特定节日增加一个活动入口只需要改配置不需要改页面代码。5.2 菜单项的动态配置和权限控制权限控制在功能菜单里是绕不开的。比如“疫苗提醒”和“数据导出”比较敏感需要登录后才能用而“附近医院”和“帮助反馈”游客也可以访问。我的做法是遍历菜单数组时根据needAuth字段判断如果用户未登录点击需要权限的入口时不是简单地禁用而是跳转到登录页并在登录成功后自动跳回原目标。这样的用户体验比“灰置按钮”要好因为用户会感觉到“原来这个功能需要登录我现在登一下就能用”。图标这个细节也要提一下。菜单里的图标我用的是自绘 SVG 转成的 PNG 图标集没有依赖第三方图标字体库。原因是在鸿蒙的 RN 环境里图标字体文件的加载路径偶尔和安卓不一致会出现“豆腐块”乱码而 PNG 图标是静态资源只要打包时通过图片配置正确引入三端表现就能做到完全一致。5.3 混合跳转RN 页面和原生 ArkTS 页面的互通应用里并非所有功能都用 RN 实现。“附近医院”的页面比较特殊需要通过地图 SDK 展示诊所位置整体交互天然适合原生 ArkTS 写。这意味着功能菜单不仅要支持 RN 内部路由跳转还要能在必要时跳转到原生页面。实现上我用的是 React Navigation 配合系统级Linking。先在应用里注册一个 URL scheme比如petsapp://native/hospital然后在原生侧写一个接收该 scheme 的 Intent 过滤器原生页面解析参数后显示对应医院信息。反之原生页面点击“返回宠物档案”时也是通过 scheme 调用回 RN 侧。这套混合跳转方案在鸿蒙上遇到的坑比我想象中少但有一个点需要提前说明URL scheme 的注册名要足够独特避免和其他应用冲突。我当时注册了一个太常见的名字结果有次在一台装有多个类似应用的测试机上点击菜单跳转到了另一个应用的页面场面一度尴尬。后来改成了带应用标识的长前缀再没出过问题。5.4 侧滑返回手势和菜单的交互冲突鸿蒙系统有全局侧滑返回手势这个手势和底部的 Tab 切换、左滑菜单、以及“我的”页面里的二级列表返回都存在潜在的交互冲突。我在真机测试时遇到一个具体问题在“我的”页面里进入“疫苗提醒”二级页左边缘向右滑动时有时会直接弹出应用而不是返回上一页。排查之后发现不是手势本身有问题而是二级页的返回行为没有通过 React Navigation 的 API 正确注册。在 iOS 和安卓上导航器对返回手势有着和系统一致的默认处理但鸿蒙的全局手势优先级更高JS 侧如果不显式声明“这个页面要拦截侧滑返回”系统就会认为你没有要拦截的意图直接走全局手势。解决办法是在二级页根组件里通过BackHandler注册返回监听在事件回调里手动调用navigation.goBack()并返回true告诉系统“返回事件已经被处理”。这个处理方式在安卓上是为实体返回键准备的在鸿蒙上正好也覆盖了侧滑手势。为了让三个平台体验一致我把这段逻辑写成了条件注入只有鸿蒙平台才启用避免干扰 iOS 的原生侧滑。6. 实战踩坑清单四类问题值得你提前布防6.1 图片选择器在鸿蒙上“不弹相册”的替代方案宠物管理的编辑页需要支持更换头像早期我引入了一个社区里常用的图片选择库。这套库在安卓和 iOS 上工作良好但到了鸿蒙平台调用系统相册时直接没反应也没有任何报错——这是最让人头疼的情况JS 日志干干净净原生日志找了一圈才发现是底层某个 AIDL 调用不兼容。我没有止步于“这个库不行”而是找了一个折中方案写一个轻量的原生模块通过 ArkTS 调用系统相册接口选图再把选中的图片路径回传给 RN 侧。这其实就是 React Native 最典型的能力扩展路径虽然写了原生代码但工程量很小只封装了“打开相册、读取图片、返回路径”三个动作。对于每个团队来说掌握这种“自包原生模块”的方法比祈祷某个社区库支持鸿蒙更可靠。6.2 本地存储AsyncStorage 能撑住宠物档案吗宠物资料和整个用户设置我用异步存储库保存了一份本地副本。在鸿蒙上这个存储库的表现中规中矩读写速度没问题但有一个隐患如果把宠物头像转成 base64 直接塞进存储随着宠物数量增长和图片体积变大存储占用会飙升读写也会变慢极端情况下会出现“写入失败”的报错。我的调整是存储里只保存图片的远程 URL 和本地文件路径不保存图片二进制。头像图片用图片缓存库在本地做缓存需要时从缓存目录读取不需要时自动清理。这样存储库只负责保存文本 路径这种轻量数据性能压力小很多。这不仅是鸿蒙平台要注意的问题安卓 iOS 同样适用只是鸿蒙现在的存储回收机制更激进提前做好规范能少踩很多雷。6.3 长列表性能用 FlatList 却卡顿问题不一定在列表宠物数量超过一两百条的时候首页宠物列表的滚动会出现掉帧。起初我以为是鸿蒙渲染性能不行后来一步步排查才发现问题出在每一条宠物卡片组件的一个看似的“无心之举”每次渲染都会计算一个基于当前时间的时间差字符串比如“3天前打过疫苗”而列表滚动时每个卡片重新渲染都会重新执行计算导致渲染函数被反复触发。解决方式很传统用useMemo把时间差计算缓存起来让依赖的数据没变就不重新计算同时配置 FlatList 的initialNumToRender、maxToRenderPerBatch和windowSize参数把每次渲染的批次控制在一个合理范围。这里我最大的教训是跨平台项目里出现性能问题先看自己的代码有没有“每帧重活”不要第一反应就怪平台渲染引擎。6.4 让人迷惑的字体单位RN 的像素和鸿蒙的 vp最后一个想单独说说的坑是字体单位。在 React Native 里写fontSize: 16指的是逻辑像素这套逻辑在鸿蒙上映射时和 ArkUI 自己的vp单位并不完全等价。实际测试中同一个 16在部分鸿蒙机型上渲染结果比安卓偏小导致原本能放一行的标题变成了两行布局被撑变形。我自己的处理方式是不在 JS 侧硬编码依赖平台的魔法数值而是用Platform.select为鸿蒙单独定义一套字号缩放系数在全局样式基础上统一乘上去。宠物资料页的昵称和疫苗状态文字是重灾区单独针对这些场景做了一轮真机视觉走查确保三个主流机型上的文字大小和行数一致。跨平台开发里“差不多就行”往往会在真机上变成“差很多”字体单位这种细节最需要提前定好规范。整套宠物应用从选型评估到三个核心功能全部落地前后花了大概几周时间中间有无数次想摔手机的时刻但最终的成果确实让人欣慰一套 React Native 代码跑通了安卓、iOS 和鸿蒙三个平台宠物的资料展示、管理操作和功能菜单在鸿蒙上都能提供接近原生的体验。如果你也准备走这条路我给的建议是环境版本对齐是最先要解决的硬门槛然后从功能菜单这种低风险模块起步逐步啃资料展示和业务管理最后再回头优化长列表和图片性能。每个模块都留出真机调试的时间鸿蒙上“模拟器可用”和“真机可用”之间的差距往往比你在安卓上经历过的还要大。