Posted Updated Mobile / Cross-Platform / Android24 minutes read (About 3579 words)

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  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

依赖方向：androidMain → commonMain，iosMain → commonMain，commonMain 不能依赖平台源集。

典型目录结构：

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），而无需在 iosArm64Main、iosSimulatorArm64Main 里各写一遍。

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 对线程模型有约束，需注意 @ThreadLocal、freeze 等
  4. 依赖版本：多平台库需保证各目标使用兼容版本

6.3 学习路线建议

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

七、小结

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

参考资料

Posted Updated Mobile / Cross-Platform / Flutter / Electron / HarmonyOS31 minutes read (About 4709 words)

跨平台与原生交互：Flutter × Electron

由浅入深，从基本概念到源码解析，全面掌握 Flutter 与 Android/iOS/鸿蒙、Electron 与 Mac/Windows 的原生交互能力

一、为什么需要原生交互？

1.1 跨平台框架的局限

跨平台框架（Flutter、Electron、React Native 等）为开发效率带来巨大提升，但受限于自身运行时，无法直接访问所有原生能力：

场景 Flutter 移动端 Electron 桌面端
硬件访问 相机、蓝牙、NFC、传感器 串口、USB、显卡驱动
系统 API 推送、定位、生物识别 剪贴板、系统托盘、原生菜单
第三方 SDK 微信/支付宝支付、地图 企业认证、硬件加密狗
性能敏感 视频编解码、图像处理 大文件加解密、实时音视频
平台特性 iOS Live Activities、Android WorkManager macOS Touch Bar、Windows 通知中心

核心矛盾：跨平台代码运行在「沙箱」中，必须通过桥接层与原生世界通信。

1.2 两种典型架构对比

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────────────────────┐
│                    Flutter 移动端（Android / iOS / 鸿蒙）                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Dart (UI/逻辑)  ──► Platform Channel  ──►  Native (Kotlin/Swift/ArkTS)   │
│   MethodChannel      EventChannel          Android/iOS/HarmonyOS API      │
│   BasicMessageChannel                                                     │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────┐
│                    Electron 桌面端（Mac / Windows / Linux）                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Renderer (HTML/JS)  ──► IPC  ──►  Main Process  ──►  Native Addon       │
│                              contextBridge         Node-API / FFI         │
│                                                     .node / .dll / .dylib  │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

二、Flutter 与原生交互

2.1 基本概念

2.1.1 Platform Channel 架构

Flutter 的 Platform Channel 是 Dart 与原生代码之间的消息传递机制，底层基于 BinaryMessenger 进行异步二进制通信。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌──────────────────┐         channel name          ┌──────────────────┐
│                  │   ◄────────────────────────►   │                  │
│   Dart 端        │   ByteData (序列化消息)         │   Native 端      │
│   (Client)       │   Future/Stream 响应            │   (Host)         │
│                  │                                │                  │
│  MethodChannel   │                                │  MethodChannel   │
│  EventChannel    │                                │  EventChannel    │
│  BasicMessageChannel                              │  BasicMessageChannel │
└──────────────────┘                                └──────────────────┘
         │                                                      │
         │  StandardMessageCodec (JSON-like 序列化)               │
         │  支持: null, bool, int, double, String                 │
         │       Uint8List, List, Map                            │
         ▼                                                      ▼
    Flutter Engine (C++)  ────────────────────  Platform Embedder

2.1.2 三种 Channel 类型辨析

Channel 类型 通信模式 典型场景 特点
MethodChannel 请求-响应（RPC） 获取电池电量、调用支付 SDK、打开相机 最常用，一对一调用，返回 Future
EventChannel 流式数据（Stream） 监听传感器、位置更新、蓝牙扫描 单向流，Native → Dart，支持 cancel
BasicMessageChannel 简单消息传递 低层级自定义协议 无方法语义，纯消息收发，较少直接使用

2.1.3 数据类型映射（Dart ↔ Native）

Dart Kotlin/Java Swift/ObjC ArkTS (鸿蒙)
null null nil null
bool Boolean Bool / NSNumber boolean
int (≤32位) Int Int32 number
int (>32位) Long Int64 number
double Double Double number
String String String string
Uint8List ByteArray FlutterStandardTypedData Uint8Array
List List Array Array
Map HashMap Dictionary Object

2.2 MethodChannel 实战：获取电池电量

2.2.1 Dart 端

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
import 'package:flutter/services.dart';

class _MyHomePageState extends State<MyHomePage> {
  static const platform = MethodChannel('samples.flutter.dev/battery');
  String _batteryLevel = 'Unknown';

  Future<void> _getBatteryLevel() async {
    try {
      final int level = await platform.invokeMethod<int>('getBatteryLevel');
      setState(() => _batteryLevel = 'Battery level: $level%');
    } on PlatformException catch (e) {
      setState(() => _batteryLevel = "Failed: '${e.message}'");
    }
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        ElevatedButton(onPressed: _getBatteryLevel, child: Text('Get Battery')),
        Text(_batteryLevel),
      ],
    );
  }
}

要点：

  • Channel 名必须与原生端完全一致
  • invokeMethod 返回 Future，支持泛型
  • 捕获 PlatformException 处理原生端 result.error()

2.2.2 Android (Kotlin)

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
// MainActivity.kt
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel

class MainActivity : FlutterActivity() {
    private val CHANNEL = "samples.flutter.dev/battery"

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            CHANNEL
        ).setMethodCallHandler { call, result ->
            when (call.method) {
                "getBatteryLevel" -> {
                    val level = getBatteryLevel()
                    if (level != -1) {
                        result.success(level)
                    } else {
                        result.error("UNAVAILABLE", "Battery level not available.", null)
                    }
                }
                else -> result.notImplemented()
            }
        }
    }

    private fun getBatteryLevel(): Int {
        val batteryManager = getSystemService(Context.BATTERY_SERVICE) as BatteryManager
        return batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY)
    }
}

2.2.3 iOS (Swift)

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
// AppDelegate.swift
import Flutter
import UIKit

@main
@objc class AppDelegate: FlutterAppDelegate {
    override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        let controller = window?.rootViewController as! FlutterViewController
        let channel = FlutterMethodChannel(
            name: "samples.flutter.dev/battery",
            binaryMessenger: controller.binaryMessenger
        )
        channel.setMethodCallHandler { [weak self] (call, result) in
            guard call.method == "getBatteryLevel" else {
                result(FlutterMethodNotImplemented)
                return
            }
            self?.receiveBatteryLevel(result: result)
        }
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }

    private func receiveBatteryLevel(result: FlutterResult) {
        let device = UIDevice.current
        device.isBatteryMonitoringEnabled = true
        if device.batteryState == .unknown {
            result(FlutterError(code: "UNAVAILABLE", message: "Battery level not available.", details: nil))
        } else {
            result(Int(device.batteryLevel * 100))
        }
    }
}

2.2.4 鸿蒙 (ArkTS)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// EntryAbility.ets
import type { FlutterPlugin } from '@ohos/flutter';

export default class EntryAbility extends UIAbility {
  onWindowStageCreate(windowStage: window.WindowStage) {
    const flutterEngine = getFlutterEngine();
    const messenger = flutterEngine.getBinaryMessenger();
    
    const channel = new MethodChannel(messenger, 'samples.flutter.dev/battery');
    channel.setMethodCallHandler(async (call) => {
      if (call.method === 'getBatteryLevel') {
        const level = await this.getBatteryLevel();
        return level;
      }
      throw new Error('NotImplemented');
    });
  }

  private async getBatteryLevel(): Promise<number> {
    const batteryInfo = await battery.getBatteryInfo();
    return batteryInfo.batterySoc; // 0-100
  }
}

2.3 EventChannel 实战：监听位置更新

适用于持续从 Native 向 Dart 推送数据的场景。

2.3.1 Dart 端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import 'dart:async';
import 'package:flutter/services.dart';

class LocationService {
  static const _channel = EventChannel('samples.flutter.dev/location');

  Stream<Location> get locationStream => _channel
      .receiveBroadcastStream()
      .map((dynamic event) => Location.fromMap(Map<String, dynamic>.from(event as Map)));
}

// 使用
StreamSubscription? _subscription;

void _startListening() {
  _subscription = LocationService().locationStream.listen(
    (loc) => print('Lat: ${loc.lat}, Lng: ${loc.lng}'),
    onError: (e) => print('Error: $e'),
  );
}

void _stopListening() {
  _subscription?.cancel();
}

2.3.2 Android (Kotlin) - EventChannel.StreamHandler

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
class LocationStreamHandler : EventChannel.StreamHandler {
    private var eventSink: EventChannel.EventSink? = null
    private var locationCallback: LocationCallback? = null

    override fun onListen(arguments: Any?, events: EventChannel.EventSink?) {
        eventSink = events
        locationCallback = object : LocationCallback() {
            override fun onLocationResult(result: LocationResult) {
                for (loc in result.locations) {
                    eventSink?.success(mapOf(
                        "lat" to loc.latitude,
                        "lng" to loc.longitude
                    ))
                }
            }
        }
        fusedLocationClient.requestLocationUpdates(request, locationCallback!!, Looper.getMainLooper())
    }

    override fun onCancel(arguments: Any?) {
        locationCallback?.let { fusedLocationClient.removeLocationUpdates(it) }
        eventSink = null
    }
}

// 注册
EventChannel(flutterEngine.dartExecutor.binaryMessenger, "samples.flutter.dev/location")
    .setStreamHandler(LocationStreamHandler())

2.4 底层原理：BinaryMessenger

所有 Channel 的底层都依赖 BinaryMessenger：

1
2
3
4
5
6
7
8
9
Dart 侧 (binary_messenger.dart)
├── send(channel, message) → Future<ByteData?>
├── setMessageHandler(channel, handler)
└── 消息以 ByteData 形式序列化传输

Native 侧 (Android: DartExecutor, iOS: FlutterBinaryMessenger)
├── 实现 BinaryMessenger 接口
├── 通过 Flutter Engine 与 Dart 隔离
└── 线程：Android 主线程，iOS 主线程

关键点：

  • 消息是异步的，保证 UI 不阻塞
  • 序列化由 StandardMessageCodec 完成（或自定义 MessageCodec）
  • Channel 名称是路由键，用于区分不同功能

2.5 Pigeon：类型安全的 Platform Channel

手动维护 MethodChannel 容易出错（字符串拼写、类型不匹配）。Pigeon 是 Flutter 官方代码生成工具，从接口定义自动生成各端代码。

2.5.1 定义接口 (pigeon/api.dart)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import 'package:pigeon/pigeon.dart';

@HostApi()
abstract class BatteryApi {
  int getBatteryLevel();
}

@HostApi()
abstract class LocationApi {
  void startLocationUpdates();
  void stopLocationUpdates();
}

@FlutterApi()
abstract class LocationCallback {
  void onLocation(double lat, double lng);
}

2.5.2 生成代码

1
2
3
# pubspec.yaml
dev_dependencies:
  pigeon: ^26.0.0
1
flutter pub run pigeon --input pigeon/api.dart

会生成：

  • dart/*.dart：Dart 端接口实现
  • kotlin/*.kt：Android Kotlin 实现骨架
  • swift/*.swift：iOS Swift 实现骨架

2.5.3 优势

对比 手动 MethodChannel Pigeon
类型安全 运行时检查 编译期保证
维护成本 三端同步改 改接口定义即可
代码量 重复样板 自动生成

2.6 实际项目应用案例

案例 1：支付 SDK 接入

1
2
3
4
5
6
7
业务需求：Flutter 调起微信/支付宝支付，并接收支付结果回调

实现要点：
1. MethodChannel 调用 Native 调起支付
2. 支付结果通过 EventChannel 或 MethodChannel.invokeMethod 反向回调
3. Android: Activity Result API，iOS: URL Scheme / Universal Links
4. 注意：支付必须在主线程/主 Activity 完成

案例 2：相机自定义预览 + 拍照

1
2
3
4
5
6
7
业务需求：自定义相机 UI，支持滤镜、闪光灯、变焦

实现要点：
1. 使用 Platform View (AndroidView / UiKitView) 嵌入原生相机 View
2. MethodChannel 控制：开始预览、拍照、切换滤镜
3. EventChannel 或 Texture 传递预览帧（如需实时处理）
4. 注意线程：相机回调可能在子线程，需 Post 到主线程再通过 Channel 回传

案例 3：蓝牙设备扫描与连接

1
2
3
4
5
6
7
业务需求：扫描 BLE 设备，连接并读写特征值

实现要点：
1. EventChannel 持续推送扫描到的设备列表
2. MethodChannel 执行：连接、断开、读/写特征值
3. 连接状态、数据回调通过 EventChannel 流式回传
4. 鸿蒙侧使用 @ohos.bluetooth 相关 API，需申请权限

三、Electron 与原生交互

3.1 基本概念

3.1.1 Electron 架构回顾

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────────────┐
│                        Renderer Process (多个)                        │
│   HTML + CSS + JavaScript (前端界面)                                  │
│   受沙箱限制，无法直接访问 Node.js / 原生模块                          │
└───────────────────────────────────┬─────────────────────────────────┘
                                    │ IPC (ipcRenderer / contextBridge)
┌───────────────────────────────────▼─────────────────────────────────┐
│                        Main Process (单个)                            │
│   Node.js 运行时，可 require('fs')、require('原生模块')                │
│   可加载 .node (Native Addon)、调用 FFI                               │
└───────────────────────────────────┬─────────────────────────────────┘
                                    │ Node-API / N-API
┌───────────────────────────────────▼─────────────────────────────────┐
│                        Native Addon / 系统 API                        │
│   C/C++ 编写，编译为 .node (Unix) / .dll (Windows)                     │
│   或通过 FFI 调用已有 .dll / .dylib / .so                             │
└─────────────────────────────────────────────────────────────────────┘

核心原则：所有原生调用必须在 Main Process 完成，Renderer 通过 IPC 与 Main 通信。

3.1.2 两种原生交互方式

方式 适用场景 技术栈
Native Addon 自己用 C++ 写模块，编译成 .node Node-API / N-API、node-gyp、node-addon-api
FFI 调用已有的 C 库（.dll/.dylib/.so） node-ffi-napi、koffi

3.2 Native Addon 开发（Node-API）

3.2.1 环境准备

macOS：

1
xcode-select --install  # 安装 Xcode Command Line Tools

Windows：

  • 安装 Node.js 时勾选 “Tools for Native Modules”
  • 或通过 npm install -g windows-build-tools 安装 VS Build Tools

依赖：

1
2
npm install node-addon-api bindings
npm install -g node-gyp

3.2.2 项目结构

1
2
3
4
5
6
native-addon/
├── binding.gyp          # 构建配置
├── src/
│   └── addon.cc         # C++ 源码
├── package.json
└── index.js             # 对外导出

3.2.3 binding.gyp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "targets": [{
    "target_name": "my_addon",
    "sources": [ "src/addon.cc" ],
    "include_dirs": [
      "<!@(node -p \"require('node-addon-api').include\")"
    ],
    "dependencies": [
      "<!(node -p \"require('node-addon-api').gyp\")"
    ],
    "cflags!": [ "-fno-exceptions" ],
    "cflags_cc!": [ "-fno-exceptions" ],
    "defines": [ "NAPI_DISABLE_CPP_EXCEPTIONS" ],
    "conditions": [
      ["OS=='win'", { "msvs_settings": { "VCCLCompilerTool": { "ExceptionHandling": 1 } } }]
    ]
  }]
}

3.2.4 C++ 源码 (src/addon.cc)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <napi.h>

Napi::Value Add(const Napi::CallbackInfo& info) {
  Napi::Env env = info.Env();
  if (info.Length() < 2 || !info[0].IsNumber() || !info[1].IsNumber()) {
    Napi::TypeError::New(env, "Number expected").ThrowAsJavaScriptException();
    return env.Null();
  }
  double a = info[0].As<Napi::Number>().DoubleValue();
  double b = info[1].As<Napi::Number>().DoubleValue();
  return Napi::Number::New(env, a + b);
}

Napi::Object Init(Napi::Env env, Napi::Object exports) {
  exports.Set("add", Napi::Function::New(env, Add));
  return exports;
}

NODE_API_MODULE(my_addon, Init)

3.2.5 调用方 (index.js)

1
2
const addon = require('bindings')('my_addon');
console.log(addon.add(1.5, 2.3));  // 3.8

3.2.6 在 Electron 中使用

关键：Electron 的 Node.js 版本与官方 Node 不同，需要重新编译 Native Addon：

1
2
npm install @electron/rebuild --save-dev
npx electron-rebuild

或在 package.json 中配置：

1
2
3
4
5
{
  "scripts": {
    "rebuild": "electron-rebuild"
  }
}

Main Process 中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// main.js
const { app, BrowserWindow, ipcMain } = require('electron');
const addon = require('bindings')('my_addon');

let win;

function createWindow() {
  win = new BrowserWindow({
    webPreferences: { nodeIntegration: false, contextIsolation: true }
  });
  win.loadFile('index.html');
}

ipcMain.handle('add-numbers', (event, a, b) => {
  return addon.add(a, b);
});

app.whenReady().then(createWindow);

Preload (preload.js)：

1
2
3
4
5
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('native', {
  add: (a, b) => ipcRenderer.invoke('add-numbers', a, b)
});

Renderer：

1
2
const result = await window.native.add(1.5, 2.3);
console.log(result);  // 3.8

3.3 FFI：调用已有 C 库

当需要调用已有的 .dll (Windows)、.dylib (macOS)、.so (Linux) 时，使用 FFI 无需重写 C++ 代码。

3.3.1 使用 koffi（推荐，支持 N-API）

1
npm install koffi
1
2
3
4
5
6
7
8
9
10
11
12
13
const koffi = require('koffi');

// 加载系统库
const libc = koffi.load('libc.so.6');  // Linux
// const libc = koffi.load('msvcrt.dll');  // Windows
// const libc = koffi.load('libc.dylib');  // macOS

const ceil = libc.func('double ceil(double)', 'ceil');
console.log(ceil(3.2));  // 4

// 加载自定义 DLL
const myLib = koffi.load('./my_lib.dll');
const myFunc = myLib.func('int my_func(const char* str, int len)', 'my_func');

3.3.2 使用 node-ffi-napi（注意 Electron 兼容性）

1
2
3
4
5
6
7
8
const ffi = require('ffi-napi');
const ref = require('ref-napi');

const msvcrt = ffi.Library('msvcrt', {
  'ceil': ['double', ['double']]
});

console.log(msvcrt.ceil(3.2));  // 4

注意：Electron 20.3.8+ 的沙箱可能限制指针操作，导致 ffi-napi 崩溃，可考虑：

  • 使用 koffi（基于 N-API，兼容性更好）
  • 或通过 Main Process 调用，避免在 Renderer 使用 FFI

3.4 实际项目应用案例

案例 1：调用 Windows 系统 API（获取 CPU 使用率）

1
2
3
4
5
6
7
需求：在 Electron 应用中显示实时 CPU 使用率

实现：
1. 使用 node-ffi-napi 或 koffi 加载 kernel32.dll / pdh.dll
2. 调用 GetSystemTimes、PdhCollectQueryData 等 API
3. Main Process 定时采样，通过 IPC 推送到 Renderer 展示
4. 跨平台：macOS 使用 sysctl，Linux 使用 /proc/stat

案例 2：硬件加密狗认证

1
2
3
4
5
6
7
需求：桌面端软件需插入 USB 加密狗才能使用

实现：
1. 厂商提供 .dll / .so SDK
2. 通过 FFI 加载 SDK，调用 CheckDongle()、GetLicense() 等
3. Main Process 启动时校验，失败则禁止启动
4. 注意：.dll 路径需随应用打包正确配置（如 resources/ 目录）

案例 3：大文件加解密（性能敏感）

1
2
3
4
5
6
7
需求：对 GB 级文件进行 AES 加解密，纯 JS 太慢

实现：
1. 用 C++ 编写加解密模块，基于 OpenSSL 或 crypto 库
2. 编译为 Native Addon，暴露 encryptFile(path)、decryptFile(path)
3. Main Process 调用，通过 Stream 或进度回调推送到 Renderer
4. 可考虑 Worker 线程 + 原生模块，避免阻塞主进程

四、对比与选型

4.1 Flutter vs Electron 原生交互对比

维度 Flutter (移动端) Electron (桌面端)
通信机制 Platform Channel（异步消息） IPC + Native Addon / FFI
数据格式 StandardMessageCodec（JSON-like） 任意（JS 对象 ↔ C 结构体需手动处理）
类型安全 可配合 Pigeon 生成 需自行保证
多端一致性 同一套 Channel 名，各端实现不同 同一套 Addon/FFI 调用，各平台编译不同
性能 消息序列化有开销，适合中低频调用 Native Addon 直接调用，适合高性能场景
调试 可通过日志追踪 Channel 消息 需 gdb/lldb 调试 C++

4.2 何时用 MethodChannel / EventChannel / FFI / Native Addon

需求 推荐方案
单次调用原生 API（如获取电池） Flutter MethodChannel / Electron IPC + Addon
持续接收原生数据流（如传感器） Flutter EventChannel
调用已有 C 库，不想重写 Electron FFI
高性能计算、自定义算法 Native Addon（C++）
需要类型安全、少写样板 Flutter Pigeon

五、最佳实践与注意事项

5.1 Flutter

  1. Channel 命名：使用反向域名，如 com.yourapp.service/battery，避免冲突
  2. 主线程：Android/iOS 的 Channel 回调一般在主线程，耗时操作应异步处理
  3. 错误处理：原生端务必调用 result.error() 或 result.notImplemented()，避免 Dart 侧 Future 一直挂起
  4. 内存泄漏：EventChannel 的 onCancel 必须移除监听器、释放资源
  5. 插件化：可复用逻辑封装为 Flutter Plugin，发布到 pub.dev

5.2 Electron

  1. 安全：禁用 Renderer 的 nodeIntegration，仅通过 contextBridge 暴露必要 API
  2. 重建：每次升级 Electron 版本后执行 electron-rebuild
  3. 路径：Native Addon 的 .node 文件路径在打包后可能变化，使用 __dirname、app.getPath('userData') 等正确处理
  4. 崩溃：C++ 模块崩溃会导致整个进程退出，需做好 try-catch 和日志

5.3 鸿蒙特别说明

  • Flutter 对 OpenHarmony/HarmonyOS 的支持在快速演进，需关注官方文档和 flutter_harmony 等生态
  • ArkTS 与 Dart 的 MethodChannel 接口类似，但需使用鸿蒙提供的 FlutterPlugin、MethodChannel 等 API
  • 权限、包名、签名等需符合鸿蒙应用规范

六、总结

技术栈 核心机制 典型用途
Flutter + Android/iOS/鸿蒙 Platform Channel（MethodChannel / EventChannel） 移动端调用相机、支付、蓝牙等
Electron + Mac/Windows IPC + Native Addon / FFI 桌面端调用系统 API、硬件、高性能计算

掌握原生交互能力，是跨平台开发从「能写」到「写好」的关键一步。建议先跑通官方示例，再结合实际业务逐步封装和优化。

附录：参考资源

Posted Updated Mobile / Android31 minutes read (About 4680 words)

Android 模块化、组件化与插件化实践

从基础概念到实战应用，系统梳理 Android 架构演进之路

一、基础概念

1.1 为什么需要架构优化？

随着业务迭代，单体 App 会遇到诸多问题：

问题 表现 影响
代码耦合严重 模块间直接 import，循环依赖 难以维护、编译慢
编译效率低 改一行代码全量编译 开发效率下降
团队协作冲突 多人修改同一工程 Git 冲突频繁
无法独立开发 强依赖主工程 无法并行开发、独立测试
复用困难 业务逻辑与 UI 混在一起 跨项目复用成本高

1.2 三种架构模式辨析

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────┐
│                        架构演进路径                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   单体架构 ──► 模块化 ──► 组件化 ──► 插件化                        │
│      │           │          │           │                         │
│      │           │          │           │                         │
│      ▼           ▼          ▼           ▼                         │
│   按功能拆分   Gradle模块   路由解耦    运行时动态加载               │
│   包结构划分   build独立   ARouter等    热更新/按需下载              │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

模块化（Modularization）

  • 定义：按业务功能将代码拆分为独立的 Gradle 模块，每个模块有清晰的 build.gradle 和边界
  • 特点：物理隔离、可独立编译，通常仍在同一 Git 仓库内
  • 粒度：中等，如「用户模块」「订单模块」「支付模块」

组件化（Componentization）

  • 定义：在模块化基础上，通过路由/服务发现实现模块间完全解耦，可独立开发、独立运行
  • 特点：依赖倒置、接口隔离、可单模块调试（Application 切换）
  • 粒度：较细，如「登录组件」「分享组件」「埋点组件」

插件化（Pluginization）

  • 定义：插件 APK/Dex 可动态加载、热更新，主 App 与插件解耦到运行时
  • 特点：运行时动态、按需下载、可热修复、减小包体积
  • 粒度：独立 APK/模块

二、模块化原理与实践

2.1 模块化的核心原则

  1. 单一职责：每个模块只负责一块业务
  2. 接口隔离：模块间通过接口/路由通信，不暴露实现细节
  3. 依赖倒置：依赖抽象（interface）而非具体实现

2.2 Gradle 多模块目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
MyApp/
├── app/                        # 主工程壳
│   └── build.gradle
├── module_user/                # 用户模块
│   ├── build.gradle
│   └── src/main/
├── module_order/               # 订单模块
│   └── build.gradle
├── module_payment/             # 支付模块
│   └── build.gradle
├── common_base/                # 公共基础库
│   ├── network/
│   ├── utils/
│   └── base/
├── common_router/              # 路由层
│   └── build.gradle
├── build.gradle
└── settings.gradle

2.3 settings.gradle 与模块声明

1
2
3
4
5
6
7
8
// settings.gradle
rootProject.name = "MyApp"
include ':app'
include ':module_user'
include ':module_order'
include ':module_payment'
include ':common_base'
include ':common_router'

2.4 模块间依赖配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// app/build.gradle - 主工程依赖各业务模块
dependencies {
    implementation project(':module_user')
    implementation project(':module_order')
    implementation project(':module_payment')
    implementation project(':common_router')
    implementation project(':common_base')
}

// module_user/build.gradle - 业务模块只依赖基础库和路由
dependencies {
    implementation project(':common_base')
    implementation project(':common_router')
    // 不要依赖 module_order、module_payment！
}

// common_base/build.gradle - 基础库不依赖任何业务模块
dependencies {
    implementation 'androidx.appcompat:appcompat:1.6.1'
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

2.5 模块间通信：接口 + 实现注入

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
// common_router 中定义接口
interface IUserService {
    fun getCurrentUser(): User?
    fun logout()
}

// module_user 中实现接口
class UserServiceImpl : IUserService {
    override fun getCurrentUser(): User? = UserManager.currentUser
    override fun logout() { /* ... */ }
}

// 通过 ServiceLocator 或依赖注入框架注入
object ServiceLocator {
    var userService: IUserService? = null
}

// module_order 中调用
class OrderActivity : AppCompatActivity() {
    private val userService: IUserService? by lazy { ServiceLocator.userService }

    fun showUserInfo() {
        userService?.getCurrentUser()?.let { user ->
            // 显示用户信息
        }
    }
}

三、组件化原理与实现

3.1 组件化架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
                ┌──────────────────┐
                │     app (壳)      │
                │   主工程/组装     │
                └────────┬─────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ module_user │ │ module_order│ │module_payment│
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
                ┌──────▼──────┐
                │   ARouter   │
                │ 路由中间层   │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ common_base │
                │ 基础组件库   │
                └─────────────┘

3.2 路由方案对比

方案 原理 优点 缺点
ARouter 注解 + 编译期生成路由表 阿里出品、生态成熟、支持拦截器 需引入注解处理器
WMRouter 美团方案，分组路由 按需加载、包体积优化 学习成本略高
CC (Component Call) 组件调用框架 同步/异步调用、跨进程 概念较多
手写路由表 Map 映射 简单、无依赖 维护成本高

3.3 单模块独立运行（Application 切换）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// module_user/build.gradle
android {
    defaultConfig {
        // 作为 Application 运行时使用
        if (project.hasProperty('runAsApp') && runAsApp) {
            applicationId "com.example.user"
        }
    }
    sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            if (project.hasProperty('runAsApp') && runAsApp) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            }
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
<!-- module_user/src/main/debug/AndroidManifest.xml - 独立运行时的 Manifest -->
<manifest>
    <application
        android:name=".UserDebugApplication"
        android:label="User Module Debug">
        <activity android:name=".UserActivity" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>
1
2
# 独立运行用户模块
./gradlew :module_user:installDebug -PrunAsApp=true

3.4 ARouter 使用与原理

3.4.1 添加依赖

1
2
3
4
5
// 各模块 build.gradle
dependencies {
    implementation 'com.alibaba:arouter-api:1.5.2'
    kapt 'com.alibaba:arouter-compiler:1.5.2'
}

3.4.2 路由配置与跳转

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ========== 组件端：Order 模块 ==========
// 在 OrderListActivity 上添加路由注解
@Route(path = "/order/list")
class OrderListActivity : AppCompatActivity() {
    @Autowired
    lateinit var userId: String

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ARouter.getInstance().inject(this)
        // userId 已自动注入
    }
}

// ========== 调用端：任意模块 ==========
ARouter.getInstance()
    .build("/order/list")
    .withString("userId", "12345")
    .navigation()

3.4.3 服务发现（跨模块获取实现）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 定义接口（可在 common_base 或单独 api 模块）
interface IOrderService {
    fun getOrderCount(userId: String): Int
}

// Order 模块实现并注册
@Route(path = "/service/order")
class OrderServiceImpl : IOrderService {
    override fun getOrderCount(userId: String): Int = /* ... */
}

// 调用端获取
val orderService = ARouter.getInstance()
    .navigation(IOrderService::class.java)
orderService?.getOrderCount("12345")

3.4.5 ARouter 核心源码解析

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
// 简化版 ARouter 核心逻辑
// 1. 初始化时扫描 Dex，加载路由表（通过 Gradle 插件编译期生成）
class Warehouse {
    // 路由表：path -> RouteMeta
    static Map<String, RouteMeta> routes = ConcurrentHashMap()
    // 分组缓存
    static Map<String, Class<? extends IRouteGroup>> groupsIndex = ConcurrentHashMap()
}

// 2. navigation 流程
fun navigation(path: String): Postcard {
    val meta = Warehouse.routes[path]  // 从路由表获取
    return Postcard(path, meta)
}

fun Postcard.navigation(): Any? {
    return _ARouter.navigation(context, this, requestCode, navigationCallback)
}

// 3. 实际跳转
fun _ARouter.navigation(...) {
    when (meta.type) {
        RouteType.ACTIVITY -> {
            val intent = Intent(context, meta.destination)
            // 注入参数
            context.startActivity(intent)
        }
        RouteType.ISERVICE -> {
            return meta.destination.newInstance()  // 服务实现类
        }
    }
}

// 4. 编译期注解处理器生成路由表
// 生成类似：ARouter$$Group$$order、ARouter$$Providers$$order
// 在 init() 时通过反射加载到 Warehouse

3.5 依赖关系设计原则

1
2
3
4
5
6
7
8
9
业务模块 (user/order/payment)
    │
    ├── 只依赖 common_base、common_router (arouter-api)
    │
    └── 业务模块之间 不直接依赖

app 壳工程
    │
    └── 依赖所有业务模块，负责组装和 Application 初始化

四、插件化原理与实现

4.1 插件化的应用场景

  • 热更新：修复线上 Bug 无需发版
  • 按需加载：减小包体积，冷启动只加载核心
  • 动态能力：运营活动插件、A/B 测试模块
  • 多端复用：同一套插件可被主 App、Split APK 加载

4.2 Android 插件化技术选型

方案 说明 适用场景
Dynamic Feature Modules Google 官方，AGP 支持 按需下载、免安装功能模块
VirtualAPK 滴滴开源 完整的插件化框架
RePlugin 360 出品 插件即独立 APK，稳定成熟
Shadow 腾讯开源 支持 Android 10+，零 Hook
Atlas 阿里 大型 App 动态化

4.3 Dynamic Feature Modules（官方方案）

4.3.1 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// settings.gradle
include ':app'
include ':feature:order'  // 动态功能模块

// app/build.gradle
dependencies {
    implementation project(':common_base')
    dynamicFeatures = [':feature:order']
}

// feature/order/build.gradle
apply plugin: 'com.android.dynamic-feature'
android {
    defaultConfig {
        minSdk 24
    }
}
dependencies {
    implementation project(':app')
}

4.3.2 按需下载与安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 使用 Play Core Library 下载动态模块
val splitInstallManager = SplitInstallManagerFactory.create(context)
val request = SplitInstallRequest.newBuilder()
    .addModule("order")
    .build()

splitInstallManager.startInstall(request)
    .addOnSuccessListener {
        // 安装成功，可跳转
        startActivity(Intent(this, OrderActivity::class.java))
    }
    .addOnFailureListener {
        // 处理失败
    }

4.4 RePlugin 核心原理简述

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──────────────────────────────────────────────────────┐
│                     Host App                          │
│  ┌────────────────────────────────────────────────┐  │
│  │  RePluginHostConfig / PluginManager             │  │
│  │  - 加载插件 APK                                  │  │
│  │  - 替换 ClassLoader                              │  │
│  │  - Hook Activity/Service 等组件                  │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
   ┌──────────┐   ┌──────────┐   ┌──────────┐
   │ Plugin1  │   │ Plugin2  │   │ Plugin3  │
   │  .apk    │   │  .apk    │   │  .apk    │
   └──────────┘   └──────────┘   └──────────┘

核心流程：

  1. Dex 加载：将插件 APK 的 classes.dex 加入宿主的 DexPathList
  2. 资源加载：创建 Resources，合并插件的 AssetManager
  3. 组件占位：通过 Hook Instrumentation/IActivityManager，用占位 Activity 代理插件 Activity

4.5 手写简易插件加载（Dex 加载）

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
// 简化示例：加载插件 APK 中的类
class PluginLoader(private val context: Context) {

    private val pluginClassLoaders = mutableMapOf<String, DexClassLoader>()

    fun loadPlugin(apkPath: String): Boolean {
        val optimizedDir = File(context.filesDir, "plugin_opt").apply { mkdirs() }
        val libDir = File(context.filesDir, "plugin_lib").apply { mkdirs() }

        val classLoader = DexClassLoader(
            apkPath,
            optimizedDir.absolutePath,
            null,
            context.classLoader
        )
        pluginClassLoaders[apkPath] = classLoader
        return true
    }

    fun loadClass(apkPath: String, className: String): Class<*>? {
        val loader = pluginClassLoaders[apkPath] ?: return null
        return try {
            loader.loadClass(className)
        } catch (e: ClassNotFoundException) {
            null
        }
    }
}

// 加载插件中的 Activity（实际还需 Hook 组件启动流程）
val loader = PluginLoader(context)
loader.loadPlugin("/sdcard/plugin.apk")
val clazz = loader.loadClass("/sdcard/plugin.apk", "com.plugin.MainActivity")
val activity = clazz.newInstance()

4.6 插件化资源加载

1
2
3
4
5
6
7
8
9
10
11
12
// 合并插件资源到宿主
fun createPluginResources(hostResources: Resources, apkPath: String): Resources {
    val assets = AssetManager::class.java.newInstance()
    val addAssetPath = AssetManager::class.java.getMethod("addAssetPath", String::class.java)
    addAssetPath.invoke(assets, apkPath)

    return Resources(
        assets,
        hostResources.displayMetrics,
        hostResources.configuration
    )
}

五、ARouter 框架源码深度解析

5.1 整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌────────────────────────────────────────────────────────┐
│                     ARouter                              │
│  - 对外 API：build、navigation、inject                    │
└────────────────────────────────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  _ARouter (内部实现)                     │
│  - LogisticsCenter：路由表、分组加载                      │
│  - Warehouse：路由/服务/拦截器 存储                       │
└────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 注解处理器    │  │ 拦截器链     │  │ 降级策略      │
│ 编译期生成   │  │ 可扩展       │  │ DegradeService│
└──────────────┘  └──────────────┘  └──────────────┘

5.2 LogisticsCenter 路由表加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 初始化时通过插件扫描 Dex 中的特定类
public static void init(Context context) {
    try {
        // 获取所有 ARouter 生成的类：ARouter$$Root$$xxx
        Set<String> routerMap = ClassUtils.getFileNameByPackageName(
            context, ROUTE_ROOT_PACKAGE);
        for (String className : routerMap) {
            if (className.startsWith(ROUTE_ROOT_PACKAGE + DOT + SDK_NAME + SEPARATOR + SUFFIX_ROOT)) {
                ((IRouteRoot) Class.forName(className).getConstructor().newInstance())
                    .loadInto(Warehouse.groupsIndex);
            }
        }
        // 分组按需加载，避免启动时加载全部
    } catch (Exception e) {
        throw new HandlerException("ARouter init logistics center exception");
    }
}

5.3 拦截器机制

1
2
3
4
5
6
7
8
9
10
11
12
@Interceptor(priority = 8)
class LoginInterceptor : IInterceptor {
    override fun process(postcard: Postcard, callback: InterceptorCallback) {
        if (postcard.extra == NEED_LOGIN && !UserManager.isLoggedIn()) {
            // 未登录，拦截并跳转登录
            ARouter.getInstance().build("/user/login").navigation()
            callback.onInterrupt(null)
        } else {
            callback.onContinue(postcard)
        }
    }
}

六、实际项目应用案例

6.1 某电商 App 组件化拆分

1
2
3
4
5
6
7
8
9
10
11
app (壳工程)
├── module_home          # 首页
├── module_product       # 商品详情
├── module_cart          # 购物车
├── module_order         # 订单
├── module_user          # 用户中心
├── module_payment       # 支付
├── module_share         # 分享（可复用）
├── module_analytics     # 埋点（可复用）
├── common_router        # ARouter 封装
└── common_base          # 网络/缓存/UI 基础库

收益：

  • 编译时间：全量 6min → 单模块 1min
  • 4 个业务线可并行开发，Git 冲突减少 60%
  • ShareModule、AnalyticsModule 复用到多个 App

6.2 路由表设计实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 统一路由 Path 常量
object RouterPath {
    const val ORDER_LIST = "/order/list"
    const val ORDER_DETAIL = "/order/detail"
    const val USER_LOGIN = "/user/login"
    const val USER_PROFILE = "/user/profile"
}

// 封装便捷方法
object Router {
    fun toOrderList(userId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_LIST)
            .withString("userId", userId)
            .navigation()
    }

    fun toOrderDetail(orderId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_DETAIL)
            .withString("orderId", orderId)
            .navigation()
    }
}

6.3 解耦实践：避免循环依赖

错误示例：

1
2
module_order -> module_user (获取用户信息)
module_user  -> module_order (跳转订单列表)

形成循环依赖，Gradle 编译失败。

正确做法：

1
2
module_order -> common_router
module_user  -> common_router

需要「用户信息」时，Order 通过 ARouter.getInstance().navigation(IUserService::class.java) 获取；需要「跳转订单」时，User 通过 ARouter.getInstance().build("/order/list").navigation() 跳转。

6.4 模块化 + 插件化组合：Dynamic Feature 实践

某资讯 App 将「小说」「漫画」等非核心功能做成 Dynamic Feature，用户首次进入时提示下载：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 检查模块是否已安装
fun isModuleInstalled(moduleName: String): Boolean {
    return SplitInstallManagerFactory.create(context)
        .installedModules.contains(moduleName)
}

// 进入小说模块前检查
fun openNovelModule() {
    if (isModuleInstalled("novel")) {
        startActivity(Intent(this, NovelActivity::class.java))
    } else {
        showDownloadDialog {
            installDynamicModule("novel")
        }
    }
}

七、最佳实践与注意事项

7.1 模块拆分原则

  • 高内聚低耦合：模块内聚度高，模块间依赖少
  • 按业务边界拆分：参考 DDD 的 Bounded Context
  • 基础组件下沉：网络、缓存、日志等抽成 common_base
  • 渐进式演进：先模块化再组件化，避免一步到位导致成本过高

7.2 常见坑与规避

问题 原因 规避
编译顺序错误 模块间隐式依赖 严格检查 build.gradle，用 ./gradlew :module_x:dependencies 检查
路由表膨胀 所有页面都注册路由 仅对外暴露的页面注册，内部页面用 startActivity
启动变慢 初始化时加载全部路由 使用分组按需加载（ARouter 已支持）
R 文件冲突 多模块资源 ID 冲突 在 build.gradle 中设置 resourcePrefix "module_user_"
插件化兼容性 不同厂商 ROM 限制 优先使用 Dynamic Feature，第三方框架需充分测试

7.3 R 文件与资源隔离

1
2
3
4
// 各业务模块 build.gradle 中
android {
    resourcePrefix "user_"   // 资源必须以 user_ 开头
}

7.4 架构演进路线图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Phase 1: 模块化
├── 拆分为 Gradle 多模块
├── 建立 common_base、common_router
└── 模块间通过接口通信

Phase 2: 组件化
├── 引入 ARouter 路由
├── 服务发现替代直接依赖
└── 支持单模块独立运行调试

Phase 3: 插件化（可选）
├── 非核心功能改为 Dynamic Feature
├── 或引入 RePlugin/Shadow 做完整插件化
└── 按需下载、热更新

八、总结

架构 适用场景 核心手段
模块化 中小型 App、团队 < 10 人 Gradle 多模块、接口、依赖配置
组件化 中大型 App、多业务线并行 ARouter、服务发现、单模块调试
插件化 需要动态化、热更新、包体积优化 Dynamic Feature、RePlugin、Shadow

架构没有银弹，需结合团队规模、业务复杂度、迭代节奏选择合适方案。建议从模块化起步，随着复杂度提升再逐步演进到组件化，插件化则按实际需求谨慎引入。

参考资源

Posted Updated Mobile / Android25 minutes read (About 3752 words)

Android 核心组件体系与设计思想

由浅入深，从四大组件、应用骨架到设计哲学与最佳实践，系统梳理 Android 核心组件体系与架构思想

一、基本概念

1.1 什么是 Android 核心组件？

Android 核心组件是系统提供的、用于构建应用的基本构建块。应用由多个组件组成，组件之间通过 Intent 和 Binder 等机制协作，由系统负责创建、调度和生命周期管理。

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────────────────┐
│                    Android 应用 = 组件的组合与协作                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   四大组件                                                                 │
│   Activity / Service / BroadcastReceiver / ContentProvider               │
│         │                                                                 │
│         ▼                                                                 │
│   Intent（意图）──► 组件间通信、启动、数据传递                              │
│   Context（上下文）──► 访问资源、启动组件、获取系统服务                      │
│   Application ──► 进程级单例，应用全局状态与初始化                          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

1.2 为什么是「组件化」？

Android 没有「一个 main 入口跑到底」的传统应用模型，而是采用 组件化 + 系统调度：

设计点 说明
可复用 任意应用可通过 Intent 启动其他应用的 Activity（如调起相机、地图），无需链接其代码
可替换 同一种组件类型可有多个实现（如多个浏览器），用户或系统可选择
生命周期由系统管 组件由系统创建与销毁，便于在内存紧张时回收、在配置变更时重建
安全与隔离 组件运行在应用进程内，通过权限与 Intent 过滤控制谁能调谁

二、四大核心组件

2.1 Activity：界面与用户交互

Activity 代表一个「界面」或「屏幕」。用户看到的每一个全屏/窗口化界面，通常对应一个 Activity（或 Fragment 承载的视图）。

要点 说明
职责 提供 UI、处理用户输入、与用户交互
生命周期 onCreate → onStart → onResume → (运行中) → onPause → onStop → onDestroy
启动方式 其他 Activity 或应用通过 startActivity(Intent) 启动
任务栈 多个 Activity 组成「返回栈」，Back 键按栈顶依次退出 
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────────────┐
│  Activity 典型生命周期（简化）                                             │
│                                                                          │
│  创建 ──► onCreate() ──► onStart() ──► onResume() ──► 可见且可交互        │
│                                              │                           │
│                                              ▼                           │
│  切到后台 / 被遮挡  ──► onPause() ──► onStop()                            │
│                                              │                           │
│  再次回到前台  ──► onRestart() ──► onStart() ──► onResume()               │
│                                                                          │
│  销毁  ──► onDestroy()                                                    │
└─────────────────────────────────────────────────────────────────────────┘
  • 与 Fragment 的关系：一个 Activity 可包含多个 Fragment，Fragment 是「界面片段」，用于在同一个 Activity 内做模块化 UI 与复用。

2.2 Service：后台任务与长期运行

Service 用于在「无界面」的情况下执行长时间运行的任务，或为其他组件提供后台能力（如播放音乐、下载、同步）。

类型 说明 典型场景
Started Service 由 startService() 启动，可长期运行直到 stopSelf() 或 stopService() 音乐播放、下载、上传
Bound Service 由 bindService() 绑定，为其他组件提供 C/S 式接口，无客户端绑定后可由系统回收 本地 SDK、数据服务、AIDL 服务
  • 生命周期：onCreate → onStartCommand（Started）或 onBind（Bound）→ 运行 → onUnbind / onDestroy。
  • 前台服务：若需长时间在后台运行且不被系统轻易杀死，可调用 startForeground() 并显示持久通知，符合系统对「前台服务」的规范。

2.3 BroadcastReceiver：事件广播与响应

BroadcastReceiver 用于接收系统或应用发出的「广播」（如开机完成、网络变化、电量低、自定义事件），并做轻量级响应。

要点 说明
注册方式 静态注册（AndroidManifest.xml）或动态注册（代码中 registerReceiver）
执行 主线程、短时执行；耗时逻辑应交给 Service 或 WorkManager
有序广播 可指定优先级与「截断」传播（abortBroadcast）

常见系统广播：ACTION_BOOT_COMPLETED、ACTION_BATTERY_LOW、CONNECTIVITY_ACTION 等。

2.4 ContentProvider：数据抽象与跨进程共享

ContentProvider 对数据提供统一的「增删改查」接口（类似小型数据库 API），并支持跨应用、跨进程访问，是 Android 中「数据共享」的标准方式。

要点 说明
职责 封装数据源（SQLite、文件、内存、网络），对外提供 URI 与 Cursor/ContentValues API
跨进程 底层通过 Binder 暴露，其他应用通过 ContentResolver 访问，无需直接依赖实现方
权限 可在 AndroidManifest 中为 Provider 声明读写权限，由系统做权限校验

系统示例：通讯录、媒体库、设置等，均通过 ContentProvider 暴露给其他应用。

三、支撑性核心：Intent、Context、Application

3.1 Intent：意图与组件间通信

Intent 表示「要做的一件事」或「要传递的一包信息」，用于启动 Activity/Service、发送广播，并携带数据与标志。

类型 说明 典型用法
显式 Intent 指定 ComponentName（包名 + 类名），明确启动哪个组件 应用内页面跳转、指定 Service
隐式 Intent 只指定 action、category、data（可选），由系统根据各组件声明的 匹配 调起相机、分享、打开链接、跨应用启动 
1
2
显式：我知道要启动谁 → setComponent / setClassName
隐式：我只描述「要做什么」→ setAction / addCategory / setData，系统找合适的组件
  • Intent 可携带：Bundle 数据、Extra、Flags（如 FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_SINGLE_TOP）等，是组件间解耦通信的载体。

3.2 Context：上下文与资源访问

Context 是「当前组件/应用所在环境」的抽象，提供：

  • 访问应用资源（布局、字符串、drawable、主题等）
  • 启动组件（startActivity、startService、sendBroadcast）
  • 获取系统服务（getSystemService：如 LayoutInflater、ActivityManager、LocationManager）
  • 访问应用专属目录与 SharedPreferences 等
常见实现 说明
Activity Activity 本身是 Context，且带有「界面/任务」相关能力（如 startActivityForResult）
Application 进程级单例 Context，生命周期等于进程，适合做全局初始化与单例持有
Service Service 也是 Context，但无界面相关 API

注意：长时间持有 Activity 的 Context 容易导致内存泄漏（如静态变量引用 Activity），在异步回调中应避免；可改用 Application Context 或弱引用。

3.3 Application：应用级单例

Application 在进程启动时由系统创建，且每个进程只有一个实例。常用作：

  • 应用级初始化（SDK、全局配置、数据库等）
  • 全局单例或依赖注入容器的持有
  • 实现 Application 级别的生命周期回调（如 onConfigurationChanged）

在 AndroidManifest.xml 中通过 <application android:name=".MyApplication"> 指定自定义子类。

四、核心设计思想

4.1 组件化与「应用即组件集合」

Android 不强调「一个程序从 main 开始跑」，而是强调：

  • 应用由多个组件构成，每个组件有明确类型（Activity/Service/…）和声明（AndroidManifest）。
  • 入口是「可被系统或其它应用调用的组件」：例如 LAUNCHER Activity、可被隐式 Intent 匹配的 Activity/Service。
  • 组件之间通过 Intent 解耦：调用方只表达「意图」，不直接依赖实现类，便于复用与替换。
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────────────┐
│  组件化思想：应用 = 组件 + 声明 + 意图驱动                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   AndroidManifest.xml 声明组件与 Intent-Filter                            │
│         │                                                                 │
│         ▼                                                                 │
│   系统 / 其他应用  ──► 发出 Intent  ──► 系统解析  ──► 创建并启动对应组件     │
│                                                                          │
│   同一「动作」可有多个实现（如多个浏览器），用户或系统选择其一               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

4.2 生命周期由系统托管

组件的创建、暂停、恢复、销毁由 系统 根据用户行为、系统资源、配置变更（如旋转、多窗口、语言切换）统一调度：

  • 开发者实现生命周期回调（如 Activity 的 onPause/onResume），在「合适的时机」保存状态、释放资源、恢复 UI。
  • 系统可在内存紧张时回收后台组件；配置变更时销毁并重建 Activity，通过 onSaveInstanceState / ViewModel 等恢复状态。

这种设计把「何时创建/销毁」交给系统，应用只响应「已经发生」的生命周期事件，便于多任务与资源管理。

4.3 安全与权限模型

  • 进程隔离：每个应用默认运行在独立进程，内存与执行空间隔离。
  • 组件级权限：可在 AndroidManifest 中为 Activity/Service/ContentProvider 等声明 android:permission，调用方需具备相应权限才能启动或访问。
  • 运行时权限：危险权限（如相机、位置、存储）需在运行时向用户申请，用户同意后应用才可使用。
  • Intent 与导出：组件可设为 android:exported="true/false"，控制是否允许其他应用通过隐式 Intent 调起。

4.4 多任务与任务栈

  • 任务（Task）：通常对应用户概念里的「一个应用的一组界面」，由一组 Activity 的栈组成。
  • 启动模式：Activity 的 launchMode（standard、singleTop、singleTask、singleInstance）以及 Intent 的 Flags 共同决定「新 Activity 如何入栈、是否复用已有实例」，从而影响返回栈行为与多任务表现。

五、从设计思想到最佳实践

5.1 用 Intent 做解耦

  • 应用内跳转：可用显式 Intent，也可用隐式 Intent + 自定义 action，便于后续替换实现或做 Deep Link。
  • 跨应用能力：尽量用系统或公共的 action/data 约定（如 VIEW + http/https），或在自己的 Provider/Activity 上声明清晰的 intent-filter，便于被系统或其他应用发现和调起。

5.2 生命周期与状态保存

  • 短时状态：在 onSaveInstanceState 中保存，在 onCreate/onRestoreInstanceState 中恢复。
  • 界面相关数据：使用 ViewModel + LiveData/StateFlow，在配置变更时保留，避免在 Activity 里堆业务状态。
  • 释放资源：在 onPause/onStop 中暂停耗时操作、释放监听与引用，在 onDestroy 中做最终清理，避免泄漏。

5.3 Service 与后台行为规范

  • 短时任务：优先用 WorkManager 或 协程 + 应用前后台状态，避免长时间占住 Service。
  • 需要长时间运行且用户可感知（如音乐播放、导航）：使用 前台 Service，并按规定显示通知。
  • 避免在 BroadcastReceiver 中做重活：应启动 Service 或提交到 WorkManager。

5.4 架构分层与组件角色

  • Activity/Fragment：只做 UI 与用户输入，将业务与数据交给 ViewModel 或 Presenter。
  • ViewModel：持有界面状态与业务逻辑入口，不持有 Context/View，便于测试与复用。
  • Repository / UseCase：封装数据来源（网络、本地、ContentProvider），对上层提供统一接口。
  • ContentProvider：仅在需要「跨应用/跨进程共享数据」时使用；应用内本地数据可用 Room + DAO 等，不必强行上 Provider。

六、小结

主题 要点
四大组件 Activity（界面）、Service（后台）、BroadcastReceiver（广播）、ContentProvider（数据抽象与跨应用共享）
支撑核心 Intent（意图与组件通信）、Context（资源与系统服务）、Application（进程级单例）
设计思想 组件化、系统托管生命周期、Intent 驱动与解耦、安全与权限、任务栈与多任务
实践方向 善用 Intent 解耦、重视生命周期与状态保存、规范使用 Service 与后台、UI 与业务分层

理解「应用即组件的组合」「生命周期由系统托管」「Intent 表达意图、系统负责匹配与调度」，就能更好地把握 Android 核心组件与设计思想，并在此基础上用好 ViewModel、WorkManager、Jetpack 等现代组件与工具。

Posted Updated Mobile / Cross-Platform / Algorithm / HarmonyOS19 minutes read (About 2878 words)

Android / iOS / 鸿蒙 / React / Flutter 响应式编程共同点分析

由浅入深，从基本概念到源码原理，再到实战案例，系统梳理五大主流开发框架中的响应式编程共性与差异

一、什么是响应式编程？

1.1 从命令式到声明式

无论使用哪个平台，传统命令式编程的本质都是「我告诉程序每一步该做什么」：

1
2
3
4
5
6
7
8
9
// Android 命令式：手动监听 + 条件判断
editText.addTextChangedListener(object : TextWatcher {
    override fun onTextChanged(s: CharSequence?, p1: Int, p2: Int, p3: Int) {
        val text = text.toString()
        if (text.length >= 3) {
            searchUsers(text)
        }
    }
})
1
2
3
4
5
6
// iOS 命令式：Target-Action
textField.addTarget(self, action: #selector(textDidChange), for: .editingChanged)
func textDidChange() {
    let text = textField.text ?? ""
    if text.count >= 3 { searchUsers(text) }
}

响应式编程则将数据流（Data Stream）视为核心，用声明式方式描述「当数据变化时该做什么」：

1
2
命令式：监听 → 判断 → 执行
响应式：数据流 → 转换/过滤 → 订阅并响应

1.2 响应式编程的三大特征

特征 说明 跨平台体现
数据流 事件、状态、异步结果统一抽象为「流」 Observable / Signal / Stream / State
声明式 描述「是什么」而非「怎么做」 链式操作符、装饰器、Hooks
自动传播 依赖变化自动触发更新 订阅机制、依赖收集、重新渲染

1.3 五大平台的响应式方案概览

平台 主要方案 核心类型 特点
Android RxJava / Kotlin Flow Observable / Flow 操作符丰富，协程整合
iOS RAC / RxSwift Signal / Observable 热/冷信号、Cocoa 扩展
鸿蒙 ArkUI @State / @Observed 声明式 UI，装饰器驱动
React Hooks useState / useEffect 函数式、虚拟 DOM 驱动
Flutter Stream / ValueNotifier Stream / ChangeNotifier Dart 异步流、Listenable

二、核心概念共通点

2.1 观察者模式：统一的底层基石

所有响应式实现都以观察者模式为基础：有「被观察对象」和「观察者」，数据变化时通知观察者。

1
2
3
4
5
6
7
┌─────────────────┐         ┌──────────────────┐
│  数据源/生产者   │ ──────► │  观察者/消费者    │
│  (Observable等)  │  订阅   │  (Observer等)     │
└─────────────────┘         └──────────────────┘
        │                            ▲
        │  onNext / send / emit      │
        └────────────────────────────┘
平台 被观察者 观察者 订阅方式
Android RxJava Observable Observer subscribe()
Android Flow Flow Collector collect {}
iOS RAC Signal / SignalProducer Observer observe() / start()
React useState 返回值 组件 隐式（依赖 React 调度）
Flutter Stream / ValueNotifier StreamSubscription / addListener listen() / addListener()
鸿蒙 @State 变量 UI 组件 隐式（框架自动重绘）

2.2 可取消性（Disposable / 生命周期）

订阅通常会产生「可取消」的句柄，用于在合适时机释放资源，避免内存泄漏：

平台 取消句柄 典型用法
RxJava Disposable compositeDisposable.add()
Kotlin Flow Job / CoroutineScope viewModelScope.launch {}
RAC Disposable disposable.dispose()
React useEffect 清理函数 return () => cleanup()
Flutter StreamSubscription subscription.cancel()
鸿蒙 框架管理 组件销毁自动解绑

2.3 热流 vs 冷流（部分平台）

在 RxJava、RAC、Kotlin Flow 中，流有「热」「冷」之分：

类型 含义 典型场景
冷流 每次订阅才执行，每个订阅者独立收到完整数据 网络请求、文件读取
热流 无论是否订阅都会持续发送，多订阅共享同一流 按钮点击、通知、UI 事件

React / Flutter / 鸿蒙 的「状态」更接近热流：始终有一个当前值，变化时通知依赖方。

三、各平台实现原理浅析

3.1 Android：RxJava 与 Kotlin Flow

RxJava：基于 ReactiveX 规范，Observable 链式操作符，每次操作返回新 Observable，订阅时从上游向下游传递事件。

1
2
3
4
5
6
7
8
9
10
11
// RxJava 链式调用
Observable.create<String> { emitter ->
    emitter.onNext("Hello")
    emitter.onComplete()
}
.map { it.uppercase() }
.filter { it.length > 0 }
.subscribe(
    { println(it) },
    { it.printStackTrace() }
)

Kotlin Flow：冷流，基于协程，背压天然支持，与 StateFlow/SharedFlow 配合做 UI 状态和事件。

1
2
3
4
5
// Flow 冷流 + 操作符
flowOf(1, 2, 3)
    .map { it * 2 }
    .filter { it > 2 }
    .collect { println(it) }

LiveData：轻量级、生命周期感知，主线程回调，适合简单 UI 状态，官方推荐新项目用 Flow 替代。

3.2 iOS：ReactiveCocoa / ReactiveSwift

Signal：热信号，由 pipe() 创建，observer 控制发送。

1
2
3
let (signal, observer) = Signal<String, Never>.pipe()
signal.observeValues { print($0) }
observer.send(value: "Hi")

SignalProducer：冷信号，每次 start 执行一次，适合异步任务。

1
2
3
4
5
let producer = SignalProducer<String, Never> { obs, _ in
    obs.send(value: "Hello")
    obs.sendCompleted()
}
producer.startWithValues { print($0) }

3.3 鸿蒙 ArkUI：装饰器驱动的状态

ArkUI 用装饰器声明「可观察」的状态，状态变化自动触发 UI 更新：

1
2
3
4
5
6
7
8
9
10
11
12
// @State：组件内部状态
@State count: number = 0

// @Prop：父→子单向
// @Link：双向
// @Provide / @Consume：跨层级

// @Observed + @ObjectLink：嵌套对象
@Observed
class User {
  name: string
}

@ObservedV2 + @Trace（V2）：支持深层属性观察，解决嵌套对象不可观察的问题。

3.4 React：状态与副作用

React 的响应式体现在「状态驱动 UI」和「副作用与依赖同步」：

1
2
3
4
5
6
7
8
9
10
11
const [keyword, setKeyword] = useState('');
const [users, setUsers] = useState([]);

// 依赖 keyword 变化，自动重新执行
useEffect(() => {
  if (keyword.length < 3) return;
  const timer = setTimeout(() => {
    searchUsers(keyword).then(setUsers);
  }, 300);
  return () => clearTimeout(timer); // 清理
}, [keyword]);

状态变化 → 重新渲染 → 虚拟 DOM diff → 最小化 DOM 更新。

3.5 Flutter：Stream 与 Listenable

Stream：Dart 异步流，类似冷流，支持 map、where、asyncMap 等。

1
2
3
4
Stream.periodic(Duration(seconds: 1))
  .map((i) => i * 2)
  .take(5)
  .listen((value) => print(value));

ValueNotifier / ChangeNotifier：同步、轻量，配合 ValueListenableBuilder 做局部重建：

1
2
3
4
5
final counter = ValueNotifier<int>(0);
ValueListenableBuilder<int>(
  valueListenable: counter,
  builder: (_, value, __) => Text('$value'),
)

四、操作符与组合逻辑的共性

4.1 转换类：map / filter

操作符 含义 Android iOS RAC Flutter React
map 值转换 map {} .map {} .map() 派生 state
filter 过滤 filter {} .filter {} .where() 条件 + early return

4.2 组合类：combineLatest / merge

多流组合在各平台均有对应能力：

场景 RxJava RAC Flutter React
多源最新值 combineLatest combineLatest RxDart combineLatest2 多个 useState + useEffect
多流合并 merge merge StreamGroup.merge 自定义逻辑

4.3 扁平化：flatMap / switchMap

将「每个值 → 新流」展开，常用于搜索联想、取消旧请求：

平台 操作符 行为
RxJava flatMap / switchMap switchMap 只保留最新内层流
RAC flatMap(.latest) 新关键词取消上次请求
Flutter asyncExpand 类似 flatMap
React useEffect + 清理 依赖变化时清理上次 effect

4.4 时间控制：debounce / throttle

防抖、节流在搜索、滚动等场景通用：

平台 防抖 节流
RxJava debounce() throttleFirst/throttleLatest
RAC debounce() throttle()
Flutter debounce from rxdart throttle from rxdart
React 自定义 setTimeout + cleanup useThrottle / lodash

五、源码层面的共通原理

5.1 链式结构与包装

操作符通常不修改原流，而是返回新的「包装流」，内部订阅上游并转换后传给下游：

1
2
3
4
5
6
7
8
9
Observable.map(f)
    │
    ├─ 创建 MapObservable
    │      │
    │      ├─ source = 上游 Observable
    │      └─ mapper = 转换函数 f
    │
    └─ subscribe 时：上游.subscribe(下游的包装 Observer)
                       下游 Observer 收到值时：onNext(mapper(value))

RAC 的 map 也是类似结构：Signal { observer in self.observe { ... observer.send(value: transform($0)) } }。

5.2 订阅传播

订阅是「从下游往上游」建立，事件是「从上游往下游」传递：

1
2
3
4
5
6
subscribe(observer)
  → 下游 Observable 订阅其 source
    → 再往上游订阅
      → … 直到最顶层
        → 顶层开始 onNext/onComplete
          → 层层传递到最下游

5.3 取消传播

Disposable / Job 形成链：取消下游会向上传递，终止整条链的执行。

六、跨平台示例：搜索防抖 + 取消旧请求

6.1 Android (RxJava)

1
2
3
4
5
6
7
8
RxTextView.textChanges(searchEditText)
    .map { it.toString() }
    .filter { it.length >= 2 }
    .debounce(300, TimeUnit.MILLISECONDS)
    .switchMap { keyword -> api.searchUsers(keyword).toObservable() }
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe({ users -> updateUI(users) }, { it.printStackTrace() })
    .addTo(compositeDisposable)

6.2 iOS (RAC)

1
2
3
4
5
6
7
8
9
10
searchTextField.reactive.continuousTextValues
    .filter { ($0 ?? "").count >= 2 }
    .debounce(0.3, on: QueueScheduler.main)
    .flatMap(.latest) { keyword in
        searchAPI(keyword ?? "")
    }
    .observe(on: UIScheduler())
    .observeValues { [weak self] users in
        self?.updateSearchResults(users)
    }

6.3 鸿蒙 (ArkUI)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@State keyword: string = ''
@State users: User[] = []
private timer: number = -1

onInputChange(value: string) {
  this.keyword = value
  clearTimeout(this.timer)
  if (value.length < 2) return
  this.timer = setTimeout(() => {
    SearchAPI.searchUsers(value).then((users: User[]) => {
      this.users = users
    })
  }, 300)
}

6.4 React

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const [keyword, setKeyword] = useState('');
const [users, setUsers] = useState([]);

useEffect(() => {
  if (keyword.length < 2) return;
  const timer = setTimeout(() => {
    let cancelled = false;
    searchUsers(keyword).then(data => {
      if (!cancelled) setUsers(data);
    });
    return () => { cancelled = true; };
  }, 300);
  return () => clearTimeout(timer);
}, [keyword]);

6.5 Flutter

1
2
3
4
5
6
7
8
9
10
11
12
13
final _keyword = StreamController<String>.broadcast();
final _users = ValueNotifier<List<User>>([]);

_keyword.stream
  .where((s) => s.length >= 2)
  .transform(StreamTransformer.fromHandlers(
    handleData: (data, sink) => Timer(Duration(milliseconds: 300), () => sink.add(data)),
  ))
  .asyncMap((k) => searchAPI(k))
  .listen((users) => _users.value = users);

// 输入时
_keyword.add(controller.text);

七、实际项目应用案例

7.1 登录表单校验（多字段组合）

需求：用户名 ≥3 字符、密码 ≥6 字符时，登录按钮才可点击。

平台 实现要点
RxJava combineLatest(username, password).map { u, p -> u.length>=3 && p.length>=6 }
RAC Signal.combineLatest(username.signal, password.signal).map { … }
React useMemo 派生 canLogin = user.length>=3 && pwd.length>=6
Flutter ValueNotifier 或 Stream，combineLatest2 派生
鸿蒙 @State user/pwd，computed 或 @Computed 派生 canLogin

7.2 多数据源合并展示

需求：本地缓存 + 网络接口合并去重后展示。

各平台通用思路：

  1. 本地流 + 远程流
  2. combineLatest / zip / merge 合并
  3. map 去重、排序
  4. 订阅结果更新 UI

7.3 列表下拉刷新 + 分页加载

需求：下拉刷新、上拉加载更多，防重复请求。

  • 用 Subject / PublishSubject 表示下拉、触底事件
  • debounce 防抖
  • flatMap/switchMap 发起请求，合并到单一列表流
  • 错误重试、loading 状态管理

7.4 电商 App 购物车总价

需求：商品数量、价格变化时，实时计算总价。

  • 每个商品的数量、单价作为流/状态
  • combineLatest 合并所有项
  • map/reduce 计算总价
  • 单一订阅更新总价 UI

八、各平台选型建议

场景 Android iOS 鸿蒙 React Flutter
新项目 优先 Kotlin Flow RAC/RxSwift ArkUI 原生 Hooks Stream + ValueNotifier
复杂异步流 RxJava / Flow RAC 自定义 + Promise useEffect + 自定义 Hook rxdart
简单 UI 状态 StateFlow / LiveData @Published @State useState ValueNotifier
跨层级状态 ViewModel + StateFlow 单例 + Property @Provide/@Consume Context/Redux Provider/Riverpod

九、共同的最佳实践

  1. 生命周期绑定：订阅要在页面/组件销毁时取消，避免泄漏。
  2. 线程/调度：UI 更新必须在主线程/主 Isolate，注意 observeOn / UIScheduler。
  3. 防抖与节流：输入、滚动等高频事件务必做时间控制。
  4. 取消旧请求：搜索、联想场景用 switchMap / flatMap(.latest) 或 useEffect 清理。
  5. 错误处理：onError / catch / retry 统一处理，避免吞掉异常。
  6. 弱引用：闭包中 [weak self] / WeakReference，防止循环引用。

十、总结

维度 共性
本质 观察者模式 + 数据流抽象
思想 声明式、数据驱动、自动传播
操作符 map、filter、combine、flatMap、debounce 等在各平台都有对应
取消 Disposable / 清理函数 / 生命周期绑定
热/冷 部分平台区分热流（共享）与冷流（按需执行）
应用 表单校验、搜索联想、多源合并、列表分页、实时计算

掌握这些共性后，从一个平台迁移到另一个平台时，可以快速找到对应概念和 API，写出一致、可维护的响应式代码。

参考资源

Posted Updated Mobile / iOS25 minutes read (About 3762 words)

iOS 模块化、组件化、插件化架构

从基础概念到实战应用，系统梳理 iOS 架构演进之路

一、基础概念

1.1 为什么需要架构优化？

随着业务迭代，单体 App 会遇到诸多问题：

问题 表现 影响
代码耦合严重 模块间直接 import，循环依赖 难以维护、编译慢
编译效率低 改一行代码全量编译 开发效率下降
团队协作冲突 多人修改同一工程 Git 冲突频繁
无法独立开发 强依赖主工程 无法并行开发、独立测试
复用困难 业务逻辑与 UI 混在一起 跨项目复用成本高

1.2 三种架构模式辨析

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────┐
│                        架构演进路径                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   单体架构 ──► 模块化 ──► 组件化 ──► 插件化                        │
│      │           │          │           │                         │
│      │           │          │           │                         │
│      ▼           ▼          ▼           ▼                         │
│   按功能拆分   物理隔离   独立仓库     运行时动态加载                 │
│   代码目录     组件解耦   CocoaPods    热更新/按需加载               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

模块化（Modularization）

  • 定义：按业务功能将代码拆分为独立的「模块」，每个模块有清晰的边界
  • 特点：逻辑划分、职责单一，通常仍在同一工程内
  • 粒度：中等，如「用户模块」「订单模块」「支付模块」

组件化（Componentization）

  • 定义：将模块进一步拆分为可独立编译、可复用的「组件」，通过依赖注入解耦
  • 特点：物理隔离、独立仓库、独立编译、协议解耦
  • 粒度： finer，如「登录组件」「分享组件」「埋点组件」

插件化（Pluginization）

  • 定义：组件可动态加载、热更新，主 App 与插件解耦到运行时
  • 特点：运行时动态、按需加载、可热修复
  • 粒度：动态 Bundle/Framework

二、模块化原理与实践

2.1 模块化的核心原则

  1. 单一职责：每个模块只负责一块业务
  2. 接口隔离：模块间通过 Protocol 通信，不暴露实现细节
  3. 依赖倒置：依赖抽象（协议）而非具体实现

2.2 目录结构示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
MyApp/
├── App/                    # 主工程壳
│   ├── AppDelegate
│   └── Main
├── Modules/
│   ├── ModuleA_User/       # 用户模块
│   │   ├── Services/
│   │   ├── Views/
│   │   └── Models/
│   ├── ModuleB_Order/      # 订单模块
│   └── ModuleC_Payment/    # 支付模块
├── Common/                 # 公共基础库
│   ├── Network/
│   ├── Utils/
│   └── BaseClasses/
└── Router/                 # 路由层（模块间通信枢纽）

2.3 模块间通信：Protocol + 依赖注入

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
// 1. 定义协议（放在公共层或 Protocol 模块）
protocol UserServiceProtocol: AnyObject {
    func getCurrentUser() -> User?
    func logout()
}

// 2. 模块实现协议
// UserModule/UserService.swift
class UserService: UserServiceProtocol {
    func getCurrentUser() -> User? { /* ... */ }
    func logout() { /* ... */ }
}

// 3. 依赖注入（App 启动时或 ServiceLocator）
class ServiceLocator {
    static let shared = ServiceLocator()
    var userService: UserServiceProtocol?
}

// 4. 其他模块通过协议调用
class OrderViewController: UIViewController {
    var userService: UserServiceProtocol?
    
    func showUserInfo() {
        guard let user = userService?.getCurrentUser() else { return }
        // ...
    }
}

三、组件化原理与实现

3.1 组件化架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
                ┌──────────────────┐
                │     App Shell    │
                │  (主工程/壳工程)   │
                └────────┬─────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  用户组件    │ │  订单组件    │ │  支付组件    │
│  (Pod)      │ │  (Pod)      │ │  (Pod)      │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
                ┌──────▼──────┐
                │ 路由/中间层  │
                │ (URL/Mediator)│
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │  基础组件    │
                │ (网络/缓存/UI)│
                └─────────────┘

3.2 路由方案对比

方案 原理 优点 缺点
URL Router 字符串 URL 映射到 VC 简单、支持 H5 跳转 参数传递不便、类型不安全
Target-Action (Mediator) 通过 Mediator 类反射调用 解耦彻底、类型安全 需维护中间类
Protocol 协议注册 + 实现查找 接口清晰 需集中注册

3.3 Mediator 模式源码实现

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
50
51
52
53
54
55
56
57
58
59
// CTMediator 核心实现（简化版，源自 Casa 的 CTMediator）
import UIKit

public class CTMediator: NSObject {
    public static let shared = CTMediator()
    
    // 缓存 Target 实例，避免重复创建
    private var targetCache = [String: NSObject]()
    
    /// 通过 Target-Action 调用
    /// - Parameters:
    ///   - targetName: 目标类名，如 "Order"
    ///   - actionName: 方法名，如 "orderListViewController"
    ///   - params: 参数字典
    public func perform(target targetName: String,
                        action actionName: String,
                        params: [String: Any]? = nil) -> Any? {
        let targetClassString = "Target_\(targetName)"
        let actionString = "Action_\(actionName):"
        
        // 1. 获取 Target 类
        guard let targetClass = NSClassFromString(targetClassString) as? NSObject.Type else {
            return nil
        }
        
        // 2. 获取或创建 Target 实例
        var target = targetCache[targetClassString]
        if target == nil {
            target = targetClass.init()
            targetCache[targetClassString] = target
        }
        
        // 3. 通过 NSInvocation 或 perform 调用
        let selector = NSSelectorFromString(actionString)
        guard (target?.responds(to: selector)) ?? false else {
            return nil
        }
        
        return target?.perform(selector, with: params)?.takeUnretainedValue()
    }
}

// ========== 组件端：Order 模块 ==========
// 在 Order 组件内定义 Target_Order
class Target_Order: NSObject {
    @objc func Action_orderListViewController(_ params: [String: Any]?) -> UIViewController {
        let userId = params?["userId"] as? String ?? ""
        let vc = OrderListViewController(userId: userId)
        return vc
    }
}

// ========== 调用端：任意模块 ==========
let vc = CTMediator.shared.perform(
    target: "Order",
    action: "orderListViewController",
    params: ["userId": "12345"]
) as? UIViewController
navigationController?.pushViewController(vc!, animated: true)

3.4 依赖关系设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Podfile 示例
target 'MainApp' do
  # 业务组件（同层，互不依赖）
  pod 'UserModule'
  pod 'OrderModule'
  pod 'PaymentModule'
  
  # 中间层
  pod 'Mediator'
  pod 'Mediator/Order'   # Category，扩展 Order 的便捷方法
  pod 'Mediator/User'
end

# 各业务组件的 Podspec 只依赖基础库
# OrderModule.podspec
Pod::Spec.new do |s|
  s.name = 'OrderModule'
  s.dependency 'Mediator'
  s.dependency 'BaseNetwork'
  s.dependency 'BaseUI'
end

关键点：业务组件之间不直接依赖，都通过 Mediator 间接通信。

四、插件化原理与实现

4.1 插件化的应用场景

  • 热更新：修复线上 Bug 无需发版
  • 按需加载：减少包体积，冷启动只加载核心
  • 动态能力：运营活动插件、A/B 测试模块
  • 多端复用：同一套插件可被主 App、Widget、Watch 加载

4.2 iOS 插件化技术选型

技术 说明 限制
Dynamic Framework 动态库，可延迟加载 App Store 限制主二进制外的动态库
Bundle + 反射 资源/代码打包成 .bundle，运行时加载 无法绕过沙盒，需提前打包进 App
JavaScript 引擎 React Native / Flutter / JSI 非原生，性能与体验有差异
JSPatch / 热修复 通过 Runtime 动态替换方法 已不可上架 App Store

注意：苹果审核禁止下载执行任意代码，真正「从网络下载插件并执行」的纯插件化在 App Store 场景不可行。实际做法多为：预置多个 Framework/Bundle，运行时按需加载，或通过 JS 引擎 + 离线包 实现业务热更新。

4.3 动态 Framework 加载示例

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
import UIKit

class PluginManager {
    static let shared = PluginManager()
    private var loadedBundles: [String: Bundle] = [:]
    
    /// 加载动态 Framework（需预置在 App 内）
    func loadPlugin(named pluginName: String) -> Bool {
        guard let path = Bundle.main.path(
            forResource: pluginName,
            ofType: "framework",
            inDirectory: "Frameworks"
        ) else { return false }
        
        guard let bundle = Bundle(path: path), bundle.load() else {
            return false
        }
        
        loadedBundles[pluginName] = bundle
        return true
    }
    
    /// 通过反射获取插件内的类并调用
    func instantiateViewController(fromPlugin pluginName: String,
                                   className: String) -> UIViewController? {
        guard let bundle = loadedBundles[pluginName] ?? {
            loadPlugin(named: pluginName) ? loadedBundles[pluginName] : nil
        }() else { return nil }
        
        guard let pluginClass = bundle.classNamed(className) as? UIViewController.Type else {
            return nil
        }
        
        return pluginClass.init()
    }
}

// 使用
if PluginManager.shared.loadPlugin(named: "ActivityPlugin") {
    let vc = PluginManager.shared.instantiateViewController(
        fromPlugin: "ActivityPlugin",
        className: "ActivityPlugin.ActivityViewController"
    )
    present(vc!, animated: true)
}

4.4 基于 Runtime 的模块注册

1
2
3
4
5
6
7
8
9
10
11
12
// 插件自注册：通过 +load 在加载时注册到中心
// PluginModule.m
+ (void)load {
    [[PluginRegistry shared] registerPlugin:@"Activity"
                                withClass:[ActivityPlugin class]];
}

// PluginRegistry 管理所有插件
@interface PluginRegistry : NSObject
- (void)registerPlugin:(NSString *)name withClass:(Class)cls;
- (id)createInstanceForPlugin:(NSString *)name;
@end

五、BeeHive 框架源码解析

BeeHive 是阿里开源的 iOS 模块化框架，结合了 Protocol 注册 与 Module 生命周期。

5.1 架构概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌────────────────────────────────────────────────────────┐
│                    BHContext (上下文)                    │
│  - 配置信息、环境变量、共享数据                           │
└────────────────────────────────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  BHModuleManager                       │
│  - 管理 Module 注册、加载、生命周期                      │
└────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ BHService    │  │ BHModule     │  │ BHConfig     │
│ (协议-实现)   │  │ (模块基类)   │  │ (配置)        │
└──────────────┘  └──────────────┘  └──────────────┘

5.2 核心类：BHModuleManager

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
// 简化版核心逻辑
@implementation BHModuleManager

- (void)registerDynamicModule:(Class)moduleClass {
    if ([moduleClass conformsToProtocol:@protocol(BHModuleProtocol)]) {
        BHModuleInfo *info = [[BHModuleInfo alloc] initWithModuleClass:moduleClass];
        [self.modules addObject:info];
        [self.modules sortUsingComparator:^NSComparisonResult(BHModuleInfo *m1, BHModuleInfo *m2) {
            return m1.priority < m2.priority;  // 按优先级排序
        }];
    }
}

- (void)triggerEvent:(NSInteger)eventType {
    for (BHModuleInfo *info in self.modules) {
        id<BHModuleProtocol> instance = [info moduleInstance];
        switch (eventType) {
            case BHMSetupEvent:
                [instance modSetUp:nil];
                break;
            case BHMInitEvent:
                [instance modInit:nil];
                break;
            case BHMSplashEvent:
                [instance modSplash:nil];
                break;
            // ... 更多生命周期事件
        }
    }
}

@end

5.3 Protocol 注册与查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// BHServiceManager：Protocol -> 实现类 映射
- (void)registerService:(Protocol *)protocol implClass:(Class)implClass {
    NSString *key = NSStringFromProtocol(protocol);
    self.services[key] = implClass;
}

- (id)createService:(Protocol *)protocol {
    Class implClass = self.services[NSStringFromProtocol(protocol)];
    return [[implClass alloc] init];
}

// 使用
@protocol UserServiceProtocol <NSObject>
- (User *)currentUser;
@end

// 注册
[[BHServiceManager sharedManager] registerService:@protocol(UserServiceProtocol)
                                       implClass:[UserServiceImpl class]];

// 获取
id<UserServiceProtocol> service = [[BHServiceManager sharedManager] createService:@protocol(UserServiceProtocol)];

六、实际项目应用案例

6.1 某电商 App 组件化拆分

1
2
3
4
5
6
7
8
9
10
11
MainApp (壳工程)
├── HomeModule          # 首页
├── ProductModule       # 商品详情
├── CartModule          # 购物车
├── OrderModule         # 订单
├── UserModule          # 用户中心
├── PaymentModule       # 支付
├── ShareModule         # 分享（可复用）
├── AnalyticsModule     # 埋点（可复用）
├── Mediator            # 路由中间层
└── BasePods            # 网络/缓存/UI 基础库

收益：

  • 编译时间：全量 8min → 单模块 1.5min
  • 4 个业务线可并行开发，Git 冲突减少 70%
  • ShareModule、AnalyticsModule 复用到多个 App

6.2 路由设计实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Mediator+Order.swift (Mediator 的 Category)
extension CTMediator {
    func orderListViewController(userId: String) -> UIViewController? {
        return perform(target: "Order",
                       action: "orderListViewController",
                       params: ["userId": userId]) as? UIViewController
    }
    
    func orderDetailViewController(orderId: String) -> UIViewController? {
        return perform(target: "Order",
                       action: "orderDetailViewController",
                       params: ["orderId": orderId]) as? UIViewController
    }
}

// 调用处：无需关心 Order 模块内部实现
if let vc = CTMediator.shared.orderListViewController(userId: "123") {
    navigationController?.pushViewController(vc, animated: true)
}

6.3 解耦实践：避免循环依赖

错误示例：

1
2
OrderModule -> UserModule (获取用户信息)
UserModule  -> OrderModule (跳转订单列表)

形成循环依赖，无法独立编译。

正确做法：

1
2
OrderModule -> Mediator
UserModule  -> Mediator

需要「用户信息」时，Order 通过 Mediator 获取 UserServiceProtocol；需要「跳转订单」时，User 通过 Mediator 获取 OrderListViewController。Mediator 依赖各模块的 Target 类（可通过 Category 按需引入）。

七、最佳实践与注意事项

7.1 模块拆分原则

  • 高内聚低耦合：模块内聚度高，模块间依赖少
  • 按业务边界拆分：参考 DDD 的 Bounded Context
  • 基础组件下沉：网络、缓存、日志等抽成独立 Pod
  • 渐进式演进：先模块化再组件化，避免一步到位导致成本过高

7.2 常见坑与规避

问题 原因 规避
编译顺序错误 组件间隐式依赖 严格检查 Pod 依赖，用 pod lib lint 校验
协议爆炸 过度抽象 只对跨模块通信定义协议，模块内部保持自由
路由表膨胀 所有页面都走路由 仅对外暴露的页面注册路由
启动变慢 Module 过多，+load 耗时 延迟注册、按需加载、控制 Module 数量

7.3 架构演进路线图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Phase 1: 模块化
├── 按功能拆分目录
├── 引入 Protocol 解耦
└── 建立 ServiceLocator

Phase 2: 组件化
├── 拆分为独立 Pod
├── 引入 Mediator/路由
└── 独立编译、独立开发

Phase 3: 插件化（可选）
├── 非核心模块动态加载
├── 预置多套业务 Bundle
└── 或引入 RN/Flutter 做动态化

八、总结

架构 适用场景 核心手段
模块化 中小型 App、团队 < 10 人 目录拆分、Protocol、依赖注入
组件化 中大型 App、多业务线并行 独立 Pod、Mediator、路由
插件化 需要动态化、热更新 动态 Framework、Bundle、JS 引擎

架构没有银弹，需结合团队规模、业务复杂度、迭代节奏选择合适方案。建议从模块化起步，随着复杂度提升再逐步演进到组件化，插件化则按实际需求谨慎引入。

参考资源

Posted Updated Mobile / Android31 minutes read (About 4680 words)

Android 模块化、组件化、插件化架构

从基础概念到实战应用，系统梳理 Android 架构演进之路

一、基础概念

1.1 为什么需要架构优化？

随着业务迭代，单体 App 会遇到诸多问题：

问题 表现 影响
代码耦合严重 模块间直接 import，循环依赖 难以维护、编译慢
编译效率低 改一行代码全量编译 开发效率下降
团队协作冲突 多人修改同一工程 Git 冲突频繁
无法独立开发 强依赖主工程 无法并行开发、独立测试
复用困难 业务逻辑与 UI 混在一起 跨项目复用成本高

1.2 三种架构模式辨析

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────┐
│                        架构演进路径                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   单体架构 ──► 模块化 ──► 组件化 ──► 插件化                        │
│      │           │          │           │                         │
│      │           │          │           │                         │
│      ▼           ▼          ▼           ▼                         │
│   按功能拆分   Gradle模块   路由解耦    运行时动态加载               │
│   包结构划分   build独立   ARouter等    热更新/按需下载              │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

模块化（Modularization）

  • 定义：按业务功能将代码拆分为独立的 Gradle 模块，每个模块有清晰的 build.gradle 和边界
  • 特点：物理隔离、可独立编译，通常仍在同一 Git 仓库内
  • 粒度：中等，如「用户模块」「订单模块」「支付模块」

组件化（Componentization）

  • 定义：在模块化基础上，通过路由/服务发现实现模块间完全解耦，可独立开发、独立运行
  • 特点：依赖倒置、接口隔离、可单模块调试（Application 切换）
  • 粒度：较细，如「登录组件」「分享组件」「埋点组件」

插件化（Pluginization）

  • 定义：插件 APK/Dex 可动态加载、热更新，主 App 与插件解耦到运行时
  • 特点：运行时动态、按需下载、可热修复、减小包体积
  • 粒度：独立 APK/模块

二、模块化原理与实践

2.1 模块化的核心原则

  1. 单一职责：每个模块只负责一块业务
  2. 接口隔离：模块间通过接口/路由通信，不暴露实现细节
  3. 依赖倒置：依赖抽象（interface）而非具体实现

2.2 Gradle 多模块目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
MyApp/
├── app/                        # 主工程壳
│   └── build.gradle
├── module_user/                # 用户模块
│   ├── build.gradle
│   └── src/main/
├── module_order/               # 订单模块
│   └── build.gradle
├── module_payment/             # 支付模块
│   └── build.gradle
├── common_base/                # 公共基础库
│   ├── network/
│   ├── utils/
│   └── base/
├── common_router/              # 路由层
│   └── build.gradle
├── build.gradle
└── settings.gradle

2.3 settings.gradle 与模块声明

1
2
3
4
5
6
7
8
// settings.gradle
rootProject.name = "MyApp"
include ':app'
include ':module_user'
include ':module_order'
include ':module_payment'
include ':common_base'
include ':common_router'

2.4 模块间依赖配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// app/build.gradle - 主工程依赖各业务模块
dependencies {
    implementation project(':module_user')
    implementation project(':module_order')
    implementation project(':module_payment')
    implementation project(':common_router')
    implementation project(':common_base')
}

// module_user/build.gradle - 业务模块只依赖基础库和路由
dependencies {
    implementation project(':common_base')
    implementation project(':common_router')
    // 不要依赖 module_order、module_payment！
}

// common_base/build.gradle - 基础库不依赖任何业务模块
dependencies {
    implementation 'androidx.appcompat:appcompat:1.6.1'
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

2.5 模块间通信：接口 + 实现注入

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
// common_router 中定义接口
interface IUserService {
    fun getCurrentUser(): User?
    fun logout()
}

// module_user 中实现接口
class UserServiceImpl : IUserService {
    override fun getCurrentUser(): User? = UserManager.currentUser
    override fun logout() { /* ... */ }
}

// 通过 ServiceLocator 或依赖注入框架注入
object ServiceLocator {
    var userService: IUserService? = null
}

// module_order 中调用
class OrderActivity : AppCompatActivity() {
    private val userService: IUserService? by lazy { ServiceLocator.userService }

    fun showUserInfo() {
        userService?.getCurrentUser()?.let { user ->
            // 显示用户信息
        }
    }
}

三、组件化原理与实现

3.1 组件化架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
                ┌──────────────────┐
                │     app (壳)      │
                │   主工程/组装     │
                └────────┬─────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ module_user │ │ module_order│ │module_payment│
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
                ┌──────▼──────┐
                │   ARouter   │
                │ 路由中间层   │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ common_base │
                │ 基础组件库   │
                └─────────────┘

3.2 路由方案对比

方案 原理 优点 缺点
ARouter 注解 + 编译期生成路由表 阿里出品、生态成熟、支持拦截器 需引入注解处理器
WMRouter 美团方案，分组路由 按需加载、包体积优化 学习成本略高
CC (Component Call) 组件调用框架 同步/异步调用、跨进程 概念较多
手写路由表 Map 映射 简单、无依赖 维护成本高

3.3 单模块独立运行（Application 切换）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// module_user/build.gradle
android {
    defaultConfig {
        // 作为 Application 运行时使用
        if (project.hasProperty('runAsApp') && runAsApp) {
            applicationId "com.example.user"
        }
    }
    sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            if (project.hasProperty('runAsApp') && runAsApp) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            }
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
<!-- module_user/src/main/debug/AndroidManifest.xml - 独立运行时的 Manifest -->
<manifest>
    <application
        android:name=".UserDebugApplication"
        android:label="User Module Debug">
        <activity android:name=".UserActivity" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>
1
2
# 独立运行用户模块
./gradlew :module_user:installDebug -PrunAsApp=true

3.4 ARouter 使用与原理

3.4.1 添加依赖

1
2
3
4
5
// 各模块 build.gradle
dependencies {
    implementation 'com.alibaba:arouter-api:1.5.2'
    kapt 'com.alibaba:arouter-compiler:1.5.2'
}

3.4.2 路由配置与跳转

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ========== 组件端：Order 模块 ==========
// 在 OrderListActivity 上添加路由注解
@Route(path = "/order/list")
class OrderListActivity : AppCompatActivity() {
    @Autowired
    lateinit var userId: String

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ARouter.getInstance().inject(this)
        // userId 已自动注入
    }
}

// ========== 调用端：任意模块 ==========
ARouter.getInstance()
    .build("/order/list")
    .withString("userId", "12345")
    .navigation()

3.4.3 服务发现（跨模块获取实现）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 定义接口（可在 common_base 或单独 api 模块）
interface IOrderService {
    fun getOrderCount(userId: String): Int
}

// Order 模块实现并注册
@Route(path = "/service/order")
class OrderServiceImpl : IOrderService {
    override fun getOrderCount(userId: String): Int = /* ... */
}

// 调用端获取
val orderService = ARouter.getInstance()
    .navigation(IOrderService::class.java)
orderService?.getOrderCount("12345")

3.4.5 ARouter 核心源码解析

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
// 简化版 ARouter 核心逻辑
// 1. 初始化时扫描 Dex，加载路由表（通过 Gradle 插件编译期生成）
class Warehouse {
    // 路由表：path -> RouteMeta
    static Map<String, RouteMeta> routes = ConcurrentHashMap()
    // 分组缓存
    static Map<String, Class<? extends IRouteGroup>> groupsIndex = ConcurrentHashMap()
}

// 2. navigation 流程
fun navigation(path: String): Postcard {
    val meta = Warehouse.routes[path]  // 从路由表获取
    return Postcard(path, meta)
}

fun Postcard.navigation(): Any? {
    return _ARouter.navigation(context, this, requestCode, navigationCallback)
}

// 3. 实际跳转
fun _ARouter.navigation(...) {
    when (meta.type) {
        RouteType.ACTIVITY -> {
            val intent = Intent(context, meta.destination)
            // 注入参数
            context.startActivity(intent)
        }
        RouteType.ISERVICE -> {
            return meta.destination.newInstance()  // 服务实现类
        }
    }
}

// 4. 编译期注解处理器生成路由表
// 生成类似：ARouter$$Group$$order、ARouter$$Providers$$order
// 在 init() 时通过反射加载到 Warehouse

3.5 依赖关系设计原则

1
2
3
4
5
6
7
8
9
业务模块 (user/order/payment)
    │
    ├── 只依赖 common_base、common_router (arouter-api)
    │
    └── 业务模块之间 不直接依赖

app 壳工程
    │
    └── 依赖所有业务模块，负责组装和 Application 初始化

四、插件化原理与实现

4.1 插件化的应用场景

  • 热更新：修复线上 Bug 无需发版
  • 按需加载：减小包体积，冷启动只加载核心
  • 动态能力：运营活动插件、A/B 测试模块
  • 多端复用：同一套插件可被主 App、Split APK 加载

4.2 Android 插件化技术选型

方案 说明 适用场景
Dynamic Feature Modules Google 官方，AGP 支持 按需下载、免安装功能模块
VirtualAPK 滴滴开源 完整的插件化框架
RePlugin 360 出品 插件即独立 APK，稳定成熟
Shadow 腾讯开源 支持 Android 10+，零 Hook
Atlas 阿里 大型 App 动态化

4.3 Dynamic Feature Modules（官方方案）

4.3.1 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// settings.gradle
include ':app'
include ':feature:order'  // 动态功能模块

// app/build.gradle
dependencies {
    implementation project(':common_base')
    dynamicFeatures = [':feature:order']
}

// feature/order/build.gradle
apply plugin: 'com.android.dynamic-feature'
android {
    defaultConfig {
        minSdk 24
    }
}
dependencies {
    implementation project(':app')
}

4.3.2 按需下载与安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 使用 Play Core Library 下载动态模块
val splitInstallManager = SplitInstallManagerFactory.create(context)
val request = SplitInstallRequest.newBuilder()
    .addModule("order")
    .build()

splitInstallManager.startInstall(request)
    .addOnSuccessListener {
        // 安装成功，可跳转
        startActivity(Intent(this, OrderActivity::class.java))
    }
    .addOnFailureListener {
        // 处理失败
    }

4.4 RePlugin 核心原理简述

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──────────────────────────────────────────────────────┐
│                     Host App                          │
│  ┌────────────────────────────────────────────────┐  │
│  │  RePluginHostConfig / PluginManager             │  │
│  │  - 加载插件 APK                                  │  │
│  │  - 替换 ClassLoader                              │  │
│  │  - Hook Activity/Service 等组件                  │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
   ┌──────────┐   ┌──────────┐   ┌──────────┐
   │ Plugin1  │   │ Plugin2  │   │ Plugin3  │
   │  .apk    │   │  .apk    │   │  .apk    │
   └──────────┘   └──────────┘   └──────────┘

核心流程：

  1. Dex 加载：将插件 APK 的 classes.dex 加入宿主的 DexPathList
  2. 资源加载：创建 Resources，合并插件的 AssetManager
  3. 组件占位：通过 Hook Instrumentation/IActivityManager，用占位 Activity 代理插件 Activity

4.5 手写简易插件加载（Dex 加载）

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
// 简化示例：加载插件 APK 中的类
class PluginLoader(private val context: Context) {

    private val pluginClassLoaders = mutableMapOf<String, DexClassLoader>()

    fun loadPlugin(apkPath: String): Boolean {
        val optimizedDir = File(context.filesDir, "plugin_opt").apply { mkdirs() }
        val libDir = File(context.filesDir, "plugin_lib").apply { mkdirs() }

        val classLoader = DexClassLoader(
            apkPath,
            optimizedDir.absolutePath,
            null,
            context.classLoader
        )
        pluginClassLoaders[apkPath] = classLoader
        return true
    }

    fun loadClass(apkPath: String, className: String): Class<*>? {
        val loader = pluginClassLoaders[apkPath] ?: return null
        return try {
            loader.loadClass(className)
        } catch (e: ClassNotFoundException) {
            null
        }
    }
}

// 加载插件中的 Activity（实际还需 Hook 组件启动流程）
val loader = PluginLoader(context)
loader.loadPlugin("/sdcard/plugin.apk")
val clazz = loader.loadClass("/sdcard/plugin.apk", "com.plugin.MainActivity")
val activity = clazz.newInstance()

4.6 插件化资源加载

1
2
3
4
5
6
7
8
9
10
11
12
// 合并插件资源到宿主
fun createPluginResources(hostResources: Resources, apkPath: String): Resources {
    val assets = AssetManager::class.java.newInstance()
    val addAssetPath = AssetManager::class.java.getMethod("addAssetPath", String::class.java)
    addAssetPath.invoke(assets, apkPath)

    return Resources(
        assets,
        hostResources.displayMetrics,
        hostResources.configuration
    )
}

五、ARouter 框架源码深度解析

5.1 整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌────────────────────────────────────────────────────────┐
│                     ARouter                              │
│  - 对外 API：build、navigation、inject                    │
└────────────────────────────────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  _ARouter (内部实现)                     │
│  - LogisticsCenter：路由表、分组加载                      │
│  - Warehouse：路由/服务/拦截器 存储                       │
└────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 注解处理器    │  │ 拦截器链     │  │ 降级策略      │
│ 编译期生成   │  │ 可扩展       │  │ DegradeService│
└──────────────┘  └──────────────┘  └──────────────┘

5.2 LogisticsCenter 路由表加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 初始化时通过插件扫描 Dex 中的特定类
public static void init(Context context) {
    try {
        // 获取所有 ARouter 生成的类：ARouter$$Root$$xxx
        Set<String> routerMap = ClassUtils.getFileNameByPackageName(
            context, ROUTE_ROOT_PACKAGE);
        for (String className : routerMap) {
            if (className.startsWith(ROUTE_ROOT_PACKAGE + DOT + SDK_NAME + SEPARATOR + SUFFIX_ROOT)) {
                ((IRouteRoot) Class.forName(className).getConstructor().newInstance())
                    .loadInto(Warehouse.groupsIndex);
            }
        }
        // 分组按需加载，避免启动时加载全部
    } catch (Exception e) {
        throw new HandlerException("ARouter init logistics center exception");
    }
}

5.3 拦截器机制

1
2
3
4
5
6
7
8
9
10
11
12
@Interceptor(priority = 8)
class LoginInterceptor : IInterceptor {
    override fun process(postcard: Postcard, callback: InterceptorCallback) {
        if (postcard.extra == NEED_LOGIN && !UserManager.isLoggedIn()) {
            // 未登录，拦截并跳转登录
            ARouter.getInstance().build("/user/login").navigation()
            callback.onInterrupt(null)
        } else {
            callback.onContinue(postcard)
        }
    }
}

六、实际项目应用案例

6.1 某电商 App 组件化拆分

1
2
3
4
5
6
7
8
9
10
11
app (壳工程)
├── module_home          # 首页
├── module_product       # 商品详情
├── module_cart          # 购物车
├── module_order         # 订单
├── module_user          # 用户中心
├── module_payment       # 支付
├── module_share         # 分享（可复用）
├── module_analytics     # 埋点（可复用）
├── common_router        # ARouter 封装
└── common_base          # 网络/缓存/UI 基础库

收益：

  • 编译时间：全量 6min → 单模块 1min
  • 4 个业务线可并行开发，Git 冲突减少 60%
  • ShareModule、AnalyticsModule 复用到多个 App

6.2 路由表设计实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 统一路由 Path 常量
object RouterPath {
    const val ORDER_LIST = "/order/list"
    const val ORDER_DETAIL = "/order/detail"
    const val USER_LOGIN = "/user/login"
    const val USER_PROFILE = "/user/profile"
}

// 封装便捷方法
object Router {
    fun toOrderList(userId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_LIST)
            .withString("userId", userId)
            .navigation()
    }

    fun toOrderDetail(orderId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_DETAIL)
            .withString("orderId", orderId)
            .navigation()
    }
}

6.3 解耦实践：避免循环依赖

错误示例：

1
2
module_order -> module_user (获取用户信息)
module_user  -> module_order (跳转订单列表)

形成循环依赖，Gradle 编译失败。

正确做法：

1
2
module_order -> common_router
module_user  -> common_router

需要「用户信息」时，Order 通过 ARouter.getInstance().navigation(IUserService::class.java) 获取；需要「跳转订单」时，User 通过 ARouter.getInstance().build("/order/list").navigation() 跳转。

6.4 模块化 + 插件化组合：Dynamic Feature 实践

某资讯 App 将「小说」「漫画」等非核心功能做成 Dynamic Feature，用户首次进入时提示下载：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 检查模块是否已安装
fun isModuleInstalled(moduleName: String): Boolean {
    return SplitInstallManagerFactory.create(context)
        .installedModules.contains(moduleName)
}

// 进入小说模块前检查
fun openNovelModule() {
    if (isModuleInstalled("novel")) {
        startActivity(Intent(this, NovelActivity::class.java))
    } else {
        showDownloadDialog {
            installDynamicModule("novel")
        }
    }
}

七、最佳实践与注意事项

7.1 模块拆分原则

  • 高内聚低耦合：模块内聚度高，模块间依赖少
  • 按业务边界拆分：参考 DDD 的 Bounded Context
  • 基础组件下沉：网络、缓存、日志等抽成 common_base
  • 渐进式演进：先模块化再组件化，避免一步到位导致成本过高

7.2 常见坑与规避

问题 原因 规避
编译顺序错误 模块间隐式依赖 严格检查 build.gradle，用 ./gradlew :module_x:dependencies 检查
路由表膨胀 所有页面都注册路由 仅对外暴露的页面注册，内部页面用 startActivity
启动变慢 初始化时加载全部路由 使用分组按需加载（ARouter 已支持）
R 文件冲突 多模块资源 ID 冲突 在 build.gradle 中设置 resourcePrefix "module_user_"
插件化兼容性 不同厂商 ROM 限制 优先使用 Dynamic Feature，第三方框架需充分测试

7.3 R 文件与资源隔离

1
2
3
4
// 各业务模块 build.gradle 中
android {
    resourcePrefix "user_"   // 资源必须以 user_ 开头
}

7.4 架构演进路线图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Phase 1: 模块化
├── 拆分为 Gradle 多模块
├── 建立 common_base、common_router
└── 模块间通过接口通信

Phase 2: 组件化
├── 引入 ARouter 路由
├── 服务发现替代直接依赖
└── 支持单模块独立运行调试

Phase 3: 插件化（可选）
├── 非核心功能改为 Dynamic Feature
├── 或引入 RePlugin/Shadow 做完整插件化
└── 按需下载、热更新

八、总结

架构 适用场景 核心手段
模块化 中小型 App、团队 < 10 人 Gradle 多模块、接口、依赖配置
组件化 中大型 App、多业务线并行 ARouter、服务发现、单模块调试
插件化 需要动态化、热更新、包体积优化 Dynamic Feature、RePlugin、Shadow

架构没有银弹，需结合团队规模、业务复杂度、迭代节奏选择合适方案。建议从模块化起步，随着复杂度提升再逐步演进到组件化，插件化则按实际需求谨慎引入。

参考资源

Posted Updated Mobile / Android25 minutes read (About 3756 words)

Android 核心组件与核心设计思想

由浅入深，从四大组件、应用骨架到设计哲学与最佳实践，系统梳理 Android 核心组件体系与架构思想

一、基本概念

1.1 什么是 Android 核心组件？

Android 核心组件是系统提供的、用于构建应用的基本构建块。应用由多个组件组成，组件之间通过 Intent 和 Binder 等机制协作，由系统负责创建、调度和生命周期管理。

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────────────────┐
│                    Android 应用 = 组件的组合与协作                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   四大组件                                                                 │
│   Activity / Service / BroadcastReceiver / ContentProvider               │
│         │                                                                 │
│         ▼                                                                 │
│   Intent（意图）──► 组件间通信、启动、数据传递                              │
│   Context（上下文）──► 访问资源、启动组件、获取系统服务                      │
│   Application ──► 进程级单例，应用全局状态与初始化                          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

1.2 为什么是「组件化」？

Android 没有「一个 main 入口跑到底」的传统应用模型，而是采用 组件化 + 系统调度：

设计点 说明
可复用 任意应用可通过 Intent 启动其他应用的 Activity（如调起相机、地图），无需链接其代码
可替换 同一种组件类型可有多个实现（如多个浏览器），用户或系统可选择
生命周期由系统管 组件由系统创建与销毁，便于在内存紧张时回收、在配置变更时重建
安全与隔离 组件运行在应用进程内，通过权限与 Intent 过滤控制谁能调谁

二、四大核心组件

2.1 Activity：界面与用户交互

Activity 代表一个「界面」或「屏幕」。用户看到的每一个全屏/窗口化界面，通常对应一个 Activity（或 Fragment 承载的视图）。

要点 说明
职责 提供 UI、处理用户输入、与用户交互
生命周期 onCreate → onStart → onResume → (运行中) → onPause → onStop → onDestroy
启动方式 其他 Activity 或应用通过 startActivity(Intent) 启动
任务栈 多个 Activity 组成「返回栈」，Back 键按栈顶依次退出 
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────────────┐
│  Activity 典型生命周期（简化）                                             │
│                                                                          │
│  创建 ──► onCreate() ──► onStart() ──► onResume() ──► 可见且可交互        │
│                                              │                           │
│                                              ▼                           │
│  切到后台 / 被遮挡  ──► onPause() ──► onStop()                            │
│                                              │                           │
│  再次回到前台  ──► onRestart() ──► onStart() ──► onResume()               │
│                                                                          │
│  销毁  ──► onDestroy()                                                    │
└─────────────────────────────────────────────────────────────────────────┘
  • 与 Fragment 的关系：一个 Activity 可包含多个 Fragment，Fragment 是「界面片段」，用于在同一个 Activity 内做模块化 UI 与复用。

2.2 Service：后台任务与长期运行

Service 用于在「无界面」的情况下执行长时间运行的任务，或为其他组件提供后台能力（如播放音乐、下载、同步）。

类型 说明 典型场景
Started Service 由 startService() 启动，可长期运行直到 stopSelf() 或 stopService() 音乐播放、下载、上传
Bound Service 由 bindService() 绑定，为其他组件提供 C/S 式接口，无客户端绑定后可由系统回收 本地 SDK、数据服务、AIDL 服务
  • 生命周期：onCreate → onStartCommand（Started）或 onBind（Bound）→ 运行 → onUnbind / onDestroy。
  • 前台服务：若需长时间在后台运行且不被系统轻易杀死，可调用 startForeground() 并显示持久通知，符合系统对「前台服务」的规范。

2.3 BroadcastReceiver：事件广播与响应

BroadcastReceiver 用于接收系统或应用发出的「广播」（如开机完成、网络变化、电量低、自定义事件），并做轻量级响应。

要点 说明
注册方式 静态注册（AndroidManifest.xml）或动态注册（代码中 registerReceiver）
执行 主线程、短时执行；耗时逻辑应交给 Service 或 WorkManager
有序广播 可指定优先级与「截断」传播（abortBroadcast）

常见系统广播：ACTION_BOOT_COMPLETED、ACTION_BATTERY_LOW、CONNECTIVITY_ACTION 等。

2.4 ContentProvider：数据抽象与跨进程共享

ContentProvider 对数据提供统一的「增删改查」接口（类似小型数据库 API），并支持跨应用、跨进程访问，是 Android 中「数据共享」的标准方式。

要点 说明
职责 封装数据源（SQLite、文件、内存、网络），对外提供 URI 与 Cursor/ContentValues API
跨进程 底层通过 Binder 暴露，其他应用通过 ContentResolver 访问，无需直接依赖实现方
权限 可在 AndroidManifest 中为 Provider 声明读写权限，由系统做权限校验

系统示例：通讯录、媒体库、设置等，均通过 ContentProvider 暴露给其他应用。

三、支撑性核心：Intent、Context、Application

3.1 Intent：意图与组件间通信

Intent 表示「要做的一件事」或「要传递的一包信息」，用于启动 Activity/Service、发送广播，并携带数据与标志。

类型 说明 典型用法
显式 Intent 指定 ComponentName（包名 + 类名），明确启动哪个组件 应用内页面跳转、指定 Service
隐式 Intent 只指定 action、category、data（可选），由系统根据各组件声明的 <intent-filter> 匹配 调起相机、分享、打开链接、跨应用启动 
1
2
显式：我知道要启动谁 → setComponent / setClassName
隐式：我只描述「要做什么」→ setAction / addCategory / setData，系统找合适的组件
  • Intent 可携带：Bundle 数据、Extra、Flags（如 FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_SINGLE_TOP）等，是组件间解耦通信的载体。

3.2 Context：上下文与资源访问

Context 是「当前组件/应用所在环境」的抽象，提供：

  • 访问应用资源（布局、字符串、drawable、主题等）
  • 启动组件（startActivity、startService、sendBroadcast）
  • 获取系统服务（getSystemService：如 LayoutInflater、ActivityManager、LocationManager）
  • 访问应用专属目录与 SharedPreferences 等
常见实现 说明
Activity Activity 本身是 Context，且带有「界面/任务」相关能力（如 startActivityForResult）
Application 进程级单例 Context，生命周期等于进程，适合做全局初始化与单例持有
Service Service 也是 Context，但无界面相关 API

注意：长时间持有 Activity 的 Context 容易导致内存泄漏（如静态变量引用 Activity），在异步回调中应避免；可改用 Application Context 或弱引用。

3.3 Application：应用级单例

Application 在进程启动时由系统创建，且每个进程只有一个实例。常用作：

  • 应用级初始化（SDK、全局配置、数据库等）
  • 全局单例或依赖注入容器的持有
  • 实现 Application 级别的生命周期回调（如 onConfigurationChanged）

在 AndroidManifest.xml 中通过 <application android:name=".MyApplication"> 指定自定义子类。

四、核心设计思想

4.1 组件化与「应用即组件集合」

Android 不强调「一个程序从 main 开始跑」，而是强调：

  • 应用由多个组件构成，每个组件有明确类型（Activity/Service/…）和声明（AndroidManifest）。
  • 入口是「可被系统或其它应用调用的组件」：例如 LAUNCHER Activity、可被隐式 Intent 匹配的 Activity/Service。
  • 组件之间通过 Intent 解耦：调用方只表达「意图」，不直接依赖实现类，便于复用与替换。
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────────────────┐
│  组件化思想：应用 = 组件 + 声明 + 意图驱动                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   AndroidManifest.xml 声明组件与 Intent-Filter                            │
│         │                                                                 │
│         ▼                                                                 │
│   系统 / 其他应用  ──► 发出 Intent  ──► 系统解析  ──► 创建并启动对应组件     │
│                                                                          │
│   同一「动作」可有多个实现（如多个浏览器），用户或系统选择其一               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

4.2 生命周期由系统托管

组件的创建、暂停、恢复、销毁由 系统 根据用户行为、系统资源、配置变更（如旋转、多窗口、语言切换）统一调度：

  • 开发者实现生命周期回调（如 Activity 的 onPause/onResume），在「合适的时机」保存状态、释放资源、恢复 UI。
  • 系统可在内存紧张时回收后台组件；配置变更时销毁并重建 Activity，通过 onSaveInstanceState / ViewModel 等恢复状态。

这种设计把「何时创建/销毁」交给系统，应用只响应「已经发生」的生命周期事件，便于多任务与资源管理。

4.3 安全与权限模型

  • 进程隔离：每个应用默认运行在独立进程，内存与执行空间隔离。
  • 组件级权限：可在 AndroidManifest 中为 Activity/Service/ContentProvider 等声明 android:permission，调用方需具备相应权限才能启动或访问。
  • 运行时权限：危险权限（如相机、位置、存储）需在运行时向用户申请，用户同意后应用才可使用。
  • Intent 与导出：组件可设为 android:exported="true/false"，控制是否允许其他应用通过隐式 Intent 调起。

4.4 多任务与任务栈

  • 任务（Task）：通常对应用户概念里的「一个应用的一组界面」，由一组 Activity 的栈组成。
  • 启动模式：Activity 的 launchMode（standard、singleTop、singleTask、singleInstance）以及 Intent 的 Flags 共同决定「新 Activity 如何入栈、是否复用已有实例」，从而影响返回栈行为与多任务表现。

五、从设计思想到最佳实践

5.1 用 Intent 做解耦

  • 应用内跳转：可用显式 Intent，也可用隐式 Intent + 自定义 action，便于后续替换实现或做 Deep Link。
  • 跨应用能力：尽量用系统或公共的 action/data 约定（如 VIEW + http/https），或在自己的 Provider/Activity 上声明清晰的 intent-filter，便于被系统或其他应用发现和调起。

5.2 生命周期与状态保存

  • 短时状态：在 onSaveInstanceState 中保存，在 onCreate/onRestoreInstanceState 中恢复。
  • 界面相关数据：使用 ViewModel + LiveData/StateFlow，在配置变更时保留，避免在 Activity 里堆业务状态。
  • 释放资源：在 onPause/onStop 中暂停耗时操作、释放监听与引用，在 onDestroy 中做最终清理，避免泄漏。

5.3 Service 与后台行为规范

  • 短时任务：优先用 WorkManager 或 协程 + 应用前后台状态，避免长时间占住 Service。
  • 需要长时间运行且用户可感知（如音乐播放、导航）：使用 前台 Service，并按规定显示通知。
  • 避免在 BroadcastReceiver 中做重活：应启动 Service 或提交到 WorkManager。

5.4 架构分层与组件角色

  • Activity/Fragment：只做 UI 与用户输入，将业务与数据交给 ViewModel 或 Presenter。
  • ViewModel：持有界面状态与业务逻辑入口，不持有 Context/View，便于测试与复用。
  • Repository / UseCase：封装数据来源（网络、本地、ContentProvider），对上层提供统一接口。
  • ContentProvider：仅在需要「跨应用/跨进程共享数据」时使用；应用内本地数据可用 Room + DAO 等，不必强行上 Provider。

六、小结

主题 要点
四大组件 Activity（界面）、Service（后台）、BroadcastReceiver（广播）、ContentProvider（数据抽象与跨应用共享）
支撑核心 Intent（意图与组件通信）、Context（资源与系统服务）、Application（进程级单例）
设计思想 组件化、系统托管生命周期、Intent 驱动与解耦、安全与权限、任务栈与多任务
实践方向 善用 Intent 解耦、重视生命周期与状态保存、规范使用 Service 与后台、UI 与业务分层

理解「应用即组件的组合」「生命周期由系统托管」「Intent 表达意图、系统负责匹配与调度」，就能更好地把握 Android 核心组件与设计思想，并在此基础上用好 ViewModel、WorkManager、Jetpack 等现代组件与工具。

Posted Updated Mobile / iOS25 minutes read (About 3690 words)

iOS 开发中的热更新

由浅入深，从基本概念到源码解析，带你全面掌握 iOS 热更新的原理、方案与实战理、方案与实战

一、什么是热更新？为什么需要它？

1.1 从「发版周期」说起

传统原生 iOS 开发的痛点：

  • 审核周期长：App Store 审核通常需要 1～3 天，紧急 Bug 无法及时修复
  • 版本割裂：用户更新率有限，线上可能同时存在多个旧版本
  • 迭代成本高：每次改动都要重新打包、提审、等待上线

热更新（Hot Update） 的核心诉求是：在不发新版本、不通过 App Store 审核的前提下，动态更新应用逻辑与资源。

1.2 热更新的分类

类型 说明 典型场景
资源热更新 更新图片、配置、文案等非代码资源 活动页、Banner、AB 实验
脚本热更新 更新 JavaScript/Lua 等脚本，在解释器中执行 RN、Weex、游戏 Lua
原生热修复 通过 Runtime 等手段替换/修补 OC 方法 紧急 Bug 修复（受政策限制）

1.3 热更新能解决什么问题？

  • 紧急 Bug 修复：线上崩溃、逻辑错误，可快速下发补丁
  • 业务快速迭代：活动页、营销逻辑，无需等审核
  • 灰度与回滚：小范围验证后全量，出问题可秒级回滚

二、核心原理

2.1 动态执行：热更新的基础

iOS 支持多种「运行时执行代码」的方式，这是热更新的技术前提：

1
2
3
4
5
6
7
┌─────────────────────────────────────────────────────────────┐
│                    热更新技术栈层次                           │
├─────────────────────────────────────────────────────────────┤
│  应用层      │  下发 JS/Lua/配置 → 解释执行 / 加载资源         │
│  中间层      │  JavaScriptCore / Lua VM / 自研解释器          │
│  系统层      │  Runtime、dlopen、performSelector 等           │
└─────────────────────────────────────────────────────────────┘

不同方案对「动态执行」的依赖程度不同，也决定了其合规性。

2.2 两类热更新思路

思路 机制 代表方案 Apple 态度
脚本在容器内执行 使用系统提供的 JS 引擎（如 JavaScriptCore）执行脚本，不直接修改原生代码 React Native OTA、Weex 原则上允许
直接 Hook 原生方法 通过 Runtime、libffi 等替换 OC 方法的 IMP，或动态下发可执行代码 JSPatch、WaxPatch 明确禁止

2.3 Apple 3.3.2 条款与审核边界

Apple 开发者协议 3.3.2 明确规定：

应用不得包含、提供或使用未包含在应用中的可执行代码的下载、安装或执行机制。

被严格禁止的：

  • 下载并执行任意原生代码（如通过 dlopen、dlsym 动态加载）
  • 使用可调用原生 API 的脚本引擎（如 JSPatch 通过 JS 调用 performSelector:、修改 IMP）
  • 绕过审核、改变应用主要功能或目的的动态能力

允许的例外：

  • 使用 WebKit 或 JavaScriptCore 执行脚本
  • 前提：不改变应用的主要功能或目的，与提交版本及宣传描述相符
  • 典型：React Native 的 JS Bundle 热更新、游戏内 Lua 脚本（在引擎容器内运行）

核心差异：Apple 禁止的是「能绕过审核、调用私有 API、实质改变应用功能」的方案，而非热更新本身。使用系统 JS 引擎、仅更新业务逻辑（不修改原生层）的方案，在合理范围内通常可接受。

三、主流方案概览

3.1 方案对比

方案 类型 合规性 能力边界 适用场景
React Native OTA 脚本热更新 ✅ 合规 只更新 JS 层 RN 项目
CodePush 脚本热更新 ✅ 合规 RN/Weex JS Bundle 需完善 OTA 能力的 RN 项目
JSPatch 原生热修复 ❌ 禁止 可替换任意 OC 方法 已弃用
TTDFKit (TTPatch) 原生热修复 ⚠️ 风险 基于 libffi 动态调用 内测/企业包
BuglyHotfix 原生热修复 ⚠️ 风险 兼容 JSPatch 脚本 企业级、需完整工具链
Lua + 游戏引擎 脚本热更新 ✅ 合规 游戏逻辑在引擎内 游戏项目

3.2 选型建议

项目类型 推荐方案
React Native 应用 CodePush 或自建 OTA 服务
纯原生 + 需热修 优先考虑架构调整（如 RN/Flutter 化），慎用原生热修
游戏 引擎自带 Lua/脚本热更
企业内部分发 可评估 TTDFKit、BuglyHotfix，注意合规

四、React Native OTA 热更新

4.1 基本原理

RN 的 UI 与业务逻辑运行在 JavaScript 中，而 JS 可由 JavaScriptCore（或 Hermes）在运行时执行。因此，只需将新的 JS Bundle 下发到设备，启动时优先加载该 Bundle，即可实现热更新，无需修改原生代码。

1
2
3
4
5
6
7
8
┌─────────────────────────────────────────────────────────────┐
│                    RN 热更新流程                              │
├─────────────────────────────────────────────────────────────┤
│  1. 服务端：打包 JS Bundle（含业务逻辑）                       │
│  2. 下发：通过 HTTP/CDN 将 Bundle 下发到客户端                 │
│  3. 客户端：存储到本地（如 Document 目录）                     │
│  4. 启动：RCTBridge 优先加载本地 Bundle，而非打包进 App 的     │
└─────────────────────────────────────────────────────────────┘

4.2 CodePush 架构

CodePush 是微软推出的 RN 热更新方案，由三部分组成：

组件 职责
code-push-server 服务端：身份认证、更新包存储、版本校验、下载、统计
code-push-cli 命令行：登录、打包、部署
react-native-code-push 客户端 SDK：检测更新、下载、安装、上报

版本策略：支持 semver 约束，例如 ^1.2.3 表示 >=1.2.3 <2.0.0 的原生版本可收到该更新。

4.3 集成示例

1
2
3
# 安装
npm install --save react-native-code-push
cd ios && pod install
1
2
3
4
5
6
7
8
9
10
11
// AppDelegate.m - 指定 Bundle 加载路径
#import <CodePush/CodePush.h>

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
#else
  return [CodePush bundleURL];  // 生产环境从 CodePush 获取
#endif
}
1
2
3
4
5
6
7
// 检查更新
import codePush from 'react-native-code-push';

codePush.sync({
  updateDialog: { title: '发现新版本' },
  installMode: codePush.InstallMode.IMMEDIATE,
});

4.4 自建 OTA 简要思路

若不使用 CodePush，可自建：

  1. 服务端：提供接口，根据 appVersion、binaryVersion 返回可用的 Bundle 信息（URL、hash、是否强制）
  2. 客户端：启动时请求接口，若有新版本则下载到本地
  3. 加载：修改 RCTRootView 的 bridge 初始化，优先从本地路径加载 JS Bundle

五、JSPatch 原理与源码解析（历史与教育意义）

⚠️ JSPatch 已被 Apple 明确禁止，此处仅作原理与源码层面的学习参考。

5.1 核心思想

JSPatch 通过 JavaScript 调用 Objective-C，利用 OC 的 Runtime 动态性，实现：

  1. 用 JS 写「补丁逻辑」
  2. 下发 JS 到客户端
  3. 在 JavaScriptCore 中执行
  4. JS 通过桥接层调用 OC Runtime，替换方法实现（IMP）

5.2 JS 调用 OC 的底层机制

OC 是「消息型」语言，方法调用本质是 objc_msgSend(receiver, selector, ...)。JSPatch 的做法是：

  • JS 侧：调用 require('UIView').alloc().init()
  • 桥接层：将 UIView、alloc、init 等字符串传给 OC
  • OC 侧：通过 NSClassFromString、class_getInstanceMethod 等 Runtime API 获取类和方法，用 objc_msgSend 或 NSInvocation 完成调用
1
2
3
4
5
6
7
8
9
10
11
JS: UIView.alloc().init()
       │
       ▼
JPEngine: 解析调用链 → 获取 Class、SEL
       │
       ▼
Runtime: objc_msgSend([UIView class], @selector(alloc))
         objc_msgSend(allocResult, @selector(init))
       │
       ▼
返回 OC 对象给 JS（封装为 JPBoxing 等结构）

5.3 方法替换（热修复）实现

热修复的关键是「替换方法的 IMP」：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 伪代码：JSPatch 方法替换思路
// 原方法：- (void)originalMethod;
// 新实现：在 JS 中定义，通过桥接调用

static void (^jsImplementation)(id, ...) = ...; // 从 JS 传过来的 block

IMP newIMP = imp_implementationWithBlock(^(id self, ...) {
    // 调用 JS 定义的逻辑
    jsImplementation(self, ...);
});

// 替换
Method m = class_getInstanceMethod(cls, @selector(originalMethod));
method_setImplementation(m, newIMP);

5.4 为何被禁止

JSPatch 能让 JS 间接调用任意 OC 方法，包括：

  • performSelector:
  • class_replaceMethod、method_setImplementation
  • 私有 API、系统内部方法

这相当于 绕过了 App Store 审核，可动态改变应用行为，因此被 Apple 明确列入违规。

六、TTDFKit / TTPatch 与 libffi

6.1 简介

TTDFKit（原 TTPatch）是基于 libffi 的 iOS 热修复方案，不依赖 JSPatch，但能力类似：

  • 方法替换、动态创建方法
  • 添加属性、支持 Block
  • 支持 JavaScript 脚本下发

6.2 libffi 的作用

libffi（Foreign Function Interface）用于在运行时根据函数签名动态调用 C 函数。OC 方法本质上也是 C 函数（带 self、_cmd 等参数），通过 libffi 可以：

  1. 根据 NSMethodSignature 得到参数类型、返回值类型
  2. 构造 ffi_cif（调用约定）
  3. 使用 ffi_call 调用目标 IMP

从而实现「用动态生成的逻辑替换原方法」。

6.3 合规性说明

TTDFKit 同样具备「动态修改原生方法」的能力，在正式上架 App Store 的包中使用的合规风险与 JSPatch 类似，更适用于企业内部或内测分发场景。

七、实战示例：RN 自建 OTA

7.1 服务端接口设计（简化）

1
2
3
4
5
6
7
8
// GET /api/ota/check?platform=ios&version=1.2.3&build=10
{
  "hasUpdate": true,
  "downloadUrl": "https://cdn.example.com/bundle/1.2.3.10.jsbundle",
  "hash": "abc123",
  "forceUpdate": false,
  "minVersion": "1.2.0"
}

7.2 客户端核心逻辑（示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// OTAManager.m
- (void)checkUpdate {
  NSString *url = [NSString stringWithFormat:
    @"https://api.example.com/ota/check?platform=ios&version=%@&build=%@",
    appVersion, buildNumber];
  // 发起请求，解析 hasUpdate、downloadUrl、forceUpdate
  // 若 hasUpdate，则下载到 Document/OTA/bundle.js
}

- (NSURL *)bundleURL {
  NSString *otaPath = [self otaBundlePath];
  if ([[NSFileManager defaultManager] fileExistsAtPath:otaPath]) {
    return [NSURL fileURLWithPath:otaPath];
  }
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
}

7.3 启动时加载

1
2
3
4
// AppDelegate.m
- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge {
  return [[OTAManager shared] bundleURL];
}

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

8.1 电商 App：活动页热更新

场景：大促活动页面布局、规则频繁调整，无法每次发版。

方案：使用 React Native 搭建活动页，通过 CodePush 下发 JS Bundle。活动开始前发布新版本，用户打开即可看到最新逻辑，无需等 App Store 审核。

效果：活动页迭代周期从 1～3 天缩短到几分钟，支持灰度与秒级回滚。

8.2 金融 App：合规前提下的热更新

场景：需要快速修复展示类 Bug（如文案错误、接口字段变更），但不能修改核心交易逻辑。

方案：

  • 交易、支付等核心流程保持纯原生，不热更
  • 非核心页面（资讯、活动、设置）采用 RN，通过 OTA 更新
  • 严格控制热更范围，符合「不改变应用主要功能」的审核边界

8.3 游戏：Lua 热更新

场景：Unity / Unreal / Cocos 等引擎，游戏逻辑用 Lua 编写。

方案：Lua 脚本存在服务端，启动时或进入场景时下载到本地，由引擎内嵌的 Lua VM 执行。不涉及原生代码动态替换，符合平台规则。

8.4 企业内包：JSPatch 替代方案

场景：内部分发、不通过 App Store，需要紧急修复原生 Bug。

方案：使用 TTDFKit 或 BuglyHotfix，下发 JS 补丁，替换有问题的 OC 方法。需注意仅用于内部分发场景，避免用于正式上架版本。

九、最佳实践与注意事项

9.1 合规优先

  • 上架 App Store 的应用：优先使用 RN OTA、CodePush 等脚本热更新，避免 JSPatch 类方案
  • 热更范围：尽量限制在业务逻辑、UI 展示，不触及支付、权限等敏感能力
  • 文档与描述：确保应用功能与审核描述一致，避免「隐藏能力」引起拒审

9.2 版本与兼容

  • 使用 语义化版本 约束可更新范围，避免旧版本收到不兼容的 Bundle
  • 做好 灰度：先小流量验证，再全量
  • 设计 回滚：保留上一版本 Bundle，出错时快速切回

9.3 安全与校验

  • 对 Bundle 做 哈希校验，防止篡改
  • 使用 HTTPS 下发，避免中间人攻击
  • 敏感逻辑不宜完全依赖热更，核心安全校验应留在原生

9.4 性能与体验

  • 启动时异步检查更新，不阻塞首屏
  • 大 Bundle 可做 差分更新，减少下载量
  • 明确 强制更新 与 静默更新 策略，平衡体验与覆盖率

十、总结

维度 要点
概念 热更新 = 不发版、动态更新逻辑/资源，分资源、脚本、原生三类
原理 依赖运行时执行（JS 引擎、Runtime、libffi），不同方案能力与合规性不同
政策 Apple 3.3.2 禁止下载执行可执行代码；JS 在 JavaScriptCore 内执行、不改变主要功能的可接受
推荐 RN 项目用 CodePush/自建 OTA；纯原生慎用原生热修，优先考虑架构升级
实践 合规优先、版本约束、灰度回滚、安全校验

热更新能显著提升迭代效率，但必须在 合规、安全、可维护 的前提下使用。理解原理与边界，才能做出正确的技术选型与实现。

Posted Updated Mobile / iOS16 minutes read (About 2465 words)

iOS 开发中的 RunLoop

由浅入深，从基本概念到源码解析，带你全面理解 iOS 事件循环机制

一、什么是 RunLoop？

1.1 从 Event Loop 说起

通常，一个线程一次只能执行一个任务，任务完成后线程就会退出。但在 GUI 应用中，我们需要一种机制：线程能够随时处理事件或消息，并且在空闲时不会退出。这种机制称为 Event Loop（事件循环）。

1
2
3
4
5
6
7
function main
    initialize()
    while message != quit
        message := get_next_message()
        process_message(message)
    end while
end function

Event Loop 的核心问题是：

  • 如何管理事件/消息
  • 如何让线程在没有任务时休眠，避免 CPU 空转
  • 如何在事件到来时唤醒线程处理

1.2 RunLoop 是什么？

RunLoop 是苹果在 OSX/iOS 上对 Event Loop 的实现。它是一个对象，负责：

  • 管理需要处理的事件/消息
  • 提供入口函数执行「接收消息 → 等待 → 处理」的循环
  • 在没有事件时让线程休眠，有事件时唤醒并分发处理

RunLoop 从 Input Sources 和 Timer Sources 接收事件，然后在线程中执行对应的 Handler。

1.3 NSRunLoop 与 CFRunLoop

苹果提供了两层 API：

类型 说明 线程安全
NSRunLoop 基于 CFRunLoop 的 OC 封装，面向对象 API 否
CFRunLoopRef CoreFoundation 的 C 实现 是

日常开发多用 NSRunLoop，底层和性能相关则直接用 CFRunLoop。

二、RunLoop 与线程

2.1 一一对应关系

  • RunLoop 和线程是 一一对应 的
  • 每个线程（含主线程）都有唯一的 RunLoop
  • RunLoop 在 首次获取 时创建，线程结束时 销毁
  • 只能在 对应线程内部 获取该线程的 RunLoop（主线程除外）
1
2
3
4
5
// 获取当前线程的 RunLoop
let runLoop = RunLoop.current

// 获取主线程 RunLoop（任意线程可调用）
let mainRunLoop = RunLoop.main

2.2 主线程 vs 子线程

  • 主线程：应用启动时，主线程 RunLoop 自动创建并运行
  • 子线程：默认不启动 RunLoop，需要主动调用 run 才会进入事件循环
1
2
3
4
5
6
7
// 主线程 RunLoop 自动运行，无需手动启动
// 子线程 RunLoop 默认不运行
Thread.detachNewThread {
    let runLoop = RunLoop.current
    runLoop.add(Port(), forMode: .default)  // 必须有 source，否则 run 会立即退出
    runLoop.run()
}

三、核心组件

3.1 Run Loop Source（事件源）

RunLoop 从两类 Source 接收事件：

类型 名称 特点 典型场景
Source0 Custom Input Source 需手动标记为待处理，不主动唤醒线程 UIEvent、CFSocket、普通回调
Source1 Port-Based Source 基于 Mach Port，可主动唤醒 RunLoop 系统触摸事件、进程间通信 
1
2
Source0：用户事件、自定义事件 → 需外部调用 CFRunLoopSourceSignal 标记
Source1：系统 Port 事件 → 内核可主动唤醒线程

3.2 Run Loop Timer（定时器）

Timer 本质是 基于 Port 的 Source，所有 Timer 共用同一个「Mode Timer Port」。常见实现如 NSTimer、CADisplayLink。

3.3 Run Loop Observer（观察者）

Observer 不处理事件，而是 观察 RunLoop 的状态变化，可监控以下活动：

1
2
3
4
5
6
7
8
9
// CFRunLoopActivity 定义
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0),  // 即将进入 Loop
    kCFRunLoopBeforeTimers  = (1UL << 1),  // 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL << 2),  // 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5),  // 即将进入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6),  // 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL << 7),  // 即将退出 Loop
}

四、Run Loop Mode

4.1 什么是 Mode？

Mode 是 RunLoop 的「工作模式」。一个 RunLoop 包含多个 Mode，每个 Mode 下有各自的 Source、Timer、Observer。同一时刻 RunLoop 只运行在一个 Mode 下，只处理该 Mode 里的 Source/Timer/Observer。

这样可以把不同场景的事件隔离，例如：

  • 默认模式下处理普通事件
  • 滑动 ScrollView 时切到 UITrackingRunLoopMode，只处理触摸，保证滑动流畅

4.2 常见 Mode

Mode 说明
NSDefaultRunLoopMode 默认模式，App 空闲时主线程通常在此模式
UITrackingRunLoopMode 界面追踪模式，ScrollView 滑动时切换到此
NSRunLoopCommonModes 占位符，表示「Common 模式集合」

NSRunLoopCommonModes 默认包含 NSDefaultRunLoopMode 和 UITrackingRunLoopMode。把 Timer/Source 加到 CommonModes，会在上述两种模式切换时都得到回调。

4.3 常见问题：Timer 滑动时失效

1
2
3
4
5
6
7
8
// 仅加入 DefaultMode：滑动 UITableView 时 Timer 暂停
let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
    print("tick")
}
RunLoop.main.add(timer, forMode: .default)

// 加入 CommonModes：滑动时 Timer 继续触发
RunLoop.main.add(timer, forMode: .common)

4.4 数据结构示意

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct __CFRunLoopMode {
    CFStringRef _name;            // Mode 名称，如 @"kCFRunLoopDefaultMode"
    CFMutableSetRef _sources0;    // Source0 集合
    CFMutableSetRef _sources1;    // Source1 集合
    CFMutableArrayRef _observers; // Observer 数组
    CFMutableArrayRef _timers;    // Timer 数组
    ...
};

struct __CFRunLoop {
    CFMutableSetRef _commonModes;     // 标记为 Common 的 Mode 集合
    CFMutableSetRef _commonModeItems; // 加到 Common 的 Source/Timer/Observer
    CFRunLoopModeRef _currentMode;    // 当前 Mode
    CFMutableSetRef _modes;           // 所有 Mode
    ...
};

commonModeItems 会被自动同步到所有 Common Mode 中，这就是把 Timer 加到 .common 能解决滑动暂停的原因。

五、RunLoop 工作流程（源码级）

5.1 整体流程

CFRunLoopRun 的简化调用链：

1
2
3
void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}

核心逻辑在 CFRunLoopRunSpecific 里，内部是一个 do-while 循环，大致步骤如下：

5.2 核心源码流程

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
50
51
52
53
54
55
56
57
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    if (__CFRunLoopModeIsEmpty(currentMode)) return;  // Mode 为空则直接返回

    // 1. 通知 Observers：即将进入 Loop
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);

    __CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
        do {
            // 2. 通知 Observers：即将处理 Timer
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);

            // 3. 通知 Observers：即将处理 Source0
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);

            // 4. 执行被加入的 Block
            __CFRunLoopDoBlocks(runloop, currentMode);

            // 5. 处理 Source0
            sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
            __CFRunLoopDoBlocks(runloop, currentMode);

            // 6. 若有 Source1 就绪，处理 Source1 消息
            if (__Source0DidDispatchPortLastTime) {
                if (__CFRunLoopServiceMachPort(dispatchPort, &msg))
                    goto handle_msg;
            }

            // 7. 通知 Observers：即将进入休眠
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }

            // 8. 调用 mach_msg 等待消息，线程休眠，直到被唤醒
            __CFRunLoopServiceMachPort(waitSet, &msg, ...);
            // 唤醒条件：Port 事件、Timer 到期、超时、手动唤醒

            // 9. 通知 Observers：刚刚被唤醒
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);

        handle_msg:
            if (msg_is_timer) {
                __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time());
            } else if (msg_is_dispatch) {
                __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);  // GCD 主队列
            } else {
                __CFRunLoopDoSource1(runloop, currentMode, source1, msg);  // Source1
            }

            __CFRunLoopDoBlocks(runloop, currentMode);

        } while (retVal == 0);  // 根据 retVal 决定是否继续循环
    }

    // 10. 通知 Observers：即将退出 Loop
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

5.3 流程简图

1
2
3
4
5
6
Entry → BeforeTimers → BeforeSources → DoBlocks → DoSources0
                                                    ↓
Exit  ← BeforeExit   ← AfterWaiting  ← mach_msg 等待
       ↑                           ↓
       └──────── handle_msg ───────┘
                 (Timer / Source1 / Dispatch)

六、基于 RunLoop 的系统功能

6.1 AutoreleasePool

主线程 RunLoop 中注册了两个 Observer，回调都是 _wrapRunLoopWithAutoreleasePoolHandler：

时机 回调 作用
kCFRunLoopEntry _objc_autoreleasePoolPush() 创建自动释放池
kCFRunLoopBeforeWaiting _objc_autoreleasePoolPop() + Push 释放旧池并创建新池
kCFRunLoopExit _objc_autoreleasePoolPop() 退出时释放池

因此主线程上的事件回调、Timer 回调等都会在 AutoreleasePool 包裹下执行，一般无需手动创建。

6.2 事件响应链路

  1. 硬件事件（触摸、按键等）→ IOKit 生成 IOHIDEvent
  2. SpringBoard 接收，通过 Mach Port 转发给 App
  3. 主线程 RunLoop 的 Source1 回调 __IOHIDEventSystemClientQueueCallback
  4. 内部调用 _UIApplicationHandleEventQueue() 包装成 UIEvent
  5. 经 hitTest、响应链，最终到达对应 Target-Action 或 touches 方法

6.3 手势识别

  • _UIApplicationHandleEventQueue() 识别到手势时，会打断 touches 序列
  • 将 UIGestureRecognizer 标记为待处理
  • 在 kCFRunLoopBeforeWaiting 的 Observer _UIGestureRecognizerUpdateObserver 中统一执行手势回调

6.4 界面更新

  • 调用 setNeedsLayout / setNeedsDisplay 后，视图被标记为待更新
  • 在 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 的 Observer 中，Core Animation 执行实际布局和绘制

6.5 PerformSelector

performSelector:afterDelay: 和 performSelector:onThread: 内部都会创建 Timer 并加入对应线程的 RunLoop。若该线程没有 RunLoop 或 RunLoop 未运行，这些方法不会生效。

七、实战示例

7.1 常驻线程（如 AFNetworking）

子线程默认不跑 RunLoop，需要手动添加 Source 并 run：

1
2
3
4
5
6
7
8
9
10
class NetworkThread: Thread {
    override func main() {
        autoreleasepool {
            self.name = "AFNetworking"
            let runLoop = RunLoop.current
            runLoop.add(Port(), forMode: .default)  // 添加 Port 作为 Source，否则 run 会立即退出
            runLoop.run()
        }
    }
}
1
2
3
4
5
6
7
8
9
// AFNetworking 2.x 的经典实现
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}

7.2 使用 Observer 监控卡顿

通过观察主线程 RunLoop 状态，检测某个阶段耗时是否过长：

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
import UIKit

class RunLoopMonitor {
    private var observer: CFRunLoopObserver?
    private var semaphore: DispatchSemaphore
    private var timeout = true
    private let timeoutCount: Int = 5
    private var count = 0

    init() {
        semaphore = DispatchSemaphore(value: 0)
    }

    func start() {
        let activities: CFRunLoopActivity = [.beforeWaiting, .afterWaiting]
        var context = CFRunLoopObserverContext(
            version: 0,
            info: Unmanaged.passUnretained(self).toOpaque(),
            retain: nil,
            release: nil,
            copyDescription: nil
        )

        observer = CFRunLoopObserverCreate(
            kCFAllocatorDefault,
            activities.rawValue,
            true,
            0,
            { _, activity, info in
                guard let info = info else { return }
                let monitor = Unmanaged<RunLoopMonitor>.fromOpaque(info).takeUnretainedValue()
                monitor.handleObserverCallback(activity)
            },
            &context
        )

        CFRunLoopAddObserver(CFRunLoopGetMain(), observer, .commonModes)

        DispatchQueue.global().async { [weak self] in
            self?.monitor()
        }
    }

    private func handleObserverCallback(_ activity: CFRunLoopActivity) {
        if activity == .beforeWaiting || activity == .afterWaiting {
            count = 0
            timeout = false
        }
        semaphore.signal()
    }

    private func monitor() {
        while true {
            let result = semaphore.wait(timeout: .now() + 1)
            if result == .timedOut {
                if timeout {
                    count += 1
                    if count >= timeoutCount {
                        print("⚠️ 主线程可能发生卡顿")
                    }
                } else {
                    timeout = true
                    count = 0
                }
            }
        }
    }
}

7.3 在指定 RunLoop 模式执行任务

1
2
3
4
5
6
7
8
// 仅在 Default 模式执行
RunLoop.current.perform(#selector(doWork), target: self, argument: nil, order: 0, modes: [.default])

// 使用 CFRunLoop 添加 Block（iOS 10+）
CFRunLoopPerformBlock(CFRunLoopGetMain(), CFRunLoopMode.defaultMode.rawValue as CFString) {
    print("在 RunLoop 当前迭代中执行")
}
CFRunLoopWakeUp(CFRunLoopGetMain())

7.4 NSTimer 与 RunLoop

1
2
3
4
5
6
7
8
9
10
11
12
13
// scheduledTimer 会自动加入当前 RunLoop 的 Default 模式
let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
    print("tick")
}

// 若在子线程使用，需确保 RunLoop 在运行
DispatchQueue.global().async {
    let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
        print("tick")
    }
    RunLoop.current.add(timer, forMode: .default)
    RunLoop.current.run()  // 必须 run，否则 Timer 不会触发
}

八、常见面试要点

  1. RunLoop 和线程的关系：一一对应，主线程自动运行，子线程需手动启动。
  2. Source0 与 Source1：Source0 需手动标记；Source1 基于 Port，可主动唤醒。
  3. Mode 的作用：隔离不同场景的事件，滑动时切换到 UITrackingRunLoopMode 保证流畅。
  4. CommonModes：把 Timer/Source 加到 CommonModes 可在 Default 和 Tracking 下都收到回调。
  5. AutoreleasePool 与 RunLoop：主线程在 Entry、BeforeWaiting、Exit 时自动 Push/Pop。
  6. 卡顿监控思路：用 CFRunLoopObserver 监听主线程，结合超时判定卡顿。

九、参考

Follow

Links

Categories

Recents

Archives

Tags

AI1
Activity2
Algorithm7
Android9
Architecture5
ArkTS1
Backend1
Blockchain2
Browser1
Combine1
Component3
Components2
Concurrency1
Cpp1
Cross-Platform4
Dart2
Design Patterns1
DevOps1
EIP15591
Electron2
Ethereum5
Event Loop1
Fiber2
Flutter12
GCD1
Gas1
HarmonyOS4
Hooks2
Hot Update2
Image Loading1
Interview1
JSPatch1
JavaScript3
Jetpack Compose1
KMP1
Kotlin1
MCP1
Memory Safety1
Modular3
Multithreading1
Native Bridge1
Navigator2
Next.js1
Nginx1
Node.js1
Objective-C1
Optimization1
Performance2
Platform Channel2
React8
React Native3
Reactive1
Reactive Programming2
ReactiveCocoa1
Routing2
RunLoop1
Runtime1
Rust1
RxJava1
RxSwift2
SDWebImage1
Scheduling1
Service2
Skills1
Smart Contract1
Solana1
Solidity1
State Management4
Swift1
SwiftUI1
Systems Programming1
Taro1
Tools2
VSCode1
Viem1
Wagmi1
Wallet1
Web37
Workflow1
ethers.js2
go_router1
iOS14
npm1
代码审查1
跨平台1

Subscribe for updates

follow.it

×