4. Intent匹配规则与隐式启动边界：action、category、data的过滤逻辑

Intent 是 Android 组件间通信的载体，其匹配规则决定了隐式启动的成功与否。掌握 action、category、data 的过滤逻辑，是构建稳定、安全且边界可控的 ActivityManager 系统的核心前提。本章深入拆解三要素的匹配机制、执行顺序与边界校验方法。

4.1 匹配原理：三要素的交集逻辑

系统通过 PackageManager.resolveActivity() 执行隐式匹配，采用“与（AND）”逻辑：目标组件必须在 <intent-filter> 中同时包含发起 Intent 指定的 action、category、data 要求，才算匹配成功。任一要素不满足则直接拒绝。

4.2 匹配要素逐项解析

4.3 匹配流程与优先顺序

系统按以下顺序执行三要素校验：

1. Action 过滤：Intent 的 action 必须在 filter 的 action 列表中，否则直接跳出。
2. Category 过滤：遍历 Intent 的所有 category，每个都必须出现在 filter 的 category 列表中。若 filter 包含 CATEGORY_DEFAULT，则 Intent 无 category 时自动补入该值。
3. Data 过滤：先匹配 URI 部分（scheme → host → port → path），再匹配 MIME type。若 filter 声明了 data，但 Intent 的 data 为 null → 匹配失败。若 filter 未声明 data，仅当 Intent 的 data 也为 null 时通过。

4.4 Intent 匹配流程结构图

下图展示了系统对单条 intent-filter 进行隐式匹配的完整决策路径：

4.5 实现流程与配置示例

在实际开发中，隐式匹配的配置集中在 AndroidManifest.xml 的 <intent-filter> 中。以下展示一个完整的边界控制配置：

<activity android:name=“.SecureReceiverActivity”
    android:exported=“true”
    android:permission=“android.permission.BIND_ACCESSIBILITY_SERVICE”>
    <intent-filter>
        <action android:name=“com.example.action.SECURE” />
        <category android:name=“android.intent.category.DEFAULT” />
        <category android:name=“com.example.category.CUSTOM” />
        <data
            android:scheme=“example”
            android:host=“secure”
            android:pathPrefix=“/api/v2” />
    </intent-filter>
</activity>

4.6 命令行调试与验证方法

使用 adb shell dumpsys package 和 am start 命令可直接验证匹配行为：

4.6.1 检查目标组件 filter 信息

adb shell dumpsys package com.example.myapp | grep -A 20 “SecureReceiverActivity”

输出中应包含 Intent Filter: 节，显示所有声明的 action、category、data 信息。

4.6.2 发送隐式 Intent 进行测试

# 成功案例：包含完整三要素
adb shell am start -a com.example.action.SECURE
    -c android.intent.category.DEFAULT
    -c com.example.category.CUSTOM
    -d “example://secure/api/v2/resource”

# 失败案例：缺少 Custom category
adb shell am start -a com.example.action.SECURE
    -c android.intent.category.DEFAULT
    -d “example://secure/api/v2/resource”

# 失败案例：MIME type 不匹配
adb shell am start -a com.example.action.SECURE
    -c android.intent.category.DEFAULT
    -t “text/plain”
    -d “example://secure/api/v2/resource”

若隐式启动失败，logcat 会输出类似：

E/ActivityManager: No Activity found to handle Intent {
    act=com.example.action.SECURE
    cat=[android.intent.category.DEFAULT]
    dat=example://secure/api/v2/resource
}

4.7 常见边界错误与规避

4.8 性能与稳定性优化建议

• 减少模糊 filter：避免声明过于宽泛的 action（如 ACTION_VIEW）且无 data 约束，否则系统在解析时需遍历大量组件。
• 优先使用 URI scheme + host：相比仅声明 scheme，指定 host 和 path 可大幅缩小匹配范围，提升 resolveActivity() 速度。
• 避免在 filter 中使用正则 pathPattern：正则匹配性能开销较大；若必须使用，确保 pattern 简单且非频繁调用。
• 谨慎暴露 export：对不需要外部启动的组件务必设置 exported=“false”，减少系统无谓的匹配尝试，同时提升安全性。
• 利用 PackageManager.queryIntentActivities() 预校验：在调用 startActivity() 前先查询匹配结果，避免因匹配不到而崩溃。

// 预校验示例
PackageManager pm = context.getPackageManager();
List<ResolveInfo> activities = pm.queryIntentActivities(intent, 0);
if (activities.size() > 0) {
    context.startActivity(intent);
} else {
    // 处理无匹配情况，如提示用户或降级
}

4.9 课后验证清单

• □ 能否列举 action、category、data 三要素的匹配失败条件？
• □ 能否复现使用 adb shell dumpsys 查看目标组件的所有 filter 信息？
• □ 能否写出一段包含 action、category、data 的隐式启动配置，并在手机上验证？
• □ 能否解释为什么 filter 中必须包含 CATEGORY_DEFAULT 才能接收不带 category 的隐式 Intent？
• □ 能否在 AndroidManifest.xml 中为同一个 activity 配置两个不同的 filter，并描述系统如何选择？