高榕资本做移动端开发这些年，我一直在跟跨平台框架较劲。今年接手了一个很有意思的项目：把原本跑在安卓和 iOS 上的 React Native（RN）应用，完整搬到鸿蒙平台上，同时把原来的固定浏览页升级成了一套带个性化推荐的智能浏览系统。这个项目几乎是把 RN 跨平台开发、鸿蒙生态适配、推荐系统这三块硬骨头一次踩了个遍，过程中有不少东西是文档里翻不到的，今天把这大半年的实践整理出来，希望能给正在做同类方案的同学省点时间。
先说清楚这套东西到底解决什么问题。传统的内容浏览 App 基本都是服务端下发一个通用列表，所有用户看到的东西一模一样，用户翻两下就觉得没意思，留存和点击率都上不去。我们的目标是在鸿蒙、安卓、iOS 三端共用一套 React Native 业务代码的前提下，引入一套轻量级的智能推荐链路，做到"千人千面"，最终提升用户停留时长和内容转化率。适合正在考虑 RN 鸿蒙跨平台方案、或者准备给现有 App 加推荐模块的团队参考，文章里的代码和配置都来自真实项目，可以直接当参考资料用。
1. 项目整体设计与技术选型思路
1.1 核心需求拆解
这个项目表面上看起来是两个需求：跨平台适配和智能推荐。但实际落地时你会发现，这两件事会互相牵制。跨平台决定的是你的代码跑在哪些端上、UI 怎么渲染、原生能力怎么调；推荐系统则决定你的数据链路怎么设计、接口怎么下发、页面怎么承载。如果先做推荐再做跨平台，很容易出现推荐模块在鸿蒙上跑不动的情况；如果先做跨平台再补推荐，又可能发现页面结构根本不好埋点、数据回传路径不通。
我拿到需求后第一件事不是写代码，而是把需求拆成三层：
首先是"承载层"。这一层要解决的是 RN 在鸿蒙上怎么跑起来、原生组件怎么映射、整个应用怎么打包成鸿蒙能识别的产物。这一步不解决，后面所有东西都白搭。
其次是"业务层"。浏览系统本身包含列表页、详情页、搜索、收藏等模块，我们需要在 RN 里把这套页面全部实现，同时抽出统一的页面容器和网络层。
最后是"智能层"。也就是推荐系统，需要完成用户行为采集、召回、排序、下发、展示反馈这整套闭环。
这三层之间是强依赖关系。比如推荐效果好不好，很大程度上取决于承载层能不能稳定地采集到用户的曝光和点击行为；而推荐结果下发之后，也需要业务层有足够的扩展性去渲染不同类型的卡片。
1.2 为什么选 React Native 而不是 Flutter 或 uni-app
技术选型阶段，团队内部其实争论过一轮。当时摆在桌面上的方案有三个：RN、Flutter、uni-app。考察下来，RN 反而成了最适合我们场景的选择，原因主要有三点：
第一，存量代码复用率高。我们的安卓和 iOS 端本来就用 RN 开发，核心业务逻辑已经写了一大堆 JS/TS 代码，选 RN 意味着这些代码能在鸿蒙上直接用，改动量最小。如果用 Flutter，等于要把整个业务层用 Dart 重写一遍，成本完全不可控。
第二，鸿蒙适配进展。RN 社区对鸿蒙的适配比很多人想象的要成熟。华为官方和开源社区维护了一套 React Native for OpenHarmony 的适配层，核心组件和原生模块的映射已经覆盖了绝大多数场景，而且迭代速度很快。相比之下，Flutter 的鸿蒙适配虽然也在推进，但当时在第三方插件、原生交互等方面还不太稳。
第三，JS/TS 生态的灵活性对推荐系统很有利。推荐业务需要频繁调整策略、更新规则，RN 配合热更新机制可以做到天级别迭代，不需要等应用市场审核。
我不是说 Flutter 不行，如果你从零启动一个新项目、团队又主攻 Dart，那 Flutter 可能更合适。但在"老 RN 项目 + 新鸿蒙平台"这个特定场景下，RN 是综合成本最低的选择。
技术选型对比：
| 对比维度 | React Native | Flutter | uni-app |
|---|---|---|---|
| 存量代码复用 | 高（JS/TS） | 低（Dart 重写） | 中（需看语法转换） |
| 鸿蒙适配成熟度 | 较高（社区+厂商共建） | 中 | 中 |
| 热更新能力 | 强 | 较弱 | 中 |
| 推荐业务迭代灵活性 | 强 | 中 | 中 |
1.3 推荐系统的业务定位
再聊推荐系统的定位。我的观点是，小团队做推荐千万不要一上来就追求"千人千面"的深度学习模型那套东西，先想清楚推荐到底为业务解决什么问题。我们这个项目里的浏览系统是内容聚合类产品，核心指标是点击率、人均浏览时长和次日