RN开发鸿蒙适配：桥接原理与最小闭环实操指南

1. 为什么React Native开发者要正视HarmonyOS适配

先说个真实感受：很多做React Native（以下简称RN）的团队，直到2024年底还在观望鸿蒙适配这件事。但到2025年，这个态度基本已经撑不住了——新发布的HarmonyOS NEXT设备不再兼容Android APK，这意味着纯RN打包的App在纯血鸿蒙设备上直接装不上、跑不了。

如果你所在的公司或客户对国内消费市场有覆盖需求，鸿蒙已经是绕不开的交付目标。而RN作为跨端方案，在鸿蒙生态里并没有像iOS/Android那样“打包即用”的成熟通道，需要开发者理解鸿蒙的原生体系，再通过桥接层把RN的能力映射过去。一句话说清楚就是——你可以在RN里写鸿蒙组件，但前提是你要先搞清楚鸿蒙这边的原生接口、生命周期和数据绑定方式。

这篇文章面向的是有RN基础、但对HarmonyOS原生开发了解不多的开发者。我会从一个实操过的角度，把鸿蒙侧的基础概念、RN桥接鸿蒙的原理解析、一个完整可跑的Demo步骤，以及踩坑记录全部梳理出来。目标就是：你看完以后，能自己搭出一个RN调用鸿蒙原生能力的最小闭环，而不是只看一堆官方文档却无从下手。

我先把话说在前面——鸿蒙开发的基础不是“要不要学”的问题，而是“要学到哪一层”的问题。对于RN开发者，你不需要成为鸿蒙原生专家，但至少得弄懂四件事：ArkTS语法、UI组件模型、Ability生命周期、权限声明方式。这四件事搞明白，后面接RN的任何原生模块都不慌。

2. 鸿蒙开发基础认知：RN开发者必须掌握的四块拼图

2.1 ArkTS与ArkUI：听起来新，本质不陌生

HarmonyOS原生开发目前的主推语言是ArkTS，基于TypeScript扩展而来。如果你写过TS，转到ArkTS几乎没有语法门槛——它保留了TS的静态类型、泛型和装饰器能力，额外加了状态管理相关的注解和一些并发API约束。最明显的区别是：ArkTS对某些动态语法（比如用any满天飞、随意用eval）限制非常严格，编译器会主动报错，逼你写出可静态分析的代码。

UI部分叫ArkUI，提供了一套声明式写法，跟SwiftUI和Flutter的Widget树很像。一个最简单的页面长这样：

typescript复制@Entry
@Component
struct IndexPage {
  @State message: string = 'Hello HarmonyOS'

  build() {
    Column({ space: 10 }) {
      Text(this.message)
        .fontSize(30)
        .fontWeight(FontWeight.Bold)
      Button('点击更新')
        .onClick(() => {
          this.message = '已从RN侧触发'
        })
    }
    .width('100%')
    .height('100%')
    .padding(20)
  }
}

@Entry标记入口组件，@Component声明这是一个组件，@State声明响应式状态，UI会跟随状态变化自动刷新。这套写法和RN中的useState配合JSX的逻辑非常像，只不过这里是编译期处理状态依赖。

RN开发者学ArkUI最快的路径是：把@State当成useState，把build()里的组件树当成手写JSX，把.fontSize()这类链式调用当成RN的style属性。一旦建立起这层映射，你读鸿蒙原生组件的代码就不会有障碍。

2.2 Ability与页面生命周期：这不是Activity，但你可以这么理解

鸿蒙的Ability分两种：UIAbility和ExtensionAbility。RN开发者在做原生集成时，主要和UIAbility打交道——它是带界面的能力单元，类似Android的Activity。一个应用可以有多个UIAbility，每个UIAbility可以包含多个页面（Page），页面之间通过router或Navigation跳转。

生命周期上，UIAbility有onCreate、onDestroy、onForeground、onBackground，页面级组件有aboutToAppear、aboutToDisappear。如果你从Android过来，这些名字几乎不用查文档都能猜到含义。但有个区别需要注意：鸿蒙对后台运行限制非常严格，UIAbility切到后台后，如果被系统回收，没有Android那种"被杀后自动重建Activity"的完整机制，所以数据恢复逻辑要自己用状态管理组件（比如AppStorage、PersistentStorage）做好持久化。

RN的AppState监听在鸿蒙侧同样适用，但触发时机和后台限制有关。实际开发中，如果RN页面在鸿蒙App进入后台后需要做数据刷新，建议在原生侧通过onBackground回调主动通知JS层，不要完全依赖RN自身的事件派发——我遇到过RN的AppState事件在鸿蒙上偶尔延迟的情况，主动通知反而更靠谱。

2.3 模块权限与声明：一个容易翻车的基础点

鸿蒙的权限系统和Android类似，需要在module.json5里声明。比如需要读取相册：

json复制{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.READ_IMAGEVIDEO",
        "reason": "需要读取图片以完成上传功能",
        "usedScene": {
          "abilities": ["EntryAbility"],
          "when": "inuse"
        }
      }
    ]
  }
}

注意reason不能乱写，应用市场审核时会看这个字段。usedScene里的when有三种取值：inuse（仅在前台使用）、always（后台也使用）、notInuse（后台使用但界面不可见）。RN原生模块如果需要权限，同样要在这里声明——不要试图在JS层用PermissionsAndroid的API去请求鸿蒙权限，那是Android专属的，鸿蒙侧需要调用abilityAccessCtrl的API，通常建议封装在原生模块里。

2.4 分布式能力：RN开发者可以先不碰，但要知道它存在

鸿蒙的分布式软总线、跨设备流转这些能力，是它区别于Android/iOS的核心卖点。但这些能力目前和RN的桥接层还没有形成成熟的封装方案，所以在RN鸿蒙组件开发中，分布式相关的内容更多是“预留接口”。我建议你第一阶段先忽略分布式相关API，把精力放在UI渲染和基础能力桥接上；等RN鸿蒙生态发展成熟一些，再考虑跨端流转的场景。

3. RN集成鸿蒙的路线选择：三条路分别适用于什么场景

搞懂基础概念后，接下来是路线决策。RN接入鸿蒙目前有三条主流路线，我分别说下优劣和适用场景。

3.1 路线一：使用社区维护的RN鸿蒙适配框架

社区目前有部分开源团队在做RN的鸿蒙适配层，它们把RN的C++核心和HarmonyOS的底层能力做了绑定，形成一个类似react-native-harmony的框架。使用这种框架时，你现有RN代码改动量很小，大部分JS代码可以直接复用，原生侧的系统会自动把你写的RN组件渲染成鸿蒙原生视图。

适合：已有成熟RN项目、团队规模不大、没精力自研桥接层的场景。优点是快，缺点同样明显——框架的维护速度和鸿蒙系统版本绑定较紧，一旦鸿蒙发布新特性，你可能得等框架跟进。

3.2 路线二：通过自定义原生模块自行桥接

自己写一个鸿蒙原生模块，暴露给JS调用。这是目前最灵活、可控性最强的方案。你在鸿蒙工程里用ArkTS写业务逻辑，通过TurboModule的接口约定暴露给RN侧JS调用，RN侧负责UI和交互层，需要系统能力时再调用原生模块。

适合：对鸿蒙有定制需求、现有RN工程规模较大、想逐步迁移的场景。这条路对开发者的鸿蒙基础要求最高，但收益也最大——你可以精确控制每一个桥接方法的性能和安全性。

3.3 路线三：WebView混合方案，把RN嵌入鸿蒙Web容器

将RN构建出的Web资源包直接放进鸿蒙的Web组件中，相当于用WebView来做混合渲染。这条路最简单，但性能和体验比原生渲染差不少，而且无法获取鸿蒙的系统级能力。适合临时过渡，或者对UI性能要求不高的管理类应用。

我把三条路线整理成一张对比表，方便你参考：

我个人的倾向是：如果你是做个Demo或验证可行性，走路线一；如果是要长期维护上架应用，直接走路线二——自己掌握原生模块源码，才能在鸿蒙系统版本更新时主动适配，而不是被动等社区。

4. 核心原理拆解：RN桥接鸿蒙底层是怎么工作的

4.1 RN的JS引擎与鸿蒙原生模块之间那层"翻译官"

RN在鸿蒙上的通信机制，核心依旧是JS Bridge和TurboModule两套体系。JS Bridge是经典方案，通过JSON序列化消息在JS和原生侧之间传递；TurboModule则是新一代方案，用JSI（JavaScript Interface）直接持有C++层的对象引用，省去序列化开销。

在鸿蒙适配中，TurboModule被映射为鸿蒙侧的NativeModule接口。你写的ArkTS模块只要实现了这个接口，RN的JS运行时就能通过JSI直接调用它。整个过程可以类比为：RN的JS代码是“乘客”，鸿蒙原生模块是“目的地”，JSI是“直达地铁”——不需要每次上下车换乘（JSON序列化），效率自然高。

用代码感受一下。鸿蒙侧定义一个简单的原生模块：

typescript复制import { TurboModule } from '@ohos.telephony.turboModule';

export class RNHarmonyToastModule extends TurboModule {
  showToast(message: string): void {
    promptAction.showToast({
      message: message,
      duration: 2000
    });
  }
}

然后通过模块注册表把RNHarmonyToastModule注册成JS侧可访问的ToastModule。RN侧JS调用时，完全像是在调用一个普通的JS模块：

javascript复制import { NativeModules } from 'react-native';
const { ToastModule } = NativeModules;

ToastModule.showToast('这是来自RN的调用');

整个过程的关键在于：鸿蒙侧的模块接口签名，必须和RN JS侧调用的方法名、参数类型严格对应。这里最容易犯的错误是参数类型不匹配——比如鸿蒙侧声明的是string，JS侧传number，桥接层可能直接抛异常而不是帮你做隐式转换。

4.2 原生UI组件的封装原理：从鸿蒙View到RN组件

除了调用原生能力（如弹窗、数据库），你还需要在某些场景下把鸿蒙的原生UI组件嵌入到RN的页面中。比如你写了一个鸿蒙侧的高性能列表组件，想直接在RN的View层级里使用。

RN在Android/iOS上提供了requireNativeComponent接口来暴露原生视图。在鸿蒙适配中，思路完全一致，只是底层实现从Android的ViewManager换成了鸿蒙的ComponentManager。你在鸿蒙侧创建一个组件管理器，实现createView、updateView等方法，RN侧用requireNativeComponent把它声明成一个JS组件。

一个简化的鸿蒙侧组件管理器长这样：

typescript复制export class RNHarmonyCustomViewManager extends ComponentManager {
  createView(): CustomComponent {
    return new CustomComponent();
  }

  updateView(view: CustomComponent, props: Record<string, string>): void {
    if (props.text) {
      view.setText(props.text);
    }
  }
}

RN侧对应：

javascript复制import { requireNativeComponent } from 'react-native';

const CustomView = requireNativeComponent('RNHarmonyCustomView', CustomViewComponent);

function CustomViewComponent(props) {
  return <CustomView {...props} />;
}

理解这个机制的关键点在于：RN侧组件只是“遥控器”，真正渲染在屏幕上的视图是鸿蒙原生的CustomComponent实例。事件回调（比如点击）需要从鸿蒙侧通过emitMessage主动抛给RN JS层，而不是RN主动去拉取。

4.3 桥接层的数据类型与内存管理细节

桥接层的数据类型映射是很多RN开发者在鸿蒙上栽跟头的地方。JS侧的数据类型到ArkTS侧的映射规则大致如下：

内存方面，RN的JSI在鸿蒙上使用Hermes引擎时，JavaScript对象和ArkTS对象之间的引用要留心循环引用问题。如果你在JS侧把一个对象传给原生侧，原生侧持有这个对象不走release，而JS侧也已经不再持有，就会造成泄漏。后续我会在排查章节详细讲这个坑。

5. 实操：从零搭建RN调用鸿蒙原生模块的最小Demo

5.1 准备工作：环境与工程目录结构

先准备好环境，这不是可以跳过的步骤：

• 安装了DevEco Studio（鸿蒙官方IDE）
• 下载了HarmonyOS SDK（API版本建议用最新的稳定版，注意API 12及以上对ArkTS的限制更严格）
• 一台鸿蒙真机或模拟器（最好有真机，模拟器对部分硬件能力模拟不完整）
• 你现有的RN工程（建议RN版本在0.72以上，对Hermes和TurboModule支持更好）

推荐的工程目录结构是把鸿蒙工程作为RN工程下的一个子项目，比如：

code复制my-rn-app/
├── harmony/
│   ├── entry/src/main/ets/
│   │   ├── MainAbility/
│   │   ├── pages/
│   │   └── nativeModules/
│   └── entry/src/main/resources/
├── android/
├── ios/
├── index.js
├── package.json
└── app.json

把鸿蒙工程放在harmony/目录下，好处是两个工程相对独立，但又共享同一个仓库，多人协作时不会互相干扰。

5.2 鸿蒙工程侧：创建桥接模块的完整步骤

第一步，在entry/src/main/ets/nativeModules/目录下新建ToastModule.ets：

typescript复制import { TurboModule } from '@ohos.telephony.turboModule';
import promptAction from '@ohos.promptAction';

export class ToastModule extends TurboModule {
  showToast(message: string): void {
    promptAction.showToast({
      message: message,
      duration: 2000
    });
  }

  showToastLong(message: string): void {
    promptAction.showToast({
      message: message,
      duration: 3500
    });
  }
}

第二步，在entry/src/main/ets/下找到模块注册入口（通常是EntryAbility.ts或Index.ets），注册这个模块：

typescript复制import { ToastModule } from './nativeModules/ToastModule';

// 在合适的位置（通常是onCreate或模块初始化回调里）执行注册
TurboModuleManager.registerModule('ToastModule', new ToastModule());

第三步，在鸿蒙工程的module.json5中确认包结构正确，同时注意entry模块的abilities配置中，UIAbility的exported属性需要按需设置，如果是仅用于RN容器，通常设置为false。

5.3 RN侧：配置与调用代码

RN侧在index.js或App.js里，通过NativeModules直接调用：

javascript复制import { NativeModules, Button, View } from 'react-native';
const { ToastModule } = NativeModules;

function App() {
  const handlePress = () => {
    ToastModule.showToast('你好，鸿蒙！');
  };

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Button title="调用鸿蒙Toast" onPress={handlePress} />
    </View>
  );
}

这样写有个前提：RN工程已经通过社区适配框架跑在了鸿蒙的UIAbility容器里，JS引擎已经能正常加载bundle。如果你的工程还没跑到这一步，建议先跑通一个空的RN页面在鸿蒙上渲染成功，再做原生模块桥接——要把调不通的问题分层排查，别把基础环境问题和桥接问题混在一起。

5.4 构建运行：手动触发与调用验证

在DevEco Studio中打开harmony/目录，选择你的设备，点击Run，鸿蒙工程会编译并安装到设备。安装完成后，应用启动时会自动加载RN的bundle。如果一切顺利，你会在鸿蒙设备上看到一个RN页面，点击按钮后弹出鸿蒙原生Toast。

我在第一次跑这个Demo时踩了个坑：RN侧调用方法时，Toast没弹出来，但也没有报错。排查半天发现是鸿蒙侧showToast方法名在编译时被混淆了——鸿蒙的Release包默认会做混淆，而RN侧调用的是原始方法名，所以找不到入口。解决办法是在鸿蒙侧混淆配置中排除原生模块相关类名和方法名。

5.5 参数计算与配置细节

这里有一个参数细节需要注意：promptAction.showToast的duration参数只接受两个固定值——2000毫秒和3500毫秒。如果传别的值，不会报错，但系统会默认当作2000来处理。我在自己的Demo里，把短提示定义为2000毫秒，长提示定义为3500毫秒，并在RN侧封装一个JS工具函数：

javascript复制export function showNativeToast(message, duration = 'short') {
  if (!ToastModule) {
    throw new Error('ToastModule未注册，请检查鸿蒙侧配置');
  }
  if (duration === 'long') {
    ToastModule.showToastLong(message);
  } else {
    ToastModule.showToast(message);
  }
}

这样的好处是，JS侧不需要感知鸿蒙侧的固定时间和唯一调用方式，后续如果要替换实现（比如改用Dialog），只需要改封装函数内部，业务代码完全不受影响。

6. 进阶：写一个鸿蒙原生UI组件并在RN中渲染

如果只是调用原生能力，你很快会发现一个更迫切的需求：把鸿蒙的原生UI组件嵌入RN页面。这个场景最常见的是地图组件、高性能列表和音视频播放器——这些组件纯用RN的自带View去实现，性能不够，或者能力不足。

6.1 鸿蒙侧实现原生组件管理器

我以一个简单的"原生标签组件"为例，它接收一个text属性和一个onPress事件回调。

在nativeModules/目录下新建NativeLabelManager.ets：

typescript复制import { ComponentManager } from '@ohos.arkui.componentManager';
import { Router } from '@ohos.router';

export class NativeLabelManager extends ComponentManager {
  createView(): NativeLabelComponent {
    return new NativeLabelComponent();
  }

  updateView(view: NativeLabelComponent, props: Record<string, string>, oldProps: Record<string, string>): void {
    if (props.text !== undefined && props.text !== oldProps.text) {
      view.setText(props.text);
    }
  }
}

class NativeLabelComponent extends Component {
  private text: string = '';

  setText(value: string): void {
    this.text = value;
    this.textView().setText(value);
  }

  textView(): Text {
    // 返回实际的Text组件
    return new Text(this.text);
  }

  onPress(): void {
    this.emitMessage('onPress', { value: this.text });
  }
}

组件管理器需要注册到鸿蒙组件管理器中，开发环境和Release环境注册代码略有不同。另一点需要注意的是，updateView在RN侧首次渲染时也会被调用，所以老的props参数可能为空对象，要做空值判断。

6.2 RN侧声明与使用原生组件

RN侧创建NativeLabel组件：

javascript复制import { requireNativeComponent } from 'react-native';

const NativeLabel = requireNativeComponent('NativeLabelManager', NativeLabelView);

function NativeLabelView({ text, onPress }) {
  return <NativeLabel text={text} onPress={onPress} />;
}

export default NativeLabelView;

然后在业务代码中直接使用：

javascript复制<NativeLabel
  text="这是一个鸿蒙原生标签"
  onPress={(event) => {
    console.log('原生组件被点击了', event.nativeEvent.value);
  }}
/>

这套流程跑通后，你会发现RN的页面中“镶”了一块鸿蒙原生的UI组件，事件传递和属性更新都是实时同步的。性能比用RN重新实现同样功能好很多，尤其在需要频繁刷新UI的场景（比如滑动列表、视频帧回调）。

6.3 原生组件事件回调的几个细节

事件回调最容易出问题的是频率控制。如果鸿蒙侧在滚动、帧率变化等高频场景下频繁emitMessage，会导致RN侧JS线程事件积压，UI卡顿。我的建议是：在鸿蒙侧做节流，至少16毫秒内只发一条事件；如果只有最新值才有意义（比如进度条），直接在鸿蒙侧做“最新值覆盖”逻辑，丢弃中间值。

还要注意事件回调的参数序列化。鸿蒙侧emitMessage时传的object参数，在RN侧会变成一个nativeEvent对象，注意保持字段命名一致，并且如果存在嵌套对象，确保巢不超过一层——深嵌套在序列化时容易丢失数据。

7. 常见问题与排查技巧实录

这部分内容是我实际操作中积攒下来的，很多坑在官方文档里找不到明确答案，但遇到了又很致命。

7.1 桥接方法调用无反应，也没有报错

现象：JS侧调用ToastModule.showToast，控制台无输出，鸿蒙也没弹出Toast。

排查思路分三步：

1. 先确认模块是否注册成功。在鸿蒙侧注册后加一行日志，比如console.info('ToastModule registered')，如果设备日志里没有这行，说明注册路没走通。
2. 再确认RN侧加载的bundle是新的。有时候改了JS代码但bundle缓存没刷新，可以手动执行一次build和bundle生成命令。
3. 最后确认Release混淆问题。鸿蒙Release包默认开启混淆，需要在entry/build-profile.json5里的arkOptions.obfuscation里加上要保留的类名，比如：

json复制{
  "arkOptions": {
    "obfuscation": {
      "ruleOptions": {
        "enable": true,
        "files": ["./obfuscation-rules.txt"]
      }
    }
  }
}

然后在obfuscation-rules.txt里加上：

code复制-keep-names, class com.example.myapp.nativeModules.** { *; }

7.2 数据类型映射导致的Crash

现象：JS侧传递一个数字给鸿蒙侧方法，鸿蒙侧接收的是string，运行时崩溃。

RN的桥接在Android上偶尔会做宽松转换，但在鸿蒙的ArkTS强类型约束下，这种宽松是不存在的。解决办法只有一个：鸿蒙侧方法签名用Object接收，然后在内部手动转换，比如：

typescript复制showMessage(value: Object): void {
  const message = typeof value === 'number' ? String(value) : value as string;
}

这种方法能在桥接边界做兼容，但要付出一定的性能代价。如果产品上允许，最好在RN侧就严格确保类型一致性。

7.3 内存泄漏：原生模块持有JS回调引用

现象：页面反复进入退出后，内存持续增长。

原因很简单：鸿蒙侧保存了从RN传来的回调函数，但RN侧页面销毁时没有通知鸿蒙侧释放这个引用，导致每次进入页面都积累一个新的回调。

解决思路是：RN侧在组件卸载时，显式调用一个原生方法（比如cleanup），让鸿蒙侧做引用清理。同时，在鸿蒙侧用WeakReference保存JS回调，而不是强引用，这样即使偶发忘记清理，也不会造成内存泄漏。

7.4 页面生命周期不同步导致的事件丢失

现象：RN页面还在，但原生的onBackground事件已经把某些功能停了，导致RN侧调用原生模块时行为异常。

这是因为RN的AppState事件和鸿蒙UIAbility的生命周期不是完全同步的。我的习惯是在原生模块内部自行处理生命周期逻辑，不依赖JS侧去感知。比如，如果原生模块需要在后台暂停某些服务，我会在onBackground里直接暂停，然后向JS侧发送一条"状态变更"事件。这样可以保证原生侧行为自主可控。

7.5 常见问题速查表

8. 经验总结与实操建议

最后说几个我在实操过程中积累的技巧，每一句都是踩过坑之后得出的。

第一个建议是：先在鸿蒙工程里把纯原生版跑通，再谈RN桥接。很多人一上来就试图在RN里调鸿蒙原生模块，结果调不通根本不知道问题出在哪一层。正确顺序是：先在纯鸿蒙工程里验证原生模块能正常工作，再把这个模块嵌入到RN容器里。这样每一层都是有把握的。

第二个建议是：在RN侧建一个"原生能力适配层"，不要直接散装调用NativeModules。比如：

javascript复制// nativeAdapter.js
import { NativeModules, Platform } from 'react-native';

const isHarmonyOS = Platform.OS === 'harmony' || Platform.OS === 'android';

export function showToast(message, duration = 'short') {
  if (isHarmonyOS && NativeModules.ToastModule) {
    NativeModules.ToastModule.showToast(message);
    return;
  }
  // 非鸿蒙平台回退到JS实现
  console.log(`[Toast] ${message} (${duration})`);
}

这样做的价值在于：你的业务代码不用感知平台差异，后续鸿蒙平台表现不稳定或有新API时，只需要改这一个适配层文件。

第三个建议是：关注鸿蒙系统的API变更公告。鸿蒙的版本演进速度比Android快，API接口经常在Minor版本就发生变化。你在发布正式版前，一定要用目标版本的SDK重新编译测试，最好建立一套自动构建流程，每次鸿蒙新版发布时自动拉取跑一遍回归用例。

第四个建议是：给团队里至少一个人做鸿蒙原生开发的培训。RN鸿蒙桥接这个活儿，本质上是个"跨端翻译"的岗位，既要懂RN的JS运行时和组件生命周期，又要懂鸿蒙的UIAbility和ArkTS。如果团队里没有懂鸿蒙原生的人，全靠看文档摸索，效率会非常低。找一个熟悉RN但愿意学原生开发的同事，给他两三周时间专攻鸿蒙基础，后面整个团队都能受益。

说到底，RN开发鸿蒙组件这件事，刚起步的时候确实有不少信息和工具上的缺口。但随着鸿蒙生态的完善和社区框架的成熟，这条路会越来越顺。现阶段谁先跑通闭环，谁就能在适配速度和稳定性上占得先机。

我自己的体会是，开发者真正需要的不是把鸿蒙文档背下来，而是建立"RN到鸿蒙"这套双层映射的心智模型。一旦你理解了桥接的本质不过是在两种UI体系和两种运行时之间做翻译，那么迁移到任何跨端框架、任何原生系统，都是同样的方法论。这也是为什么我一直建议身边做RN的同事早点把鸿蒙基础补上——多掌握一套原生体系，跨端开发的底子就更扎实一层。