Android 应用进程、四大组件与系统架构全景（API 34）《Android深水区（一）》从应用开发到 Framew

Android 应用进程、四大组件与系统架构全景（API 34）：从 Zygote 到 ActivityThread

本文属于 Android 系统化技术博客系列（A019）。建议先掌握协程通信基础，再结合官方文档与 AOSP 源码阅读。

你将搞懂：为什么 startActivity() 不会立刻 new Activity、多进程单例为何失效、冷启动为何被 Provider 拖慢，以及 AMS / ATMS / Binder 在其中的分工。

标签：Android, 四大组件, Process, Zygote, AMS, ATMS, Binder, system_server, 冷启动, Architecture

适合读者：Foundation（有 Kotlin 基础，想建立 Framework 全局地图）

前言

很多 Android 问题表面上是「某个 API 不好用」，根因往往在更底层：进程怎么被创建、组件由谁调度、应用与系统服务如何通信。

典型困惑：

为什么 startActivity() 不会立刻 new 出目标页面？
为什么后台 Service 会被系统回收？
为什么多进程里单例会失效？

要回答这些，需要先建立一张系统地图：应用层、Framework API、系统服务、Native 层各自负责什么。本文是系列 A019，为 Activity 生命周期、启动模式、Context 区别等后续文章打基础。行为描述以 API 34 / android-14 为参考，请以项目 targetSdkVersion 为准。

前置：建议已了解 Channel / SharedFlow / StateFlow（系列 A018）。

核心概念

四大应用组件

组件	职责	典型入口	调度侧（概览）
Activity	有界面交互	`startActivity()`	ATMS + `ActivityThread`
Service	后台长任务	`startService()` / `bindService()`	AMS + `ActivityThread`
BroadcastReceiver	广播响应	`sendBroadcast()` / 注册	AMS（注册与投递）
ContentProvider	跨应用数据共享	`ContentResolver`	AMS + `ActivityThread`

另有 Application：进程级入口，非「四大组件」之一。

要点：组件不是普通对象，不能 new Activity() 指望它能用；调度决策多在 system_server，业务回调在应用主线程。

应用进程

默认独立 Linux 进程，独立 UID，沙箱隔离。
由 Zygote fork，Copy-on-Write 共享预加载类，加速启动。
android:process 可声明多进程（:push 等）。

系统分层架构

flowchart TB
  subgraph AppLayer[&#34;应用层&#34;]
    UI[&#34;Activity / Compose&#34;]
    Svc[&#34;Service&#34;]
    BR[&#34;BroadcastReceiver&#34;]
    CP[&#34;ContentProvider&#34;]
  end
  subgraph Framework[&#34;Framework API&#34;]
    Ctx[&#34;Context&#34;]
    AM[&#34;ActivityManager 客户端&#34;]
  end
  subgraph SystemServer[&#34;system_server&#34;]
    AMS[&#34;AMS&#34;]
    ATMS[&#34;ATMS&#34;]
  end
  subgraph Native[&#34;Native&#34;]
    Binder[&#34;Binder&#34;]
    Zygote[&#34;Zygote&#34;]
  end
  UI --> Ctx --> AM
  AM -->|Binder| AMS
  AM -->|Binder| ATMS
  Zygote -->|fork| AppLayer

读图口诀：决策在 system_server，执行在 ActivityThread 主线程。

工作流程

从开机到首个 Activity

sequenceDiagram
  participant Z as Zygote
  participant ATMS as ATMS
  participant AT as ActivityThread
  participant Act as Activity
  ATMS->>Z: fork 应用进程
  Z-->>AT: 主线程 + Looper
  AT->>AT: installContentProviders
  AT->>AT: Application.onCreate
  ATMS->>AT: scheduleTransaction
  AT->>Act: performLaunchActivity → onCreate

进程优先级（简化）

flowchart LR
  FG[&#34;前台&#34;] --> VIS[&#34;可见&#34;] --> SVC[&#34;服务&#34;] --> CACHED[&#34;缓存&#34;]
  CACHED -->|内存压力| KILL[&#34;被杀&#34;]

前台最后死、缓存最先牺牲——这一模型长期有效，具体实现随版本演进（lmkd、PSI 等）。

API 使用

Manifest（Android 12+ 注意 exported）

<activity
    android:name=".ui.MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<service
    android:name=".push.PushService"
    android:process=":push"
    android:exported="false" />

有 intent-filter 的组件必须显式声明 android:exported（Android 12+）。

Kotlin 最小示例

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        startActivity(Intent(this, DetailActivity::class.java))
    }
}

class DownloadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int) =
        START_NOT_STICKY
    override fun onBind(intent: Intent?): IBinder? = null
}

Activity 启动链（API 28+ ClientTransaction）

Activity.startActivity()
  → Instrumentation.execStartActivity()
  → ATMS.startActivity()              // Binder 跨进程
  → scheduleTransaction(ClientTransaction)
  → TransactionExecutor.execute()
  → LaunchActivityItem.execute()
  → performLaunchActivity() → onCreate()   // 主线程

Android 9 以前多以 handleLaunchActivity 为主；API 28+ 以 ClientTransaction 为准。

源码分析要点

ActivityThread 启动顺序（主线程）

ActivityThread.main()
  → attach()
  → installContentProviders()   // 早于 Application！
  → callApplicationOnCreate()
  → Looper.loop()

冷启动坑：Provider onCreate() 在 Application.onCreate() 之前同步执行。

AMS / ATMS 分工

模块	职责
ATMS	Activity 任务栈、启动模式、多窗口
AMS	进程、Service、Broadcast、Provider 协调

应用里拿到的 ActivityManager 是 Binder 代理，真身在 system_server。

广播版本差异

场景	要点
动态注册	随进程生死
静态注册	Android 8.0+ 隐式广播大量不可用
targetSdk 31+	须声明 `exported`

实战案例

① 推送 :push 多进程
单例不跨进程；用 AIDL / Messenger / Provider；勿用已废弃的 MODE_MULTI_PROCESS。

② 冷启动慢
查 Provider 链；adb shell am start -W -n pkg/.Activity；用 App Startup 合并初始化。

③ 后台定位被杀
Android 8.0+ 需 Foreground Service + 合法 foregroundServiceType，或 WorkManager。

性能优化

维度	方向
冷启动	延迟初始化、Baseline Profile、监控 TTID/TTFD
多进程	非必要不开
Binder	主线程避免同步大事务
内存	`onTrimMemory()` 主动释放

adb shell am start -W -n com.example.app/.MainActivity
adb shell dumpsys meminfo com.example.app

常见误区

可以 new Activity() — 不行
Service 一定能保活 — 后台限制下随时可能停
多进程共享单例 — 须 IPC
Manifest 静态广播一定能收 — 8.0+ 大量受限
ActivityManager = AMS 实例 — 只是代理

面试考点（精选）

四大组件各解决什么？
Zygote 作用？
ActivityThread 是线程吗？
startActivity → onCreate 跨了哪些层？
为何引入 ClientTransaction？
多进程单例为何失效？
AMS vs ATMS？
Binder 角色（Proxy / Stub / 驱动）？
系统如何选进程杀？
冷启动 vs 热启动？

第 4 题要点：Instrumentation → Binder 到 ATMS → 必要时 Zygote fork → ClientTransaction → 主线程 onCreate。

总结

组件 = 系统调度单元，不是普通对象。
进程 = 资源与安全边界，Zygote fork，AMS 管生死。
Binder 连接应用与 system_server — 决策在服务端，执行在主线程。

系列：A018 协程流 → A019 本文 → A020 生命周期 → A021 启动模式 → A027 Context

参考资料

Application fundamentals
Processes and app lifecycle
Android 12 exported 变更
App startup time (TTID/TTFD)
AOSP：ActivityThread.java · ClientTransaction.java · ActivityTaskManagerService.java

标签：#Android #四大组件 #Process #Zygote #AMS #ATMS #Binder #system_server #冷启动 #Architecture