indienova1. 从React Native到鸿蒙：跨平台开发的一次顺畅转身
做移动端开发这些年，我一直是React Native的深度用户。一套JS代码同时跑Android和iOS，省掉的维护成本不用多说。但当团队接到鸿蒙适配需求时，说实话，我第一反应是又要折腾一套新语法、新框架了。结果真正动手之后才发现，React Native对鸿蒙的支持比想象中成熟得多，尤其是在业务逻辑层面，几乎可以做到“原封不动”地复用。
这次我做的项目是个内容类App的个性化推荐模块，核心场景很简单：用户在首页看到的信息流要按兴趣偏好排序，不同状态的用户看到的内容完全不同，还需要在页面局部动态切换推荐结果的展示形式。放到以前，这种逻辑要么在后端做死，要么在前端写一堆if-else套娃。但借着React Native跨平台的能力和鸿蒙侧的兼容支持，我用一套JS代码就搞定了Android、iOS、鸿蒙三端的统一逻辑，核心全靠条件判断、状态管理和条件渲染这三板斧。
如果你正在做React Native的鸿蒙适配，或者打算用一套代码覆盖多端，这篇文章应该能帮你省掉不少弯路。我会把整个设计过程、关键代码实现、还有那些文档里不会写的坑，全部摊开来讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么推荐逻辑要放在前端用条件判断实现
2.1 后端下发与前端判断的取舍
团队最初讨论方案时，产品经理倾向于让后端把推荐结果算好，前端只管渲染。这个思路在数据量大的内容平台没问题，推荐策略复杂、需要千人千面的场景下，后端算法确实更合适。但我们的场景有个特殊性：推荐规则非常轻量，核心就两条维度——用户当前所处状态（比如是否登录、会员等级、使用时长）和内容类型的组合权重。
如果全部走后端，每次筛选条件变化都要发版或调接口，而且实时交互体验会受网络延迟影响。举个最简单的例子，用户从“未登录”切换到“登录”状态时，推荐列表需要立即刷新。这个请求走一遍后端，再怎么优化也得几百毫秒到一两秒，而前端用状态管理直接切换数据源，几乎是毫秒级响应。
所以我的结论是：轻量级、规则明确的个性化场景，前端条件判断比后端下发更合适；重型算法、海量数据的场景，才需要后端介入。 两者的边界要清晰，前端只做“规则执行”，后端才做“规则生成”。
2.2 跨三端共用一套逻辑的收益
团队覆盖Android、iOS、鸿蒙三个平台，最怕的就是同一个推荐逻辑在三个端各写一份，后续维护就是场灾难。React Native跨平台带来的最大红利是：JS代码层完全共享，只有原生模块可能有差异。
鸿蒙系统虽然底层是自家的ArkUI和方舟运行时，但React Native通过OpenHarmony的适配层，已经可以跑在鸿蒙设备上。我在实践中的做法是：所有推荐逻辑的JS代码放公共目录，鸿蒙端通过原生桥接调用权限和系统能力，UI部分用React Native的组件标准写法。三端的能力差异通过环境检测做条件处理，业务逻辑100%共用了一份代码。
实测下来的感受是：写一套判断逻辑，三端表现一致。而且鸿蒙的方舟编译器对JS代码的执行效率并不差，复杂条件判断的性能损耗几乎可以忽略。
3. 状态管理设计：把用户状态变成可判断的数据
3.1 状态分类与数据模型设计
推荐逻辑要跑起来，第一步是设计好状态数据结构。我把用户状态分为三类：
- 身份状态：是否登录、会员等级、注册时长
- 行为状态：最近浏览的内容类型、收藏偏好、搜索关键词
- 环境状态：设备类型（手机或平板）、网络环境、App版本
这三类状态在JS中用一个扁平对象管理，避免嵌套过深。比如这样：
javascript复制const userState =