Android KMP(Kotlin Multiplatform)

由浅入深,从基本概念到源码原理,再到实战示例与生产级应用案例,系统梳理 Kotlin 跨平台开发之道


一、基础概念

1.1 什么是 Kotlin Multiplatform(KMP)?

Kotlin Multiplatform(又称 KMP 或 KMM)是 JetBrains 推出的跨平台代码共享方案,其核心理念是:共享业务逻辑,保留原生 UI

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────────────────┐
│ KMP 架构:共享逻辑,原生 UI │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Android │ │ iOS │ │ Web │ │
│ │ (Kotlin) │ │ (Swift) │ │ (JS/WasM) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ │ 原生 UI 层 │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 共享模块 (shared / commonMain) │ │
│ │ 业务逻辑 · 网络请求 · 数据模型 · 存储 · ViewModel │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

与 Flutter、React Native 等「一套 UI 到处跑」的方案不同,KMP 让你:

  • Kotlin 写共享的业务逻辑、网络、数据层
  • Jetpack Compose 写 Android UI,用 SwiftUI 写 iOS UI
  • 得到的是 原生体验,而非 WebView 或自绘引擎

1.2 为什么需要 KMP?

痛点 KMP 的解决方式
Android / iOS 重复实现业务逻辑 共享 ViewModel、UseCase、Repository 等
双端行为不一致(如计算逻辑) 同一套 Kotlin 代码,编译到各平台
双端各自维护一套网络/序列化代码 共享 Ktor + kotlinx.serialization
希望跨平台但不牺牲原生体验 保留原生 UI 框架
团队已有 Kotlin 基础 复用技能栈,降低学习成本

1.3 KMP 与主流跨平台方案对比

维度 KMP Flutter React Native
UI 方案 原生 UI(Compose / SwiftUI) 自绘引擎(Skia) 原生组件 + Bridge
共享范围 业务逻辑、网络、数据 UI + 逻辑全部共享 UI + 逻辑共享
性能 接近原生 接近原生 依赖 JS Bridge
包体积 共享库较小 需携带 Flutter 引擎 需携带 RN 运行时
生态 Kotlin 生态、官方支持 Dart/Flutter 生态 JS/React 生态
学习曲线 Kotlin 开发者友好 需学 Dart 需学 React/JS

适用场景:KMP 更适合「业务逻辑复杂、希望 UI 保持原生」的应用,如金融、电商、工具类 App。


二、核心原理

2.1 编译模型

KMP 将 Kotlin 代码编译成各平台的原生产物,而不是通过虚拟机或解释器运行:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
                    ┌──────────────────┐
│ commonMain │
│ (共享 Kotlin) │
└────────┬─────────┘

┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ JVM / Android │ │ Kotlin/Native │ │ Kotlin/JS │
│ (.class/DEX) │ │ (LLVM → .a) │ │ (JS/Wasm) │
└────────────────┘ └────────────────┘ └────────────────┘
│ │ │
▼ ▼ ▼
Android APK iOS Framework Web Bundle
  • Android:Kotlin → JVM 字节码 → DEX → APK
  • iOS:Kotlin → Kotlin/Native(LLVM)→ 静态库/框架
  • Web:Kotlin → JavaScript 或 WebAssembly

因此,共享代码在运行时就是本地代码,无额外解释层。

2.2 expect / actual 机制

当共享代码需要调用平台特有 API 时(如文件系统、UUID、日期格式化),KMP 使用 expect / actual 做编译期抽象:

在 commonMain 中声明 expect(契约):

1
2
3
4
5
// commonMain/kotlin/platform/Platform.kt
package platform

expect fun currentTimeMillis(): Long
expect fun randomUUID(): String

在各平台提供 actual 实现:

1
2
3
4
5
6
7
// androidMain/kotlin/platform/Platform.android.kt
package platform

import java.util.UUID

actual fun currentTimeMillis(): Long = System.currentTimeMillis()
actual fun randomUUID(): String = UUID.randomUUID().toString()
1
2
3
4
5
6
7
8
// iosMain/kotlin/platform/Platform.ios.kt
package platform

import platform.Foundation.NSDate
import platform.Foundation.NSUUID

actual fun currentTimeMillis(): Long = (NSDate().timeIntervalSince1970 * 1000).toLong()
actual fun randomUUID(): String = NSUUID().UUIDString()

原理要点

  • 编译时,编译器将 expect 与对应平台的 actual 匹配
  • 每个目标平台都必须有且仅有一个 actual 实现
  • 保证 common 代码只能依赖抽象,无法引用平台专属 API

2.3 Source Sets(源集)与层级结构

KMP 用 Source Set 组织代码,每个源集对应一组目标平台:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌─────────────────────────────────────────────────────────────────┐
│ Source Sets 层级 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ commonMain ◄── 编译到所有目标,只可写平台无关代码 │
│ │ │
│ ├── androidMain ◄── 仅 Android │
│ │ │
│ ├── iosMain (中间源集) ◄── 所有 iOS 目标共享 │
│ │ ├── iosArm64Main (真机) │
│ │ └── iosSimulatorArm64Main (模拟器) │
│ │ │
│ └── appleMain (中间源集) ◄── iOS + macOS + watchOS + tvOS │
│ │
└─────────────────────────────────────────────────────────────────┘

依赖方向androidMaincommonMainiosMaincommonMaincommonMain 不能依赖平台源集

典型目录结构

1
2
3
4
5
6
7
8
9
10
11
12
shared/
├── src/
│ ├── commonMain/
│ │ └── kotlin/
│ │ ├── domain/
│ │ ├── data/
│ │ └── di/
│ ├── androidMain/
│ │ └── kotlin/
│ └── iosMain/
│ └── kotlin/
└── build.gradle.kts

三、源码与实现原理

3.1 expect / actual 的编译期处理

expect/actual 并非运行时多态,而是编译期替换

  1. 在 common 编译时,expect 仅作为「占位声明」参与类型检查
  2. 在平台编译时,编译器用对应平台的 actual 替换 expect
  3. 最终产物中只存在 actual 实现,无额外抽象开销

这保证了共享代码在目标平台上等价于「直接调用平台 API」。

3.2 中间源集(Hierarchical Source Sets)

当多个平台共享同一套「非 common」逻辑时,可引入中间源集,避免重复:

1
2
3
4
5
6
7
// 声明目标
kotlin {
android()
iosArm64()
iosSimulatorArm64()
macosArm64()
}

Kotlin 插件会自动生成:

  • appleMain:所有 Apple 平台共享(iOS + macOS + watchOS + tvOS)
  • iosMain:iOS 真机 + 模拟器共享

appleMain 中可以使用 Apple 专属 API(如 platform.Foundation.NSUUID),而无需在 iosArm64MainiosSimulatorArm64Main 里各写一遍。

3.3 依赖解析规则

1
2
3
4
5
6
7
8
9
10
11
12
13
commonMain 只能依赖:
- Kotlin 标准库(多平台版本)
- kotlinx-* 多平台库(coroutines, serialization, datetime 等)
- 其他 commonMain 或「包含当前目标」的中间源集

androidMain 可额外依赖:
- Android SDK
- Jetpack 库
- 纯 JVM 库

iosMain 可额外依赖:
- Kotlin/Native 平台库
- CocoaPods 依赖

四、实战示例

4.1 项目搭建

根 build.gradle.kts:

1
2
3
4
5
plugins {
kotlin("multiplatform") version "2.0.0" apply false
kotlin("plugin.serialization") version "2.0.0" apply false
id("com.android.application") version "8.2.0" apply false
}

shared/build.gradle.kts(共享模块):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
plugins {
kotlin("multiplatform")
kotlin("plugin.serialization")
}

kotlin {
androidTarget()
listOf(
iosX64(),
iosArm64(),
iosSimulatorArm64()
).forEach { iosTarget ->
iosTarget.binaries.framework {
baseName = "shared"
isStatic = true
}
}

sourceSets {
commonMain.dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3")
implementation("io.ktor:ktor-client-core:2.3.6")
implementation("io.ktor:ktor-client-content-negotiation:2.3.6")
implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.6")
}
androidMain.dependencies {
implementation("io.ktor:ktor-client-okhttp:2.3.6")
}
iosMain.dependencies {
implementation("io.ktor:ktor-client-darwin:2.3.6")
}
}
}

4.2 网络层:Ktor + kotlinx.serialization

commonMain - 数据模型与 API:

1
2
3
4
5
6
7
8
9
10
11
12
// commonMain/kotlin/data/model/User.kt
import kotlinx.serialization.Serializable

@Serializable
data class User(
val id: Long,
val name: String,
val email: String
)

@Serializable
data class ApiResponse<T>(val data: T)
1
2
3
4
5
6
7
8
9
10
11
12
13
// commonMain/kotlin/data/remote/UserApi.kt
import io.ktor.client.*
import io.ktor.client.call.*
import io.ktor.client.request.*
import io.ktor.http.*

class UserApi(private val client: HttpClient) {
suspend fun getUser(id: Long): User {
return client.get("https://api.example.com/users/$id") {
contentType(ContentType.Application.Json)
}.body()
}
}

commonMain - Ktor 客户端工厂:

1
2
3
4
5
6
7
8
9
10
11
12
// commonMain/kotlin/di/NetworkModule.kt
import io.ktor.client.*
import io.ktor.client.plugins.contentnegotiation.*
import io.ktor.serialization.kotlinx.json.*
import kotlinx.serialization.json.Json

expect fun createHttpClient(): HttpClient

fun createJson(): Json = Json {
ignoreUnknownKeys = true
isLenient = true
}

androidMain - OkHttp 引擎:

1
2
3
4
5
6
7
8
9
10
// androidMain/kotlin/di/NetworkModule.android.kt
import io.ktor.client.*
import io.ktor.client.engine.okhttp.*
import io.ktor.client.plugins.contentnegotiation.*

actual fun createHttpClient(): HttpClient = HttpClient(OkHttp) {
install(ContentNegotiation) {
json(createJson())
}
}

iosMain - Darwin 引擎:

1
2
3
4
5
6
7
8
9
10
// iosMain/kotlin/di/NetworkModule.ios.kt
import io.ktor.client.*
import io.ktor.client.engine.darwin.*
import io.ktor.client.plugins.contentnegotiation.*

actual fun createHttpClient(): HttpClient = HttpClient(Darwin) {
install(ContentNegotiation) {
json(createJson())
}
}

4.3 ViewModel 共享

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// commonMain/kotlin/presentation/UserViewModel.kt
import kotlinx.coroutines.flow.*
import kotlinx.coroutines.*

class UserViewModel(
private val userApi: UserApi,
private val scope: CoroutineScope
) {
private val _user = MutableStateFlow<User?>(null)
val user: StateFlow<User?> = _user.asStateFlow()

fun loadUser(id: Long) {
scope.launch {
_user.value = userApi.getUser(id)
}
}
}
  • Android:注入 viewModelScope,通过 viewModel() 获取
  • iOS:注入 MainScope()ViewModelScope,通过 KMP 的 StateFlow 订阅

两端共享同一套 ViewModel 逻辑,仅 CoroutineScope 由各平台注入。

4.4 expect/actual 实用示例:日期格式化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// commonMain
expect fun formatDate(timestamp: Long): String

// androidMain
actual fun formatDate(timestamp: Long): String {
val sdf = SimpleDateFormat("yyyy-MM-dd", Locale.getDefault())
return sdf.format(Date(timestamp))
}

// iosMain
actual fun formatDate(timestamp: Long): String {
val formatter = NSDateFormatter().apply {
dateFormat = "yyyy-MM-dd"
}
return formatter.stringFromDate(NSDate(timestamp = timestamp / 1000.0))
}

五、实际项目应用案例

5.1 Cash App(Block 旗下金融应用)

项目规模 50+ 移动工程师,约 3000 万月活
策略 业务共享、UI 原生
时间线 自 2018 年起试验 KMP,逐步通过 Feature Flag 落地
效果 移除有问题的 JavaScript 共享代码;双端维护单一业务逻辑库;服务器团队(Kotlin)可直接参与共享库开发
使用库 SQLDelight、Wire、CrashKiOS

启示:大型金融场景下,KMP 在「持久化」和「纯函数业务逻辑」上收益最大,且便于服务端参与共享代码。

5.2 Netflix

  • 在移动工作室 App 中共享逻辑,减少重复开发
  • 在影视制作的高节奏迭代下,提升交付效率与稳定性

5.3 McDonald’s

  • 共享应用内支付等复杂业务逻辑
  • 支撑每月 650 万+ 笔支付
  • 验证 KMP 在电商/支付场景的可行性

5.4 Forbes

  • 在 iOS 与 Android 间共享 80%+ 逻辑
  • 双端可同步上线新功能,缩短发布周期

5.5 其他采用者

  • Wrike、Bilibili、Feres 等使用 KMP + Compose Multiplatform
  • Vouched、Karma 等采用 KMP 共享核心业务

六、最佳实践与注意事项

6.1 共享范围建议

适合共享 不建议共享
数据模型、DTO 平台特有 UI 组件
网络请求、序列化 复杂平台动画、手势
Repository、UseCase、ViewModel 平台特定系统 API 封装
业务规则、校验逻辑 第三方 SDK 深度集成
本地存储(SQLDelight、DataStore) 推送、支付等强平台相关逻辑

6.2 常见陷阱

  1. 在 commonMain 中引用平台 API:编译器会报错,应使用 expect/actual 抽象
  2. expect/actual 签名不一致:必须保持完全一致(包名、函数名、参数、返回值)
  3. 并发与线程:Kotlin/Native 对线程模型有约束,需注意 @ThreadLocalfreeze
  4. 依赖版本:多平台库需保证各目标使用兼容版本

6.3 学习路线建议

  1. 搭建最小 KMP 工程,跑通 Android + iOS
  2. 用 expect/actual 封装 1~2 个平台 API
  3. 接入 Ktor + kotlinx.serialization 实现共享网络层
  4. 共享一个 ViewModel,在双端展示数据
  5. 按业务模块逐步迁移,避免一次性大改

七、小结

KMP 以 「共享逻辑、原生 UI」 为核心,通过 expect/actualSource Sets 实现跨平台抽象,在不牺牲原生体验的前提下显著降低双端重复开发。从 Cash App、Netflix、McDonald’s 等实践来看,KMP 已可用于生产环境,特别适合业务逻辑复杂、对一致性与性能要求较高的应用。结合 Jetpack Compose 与 SwiftUI,KMP 正成为 Android 开发者拓展 iOS 能力的重要路径。


参考资料

移动端与桌面端跨平台开发

由浅入深,从基本概念、原理与源码,到示例与实际项目应用,系统梳理移动端与桌面端跨平台技术体系


一、基本概念

1.1 什么是跨平台开发?

跨平台开发指用一套(或高度共享的)代码,同时支持多个操作系统或设备形态(如 iOS、Android、macOS、Windows、Linux、Web),从而降低开发与维护成本、加快迭代速度。

1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────────────────────────────────────────┐
│ 跨平台开发的核心目标 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 一套 / 共享代码 ──► 多端运行 ──► 降低人力、统一体验、快速发布 │
│ │
│ 移动端:iOS + Android(+ 鸿蒙 / 其他) │
│ 桌面端:macOS + Windows + Linux │
│ 大前端:Web + 移动 + 桌面(部分方案可三端复用) │
│ │
└─────────────────────────────────────────────────────────────────────────┘

1.2 移动端跨平台 vs 桌面端跨平台

维度 移动端跨平台 桌面端跨平台
目标平台 iOS、Android、鸿蒙等 Windows、macOS、Linux
交互特点 触屏、手势、传感器、多分辨率 键鼠、窗口、菜单、多显示器
分发方式 App Store、应用市场、企业内部分发 安装包、商店、便携版、包管理器
性能关注 电量、内存、启动速度、流畅度 内存、CPU、GPU、安装体积
典型方案 Flutter、React Native、Kotlin Multiplatform Electron、Tauri、Flutter Desktop、Qt

1.3 为什么需要跨平台?

痛点 说明 跨平台带来的价值
多套原生实现 iOS (Swift/ObjC)、Android (Kotlin/Java) 各写一套 一套业务逻辑 + UI,多端复用
人力与节奏 双端/三端并行,需求同步、发版协调成本高 统一技术栈,一次开发多端发布
体验一致性 各端实现细节不同,交互与视觉易分裂 可控的 UI 与交互一致性(尤其自绘方案)
桌面端同样分裂 Win/Mac/Linux 三套原生或 Web 各搞一套 一套代码覆盖主流桌面系统

二、跨平台的核心原理

2.1 三种主流渲染思路

跨平台方案按「谁来画 UI」可分为三类:

1
2
3
4
5
6
7
8
9
10
11
12
┌────────────────────────────────────────────────────────────────────────────┐
│ 方式 │ 谁负责渲染? │ 代表技术 │
├────────────────────────────────────────────────────────────────────────────┤
│ 原生控件映射 │ 使用系统原生控件 │ React Native、Xamarin、Compose │
│ (Native Mapping) │ 通过桥接更新属性 │ Multiplatform │
├────────────────────────────────────────────────────────────────────────────┤
│ Web 容器 │ 内嵌 WebView/浏览器 │ Cordova、Capacitor、Electron │
│ (WebView/Chromium)│ 用 HTML/CSS/JS 画 │ (Electron 用 Chromium 做桌面壳) │
├────────────────────────────────────────────────────────────────────────────┤
│ 自绘 (Skia/Impeller)│ 自己画像素/矢量 │ Flutter、Qt、.NET MAUI 部分 │
│ (Self-draw) │ 不依赖系统控件 │ │
└────────────────────────────────────────────────────────────────────────────┘
  • 原生控件映射:体验最接近系统原生,但受限于各端控件能力与差异,需要处理平台差异。
  • Web 容器:开发效率高、生态成熟,桌面端 Electron 安装体积与内存占用较大。
  • 自绘:UI 一致性强、不依赖系统控件,可精细控制渲染;需要自己实现可访问性、输入法等。

2.2 架构共性:桥接与运行时

无论哪种方式,跨平台层都要和「宿主平台」通信:

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────────────────┐
│ 跨平台层(业务 + UI 描述) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Dart / JavaScript / C# / Kotlin 等 │ │
│ │ 组件树 / 虚拟 DOM / 声明式 UI │ │
│ └────────────────────────────┬────────────────────────────────────┘ │
│ │ 桥接层 (Bridge / Channel / FFI) │
├───────────────────────────────┼─────────────────────────────────────────┤
│ 宿主 / 原生层 ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Native (Swift/Kotlin/C++/Rust) + 系统 API + 原生控件/自绘引擎 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
  • 移动端:通常通过 Bridge / Channel(如 React Native 的 Bridge、Flutter 的 Platform Channel)做异步通信。
  • 桌面端:Electron 是 主进程 + 渲染进程 的 IPC;Tauri 是 Web 前端 + Rust 核心 的 IPC/FFI,体积更小。

2.3 技术选型简表

方案 类型 移动端 桌面端 语言/技术 特点摘要
Flutter 自绘 ✅ iOS/Android/鸿蒙 ✅ Win/Mac/Linux Dart + Skia/Impeller 一致性强、性能好、桌面逐渐成熟
React Native 原生映射 ✅ iOS/Android ❌ 需另选桌面方案 JS/TS + 原生桥 生态大、热更新友好
Electron Web 容器 ✅ Win/Mac/Linux HTML/CSS/JS + Node + Chromium 桌面占主导、包体大
Tauri Web + 原生壳 实验性 ✅ Win/Mac/Linux 前端任意 + Rust 轻量、安全、系统集成好
Kotlin Multiplatform 原生映射/共享逻辑 ✅ 主打 可共享逻辑 Kotlin 逻辑共享、UI 仍多端各自实现
Capacitor / Cordova WebView 可做桌面壳 Web 技术 用 Web 开发,打包成 App

三、代表性框架原理与源码要点

3.1 Flutter:自绘引擎与 Dart 层

3.1.1 整体架构

Flutter 的 UI 不依赖系统控件,由 Skia(或 Impeller on iOS)在画布上自绘,因此各端视觉与行为高度一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
┌──────────────────────────────────────────────────────────────────┐
│ Dart 层 │
│ Widget 树 → Element 树 → RenderObject 树(布局与绘制) │
└────────────────────────────┬─────────────────────────────────────┘
│ Dart VM / AOT 编译
┌────────────────────────────▼─────────────────────────────────────┐
│ Flutter Engine (C++) │
│ Layer 树 → Scene → Skia/Impeller 绘制 → 显示 │
└────────────────────────────┬─────────────────────────────────────┘
│ 平台嵌入层 (Embedder)
┌────────────────────────────▼─────────────────────────────────────┐
│ Android (SurfaceView) / iOS (Metal) / Windows (ANGLE) / ... │
└──────────────────────────────────────────────────────────────────┘

3.1.2 关键源码位置(概念性)

  • Widget → Element → RenderObjectflutter/lib/src/widgets/framework.dartrendering/object.dart
    Element 持有 RenderObjectRenderObject 负责 layoutpaint,最终生成 Layer 提交给引擎。
  • 绘制入口RenderViewcompositeFrame()Layer 树提交给 Window.render(),引擎再交给 Skia/Impeller。
  • 平台通道PlatformChannelflutter/lib/src/services/platform_channel.dart,Dart 与原生通过 BinaryMessenger 收发序列化消息。

理解「Widget 不可变 → Element 挂载/更新 → RenderObject 布局绘制」这条链路,就抓住了 Flutter UI 的核心。

3.2 React Native:桥接与原生组件

3.2.1 新架构(Fabric + TurboModules)与旧桥

  • 旧架构:JS 与原生通过 Bridge 异步传 JSON,原生侧用 UIManager 把「虚拟节点」转成原生 View。
  • 新架构
    • Fabric:C++ 的渲染器,Shadow 树在 C++ 中,减少跨桥次数,支持同步布局与优先级。
    • TurboModules:按需加载的 JSI 原生模块,可同步调用,不再全部在启动时塞进 Bridge。
1
2
3
4
5
6
7
8
9
┌─────────────┐     JSI (JavaScript Interface)      ┌─────────────────┐
│ JavaScript │ ◄──── 同步/异步调用 ─────────────► │ C++ Fabric / │
│ React 组件 │ (新架构) │ TurboModules │
└─────────────┘ └────────┬────────┘

┌─────────────┐ Bridge (旧) / 序列化消息 ┌───────▼───────┐
│ Metro 打包 │ ◄──────────────────────────────► │ Native Views │
│ JS Bundle │ │ (Android/iOS)│
└─────────────┘ └───────────────┘

3.2.2 源码可读入口(概念性)

  • React 组件到原生:新架构下 ReactFabricFabricUIManager 等(C++),旧架构下 UIManagerModule(Java/ObjC)把「节点树」转成原生 View。
  • 通信NativeModulesNativeEventEmitter 对应到原生模块与事件发送,新架构下通过 JSI 直接调 C++ 再调原生。

3.3 Electron:多进程与 IPC

3.3.1 主进程 + 渲染进程

Electron 基于 Chromium,每个窗口是一个渲染进程,主进程负责生命周期、系统 API、原生菜单等。

1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────────────────────────────────────────┐
│ Main Process (Node.js) │
│ BrowserWindow、app、Menu、系统 API、原生模块 (.node) │
└────────────────────────────┬────────────────────────────────────────────┘
│ IPC (ipcMain / ipcRenderer)
│ contextBridge.exposeInMainWorld 安全暴露 API
└────────────────────────────┬────────────────────────────────────────────┘
┌────────────────────────────▼─────────────────────────────────────────────┐
│ Renderer Process (Chromium) │
│ HTML / CSS / JS,类似前端 SPA;可禁用 Node 仅用 preload 暴露能力 │
└─────────────────────────────────────────────────────────────────────────┘

3.3.2 安全与 contextBridge

  • 不要在渲染进程直接开 nodeIntegration: true 并把整个 Node 暴露给页面。
  • 推荐:用 contextBridge.exposeInMainWorld 在 preload 里暴露有限 API,主进程通过 ipcMain 处理,渲染进程只调这些 API。

源码层面:lib/renderer/api/context-bridge.tslib/main/api/ipc-main.ts 等,理解「preload 注入 → contextBridge → ipcRenderer.invoke」这条链路即可。

3.4 Tauri:Rust 核心 + 前端

3.4.1 轻量从何而来

Tauri 不内嵌完整 Chromium,而是用 系统 WebView(Windows: WebView2,macOS: WKWebView,Linux: WebKitGTK),所以安装包小、内存占用低。

1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────────────────────────────────────────┐
│ Frontend (任意: React / Vue / Svelte / 纯 HTML) │
│ 运行在系统 WebView 中 │
└────────────────────────────┬────────────────────────────────────────────┘
│ Tauri API (invoke / event)
┌────────────────────────────▼─────────────────────────────────────────────┐
│ Tauri Core (Rust) │
│ 窗口、菜单、系统托盘、文件与 shell、插件;可调用任意 Rust 与系统 API │
└─────────────────────────────────────────────────────────────────────────┘

3.4.2 命令与安全

  • 前端通过 invoke('command_name', { ... }) 调用 Rust 端在 #[tauri::command] 里定义的函数。
  • 权限与能力在 tauri.conf.jsoncapabilities 中声明,避免前端随意调敏感 API。
    源码可看 tauri/src/manager.rstauri/src/app.rs 以及命令派发与 IPC 的实现。

四、示例代码

4.1 Flutter:一个跨移动端 + 桌面的页面

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// 同一套代码可跑在 iOS、Android、Windows、macOS、Linux
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
const MyApp({super.key});

@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Cross-Platform Demo',
theme: ThemeData(primarySwatch: Colors.blue),
home: const HomePage(),
);
}
}

class HomePage extends StatefulWidget {
const HomePage({super.key});

@override
State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
int _counter = 0;

@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(title: const Text('Flutter 跨平台')),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Text('点击次数: $_counter', style: Theme.of(context).textTheme.headlineMedium),
const SizedBox(height: 24),
FilledButton.icon(
onPressed: () => setState(() => _counter++),
icon: const Icon(Icons.add),
label: const Text('增加'),
),
],
),
),
);
}
}
  • 移动端:flutter run 选 iOS/Android 设备即可。
  • 桌面端:flutter run -d windows / macos / linux(需先 flutter config --enable-*desktop)。

4.2 React Native:一个带原生能力的组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// 跨 iOS + Android,调用原生模块示例
import { NativeModules, Platform, StyleSheet, Text, View, Button } from 'react-native';

const { MyNativeModule } = NativeModules; // 需在原生侧实现 MyNativeModule

export default function App() {
const [result, setResult] = React.useState('');

const callNative = async () => {
try {
const value = await MyNativeModule?.getDeviceId?.() ?? '未实现';
setResult(value);
} catch (e) {
setResult(String(e));
}
};

return (
<View style={styles.container}>
<Text style={styles.text}>平台: {Platform.OS}</Text>
<Button title="调用原生 getDeviceId" onPress={callNative} />
<Text style={styles.result}>{result}</Text>
</View>
);
}

const styles = StyleSheet.create({
container: { flex: 1, justifyContent: 'center', alignItems: 'center', padding: 20 },
text: { fontSize: 16, marginBottom: 12 },
result: { marginTop: 12, color: '#333' },
});

4.3 Electron:主进程与渲染进程通信

1
2
3
4
5
6
7
// preload.js(运行在隔离上下文中,通过 contextBridge 暴露)
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electronAPI', {
getAppVersion: () => ipcRenderer.invoke('get-app-version'),
openFolder: (path) => ipcRenderer.invoke('dialog:openFolder', path),
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// main.js(主进程)
const { app, BrowserWindow, ipcMain, dialog } = require('electron');
const path = require('path');

function createWindow() {
const win = new BrowserWindow({
width: 800,
height: 600,
webPreferences: {
preload: path.join(__dirname, 'preload.js'),
nodeIntegration: false,
contextIsolation: true,
},
});
win.loadFile('index.html');
}

app.whenReady().then(() => {
ipcMain.handle('get-app-version', () => app.getVersion());
ipcMain.handle('dialog:openFolder', (_, dir) =>
dialog.showOpenDialog({ properties: ['openDirectory'] })
);
createWindow();
});
1
2
3
4
5
6
7
8
9
<!-- 渲染进程 (index.html 里的脚本) -->
<button id="version">获取版本</button>
<div id="out"></div>
<script>
document.getElementById('version').onclick = async () => {
const v = await window.electronAPI.getAppVersion();
document.getElementById('out').textContent = 'Version: ' + v;
};
</script>

4.4 Tauri:前端调用 Rust 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// src-tauri/src/main.rs
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

#[tauri::command]
fn greet(name: &str) -> String {
format!("Hello, {}! (from Rust)", name)
}

fn main() {
tauri::Builder::default()
.invoke_handler(tauri::generate_handler![greet])
.run(tauri::generate_context!())
.expect("error while running tauri application");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 前端 (如 React)
import { invoke } from '@tauri-apps/api/core';

function App() {
const [msg, setMsg] = useState('');

const sayHello = async () => {
const result = await invoke('greet', { name: 'Tauri' });
setMsg(result);
};

return (
<div>
<button onClick={sayHello}>Say Hello</button>
<p>{msg}</p>
</div>
);
}

五、实际项目中的应用案例

5.1 移动端跨平台

产品/项目 方案 说明
阿里巴巴闲鱼 Flutter 部分核心页面用 Flutter,与原生混编,统一商品与互动体验。
腾讯微信 多端自研 + 部分 RN 核心为原生,部分业务用自研或 RN 类方案做动态化与跨端。
字节抖音 / 飞书 Flutter / 自研 部分模块 Flutter,桌面端 Electron(如飞书)。
美团 React Native 部分 App 内页用 RN,热更新与双端复用。
Reflectly Flutter 日记/习惯类 App,全 Flutter,iOS/Android 一套 UI。
BMW 车载 Flutter 车载中控 UI 使用 Flutter 做多车型统一界面。

5.2 桌面端跨平台

产品/项目 方案 说明
VS Code Electron 编辑器 UI + 扩展用 Web 技术,主进程 Node,跨 Win/Mac/Linux。
Slack / Discord Electron 桌面客户端统一用 Web 栈,一套代码多端。
Figma Desktop Electron 设计工具桌面版,与 Web 共享核心逻辑与渲染。
1Password 8 Electron 密码管理桌面端,跨平台一致体验。
Clash Verge / 部分工具 Tauri 需要小体积、低内存的桌面工具,用 Tauri 替代 Electron。
Appflowy Flutter 桌面端用 Flutter,与移动端共享部分 UI 与逻辑。

5.3 移动 + 桌面 统一

产品/项目 移动端 桌面端 说明
Flutter 官方 Flutter (iOS/Android) Flutter (Win/Mac/Linux) 同一套 Dart 代码,多端运行,适合重 UI 一致性的产品。
飞书 原生 + 混合 Electron 移动端以原生为主,桌面端 Electron,部分逻辑与 UI 复用。
Notion 原生 / WebView Electron 桌面 Electron,移动端混合,内容与逻辑复用。

5.4 选型时可参考的维度

  • 团队技能:前端强可选 RN/Electron/Tauri;能接受 Dart 可选 Flutter 全平台。
  • 体验要求:要极致接近系统原生 → 原生映射(RN)或原生开发;要强一致性、可控渲染 → Flutter/自绘。
  • 桌面包体与内存:对体积和内存敏感 → Tauri 或 Flutter Desktop;优先生态与成熟度 → Electron。
  • 热更新与合规:移动端需热更新且符合商店政策时,需评估各方案的热更与审核风险。
  • 已有资产:已有 Web 或 React 技术栈,可优先 RN/Electron/Capacitor;已有 Rust/系统开发,可考虑 Tauri。

六、小结

  • 概念:跨平台开发用一套(或共享)代码覆盖多端,降低成本、统一体验;移动端与桌面端在平台特性、交互、分发上不同,但「桥接 + 运行时」的架构思想相通。
  • 原理:三种主要思路——原生控件映射、Web 容器、自绘;理解各方案的渲染模型与桥接方式,有助于选型和排坑。
  • 源码:Flutter 的 Widget/Element/RenderObject 与引擎、RN 的 Fabric/TurboModules、Electron 的 IPC 与 contextBridge、Tauri 的 Rust 命令与系统 WebView,是深入时的好入口。
  • 示例:同一套 Flutter 可跑移动+桌面;RN 通过 NativeModules 调原生;Electron 用 preload + contextBridge + ipcMain;Tauri 用 invoke 调 Rust 命令。
  • 实战:大量商业产品已在移动端(Flutter/RN)和桌面端(Electron/Tauri/Flutter)落地,选型时结合团队、体验、体积、热更新与既有技术栈综合权衡。

掌握「概念 → 原理 → 源码入口 → 示例 → 案例」这条线,就能在移动端与桌面端跨平台开发中建立清晰的技术图景,并做出更合适的架构与选型决策。

iOS 开发中的 React Native

由浅入深,从基本概念到源码解析,带你全面掌握 React Native 在 iOS 平台的开发与应用


一、什么是 React Native?为什么选择它?

1.1 从 Hybrid 到 React Native

移动开发经历了从纯原生(Native)到 Hybrid(WebView)再到跨平台框架的演进:

方案 代表 优势 劣势
原生 Swift/ObjC 性能最佳、体验最好 双端重复开发
Hybrid Cordova、WebView 一套 HTML/JS 性能差、体验割裂
跨平台 React Native、Flutter 一套代码、接近原生 学习曲线、生态依赖

React Native (RN) 由 Meta 于 2015 年开源,核心理念是:用 JavaScript 编写逻辑,用原生组件渲染 UI,而不是在 WebView 中渲染。

1
2
传统 Hybrid:    JS/HTML → WebView 渲染 → 间接调用原生 API
React Native: JS/React → 虚拟 DOM → 原生组件(UILabel、UIView 等)直接渲染

1.2 为什么 iOS 开发者要学 React Native?

  • 业务需要:公司采用 RN 做跨端,需要维护/扩展原生能力
  • 原生桥接:RN 依赖大量原生模块(相机、蓝牙、支付等),需要 iOS 侧配合开发
  • 性能优化:理解 RN 与原生通信机制,才能做性能调优和问题排查
  • 新架构:新架构大量使用 C++、JSI,与 iOS 底层结合更紧密

1.3 RN 与 Flutter 的简要对比

维度 React Native Flutter
语言 JavaScript/TypeScript Dart
渲染 原生组件 自绘引擎(Skia)
包体积 相对较小 相对较大
生态 依赖 React、npm 独立生态
与原生交互 通过 Bridge/JSI 通过 Platform Channel

二、核心概念与架构

2.1 三层架构概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────────────────────────────────┐
│ JavaScript 层 │
│ React 组件、业务逻辑、状态管理、事件处理 │
└──────────────────────────┬──────────────────────────────┘
│ Bridge / JSI
┌──────────────────────────▼──────────────────────────────┐
│ C++ 层(新架构) │
│ JSI、Fabric 渲染、TurboModules 调度 │
└──────────────────────────┬──────────────────────────────┘
│ FFI / Objective-C++
┌──────────────────────────▼──────────────────────────────┐
│ Native 层(iOS) │
│ UIKit、系统 API、自定义原生模块 │
└─────────────────────────────────────────────────────────┘

2.2 关键概念

概念 说明
Bridge 旧架构中 JS 与 Native 的异步通信桥梁,数据需序列化
JSI JavaScript Interface,新架构中 JS 可直接持有 C++ 对象引用,同步调用
Fabric 新架构的渲染系统,将布局、绘制逻辑下沉到 C++
TurboModules 新架构的原生模块系统,懒加载、类型安全
Hermes 字节码引擎,替代 JavaScriptCore,提升启动与运行性能

2.3 旧架构 vs 新架构

维度 旧架构 新架构
通信 Bridge 异步、JSON 序列化 JSI 同步、直接引用
渲染 各平台各自实现 Fabric 统一 C++ 渲染管线
原生模块 Native Modules 启动时全量加载 TurboModules 按需懒加载
类型 无强类型约定 通过 Codegen 生成类型

三、环境搭建与项目创建

3.1 环境要求

  • Node.js:建议 LTS 版本(18+)
  • Xcode:最新稳定版
  • CocoaPodsgem install cocoapods
  • Watchman(可选):brew install watchman,用于文件监听

3.2 创建新项目

1
2
3
4
5
6
7
8
9
10
11
# 使用 React Native CLI
npx @react-native-community/cli init MyApp

# 进入 iOS 目录
cd MyApp/ios

# 安装 CocoaPods 依赖
pod install

# 返回根目录,启动 Metro
cd .. && npx react-native start

另开终端运行 iOS:

1
2
3
npx react-native run-ios
# 或指定模拟器
npx react-native run-ios --simulator="iPhone 15"

3.3 项目结构(iOS 侧)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
MyApp/
├── ios/
│ ├── MyApp/ # 原生 iOS 工程
│ │ ├── AppDelegate.mm # 入口,加载 RN 根视图
│ │ ├── Info.plist
│ │ └── ...
│ ├── Podfile # CocoaPods 配置
│ ├── Podfile.lock
│ └── MyApp.xcworkspace # 用此打开工程
├── android/
├── src/ # JS 源码
├── node_modules/
├── package.json
└── metro.config.js

3.4 AppDelegate 与 RN 加载

典型的 AppDelegate.mm 中加载 RN 的流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#import <React/RCTBundleURLProvider.h>
#import <React/RCTRootView.h>

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
NSURL *jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
moduleName:@"MyApp"
initialProperties:nil
launchOptions:launchOptions];

self.window.rootViewController = [[UIViewController alloc] init];
self.window.rootViewController.view = rootView;
[self.window makeKeyAndVisible];
return YES;
}

RCTRootView 负责加载 JS Bundle、创建 Bridge、挂载 React 组件树。


四、JS 与 Native 通信原理

4.1 旧架构:Bridge 模型

旧架构下,JS 与 Native 通过 异步 Bridge 通信:

1
2
3
4
5
6
7
JS 层发起调用

├─ 将参数序列化为 JSON

├─ 通过 Bridge 发送到 Native 队列

└─ Native 解析 JSON,执行对应模块方法,再序列化结果回传 JS

特点

  • 异步:所有跨端调用都是异步的
  • 序列化:参数和返回值需要 JSON 序列化,有性能开销
  • 全量加载:所有 Native Modules 在启动时注册

4.2 旧架构模块注册流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 1. 实现 RCTBridgeModule 协议
@interface MyNativeModule : NSObject <RCTBridgeModule>
@end

@implementation MyNativeModule

RCT_EXPORT_MODULE(); // 导出模块名,默认类名

RCT_EXPORT_METHOD(getDeviceId:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject) {
NSString *id = [[UIDevice currentDevice] identifierForVendor].UUIDString;
resolve(id);
}

@end

JS 端调用:

1
2
3
4
import { NativeModules } from 'react-native';
const { MyNativeModule } = NativeModules;

const id = await MyNativeModule.getDeviceId();

4.3 新架构:JSI 直接调用

JSI 允许 JavaScript 直接持有 C++ 对象的引用,无需经过 Bridge 序列化:

1
2
3
4
5
6
7
8
// C++ 侧:通过 JSI 暴露方法
jsi::Function getDeviceId = jsi::Function::createFromHostFunction(
runtime,
jsi::PropNameID::forAscii(runtime, "getDeviceId"),
0,
[](jsi::Runtime& rt, const jsi::Value&, const jsi::Value*, size_t) {
return jsi::String::createFromUtf8(rt, getNativeDeviceId());
});

JS 可直接同步调用,无需 Promise 包装。


五、新架构:JSI、Fabric、TurboModules

5.1 JSI(JavaScript Interface)

JSI 是 C++ 实现的薄封装层,让 JS 引擎(Hermes/JSC)能够:

  • 调用 C++ 函数
  • 读取/写入 C++ 对象属性
  • 在 C++ 中执行 JS 回调
1
2
3
4
5
6
7
8
9
// 简化示意:HostObject 暴露给 JS 的对象
class DeviceModule : public jsi::HostObject {
jsi::Value get(jsi::Runtime& rt, const jsi::PropNameID& name) override {
if (name.utf8(rt) == "getDeviceId") {
return jsi::Function::createFromHostFunction(...);
}
return jsi::Value::undefined();
}
};

5.2 Fabric 渲染管线

Fabric 将 React 的渲染逻辑从各平台分别实现,统一到 C++:

1
2
3
4
5
6
7
8
9
10
11
12
13
React 组件树


Shadow Tree(C++ 中的布局树)


布局计算(Yoga)


提交到原生层(Mount)


iOS UIView 创建/更新

优势:减少跨 Bridge 的序列化、支持同步布局、更好的并发与优先级调度。

5.3 TurboModules

TurboModules 的特性:

  • 懒加载:只在首次被 JS 引用时初始化
  • 类型安全:通过 Codegen 从 TypeScript 定义生成 C++ 和 ObjC 代码
  • 同步能力:通过 JSI 可实现同步调用

定义原生模块的规范(新架构):

1
2
3
4
5
6
7
8
9
10
// NativeMyModule.ts (Codegen 规范)
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
getDeviceId(): Promise<string>;
multiply(a: number, b: number): number;
}

export default TurboModuleRegistry.getEnforcing<Spec>('MyNativeModule');

六、原生模块开发(Native Modules)

6.1 旧架构:RCT_EXPORT_MODULE

完整示例:实现一个获取设备信息的原生模块。

Objective-C:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// DeviceInfoModule.h
#import <React/RCTBridgeModule.h>

@interface DeviceInfoModule : NSObject <RCTBridgeModule>
@end

// DeviceInfoModule.m
#import "DeviceInfoModule.h"
#import <React/RCTLog.h>
#import <UIKit/UIKit.h>

@implementation DeviceInfoModule

RCT_EXPORT_MODULE(DeviceInfo)

RCT_EXPORT_METHOD(getDeviceInfo:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject) {
dispatch_async(dispatch_get_main_queue(), ^{
NSDictionary *info = @{
@"model": [[UIDevice currentDevice] model],
@"systemVersion": [[UIDevice currentDevice] systemVersion],
@"name": [[UIDevice currentDevice] name],
};
resolve(info);
});
}

@end

JavaScript:

1
2
3
4
5
6
7
8
9
10
11
12
import { NativeModules } from 'react-native';

const { DeviceInfo } = NativeModules;

async function loadDeviceInfo() {
try {
const info = await DeviceInfo.getDeviceInfo();
console.log(info);
} catch (e) {
console.error(e);
}
}

6.2 新架构:TurboModule + Swift

新架构推荐用 Swift 实现业务逻辑,用 ObjC++ 做 JSI 胶水层。

Swift 实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// DeviceInfoModule.swift
import Foundation

@objc(DeviceInfoModule)
class DeviceInfoModule: NSObject {
@objc
static func requiresMainQueueSetup() -> Bool {
return false
}

@objc
func getDeviceInfo(_ resolve: @escaping RCTPromiseResolveBlock,
reject: @escaping RCTPromiseRejectBlock) {
let info: [String: Any] = [
"model": UIDevice.current.model,
"systemVersion": UIDevice.current.systemVersion
]
resolve(info)
}
}

通过 RCT_EXTERN_MODULE 导出给 ObjC:

1
2
3
4
5
6
7
8
9
// DeviceInfoModule.m(桥接)
#import <React/RCTBridgeModule.h>

@interface RCT_EXTERN_MODULE(DeviceInfoModule, NSObject)

RCT_EXTERN_METHOD(getDeviceInfo:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject)

@end

6.3 事件发送:从 Native 到 JS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 在原生模块中
#import <React/RCTEventEmitter.h>

@interface MyModule : RCTEventEmitter <RCTBridgeModule>
@end

@implementation MyModule

RCT_EXPORT_MODULE()

- (NSArray<NSString *> *)supportedEvents {
return @[@"onScanResult"];
}

- (void)sendScanResult:(NSString *)result {
[self sendEventWithName:@"onScanResult" body:@{@"result": result}];
}

@end
1
2
3
4
5
6
import { NativeEventEmitter, NativeModules } from 'react-native';

const emitter = new NativeEventEmitter(NativeModules.MyModule);
emitter.addListener('onScanResult', (event) => {
console.log(event.result);
});

七、原生 UI 组件(Native UI Components)

7.1 使用 ViewManager 封装 UIView

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// MyCustomViewManager.h
#import <React/RCTViewManager.h>

@interface MyCustomViewManager : RCTViewManager
@end

// MyCustomViewManager.m
#import "MyCustomViewManager.h"
#import "MyCustomView.h"

@implementation MyCustomViewManager

RCT_EXPORT_MODULE(MyCustomView)

- (UIView *)view {
return [[MyCustomView alloc] init];
}

RCT_EXPORT_VIEW_PROPERTY(title, NSString)
RCT_EXPORT_VIEW_PROPERTY(onPress, RCTBubblingEventBlock)

@end
1
2
3
4
5
// MyCustomView.h
@interface MyCustomView : UIView
@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) RCTBubblingEventBlock onPress;
@end

7.2 JS 侧使用

1
2
3
4
5
6
7
8
9
10
11
12
import { requireNativeComponent } from 'react-native';

const MyCustomView = requireNativeComponent('MyCustomView');

export default function Screen() {
return (
<MyCustomView
title="Hello"
onPress={(e) => console.log(e.nativeEvent)}
/>
);
}

7.3 新架构:Fabric 组件

新架构下,通过 Codegen 定义 Props 和事件,生成 C++ 与各平台代码,实现类型安全和更好的性能。


八、源码解析

8.1 初始化流程(iOS)

1
2
3
4
5
6
7
8
9
10
11
12
main()
└─ UIApplicationMain
└─ AppDelegate didFinishLaunchingWithOptions
└─ RCTRootView initWithBundleURL:moduleName:...
├─ 创建 RCTBridge
│ ├─ 加载 JavaScript Bundle
│ ├─ 初始化 JS 引擎(Hermes/JSC)
│ ├─ 注册所有 Native Modules
│ └─ 执行 JS 入口(AppRegistry.runApplication)

└─ 创建 RCTRootContentView
└─ 挂载 React 根组件,触发首次渲染

8.2 Bridge 核心结构(旧架构)

1
2
3
4
5
6
7
8
9
10
11
12
// 简化示意
@interface RCTBridge : NSObject
@property (nonatomic, strong) RCTBridge *batchedBridge; // 实际执行 Bridge
@end

// 模块调用流程
// JS: NativeModules.DeviceInfo.getDeviceInfo()
// -> __callFunction(moduleName, methodName, args)
// -> 序列化为 JSON,通过 RCTBridge 发送
// -> Native: RCTModuleData 根据 moduleName 找到模块实例
// -> 反序列化参数,invoke 对应方法
// -> 结果序列化回传 JS

8.3 新架构关键路径

  • JSIReactCommon/jsi/,提供 jsi::RuntimeHostObject
  • FabricReactCommon/react/renderer/,Shadow Tree、Mount、Component 定义
  • TurboModulesReactCommon/react/nativemodule/,模块注册与调用

可参考官方仓库:
https://github.com/facebook/react-native


九、实战示例

9.1 调用系统分享

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// ShareModule.m
RCT_EXPORT_METHOD(share:(NSDictionary *)options
resolve:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject) {
dispatch_async(dispatch_get_main_queue(), ^{
NSString *title = options[@"title"] ?: @"";
NSString *url = options[@"url"] ?: @"";

UIActivityViewController *activityVC = [[UIActivityViewController alloc]
initWithActivityItems:@[title, [NSURL URLWithString:url]]
applicationActivities:nil];

UIViewController *rootVC = [UIApplication sharedApplication]
.keyWindow.rootViewController;
[rootVC presentViewController:activityVC animated:YES completion:nil];
resolve(@YES);
});
}

9.2 封装原生 TabBar

在 RN 中嵌入 UITabBarController 的容器,通过 Native Module 控制 Tab 切换,实现与原生 TabBar 一致的外观和动效。

9.3 列表性能优化:FlashList

1
2
3
4
5
6
7
8
9
10
11
12
13
import { FlashList } from '@shopify/flash-list';

function ProductList({ data }) {
const renderItem = ({ item }) => <ProductCard item={item} />;

return (
<FlashList
data={data}
renderItem={renderItem}
estimatedItemSize={100}
/>
);
}

FlashList 使用按需渲染和复用,比 FlatList 更适合长列表场景。


十、实际项目中的应用案例

10.1 电商 App:商品详情混合栈

  • Native:顶部 Banner 轮播、视频播放、复杂动效
  • RN:评价列表、推荐列表、加购/下单逻辑

通过 RCTRootView 嵌入到 UIViewController 的指定区域,实现「上原生、下 RN」的混合页面。

10.2 金融 App:安全键盘

输入密码时使用 Native 自定义键盘(避免 RN 侧键盘被截屏/录屏),通过 Native Module 将输入结果回传 JS:

1
2
3
4
5
6
7
8
RCT_EXPORT_METHOD(showSecureKeyboard:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject) {
SecureKeyboardViewController *vc = [[SecureKeyboardViewController alloc]
initWithCompletion:^(NSString *pin) {
resolve(pin);
}];
[self presentVC:vc];
}

10.3 地图与 LBS

地图、路径规划、定位等使用 Native SDK,通过 Native UI Component 和 Native Module 暴露给 RN,兼顾性能与功能完整性。

10.4 OTA 热更新

将打包好的 JS Bundle 下发到本地,启动时优先加载本地 Bundle,实现不发版即可更新业务逻辑(需注意各应用市场的合规要求)。


十一、常见问题与最佳实践

11.1 主线程与 UI 更新

原生模块中涉及 UI 的操作必须回到主线程:

1
2
3
dispatch_async(dispatch_get_main_queue(), ^{
[self presentViewController:vc animated:YES completion:nil];
});

11.2 避免内存泄漏

  • 使用 RCTEventEmitter 时正确实现 invalidate
  • Block 中使用 weakSelf 避免循环引用
  • 大对象及时释放,避免长期持有

11.3 调试技巧

1
2
3
4
5
6
7
8
# 查看 Metro 日志
npx react-native start

# 真机调试
npx react-native run-ios --device

# 查看原生日志
# Xcode -> Debug -> Open System Log,或使用 Console.app

11.4 性能建议

  • 长列表使用 FlashList 或优化 FlatListgetItemLayout
  • 复杂动画考虑 react-native-reanimated
  • 新项目尽量启用新架构(Fabric + TurboModules)
  • 图片使用 FastImage 或自定义 Native 图片组件做缓存

11.5 启用新架构

ios/Podfile 中:

1
ENV['RCT_NEW_ARCH_ENABLED'] = '1'

执行 pod install 后重新编译。


十二、总结

场景 建议
新项目 启用新架构(Fabric + TurboModules + Hermes)
原生能力扩展 通过 Native Module 暴露,优先用 Swift + ObjC 桥接
复杂 UI 封装 Native UI Component,或使用成熟第三方组件
性能敏感 长列表用 FlashList,动画用 Reanimated
调试 Metro + Flipper + Xcode 结合使用

React Native 在 iOS 上的核心价值是:用 React 生态统一业务逻辑,用原生能力保证体验与性能。理解 Bridge/JSI、Fabric、TurboModules 的演进,有助于在混合栈项目中做出更合适的架构与实现选择。