第二板块：Android 四大组件标准化学理 | 第六篇：四大组件架构总论与 Manifest 规范

车载Android刘工
25 阅读5分钟

第二板块：Android 四大组件标准化学理 | 第六篇：四大组件架构总论与 Manifest 规范

所属板块：第二板块 — Android 四大组件标准化学理

前置知识：第一板块中的 Context 体系、Binder IPC 机制、Zygote 进程孵化

本篇定位：从 Android 系统设计者的视角，解析四大组件（Activity、Service、BroadcastReceiver、ContentProvider）的架构总纲与 Manifest 注册规范。我们将深入探讨组件如何被系统发现、如何被调度、以及它们之间的进程间通信（IPC）边界。

1. 核心结论先行

Android 四大组件是 Android 操作系统的应用级构建块（Application Building Blocks）。它们不是普通的 Java 对象，而是由系统服务（System Server）托管的特殊实体。

  • 组件的本质：一个声明式入口。应用进程本身不主动创建组件，而是向系统（PMS/AMS）声明“我能处理什么”，系统再根据需要在合适的时机实例化这些组件。
  • Manifest 的本质：一个全局注册表。它告诉系统：这个 APK 包含哪些组件、需要哪些权限、运行在哪个进程、以及具备什么能力。
  • 调度中心：ActivityManagerService (AMS) 是所有组件调度的中枢，它通过 Binder 与应用的 ApplicationThread 通信，指挥应用进程创建或销毁组件。

2. 四大组件架构总论

2.1 组件分类与特性对比

组件类型核心职责是否常驻是否独立进程核心系统服务
Activity用户界面交互否（前台可见时存活）可配置ActivityManagerService
Service后台逻辑执行是（除非被回收）可配置ActivityManagerService
BroadcastReceiver系统/应用事件广播否（瞬时执行）否（默认宿主进程）ActivityManagerService
ContentProvider数据共享与访问是（进程启动时加载）可配置ActivityManagerService / PackageManagerService

2.2 组件实例化模型

四大组件均遵循被动实例化模型：

sequenceDiagram
    participant System as Android System (AMS/PMS)
    participant App as 应用进程 (Zygote Fork)
    participant Component as 组件实例 (Activity/Service等)

    System->>App: 1. 请求创建组件 (Binder IPC)
    App->>Component: 2. 反射创建实例 (newInstance)
    Component->>Component: 3. 调用生命周期回调 (onCreate/onStart)
    Component-->>System: 4. 汇报状态就绪

学术定义：

  • 反射创建：系统通过 ClassLoader 加载组件的 .class 文件，并调用其无参构造函数创建实例。这就是为什么组件不能有显式构造函数。
  • 生命周期回调：系统在组件创建后，通过 Binder 回调其生命周期方法（如 onCreate），应用进程只是被动执行。

3. Manifest 规范与解析机制

3.1 Manifest 文件结构（标准化定义）

AndroidManifest.xml 是 APK 的元数据清单。以下是其标准结构（不包含业务属性）：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app"
    android:sharedUserId="string"
    android:versionCode="integer"
    android:versionName="string">

    <!-- 1. 应用全局配置 -->
    <application
        android:name=".MyApplication"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:process="string">
        
        <!-- 2. Activity 组件 -->
        <activity
            android:name=".MainActivity"
            android:exported="boolean"
            android:launchMode="standard|singleTop|singleTask|singleInstance"
            android:taskAffinity="string">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <!-- 3. Service 组件 -->
        <service
            android:name=".MyService"
            android:exported="boolean"
            android:process="string" />

        <!-- 4. BroadcastReceiver 组件 -->
        <receiver
            android:name=".MyReceiver"
            android:exported="boolean">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />
            </intent-filter>
        </receiver>

        <!-- 5. ContentProvider 组件 -->
        <provider
            android:name=".MyProvider"
            android:authorities="com.example.app.provider"
            android:exported="boolean"
            android:readPermission="string"
            android:writePermission="string" />
    </application>

    <!-- 6. 权限声明 -->
    <uses-permission android:name="android.permission.INTERNET" />
    <permission android:name="com.example.app.permission.CUSTOM" />
</manifest>

3.2 PackageManagerService (PMS) 的解析流程

PMS 在系统启动或应用安装时解析 Manifest。

graph TB
    subgraph PMS[&#34;PackageManagerService&#34;]
        A[&#34;扫描 APK 目录 (/data/app)&#34;] --> B[&#34;解析 AndroidManifest.xml&#34;]
        B --> C[&#34;构建 Package 对象&#34;]
        C --> D[&#34;注册组件信息 (Activity/Service/Provider/Receiver)&#34;]
        D --> E[&#34;保存到 Settings (packages.xml)&#34;]
        E --> F[&#34;更新系统广播 (ACTION_PACKAGE_ADDED)&#34;]
    end

    style PMS fill:#e3f2fd,stroke:#1565c0

解析结果存储：

  • PackageParser.Package：内存中的数据结构，包含所有组件信息。
  • packages.xml：持久化存储，记录所有已安装应用的包名、版本、权限、组件列表。

4. 组件间通信与 Intent 机制

4.1 Intent 作为组件间的契约

Intent 是组件间通信的消息载体。它分为两种：

Intent 类型特点解析方式
显式 Intent指定目标组件的类名直接匹配 ComponentName
隐式 Intent指定 Action、Category、Data通过 PackageManager 查询匹配的组件

4.2 Intent Filter 的匹配算法

当使用隐式 Intent 时，PMS 会根据 Manifest 中声明的 <intent-filter> 进行匹配。

// PackageManagerService 中的匹配逻辑（简化）
public List<ResolveInfo> queryIntentActivities(Intent intent, String resolvedType, int flags) {
    // 1. 遍历所有已安装的 Package
    // 2. 遍历 Package 中的所有 Activity
    // 3. 检查 Activity 的 Intent Filter 是否匹配 Intent
    // 4. 返回匹配的 Activity 列表
}

匹配规则：

  1. Action：Intent 的 Action 必须包含在 Filter 的 Action 列表中。
  2. Category：Intent 的所有 Category 必须包含在 Filter 的 Category 列表中。
  3. Data：Intent 的 URI 和数据类型（MIME）必须与 Filter 的 Data 规范匹配。

5. 进程模型与组件归属

5.1 组件与进程的映射关系

一个组件运行在哪个进程，由 Manifest 中的 android:process 属性决定。

配置方式进程行为
不配置默认运行在应用的主进程（包名进程）。
:remote运行在私有远程进程（以冒号开头，进程名 = 包名:remote）。
完整包名运行在全局共享进程（多个应用可运行在同一进程，需相同签名和 sharedUserId）。

5.2 多进程下的组件实例化

graph TB
    subgraph Proc1[&#34;主进程 (com.example.app)&#34;]
        A1[&#34;Activity A&#34;]
        S1[&#34;Service X&#34;]
    end

    subgraph Proc2[&#34;远程进程 (com.example.app:remote)&#34;]
        S2[&#34;Service Y&#34;]
        CP1[&#34;ContentProvider Z&#34;]
    end

    Proc1 -->|&#34;Binder IPC&#34;| Proc2
    Proc2 -->|&#34;Binder IPC&#34;| Proc1

学术定义：

  • 进程隔离：不同进程的内存空间是隔离的。组件跨进程通信必须通过 Binder。
  • Application 多实例：每个进程都会创建一个独立的 Application 实例。

6. 系统服务对组件的调度

6.1 ActivityManagerService (AMS) 的角色

AMS 是四大组件的总调度室。它负责：

  1. 组件生命周期：管理 Activity 栈、Service 生命周期。
  2. 进程管理：根据组件重要性调整进程优先级（oom_adj）。
  3. 任务栈管理：管理 Activity 的任务栈（Task）和回退栈（Back Stack）。

6.2 组件调度时序（以启动 Activity 为例）

sequenceDiagram
    participant Client as 应用进程
    participant AMS as ActivityManagerService
    participant Zygote as Zygote 进程

    Client->>AMS: startActivity(intent)
    AMS->>AMS: 检查权限、解析 Intent、查找目标 Activity
    AMS->>AMS: 判断目标进程是否存在
    alt 进程不存在
        AMS->>Zygote: fork 新进程
        Zygote-->>AMS: 返回新进程 PID
    end
    AMS->>Client: scheduleLaunchActivity (Binder IPC)
    Client->>Client: 创建 Activity 实例、调用 onCreate

7. 关键数据结构与源码定义

7.1 ActivityRecord（AMS 中的 Activity 记录）

// com.android.server.am.ActivityRecord
final class ActivityRecord {
    final ActivityInfo info;      // 从 Manifest 解析来的信息
    final String packageName;
    final String processName;    // 运行在哪个进程
    final int userId;
    TaskRecord task;             // 所属的 Task
    ActivityState state;         // 当前状态 (INITIALIZING, RESUMED, PAUSED...)
}

7.2 ServiceRecord（AMS 中的 Service 记录）

// com.android.server.am.ServiceRecord
final class ServiceRecord {
    final ServiceInfo info;       // 从 Manifest 解析来的信息
    final String packageName;
    final String processName;
    final int userId;
    boolean isForeground;        // 是否是前台服务
}

8. 本篇总结（知识闭环）

关键点纯学术定义
组件的本质由系统服务托管的声明式入口，而非普通对象。
Manifest 的本质全局注册表，定义组件属性、权限和进程归属。
PMS 的作用解析 Manifest，构建组件数据库，供 AMS 查询。
AMS 的作用四大组件的总调度室，管理生命周期、进程和任务栈。
Intent 的作用组件间通信的消息载体，通过匹配规则连接组件。

下一篇预告：第二板块：Android 四大组件标准化学理 | 第七篇：Activity 页面载体与任务栈算法

avatar
文章
阅读
粉丝