把 Android / iOS / 鸿蒙（HarmonyOS） 之间的工程迁移交给「大模型 + 工具」时，真正决定上限的往往不是单次对话写得多漂亮，而是：上下文从哪来、结果怎么验、每一轮提交怎么收口。本文从实践角度串一条链路：用 MCP 把仓库与外部能力接到 Agent 上，再用 Skill 把「怎么评转换质量、怎么总结变更、怎么对照需求、怎么看代码质量」固化成可重复执行的检查步骤。

说明：下文中的「转换」泛指在统一业务语义下，把一侧平台的实现（Kotlin/Swift/ArkTS 等）迁到另一侧或生成可对照骨架；不是宣称存在某种全自动、零成本的万能翻译器。MCP 与 Skill 解决的是流程与门禁，不是替代架构决策与人工验收。

1. 问题长什么样

典型诉求可以概括成四类：

纯靠聊天窗口贴代码，很快会遇到：上下文截断、无法读全仓库、无法跑构建与静态检查、无法稳定对比两次提交的差异。这就是 MCP 要接进来的原因。

2. MCP 在这条链路里干什么

MCP（Model Context Protocol） 做的是：让模型通过标准协议调用「工具」和拉取「资源」，而不是把整台电脑或整库文件糊进提示词。

在跨端迁移/转换场景里，常见有价值的 MCP 能力包括（按优先级大致排序）：

1. 代码与版本：读文件、搜索符号、git diff / git log、关联 issue / 需求文档（若你们有对应 MCP 或 HTTP 封装）。
2. 构建与检查：触发 Gradle / xcodebuild / hvigor（鸿蒙）的非交互命令，采集编译错误与警告（需沙箱与安全策略）。
3. 静态分析：对接 linter、格式化结果、甚至你们内部的二进制接口规范检查脚本。
4. 知识库：设计文档、接口契约、历史 CR 结论——用 resource 或检索类工具喂给模型当约束，而不是当闲聊材料。

一张很粗的协作关系如下：

flowchart LR
  subgraph agent["Agent（IDE / CLI）"]
    A[对话与计划]
  end
  subgraph mcp["MCP 服务"]
    G[Git / 文件]
    B[构建与日志]
    L[Lint / 测试]
    D[需求与文档]
  end
  subgraph repo["工程仓库"]
    R[Android / iOS / Harmony 模块]
  end
  A --> G
  A --> B
  A --> L
  A --> D
  G --> R
  B --> R
  L --> R

要点：MCP 负责「能持续拿到真实状态」；模型负责在约束下改代码。没有 MCP，跨端转换很容易变成「语法像、跑不通」的演示。

项目实践里 MCP 真正帮上忙的一块

在自己项目里跑下来，MCP 带来的提效很实在的一点，是支撑 大块功能在端之间的直接互转：网络、状态、一条完整业务链路里的多个类/模块，在接好仓库与构建/日志之后，Agent 能按「功能点」连续改，而不是只在聊天里贴片段。这和「整仓库一键翻译」不是一回事，但已经能覆盖不少成块迁移的工作。

转换落地之后，仍然需要人按需求自己多走几遍：主路径、边界条件、各端差异（权限、后台、埋点）往往要手动点一点才暴露。这里不必讳言——人工走查仍是验收的一环。差别在于：一旦发现问题，把报错、堆栈、复现步骤丢回给 AI，在 MCP 能读到工程上下文的前提下，修一轮的成本明显低于从零手改。整体仍是：大功能先转过去 → 人按需求验收 → 卡点再交给 AI 迭代，提效很多，但预期是「加速器」，不是「免验收」。

3. 转换工作流建议（可落地的一版）

下面是一条在团队里较容易推广的最小闭环，可按你们 CI 成熟度裁剪。

flowchart TB
  Q[对齐需求与范围] --> S[建立对照表：模块/接口/平台差异]
  S --> T[分支策略：按端或按业务垂直切]
  T --> C[大功能点互转 + 本地构建]
  C --> H[人按需求走查多遍]
  H -->|发现问题| F[把现象与日志交给 AI 修复]
  F --> C
  H -->|通过| V[门禁：Skill 清单跑一遍]
  V -->|不通过| C
  V -->|通过| P[PR：说明对照与风险]

1. 对齐需求与范围：哪些类/模块要迁、哪些只做适配层、哪些必须行为一致（加密、存储、埋点）。
2. 对照表：把「Android 类 / iOS 类型 / ArkTS 组件」映射到同一张表，避免三端各写各的命名与语义漂移。
3. 分支：要么「一需求一分支三端子目录」，要么「按端拆分支但共享契约文档」——关键是 diff 可读、review 可追责。
4. 大功能点转换 + 构建优先：先争取「能编过、主链路能跑」；报错与日志进 Agent 上下文（MCP），便于迭代大块改动而不是零散粘贴。
5. 人工按需求走查：对照验收条目多点几遍；出问题再 提醒 AI 修（复现步骤 + 日志/截图），形成短闭环，而不是指望一次生成就结项。
6. 门禁再走 PR：下文 Skill 部分把这一步拆成可执行检查项。

4. 用 Skill 做「质量门禁」：评什么、怎么评

Skill 在这里不是替你做代码审查的人，而是把「每次该怎么审」写成稳定流程，让 Agent 和人类用同一套清单。可以与 .cursor/rules 分工：规则偏常驻约束，Skill 偏「进入迁移任务时按需加载」。

下面四类，对应你提到的诉求。

4.1 评估「转换质量」（对照与语义）

建议在 Skill 里写清输入与输出：

• 输入：源端关键文件路径、目标端对应路径、需求编号或用户故事摘要。
• 输出：一张结构化表，至少包含：
  • API / 行为对照：异步模型（Kotlin 协程 vs Swift async vs Promise）、主线程约束、错误类型是否可对应。
  • 平台差异显式声明：例如 Keychain vs Keystore vs 鸿蒙安全存储、推送与后台任务差异。
  • 已知妥协：哪些为赶进度采用临时方案，必须带 TODO(@owner, deadline)。

转换质量不是「看起来像」，而是「在约束下可维护且可验证」。

4.2 总结「每次提交的变更内容」

与其让模型自由发挥写 PR 描述，不如在 Skill 里规定：

• 固定调用 git diff / git show（通过 MCP）得到事实；
• 再按模板归纳：文件级摘要 → 行为变化 → 风险点 → 测试建议；
• 禁止把「推测的业务意图」写进摘要当事实（除非文档里有依据）。

这样每一轮提交都有可比对、可审计的变更说明，也方便后面做需求完成度对照。

4.3 评估「需求完成度」

把需求拆成可勾选条目（验收标准），在 Skill 中要求：

• 每条对应 commit 或 PR 中的证据（实现位置、测试用例、或文档更新）；
• 未完成项必须标 阻塞原因（依赖、接口未就绪、平台能力缺失）。

没有结构化条目，「差不多做完了」无法复盘。

4.4 评估「提交代码的质量」

建议在 Skill 里分三层，由浅入深：

静态检查能覆盖机械层与部分工程层；语义层需要测试或人工 spot check。Skill 里应写明：哪些必须跑命令、哪些允许仅人工。

5. 示例：Skill 里可以长什么样（片段）

下面是一段示意性的 Markdown 结构，便于你落到仓库里的 SKILL.md（真实项目请补全 name、description 与触发条件）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

---
name: cross-platform-migration-review
description: Android/iOS/鸿蒙互迁时的对照审查与提交摘要
---

## 何时使用
用户提到跨端迁移、对照实现、ArkTS/Kotlin/Swift 同步修改时加载本 Skill。

## 步骤
1. 用 MCP 读取当前分支相对 main 的 diff 与最近 N 次提交信息。
2. 对照 `docs/platform-mapping.md`（若存在）检查涉及模块是否登记。
3. 按「转换质量 / 变更摘要 / 需求条目 / 代码质量」四节输出，缺信息则列出待补充问题。
4. 若涉及鸿蒙，显式检查线程与权限相关 API 是否与文档一致。

## 输出模板（节选）
### 变更摘要（基于 diff）
- 范围：...
- 行为变化：...
- 风险：...

### 需求完成度
| 条目 | 状态 | 证据 |

实际仓库里你会把路径、分支名、文档名换成自己的约定。

6. 局限与诚实边界

• MCP 不是魔法：没有构建环境、没有测试、没有清晰需求，再好的协议也只能产出「更像代码的文本」。
• 三端互转在工程上常卡在 能力不对等（系统服务、商店政策、声明式 UI 数据流），Skill 应要求把这些写进「已知妥协」，而不是一笔带过。
• 安全：能执行命令的 MCP 必须限权、审计；不要把生产密钥放进可被模型读取的资源。

7. 小结

• MCP 解决的是：让 Agent 稳定读仓库、跑检查、对齐事实，跨端转换才有可持续的闭环。
• Skill 解决的是：把 转换质量、变更摘要、需求完成度、代码质量 变成可重复执行的评审步骤，减少「同一类问题每次重新口头讲一遍」。

若你已经在用 Cursor / Claude Code 一类工具，优先落地的往往是：一个最小 MCP 集合（git + 终端或 CI 日志）+ 一个迁移审查 Skill；再逐步把需求条目与对照表接进来。和自己在项目里的做法一样：大功能点先互转、人按需求走查、问题再丢给 AI，比一上来追求「全自动三端零走查」更实在，也更容易稳定提效。

本文为工程流程向说明，具体工具链与 MCP Server 名称以各厂商文档为准；实施时请结合团队安全与合规要求。

由浅入深，从基本概念到源码原理，再到实战示例与生产级应用案例，系统梳理 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？

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

适用场景：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 旗下金融应用）

启示：大型金融场景下，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 共享范围建议

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 能力的重要路径。

参考资料

• Kotlin Multiplatform 官方文档
• Expect and actual declarations
• Kotlin Multiplatform project structure
• Cash App KMP 案例研究
• Ktor Client
• kotlinx.serialization

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

一、基础概念

1.1 为什么需要架构优化？

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

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 路由方案对比

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 插件化技术选型

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 常见坑与规避

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 做完整插件化
└── 按需下载、热更新

八、总结

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

参考资源

• ARouter - 阿里开源路由框架
• RePlugin - 360 插件化框架
• Shadow - 腾讯插件化框架
• Dynamic Feature Modules 官方文档
• 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 入口跑到底」的传统应用模型，而是采用 组件化 + 系统调度：

二、四大核心组件

2.1 Activity：界面与用户交互

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

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

• 生命周期：onCreate → onStartCommand（Started）或 onBind（Bound）→ 运行 → onUnbind / onDestroy。
• 前台服务：若需长时间在后台运行且不被系统轻易杀死，可调用 startForeground() 并显示持久通知，符合系统对「前台服务」的规范。

2.3 BroadcastReceiver：事件广播与响应

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

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

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

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

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

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

3.1 Intent：意图与组件间通信

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

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 的 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。

六、小结

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

目录

• 一、响应式编程基础
• 二、iOS响应式状态管理
• 三、Flutter响应式状态管理
• 四、React响应式状态管理
• 五、React Native响应式状态管理
• 六、鸿蒙响应式状态管理
• 七、性能优化与对比
• 八、最佳实践与架构选型

一、响应式编程基础

1.1 核心概念

响应式编程是一种编程范式，其核心思想是：

• 数据驱动UI：UI是数据的函数 UI = f(state)
• 自动更新：当数据变化时，UI自动更新
• 声明式：只关注”是什么”，不关注”怎么做”

状态管理是响应式编程的核心，解决的问题包括：

• 状态的存储和访问
• 状态变化的检测和通知
• 副作用的处理
• 状态的持久化

1.2 响应式系统的基本构成

一个完整的响应式系统通常包含以下组件：

二、iOS响应式状态管理

2.1 传统KVO机制

核心原理：

• 键值观察（Key-Value Observing）是iOS的原生响应式机制
• 基于运行时的动态方法替换
• 使用isa-swizzling技术实现属性观察

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// 1. 注册观察者
[object addObserver:self 
         forKeyPath:@"propertyName" 
            options:NSKeyValueObservingOptionNew 
            context:NULL];

// 2. 实现观察回调
- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object 
                        change:(NSDictionary *)change 
                       context:(void *)context {
    if ([keyPath isEqualToString:@"propertyName"]) {
        id newValue = change[NSKeyValueChangeNewKey];
        // 更新UI
    }
}

// 3. 移除观察者
- (void)dealloc {
    [object removeObserver:self forKeyPath:@"propertyName"];
}

技术深度：

• KVO通过动态创建子类实现，当对象被观察时，系统会：
  1. 创建一个继承自原类的子类
  2. 重写被观察属性的setter方法
  3. 替换对象的isa指针指向新子类
  4. 在setter中通知观察者

2.2 Combine框架

核心原理：

• Apple在iOS 13+推出的响应式编程框架
• 基于Publisher-Subscriber模式
• 支持函数式的响应式操作

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 1. 创建Publisher
let subject = PassthroughSubject<String, Never>()

// 2. 订阅
let cancellable = subject
    .map { $0.uppercased() }
    .filter { $0.count > 3 }
    .sink {
        print("Received: \($0)")
    }

// 3. 发送值
subject.send("Hello")
subject.send("World")

// 4. 取消订阅
cancellable.cancel()

技术深度：

• Combine使用协议和泛型实现类型安全
• Publisher：数据源，负责发送值
• Subscriber：订阅者，接收并处理值
• Operator：操作符，对数据流进行转换
• Cancellable：管理订阅生命周期

2.3 SwiftUI状态管理

核心原理：

• 声明式UI框架，与响应式状态管理深度集成
• 使用属性包装器简化状态管理
• 基于依赖追踪的更新机制

实现机制：

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

// 1. @State - 本地状态
struct ContentView: View {
    @State private var count = 0
    
    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

// 2. @ObservableObject - 可观察对象
class UserViewModel: ObservableObject {
    @Published var name: String
    
    init(name: String) {
        self.name = name
    }
}

struct UserView: View {
    @ObservedObject var viewModel: UserViewModel
    
    var body: some View {
        Text("Name: \(viewModel.name)")
    }
}

技术深度：

• @State：使用值类型的引用包装，支持本地状态
• @Published：使用属性包装器实现自动通知
• @ObservedObject：使用弱引用避免循环引用
• @EnvironmentObject：通过环境传递共享状态

三、Flutter响应式状态管理

3.1 基础状态管理（setState）

核心原理：

• 基于StatefulWidget和setState的基础状态管理
• 脏检查机制触发重建
• Element树的差异化更新

实现机制：

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

class CounterWidget extends StatefulWidget {
  @override
  _CounterWidgetState createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int _count = 0;
  
  void _increment() {
    setState(() {
      _count++;
    });
  }
  
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Count: $_count'),
        ElevatedButton(
          onPressed: _increment,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

技术深度：

• setState：标记Element为dirty，触发下一帧重建
• Widget树：不可变的配置树
• Element树：管理生命周期和状态
• RenderObject树：负责布局和渲染

3.2 InheritedWidget机制

核心原理：

• 基于继承的状态传递机制
• 利用Element树的层级关系
• 实现跨组件的状态共享

实现机制：

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

class AppState extends InheritedWidget {
  final int count;
  final VoidCallback increment;
  
  const AppState({
    Key? key,
    required this.count,
    required this.increment,
    required Widget child,
  }) : super(key: key, child: child);
  
  static AppState of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<AppState>()!;
  }
  
  @override
  bool updateShouldNotify(AppState oldWidget) {
    return oldWidget.count != count;
  }
}

// 使用
class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  int _count = 0;
  
  void _increment() {
    setState(() => _count++);
  }
  
  @override
  Widget build(BuildContext context) {
    return AppState(
      count: _count,
      increment: _increment,
      child: MaterialApp(
        home: HomePage(),
      ),
    );
  }
}

class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final appState = AppState.of(context);
    return Column(
      children: [
        Text('Count: ${appState.count}'),
        ElevatedButton(
          onPressed: appState.increment,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

技术深度：

• dependOnInheritedWidgetOfExactType：建立依赖关系
• updateShouldNotify：决定是否通知子组件
• Element依赖追踪：当InheritedWidget变化时，自动重建依赖的子组件

3.3 第三方状态管理库

Provider

核心原理：

• 基于InheritedWidget的轻量级状态管理
• 使用ChangeNotifier实现状态通知
• 支持依赖注入和状态监听

实现机制：

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

// 1. 定义模型
class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;
  
  void increment() {
    _count++;
    notifyListeners();
  }
}

// 2. 提供状态
void main() {
  runApp(
    ChangeNotifierProvider(
      create: (context) => CounterModel(),
      child: MyApp(),
    ),
  );
}

// 3. 消费状态
class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Consumer<CounterModel>(
      builder: (context, counter, child) {
        return Column(
          children: [
            Text('Count: ${counter.count}'),
            ElevatedButton(
              onPressed: counter.increment,
              child: Text('Increment'),
            ),
          ],
        );
      },
    );
  }
}

技术深度：

• ChangeNotifier：实现观察者模式
• Consumer：订阅状态变化，只重建必要的Widget
• Selector：更精确的依赖选择，避免不必要的重建

Riverpod

核心原理：

• 解决Provider的依赖注入和测试问题
• 基于ProviderContainer的状态管理
• 支持编译时安全和懒加载

实现机制：

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

// 1. 定义Provider
final counterProvider = StateProvider<int>((ref) => 0);

// 2. 使用Provider
class HomePage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);
    
    return Column(
      children: [
        Text('Count: $count'),
        ElevatedButton(
          onPressed: () => ref.read(counterProvider.notifier).state++,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

// 3. 组合Provider
final userProvider = Provider<User>((ref) {
  final userId = ref.watch(userIdProvider);
  return User(id: userId);
});

技术深度：

• ProviderScope：状态容器，支持测试和隔离
• AutoDispose：自动清理不再使用的状态
• Family：参数化Provider，支持动态创建
• FutureProvider：处理异步状态
• StreamProvider：处理流式状态

四、React响应式状态管理

4.1 基础状态管理（setState）

核心原理：

• 基于Component和setState的状态管理
• 虚拟DOM的差异化更新
• 批处理优化性能

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }
  
  increment() {
    this.setState(prevState => ({
      count: prevState.count + 1
    }));
  }
  
  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={() => this.increment()}>Increment</button>
      </div>
    );
  }
}

技术深度：

• setState：异步更新，支持函数式更新
• shouldComponentUpdate：手动优化渲染
• PureComponent：浅比较优化
• forceUpdate：强制更新

4.2 Hooks状态管理

核心原理：

• React 16.8+引入的函数组件状态管理
• 基于闭包和链表的Hook实现
• 支持自定义Hook复用逻辑

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import React, { useState, useEffect } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);
  
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

技术深度：

• useState：基于Dispatcher的状态管理
• useEffect：处理副作用，依赖数组控制执行时机
• useContext：跨组件状态共享
• useReducer：复杂状态逻辑管理
• useMemo/useCallback：性能优化

4.3 Redux状态管理

核心原理：

• 基于Flux架构的状态管理
• 单一数据源和不可变状态
• Reducer纯函数处理状态更新

实现机制：

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

// 1. 定义Action
const INCREMENT = 'INCREMENT';
const DECREMENT = 'DECREMENT';

// 2. 定义Reducer
function counterReducer(state = { count: 0 }, action) {
  switch (action.type) {
    case INCREMENT:
      return { count: state.count + 1 };
    case DECREMENT:
      return { count: state.count - 1 };
    default:
      return state;
  }
}

// 3. 创建Store
const store = createStore(counterReducer);

// 4. 订阅状态
store.subscribe(() => {
  console.log('Current state:', store.getState());
});

// 5. 分发Action
store.dispatch({ type: INCREMENT });

// 6. 在React中使用
import { connect } from 'react-redux';

function Counter({ count, increment, decrement }) {
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

const mapStateToProps = state => ({
  count: state.count
});

const mapDispatchToProps = dispatch => ({
  increment: () => dispatch({ type: INCREMENT }),
  decrement: () => dispatch({ type: DECREMENT })
});

export default connect(mapStateToProps, mapDispatchToProps)(Counter);

技术深度：

• Store：单一数据源，持有应用状态
• Action：描述状态变化的对象
• Reducer：纯函数，根据Action计算新状态
• Middleware：处理异步Action和副作用
• CombineReducers：拆分状态逻辑

五、React Native响应式状态管理

5.1 原生状态管理

核心原理：

• 与React相同的状态管理机制
• 针对移动平台的优化
• 支持原生模块的状态同步

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import React, { useState } from 'react';
import { View, Text, TouchableOpacity } from 'react-native';

function Counter() {
  const [count, setCount] = useState(0);
  
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text style={{ fontSize: 24 }}>Count: {count}</Text>
      <TouchableOpacity
        style={{ marginTop: 20, padding: 10, backgroundColor: '#007AFF' }}
        onPress={() => setCount(count + 1)}
      >
        <Text style={{ color: 'white' }}>Increment</Text>
      </TouchableOpacity>
    </View>
  );
}

技术深度：

• Bridge：JavaScript与原生通信
• Shadow Tree：虚拟DOM在RN中的实现
• Batched Updates：批量更新优化
• Native Modules：原生功能集成

5.2 第三方状态管理库

Redux

核心原理：

• 与React Redux相同的架构
• 针对移动场景的优化
• 支持持久化和中间件

实现机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 与Web React Redux相同
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers';

const store = createStore(
  rootReducer,
  applyMiddleware(thunk)
);

// 在App中使用
import { Provider } from 'react-redux';

export default function App() {
  return (
    <Provider store={store}>
      <Counter />
    </Provider>
  );
}

MobX

核心原理：

• 基于观察者模式的状态管理
• 响应式代理自动追踪依赖
• 装饰器简化状态定义

实现机制：

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

import { observable, action } from 'mobx';
import { observer } from 'mobx-react';

// 定义Store
class CounterStore {
  @observable count = 0;
  
  @action increment() {
    this.count++;
  }
  
  @action decrement() {
    this.count--;
  }
}

const counterStore = new CounterStore();

// 使用Store
@observer
class Counter extends React.Component {
  render() {
    return (
      <View>
        <Text>Count: {counterStore.count}</Text>
        <TouchableOpacity onPress={() => counterStore.increment()}>
          <Text>Increment</Text>
        </TouchableOpacity>
      </View>
    );
  }
}

技术深度：

• observable：创建响应式状态
• action：修改状态的方法
• computed：派生状态
• reaction：副作用处理

Context API

核心原理：

• React 16.3+的Context API
• 简化跨组件状态共享
• 替代Redux的轻量级方案

实现机制：

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

import React, { createContext, useContext, useState } from 'react';

// 创建Context
const CounterContext = createContext();

// 提供Context
function CounterProvider({ children }) {
  const [count, setCount] = useState(0);
  
  const value = {
    count,
    increment: () => setCount(count + 1),
    decrement: () => setCount(count - 1)
  };
  
  return (
    <CounterContext.Provider value={value}>
      {children}
    </CounterContext.Provider>
  );
}

// 使用Context
function Counter() {
  const { count, increment, decrement } = useContext(CounterContext);
  
  return (
    <View>
      <Text>Count: {count}</Text>
      <TouchableOpacity onPress={increment}>
        <Text>Increment</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={decrement}>
        <Text>Decrement</Text>
      </TouchableOpacity>
    </View>
  );
}

// 在App中使用
function App() {
  return (
    <CounterProvider>
      <Counter />
    </CounterProvider>
  );
}