新版负一屏变天了！分享pixel新桌面负一屏技术调研报告

背景

有学员反馈说新版本的pixel负一屏的方案已经不是采用以前的Overlay那种独立Window方式，而是使用的独立的Activity方式，针对学员提出的这个疑问，马哥这边也下载了一个pixel的模拟器进行调研pixel的新版本负一屏方案原理。

直观认识：

主桌面

负一屏

拖动中间时候

调研原理部分

层级结构树部分

使用dumpsys activity containers和sf等查看负一屏情况

DefaultTaskDisplayAreatype=undefinedmode=fullscreen override-mode=fullscreen requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ ├─Task=1type=HOMEmode=fullscreen override-mode=fullscreen requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ └─Task=3type=HOMEmode=fullscreen override-mode=undefined requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ ├─ ActivityRecord{6892885u0 com.google.android.apps.nexuslauncher/.NexusLauncherActivity t3}type=HOMEmode=fullscreen override-mode=undefined requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ │ └─ 6a55d8e com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivitytype=HOMEmode=fullscreen override-mode=undefined requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ └─ TaskFragment{b923527mode=multi-window}type=HOMEmode=MULTI-WINDOW override-mode=MULTI-WINDOW requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ └─ ActivityRecord{184635947u0 com.google.android.googlequicksearchbox/com.google.android.apps.search.googleapp.launcher.minusone.activity.MinusOneActivity t3}type=HOMEmode=MULTI-WINDOW override-mode=undefined requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]│ │ └─ e843f4 com.google.android.googlequicksearchbox/com.google.android.apps.search.googleapp.launcher.minusone.activity.MinusOneActivitytype=HOMEmode=MULTI-WINDOW override-mode=undefined requested-bounds=[0,0][0,0]bounds=[0,0][2076,2152]

上面的相比正常的多了一个 TaskFragment{b923527 mode=multi-window}的容器，这个是专门装载负一屏的task。

关键属性：

• TaskFragment 以WINDOWING_MODE_MULTI_WINDOW创建，与 fullscreen 的 Launcher Activity 共存于同一 Task
• TaskFragment 的organizerUid=10195(com.google.android.apps.nexuslauncher)，由 Launcher 控制
• MinusOneActivity 进程为com.google.android.googlequicksearchbox:googleapp(uid=10161)，与 Launcher不同进程

activity的生命周期部分

桌面滑动到负一屏

桌面滑动到负一屏时候，桌面首先就已经Pasue了，然后负一屏进行resume，彻底滑到负一屏后，桌面进行stop。

负一屏滑动回桌面

可以看到桌面先调研onStart，松手后滑到桌面才是resume，然后负一屏的activity就进行stop。

三种状态与生命周期

1 CLOSED 状态

• TaskFragment 存在但setHidden=true
• MinusOneActivity 未启动（或已 stopped）
• Launcher 独占显示

2 OPEN 状态

• TaskFragmentsetHidden=false, MinusOneActivity RESUMED
• Launcher Window 仍 VISIBLE 但在 WMS 中mObscured=true（被 TF 遮挡）
• Launcher Activity 状态为 PAUSED
• MinusOneActivity 为mFocusedWindow

3 MID-DRAG 状态（实验验证）

以下数据来自拖动到中间位置时的实际 dumpsys 实验：

WMS 层面 (dumpsys window)

关键发现：拖动期间 MinusOne 的 WindowmViewVisibility=0x0 (VISIBLE)且mHasSurface=true。这与 OPEN 状态一致，说明 MinusOne 的 Window 在整个拖动过程中保持可见。

Activity 层面 (dumpsys activity)

Task{68ab20d #3 type=home} ├─ topResumedActivity = MinusOneActivity ← ★ 负一屏是 resumed ├─ TaskFragment{b923527 mode=multi-window} │ └─ MinusOneActivity: state=RESUMED │ mWindowingMode=multi-window └─ NexusLauncherActivity: state=PAUSED mWindowingMode=fullscreen

关键发现：拖动过程中 MinusOneActivity 已经处于RESUMED状态，Launcher 处于PAUSED。说明一旦开始拖动（ACTION_DOWN），系统就已经完成了 Activity 生命周期的切换。用户拖动的是"已经 RESUME 的 MinusOneActivity 的 Surface 的位置"，而不是在拖动过程中做 Activity 切换。

总结部分

Pixel Launcher 的负一屏不是在 Launcher 进程内嵌入一个 View 或 Fragment，而是利用 Android 12+ 的TaskFragment API，在 Launcher 的 Task 内创建一个独立的TaskFragment，将 Google App (Velvet) 的MinusOneActivity以multi-window模式嵌入其中。

两个 Activity 拥有各自独立的 Window 和 Surface，在 SurfaceFlinger 层面通过 z-order 叠加显示，通过两种不同的偏移机制实现同步滑动：

上面就是马哥对于新版本负一屏的初步调研方案，后续有时间会进行模仿pixel实现新版本负一屏的demo，欢迎相关vip学员找马哥交流实现方案等。