从AOSP源码看Android14最近任务实现：手把手教你定制自己的RecentsView

从AOSP源码到深度定制：Android 14最近任务视图（RecentsView）的架构解析与实战改造

最近任务界面，这个用户每天要滑动数十次的系统组件，远不止是简单的应用列表。对于Android ROM定制开发者和深度系统优化者而言，它是系统交互的“门面”，是性能与体验的“试金石”。在Android 14的AOSP源码中，Launcher3的RecentsView模块经历了一系列底层重构，其数据流转、视图渲染和内存管理机制变得更加精细和模块化。如果你曾想过为何某个定制ROM的最近任务动画如此流畅，或是为何分屏任务的缩略图加载策略与众不同，答案就藏在这一行行代码构建的复杂交响曲中。本文将带你穿透API的抽象层，直抵RecentsView的核心腹地，不仅理解其如何工作，更将手把手引导你如何基于源码，对其进行符合你产品理念的深度定制。

1. 理解Android 14 RecentsView的顶层架构设计

在动手修改之前，我们必须先建立对RecentsView在整个Launcher3生态中定位的清晰认知。RecentsView并非一个孤立的视图，而是一个承上启下的视图控制器（View Controller）。它向上承接来自系统手势导航（GestureNav）或Overview按钮的交互指令，向下管理着一系列TaskView的生命周期。

Android 14中，RecentsView继承自PagedView，这意味着它天然具备了分页滚动的能力。但更重要的是，它被整合进了TaskView的视图回收池（View Pool）机制中。这种设计类似于RecyclerView的ViewHolder模式，旨在快速滚动时避免频繁的视图创建与销毁，从而保证滑动的流畅性。其核心依赖关系可以概括如下：

SystemUI (RecentTasks) -> SystemUiProxy -> RecentTasksList -> RecentsModel -> RecentsView -> TaskView Pool -> TaskView

数据流从左至右，而UI更新和用户交互产生的回调则从右至左。RecentsModel作为数据中枢（Data Hub），扮演了关键角色。它不仅仅缓存任务列表，还管理着任务图标（TaskIconCache）和任务缩略图（TaskThumbnailCache）这两大重量级资源的加载与缓存策略。一个常见的定制需求——修改任务卡片的预览图清晰度或加载优先级——往往就需要从这里入手。

注意：在AOSP的quickstep模块中，RecentsModel是一个单例。任何对其缓存策略的修改都可能全局影响Launcher的性能表现，测试时需格外谨慎。

1.1 RecentsView的核心成员变量与职责

打开RecentsView.java，你会被大量的成员变量淹没。我们聚焦几个最关键的角色：

• mTaskViewPool与mGroupedTaskViewPool: 分别用于缓存单个任务和分组（分屏）任务的视图。定制滚动效果或任务卡片样式时，常需要调整池的大小和复用逻辑。
• mTaskListChangeId: 一个用于标识当前加载任务列表版本的ID。这是实现增量更新和避免无效重绘的关键。RecentTasksList在系统任务发生变化时会递增一个全局的mChangeId，RecentsView通过对比自己的mTaskListChangeId来判断数据是否过期。
• mModel:RecentsModel的引用，数据请求的入口。
• mCurrentTask: 当前被聚焦或选中的任务，用于处理键盘导航和焦点逻辑。

理解这些成员，是后续进行任何针对性修改的基础。例如，如果你想实现一个“锁定某个任务不被清除”的功能，就需要考虑如何扩展Task或GroupTask的数据结构，并在RecentsView的渲染逻辑中加以识别和特殊处理。

2. 数据加载链路的深度拆解与定制点

原始流程概述了从UI触发到数据返回的路径，但作为定制者，我们需要关注的是其中每一个可以“介入”或“改写”的环节。让我们把这个链路拆解得再细一些。

2.1 触发时机：不只是上滑手势

reloadIfNeeded()是加载的起点，但什么情况会调用它？

1. 进入概览模式：setOverviewStateEnabled(true)是最主要的触发点。
2. 视图附着：onAttachedToWindow()中会尝试加载，确保视图可见时有数据。
3. 系统回调：通过TaskStackListener或RecentTasksList的监听器，在感知到任务变化（如应用启动、退出）后触发。
4. 主动刷新：例如在测试代码中手动调用。

定制场景：如果你希望实现“预加载”机制，即在用户可能即将进入最近任务前（比如从桌面边缘开始滑动时），就提前开始加载数据，你可以考虑在TouchController的onTouchMove事件中，根据手势位移的阈值，提前调用mModel.getTasks()。但这需要平衡好性能消耗与体验提升。

2.2 数据获取与加工：RecentTasksList的魔法

RecentTasksList.loadTasksInBackground()方法是原始数据加工的车间。这里有几个关键步骤：

1. IPC调用：通过mSysUiProxy.getRecentTasks()跨进程从SystemUI获取原始的GroupedRecentTaskInfo[]。这是数据源头。
2. 列表反转：Collections.reverse(rawTasks)。系统返回的是最新到最旧，而PagedView的渲染通常需要最旧到最新（取决于你的布局方向）。
3. 对象转换：将GroupedRecentTaskInfo转换为内部的Task和GroupTask对象。

关键定制点：数据过滤与排序getTasks()方法接收一个Predicate<GroupTask> filter参数。AOSP默认的过滤器可能只过滤掉当前应用或某些系统任务。你可以传入一个自定义的Predicate来实现强大的过滤逻辑，例如：

• 过滤掉指定包名的应用（实现“隐藏应用”功能）。
• 只显示特定用户配置文件下的任务。
• 根据任务最后使用时间或使用频率进行自定义排序（注意，排序在反转步骤前后进行效果不同）。

// 示例：自定义过滤器，隐藏包名为“com.example.secret”的应用 Predicate<GroupTask> myCustomFilter = groupTask -> { Task.TaskKey key = groupTask.task1.key; return !"com.example.secret".equals(key.getPackageName()); }; // 然后在你的定制RecentsView中调用mModel.getTasks(callback, myCustomFilter)

2.3 数据绑定与视图渲染：applyLoadPlan的细节

数据通过回调到达RecentsView.applyLoadPlan()。这里是视图更新的核心。其工作流程如下：

protected void applyLoadPlan(ArrayList<GroupTask> taskGroups) { // 1. 清空当前所有子View clearAllTasks(); // 2. 遍历每个GroupTask for (GroupTask group : taskGroups) { // 3. 从池中获取或创建TaskView TaskView tv = acquireTaskView(group, /* isNewTask= */ false); // 4. 绑定数据 tv.bind(group, mThumbnailData, mIconCache); // 5. 添加到RecentsView并设置布局参数 addView(tv); // ... 更新布局和动画状态 } // 6. 更新滚动范围和UI状态 updateCurveProperties(); updateClearAllButton(); }

深度定制示例：修改TaskView的布局与动画假设你需要为每个TaskCard添加一个常驻的“锁定”按钮。你需要：

1. 自定义TaskView子类：继承自TaskView，在onFinishInflate()中findViewById并初始化你的锁定按钮，并重写onTaskDataChanged()来根据任务数据更新按钮状态（例如，从扩展的Task属性中读取是否被锁定）。
2. 修改视图池逻辑：重写RecentsView的acquireTaskView方法，使其返回你的自定义TaskView实例。这通常需要你创建自己的TaskViewPool。
3. 处理交互事件：在你的自定义TaskView中，为锁定按钮设置OnClickListener，并将锁定状态通过某种方式（例如写入一个静态Map或修改Task对象的一个扩展字段）持久化。同时，需要确保这个状态能在任务列表刷新时得以保持。

提示：直接修改Task类可能涉及序列化/反序列化问题。一个更稳妥的做法是维护一个独立的TaskId到自定义状态的映射表，并在applyLoadPlan中为每个TaskView设置状态。

3. 性能优化与内存管理实战

RecentsView的流畅度直接关系到系统口碑。Android 14的源码中已经包含了许多优化，但仍有定制空间。

3.1 缩略图缓存策略调优

任务缩略图的加载是性能瓶颈之一。RecentsModel中的TaskThumbnailCache负责此事。它采用LRU缓存。你可以通过反射或直接修改源码来调整其参数：

• MAX_CACHE_SIZE：缓存的最大数量。在拥有大内存的设备上可以适当增加。
• MAX_CACHE_SIZE_BYTES：缓存的最大内存占用。需要根据设备分辨率（缩略图尺寸）和内存容量综合计算。

更高级的定制是修改缩略图的加载时机和分辨率。默认策略可能是在任务进入屏幕一定范围时开始加载。你可以尝试：

• 预加载：在applyLoadPlan绑定数据时，就请求加载缩略图（可能增加内存压力）。
• 分级加载：先加载低分辨率模糊图，快速显示，再异步替换为高清图。
• 智能丢弃：对于远离可视区域的任务，主动释放其缩略图资源。

3.2 视图复用池的优化

TaskViewPool的默认大小是固定的。在分析用户行为后，你可能会发现：

• 用户平均最近任务数量是5个，但池大小设为10，造成闲置。
• 或者用户频繁使用分屏，导致GroupedTaskViewPool不足，需要临时创建，引发卡顿。

通过埋点收集数据，动态调整池的大小，是一种数据驱动的优化思路。你可以在RecentsView初始化时，从配置文件中读取这些值，或者根据设备内存等级进行自适应设置。

// 伪代码：根据设备内存等级调整池大小 ActivityManager am = (ActivityManager) getContext().getSystemService(Context.ACTIVITY_SERVICE); boolean isLowRamDevice = am.isLowRamDevice(); int singleTaskPoolSize = isLowRamDevice ? 4 : 8; int groupedTaskPoolSize = isLowRamDevice ? 1 : 2; mTaskViewPool = new TaskViewPool(this, singleTaskPoolSize); mGroupedTaskViewPool = new TaskViewPool(this, groupedTaskPoolSize);

3.3 避免主线程阻塞与卡顿检测

尽管数据加载已在后台线程进行，但UI绑定（tv.bind()）和视图测量布局（onMeasure,onLayout）仍在主线程。如果自定义的TaskView布局过于复杂，或bind方法中执行了耗时操作，就会导致滑动卡顿。

建议：

• 使用Systrace或Perfetto工具录制进入最近任务和快速滑动时的轨迹，重点关注主线程的Choreographer#doFrame耗时。
• 将TaskView中不必要的UI更新（如频繁设置的文本、颜色）合并或延迟。
• 确保自定义的TaskView的onDraw方法尽可能简单，避免在滚动过程中创建新的Paint或Path对象。

4. 高级定制案例：实现“任务分组”与“智能排序”

让我们超越简单的UI修改，看两个更有挑战性的定制案例。

4.1 案例一：按应用开发商分组任务

默认的最近任务按时间倒序平铺。我们可以实现按应用包名的前缀（或从应用信息中读取的开发商字段）进行分组聚合。

实现思路：

1. 数据层扩展：在RecentTasksList.loadTasksInBackground加工数据时，不仅生成GroupTask列表，同时计算一个“分组键”（如developerName）。
2. 数据结构改造：设计一个新的TaskGroup类，包含groupKey和List<GroupTask>。
3. UI层适配：修改RecentsView，使其不再直接处理ArrayList<GroupTask>，而是处理ArrayList<TaskGroup>。在applyLoadPlan中，首先为每个TaskGroup创建一个分组标题视图（GroupHeaderView），然后依次添加该组下的所有TaskView。
4. 滚动与布局：需要重写PagedView的布局逻辑，计算分组标题和组内任务卡片的整体高度，实现分组内的紧凑布局和分组间的间隔。

这个改动涉及数据流、UI结构和布局算法的全方位调整，是检验对Recents模块理解深度的绝佳课题。

4.2 案例二：基于使用频率的智能排序

Android原生按时间排序。我们可以引入一个轻量级的本地数据库（如Room），记录每个任务（通过taskId和packageName标识）的被打开次数和累计使用时长。

实现步骤：

1. 数据收集：在系统层面（或Launcher内）监听应用切换和退出事件，更新该任务的使用频率数据。
2. 排序算法：在RecentTasksList返回数据前，介入排序过程。定义一个权重公式，例如：权重 = w1 * 最近使用时间得分 + w2 * 使用频率得分。在loadTasksInBackground方法返回最终列表前，根据权重进行排序。
3. 平滑过渡：排序规则改变后，任务卡片位置会剧烈变化，导致用户困惑。可以考虑在RecentsView中实现一个动画，展示任务卡片从旧位置移动到新位置的过程，这需要记录每个任务之前的位置索引。

潜在挑战：

• 性能：每次排序都需要读取数据库和计算，需做好缓存。
• 隐私：记录应用使用行为需符合隐私规范，可能需要在设置中提供开关。
• 冷启动：对于新安装的应用或很久未用的应用，缺乏历史数据，需要有合理的默认权重。

定制Android系统组件，尤其是像RecentsView这样核心的交互模块，是一场在功能、性能、稳定性三者之间寻求精妙平衡的旅程。阅读AOSP源码是起点，它提供了稳定可靠的框架和最佳实践。而真正的创新，始于你敢于在理解这套框架的基础上，针对特定的用户场景和设备特性，进行深思熟虑的“破坏”与重建。从调整一个缓存参数，到重写整个数据排序逻辑，每一步都需要详尽的测试——不仅仅是功能测试，更需要性能分析、内存泄露检测和跨版本兼容性验证。记住，最优雅的定制，往往是那些让用户感觉不到它的存在，却让体验悄然提升的改动。