企业官网建设流程全解析

做这套“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一把梭，安卓上有 Logcat，iOS 上有 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 }} resizeMode="cover" 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 加keyboardShouldPersistTaps="handled"和keyboardDismissMode="on-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 和鸿蒙三个平台，宠物的资料展示、管理操作和功能菜单在鸿蒙上都能提供接近原生的体验。如果你也准备走这条路，我给的建议是：环境版本对齐是最先要解决的硬门槛，然后从功能菜单这种低风险模块起步，逐步啃资料展示和业务管理，最后再回头优化长列表和图片性能。每个模块都留出真机调试的时间，鸿蒙上“模拟器可用”和“真机可用”之间的差距，往往比你在安卓上经历过的还要大。