1. 项目概述从用户手势到系统响应的旅程在Android 16或更高版本这里我们以Android 16作为代称指代当前最新的Android系统架构中分屏模式早已从一个炫酷的功能演变为提升大屏设备如平板、折叠屏手机生产力的核心交互范式。很多开发者或系统爱好者可能都好奇过当我们在最近任务列表长按一个应用图标或者从屏幕边缘向内滑动并停顿这个“分屏”的指令究竟是如何穿越复杂的系统层级最终让两个应用和谐地共享同一块屏幕的这背后是一套精密的、由用户界面UI、系统服务System Service和窗口管理器Window Manager共同协作的触发机制。今天我们就深入Android系统源码的腹地以“触发”为起点完整拆解分屏模式启动的初始链路。理解这个过程不仅有助于我们开发适配分屏的应用更能让我们洞悉Android多任务系统设计的精髓。2. 分屏触发机制的整体架构与设计思路在深入代码之前我们必须先建立起一个宏观的认知框架。Android的分屏触发并非单一入口而是一个多路并发的传感器网络旨在从不同交互场景中捕获用户的“分屏意图”。其核心设计思路是事件驱动和状态管理。2.1 核心设计哲学意图捕获与状态转换整个触发机制可以看作一个状态机。系统始终处于某种多任务状态例如全屏、画中画、分屏。用户的特定手势或操作我们称之为“触发事件”会向系统发送一个“切换至分屏状态”的意图Intent。系统服务主要是ActivityTaskManagerService和WindowManagerService在验证该意图的合法性如当前Activity是否支持分屏、设备是否处于可分屏状态后驱动整个窗口系统进行重构。触发事件主要来自两个核心路径最近任务列表Recents的UI交互这是最直观的触发方式。用户在Overview界面即最近任务列表中长按某个应用的标题栏或卡片会弹出包含“分屏”选项的菜单。手势导航Gesture Navigation的特定手势在启用全面屏手势导航时从屏幕底部向上滑动并停顿进入最近任务列表此时继续拖动某个应用卡片到屏幕顶部或侧边释放即可触发分屏。这两条路径最终会汇聚到同一个系统服务接口但它们的初始事件分发和处理流程各有不同。2.2 关键系统组件角色解析SystemUI (com.android.systemui) 它是触发事件的“第一现场”。RecentsActivity或相关的组件负责渲染最近任务列表并监听用户的长按、拖拽事件。它不处理核心逻辑而是将事件“上报”。ActivityTaskManagerService (ATMS) Android多任务管理的“大脑”。它持有所有Activity、Task任务栈的状态信息。当收到分屏请求时它负责决定哪个Task应该进入分屏以及它应该处于屏幕的哪一侧主屏或副屏。WindowManagerService (WMS) 窗口系统的“指挥官”。它根据ATMS的指令具体执行窗口的创建、销毁、布局和动画。分屏的本质就是WMS将屏幕区域划分为两个独立的“任务容器”并指导每个容器内的窗口进行重新排布。Divider (分割线控件) 这是一个特殊的系统窗口由SystemUI管理。它不仅在视觉上呈现为可拖动的分割条更是一个重要的交互控件其触摸事件会直接驱动WMS调整两个分屏区域的大小。理解这些组件的分工协作是读懂后续源码的关键。3. 触发路径一最近任务列表Recents长按触发详解这是最经典的触发方式。我们从用户手指长按屏幕这个物理事件开始追踪。3.1 事件捕获与菜单弹出在SystemUI的代码库中负责最近任务列表视图渲染的通常是TaskView或TaskThumbnailView。当用户长按事件ACTION_DOWN后经过一定时间阈值被识别会调用其onLongClick方法。// 伪代码示意流程非直接源码 public class TaskView { Override public boolean onLongClick(View v) { // 1. 获取当前任务对应的TaskInfo ActivityManager.RunningTaskInfo taskInfo getTaskInfo(); // 2. 检查该任务是否支持分屏 if (canLaunchTaskInSplitScreen(taskInfo)) { // 3. 显示上下文菜单其中包含“分屏”选项 showContextMenu(MENU_ITEM_SPLIT_SCREEN); } return true; } }弹出的菜单是一个PopupMenu或ContextMenu其中“分屏”选项的点击事件监听器被设置。当用户点击这个菜单项时真正的触发逻辑才开始。3.2 向系统服务发起请求菜单点击事件的处理函数中会通过ActivityTaskManagerService的接口发起分屏请求。这里通常不会直接调用ATMS而是通过一个封装类比如SplitScreenControllerSystemUI内部或直接使用ActivityManager的API。关键调用链可能如下// 在SystemUI的某个Controller或Action中 private void enterSplitScreenForTask(int taskId) { // 获取IActivityTaskManager的Binder代理 IActivityTaskManager atm ActivityTaskManager.getService(); try { // 调用系统服务的方法。注意这是一个高度简化的示意。 // 实际方法名和参数可能随版本变化例如startTaskInSplitScreen、enterSplitScreen等。 atm.enterSplitScreenMode(taskId, SPLIT_SCREEN_POSITION_TOP_OR_LEFT); } catch (RemoteException e) { Log.e(TAG, Failed to enter split screen, e); } }这里传递了两个关键参数taskId要放入分屏的任务ID和position希望它处于的位置。系统服务收到这个请求后会进行一系列校验。注意兼容性与API变化Android在不同版本中对分屏API的调整很大。在早期版本如Android N可能通过ActivityOptions.setLaunchWindowingMode()实现而在新版本中SplitScreenController等类被引入以提供更稳定的抽象。阅读源码时务必关注你所在分支的类和方法名。3.3 系统服务的校验与状态准备请求抵达ActivityTaskManagerService后会进入其enterSplitScreenMode或类似的方法。这里会发生几件重要的事情权限与状态检查 检查调用者SystemUI是否有权限检查设备当前是否允许分屏例如是否锁屏、是否有弹窗遮挡、当前前台Activity是否固定了方向等。目标Task验证 根据传入的taskId找到对应的Task对象。验证该Task的根Activity是否设置了android:resizeableActivity”true”或者其android:supportsPictureInPicture属性是否为true因为支持画中画通常也意味着可调整大小。如果Activity明确声明了android:screenOrientation为locked如portrait则可能无法进入分屏。寻找或创建搭档Task 分屏需要两个Task。系统需要决定另一个分屏位置由谁占据。策略通常是如果当前已经有应用在全屏运行则将其作为另一个分屏的候选。如果当前没有则另一个位置可能保持为空或者启动桌面Home。创建或更新任务栈TaskStack ATMS内部维护着TaskStack的概念用于组织Task的层级和位置。触发分屏意味着要创建或重组特定的TaskStack并将其与屏幕的特定区域绑定。这个过程涉及大量ActivityRecord、TaskRecord、TaskStack等内部类状态的变更是ATMS核心逻辑的体现。4. 触发路径二手势导航拖拽触发深度剖析全面屏手势下的拖拽触发流程更为动态和复杂它融合了触摸事件处理、动画和直接的状态变更。4.1 手势识别与任务卡片抓取当用户从底部上滑进入最近任务列表Overview时SystemUI的OverviewComponent被激活。在Overview界面每个任务同样以卡片TaskView形式呈现。此时如果用户继续拖拽一个卡片ACTION_MOVESystemUI会进入一个特殊的“拖拽状态”。TaskView的onTouchEvent或专门的GestureDetector会判断拖拽的位移和方向。当拖拽超过一定阈值并且方向是朝向屏幕左/右边缘或顶部时系统会判定用户可能想进行分屏。// 伪代码描述手势判断逻辑 if (dragDistance threshold dragDirection DIRECTION_TO_EDGE) { // 视觉反馈可能改变卡片透明度、显示目标区域高亮等 mTaskView.setDraggingForSplit(true); // 通知手势控制器准备进入分屏流程 mGestureController.prepareSplitScreenDrag(mTaskView); }4.2 实时视觉反馈与目标区域判定在拖拽过程中UI需要提供清晰的视觉反馈。通常屏幕会被划分为几个区域例如顶部区域、左侧区域、右侧区域。当拖拽的卡片中心点进入这些“投放区域”时该区域会高亮显示例如半透明蒙层提示用户释放手指即可将应用放置于此。这个高亮区域的判定逻辑在DropTarget或RegionController这样的类中实现。它持续监听卡片位置并与预定义的屏幕区域进行碰撞检测。4.3 释放手势与触发执行当用户释放手指ACTION_UP时事件处理逻辑会根据释放时卡片所处的最终区域来决定行为。public void onDragEnd(float x, float y) { DropRegion dropRegion mRegionController.getDropRegionAt(x, y); if (dropRegion ! null dropRegion.type TYPE_SPLIT_LEFT) { // 确定投放到了左侧分屏区域 int taskId mDraggedTaskView.getTaskId(); // 同样通过Controller或直接调用系统服务 mSplitScreenController.enterSplitScreen(taskId, SPLIT_SCREEN_POSITION_LEFT); // 播放一个平滑的动画将卡片“吸”到目标区域 playSnapAnimation(mDraggedTaskView, dropRegion.bounds); } else { // 未投放到分屏区域则可能返回Overview或退出 cancelDragAndReturn(); } }手势触发的核心优势在于直接操纵它将“选择任务”和“选择位置”两个步骤合并为一个流畅的拖拽动作用户体验更连贯。5. 核心交汇点系统服务中的统一入口与处理无论来自长按菜单还是手势拖拽最终都会汇聚到ActivityTaskManagerServiceATMS的某个方法。我们以enterSplitScreen为例看看这个“统一入口”做了什么。5.1 入口方法的关键步骤假设我们跟踪到ActivityTaskManagerService.enterSplitScreen(int taskId, int position)同步锁与权限校验 方法开始通常会获取ATMS的全局锁mGlobalLock确保多线程安全。然后进行调用权限检查checkCallingPermission。获取并验证目标Task 通过mRootWindowContainer.getTask(taskId)获取Task对象。如果Task不存在或已被销毁则返回失败。检查设备与窗口状态调用canEnterSplitScreenMode()检查全局开关开发者选项、设备策略等是否允许。检查KeyguardManager是否锁屏。检查当前是否有系统弹窗如权限对话框、警告框阻挡。确定分屏配对策略 这是核心逻辑之一。系统需要决定“谁和这个Task一起分屏”。Task companionTask null; // 策略1查找当前处于前台全屏的Task Task topFullscreenTask getTopFullscreenTask(); if (topFullscreenTask ! null topFullscreenTask ! targetTask) { companionTask topFullscreenTask; } // 策略2如果策略1失败且允许空分屏则companionTask可能为null显示桌面 // 策略3某些版本可能会尝试从历史记录中寻找最近的全屏Task创建或获取分屏容器 ATMS通过RootWindowContainer来管理所有窗口容器。它会确保存在一个SplitScreenController或类似的容器控制器并调用其方法将目标Task和伴侣Task放入对应的容器位置。更新任务栈与窗口模式 将涉及的两个Task的窗口模式Windowing Mode属性更新为WINDOWING_MODE_MULTI_WINDOW或其子模式如WINDOWING_MODE_SPLIT_SCREEN_PRIMARY。这个属性是后续WindowManagerService进行布局的关键依据。通知WindowManagerService 通过WindowManagerService的接口如setTaskWindowingMode通知WMS这两个Task的窗口模式已改变需要重新组织显示。5.2 WindowManagerService的响应与窗口重构ATMS完成了“逻辑状态”的变更而视觉上的变化则由WindowManagerService执行。接收模式变更 WMS的setTaskWindowingMode方法被调用。计算新的布局 WMS的DisplayArea和Task容器层级结构开始工作。DisplayArea代表屏幕的一块区域。在分屏模式下屏幕顶层的DisplayArea如TaskDisplayArea会被划分为两个子区域每个区域绑定一个Task。应用窗口策略 WMS的WindowState和WindowContainer会重新计算每个窗口的边界Frame。原本全屏的窗口其Frame会被设置为屏幕的一半减去分割线宽度。安排过渡动画 WMS会安排一个从当前状态全屏到目标状态分屏的动画。这个动画可能由SurfaceAnimator等类负责确保窗口的移动、缩放平滑进行。更新输入焦点 窗口布局改变后输入系统InputDispatcher需要知道当前触摸事件应该发送给哪个窗口。WMS会更新焦点窗口通常是用户刚刚操作的那个Task所在的窗口。至此从用户触发到屏幕完成分屏布局的完整链条就打通了。用户看到了两个应用并排显示中间有一条可拖动的分割线。6. 常见问题与调试技巧实录在实际开发和源码阅读中你可能会遇到各种问题。以下是一些典型场景和排查思路。6.1 问题排查速查表问题现象可能原因排查方向与调试技巧长按最近任务无分屏选项1. Activity不支持分屏。2. 设备策略禁用。3. 当前界面状态不允许如弹窗存在。1. 检查目标Activity的AndroidManifest.xml确保resizeableActivity”true”或未固定方向。2. 执行adb shell dumpsys activity restrictions查看用户限制。3. 使用adb shell dumpsys window查看当前焦点窗口和mSystemUiFlags。手势拖拽到边缘无反应1. 手势识别阈值未达到。2. 拖拽目标区域计算错误。3. SystemUI相关服务崩溃或未响应。1. 在GestureController或DropRegion相关类中加Log打印触摸坐标和区域判断结果。2. 检查adb logcat | grep -i systemui是否有异常。3. 确认开发者选项中“强制将活动设为可调整大小”是否开启用于调试。分屏触发后只有一个应用显示另一边黑屏或为桌面1. 未找到合适的伴侣Task。2. 伴侣Task的Activity启动失败或已销毁。3. 窗口布局计算错误。1. 在ATMS的enterSplitScreen方法中打印companionTask的值。2. 使用adb shell am stack list查看所有任务栈状态确认伴侣Task是否存在且处于RESUMED状态。3. 检查WMS的日志搜索split、windowingmode等关键词。分屏触发过程中动画卡顿或闪烁1. 应用侧未做好分屏状态切换如未重走生命周期。2. 窗口Surface重建耗时过长。3. 系统负载过高。1. 在应用Activity的onConfigurationChanged和onMultiWindowModeChanged方法中加Log观察其调用时机和耗时。2. 使用adb shell dumpsys SurfaceFlinger --latency查看帧率。3. 检查logcat中是否有Choreographer跳帧Skipped XX frames的警告。6.2 源码阅读与调试心得善用“假设-验证”法 不要试图一次性理解所有代码。先根据功能描述如“长按分屏”猜测关键类名如Recents、SplitScreen、Divider在源码中搜索。找到入口后通过打印调用栈Thread.dumpStack()或在调试器中打断点来验证你的猜测并顺藤摸瓜。关注生命周期和状态标志 分屏触发涉及大量状态变迁。重点关注ActivityRecord、Task、WindowContainer等类中的mWindowingMode、mMultiWindowMode等字段。使用adb shell dumpsys activity activities命令可以直观地看到这些状态。理解Binder通信 SystemUI和ATMS/WMS之间通过Binder IPC通信。在代码中看到IActivityTaskManager或IWindowManager的调用时要意识到这是跨进程调用。客户端SystemUI的调用最终会在服务端ATMS/WMS的onTransact方法中找到对应的处理函数。可视化调试工具 除了dumpsys开启开发者选项中的“显示布局边界”、“窗口动画缩放速度调慢”等可以辅助你观察窗口的实时变化。对于手势可以开启“指针位置”来精确查看触摸轨迹。版本差异是最大的坑 Android分屏相关的代码在N、O、P、Q、R等版本间重构频繁。你在AOSP主线看到的类在具体厂商的定制版本中可能不存在或被修改。务必确认你阅读的源码分支与你想要研究的目标系统版本一致。最可靠的方法是直接查看你设备对应版本的源码如果开源或使用反编译工具仅用于学习研究查看系统框架。触发分屏模式只是整个分屏系统的序幕。一旦进入分屏状态后续的分割线拖动调整大小、应用间焦点切换、退出分屏等逻辑同样复杂而精妙。理解了这个触发流程就如同掌握了打开这扇大门的钥匙后续对分屏内部运作机制的分析就有了坚实的基础。希望这篇基于源码视角的深度拆解能帮助你更透彻地理解Android这一核心交互功能背后的设计智慧。