Android 11中ActivityRecord可见性处理的深度解析与优化实践

1. 从一次“黑屏”卡顿说起：为什么我们要关心ActivityRecord的可见性？

大家好，我是老张，一个在Android系统层和应用层都摸爬滚打多年的开发者。不知道你们有没有遇到过这样的场景：你的应用正在前台运行，用户突然按了Home键回到桌面，然后又立刻从最近任务列表切回来。理论上，应用应该瞬间恢复，但有时候，屏幕会短暂地“黑”一下，或者界面有明显的卡顿感，然后才恢复正常。

我最近在优化一个视频播放应用时就踩了这个坑。用户反馈说，在应用切换时，视频会卡顿甚至黑屏半秒，体验非常糟糕。经过一番排查，问题根源并不在我的业务代码里，而是出在了Activity的可见性管理上，更具体地说，是Android 11系统内部对ActivityRecord可见性处理的逻辑上。

那么，ActivityRecord到底是什么？你可以把它理解为Activity在系统服务（SystemServer）里的“身份证”和“档案袋”。我们平时在应用层写的Activity，只是一个壳子，定义了界面和逻辑。当这个Activity被系统启动和管理时，系统服务端就会创建一个对应的ActivityRecord对象。这个对象同步记录着Activity的完整生命周期状态、窗口信息、任务栈归属、配置变化等所有关键信息。可以说，窗口能不能显示、显示在哪个图层、尺寸是多少，这些底层的渲染逻辑，最终都要落到对ActivityRecord状态的操作上。

所以，ActivityRecord的可见性处理，直接决定了我们的Activity窗口何时被展示、何时被隐藏。如果这个过程效率低下或者逻辑有瑕疵，就会直接导致我们上面提到的切换卡顿、黑屏等问题。今天，我就带大家深入到Android 11的源码里，把ActivityRecord可见性处理的来龙去脉掰开揉碎了讲清楚，并且分享几个我在实战中总结出来的优化思路，让你的应用切换如丝般顺滑。

2. 庖丁解牛：深入ensureActivitiesVisible的调用链

当系统需要更新一批Activity的可见状态时（比如启动新Activity、回到桌面、分屏变化），最顶层的入口函数是RootWindowContainer.ensureActivitiesVisible()。这个名字起得很直白，就是“确保该可见的Activity都可见”。我们不要被它吓到，跟着我的思路，把它想象成一个从公司CEO到基层员工的层层下达指令的过程。

2.1 指令的发起：从RootWindowContainer开始

整个流程的源头在RootWindowContainer，它是窗口容器体系的根。它的ensureActivitiesVisible方法就像一个总经理，负责把“更新可见性”这个任务布置下去。为了防止重复劳动（递归调用），这里有一道安全检查：如果系统正在更新可见性（mStackSupervisor.inActivityVisibilityUpdate()），就直接返回。这就像总经理看到部门已经在开会处理这件事了，就不会再发一遍同样的邮件。

// frameworks/base/services/core/java/com/android/server/wm/RootWindowContainer.java void ensureActivitiesVisible(ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { if (mStackSupervisor.inActivityVisibilityUpdate()) { // 安全检查：防止递归 return; } try { mStackSupervisor.beginActivityVisibilityUpdate(); // 从后往前遍历所有显示屏（Display） for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) { final DisplayContent display = getChildAt(displayNdx); display.ensureActivitiesVisible(starting, configChanges, preserveWindows, notifyClients); } } finally { mStackSupervisor.endActivityVisibilityUpdate(); } }

总经理（RootWindowContainer）自己不干活，他把任务分给了各个“区域经理”——DisplayContent，也就是一块块物理或虚拟的屏幕。这里遍历的顺序是从后往前（getChildCount() - 1），这通常意味着从最顶层的显示区域开始处理，符合视觉上的优先级。

2.2 任务的分解：DisplayContent与TaskDisplayArea

DisplayContent收到指令后，逻辑和总经理类似：先设置一个“正在处理”的标记（mInEnsureActivitiesVisible）防止递归，然后把任务进一步下发给自己的“部门主管”——TaskDisplayArea。

// frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java void ensureActivitiesVisible(ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { if (mInEnsureActivitiesVisible) { return; } mInEnsureActivitiesVisible = true; try { for (int i = getTaskDisplayAreaCount() - 1; i >= 0; --i) { getTaskDisplayAreaAt(i).ensureActivitiesVisible(starting, configChanges, preserveWindows, notifyClients); } } finally { mInEnsureActivitiesVisible = false; } }

TaskDisplayArea可以理解为一个能够容纳多个任务栈（Task）的显示区域。在常见的手机全屏模式下，通常只有一个TaskDisplayArea；但在分屏或多窗口模式下，可能会有多个。部门主管继续把任务派给每个“项目组”——ActivityStack（在Android 10以后，更准确的概念是Task，但源码中仍大量使用Stack这个历史名称）。

2.3 真正的执行者：ActivityStack与EnsureActivitiesVisibleHelper

指令层层传递，最终到达了ActivityStack。到这里，终于不再是简单的“转发”了，真正的核心逻辑即将登场。

// frameworks/base/services/core/java/com/android/server/wm/ActivityStack.java void ensureActivitiesVisible(@Nullable ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { mStackSupervisor.beginActivityVisibilityUpdate(); try { // 核心：交给Helper类处理 mEnsureActivitiesVisibleHelper.process(starting, configChanges, preserveWindows, notifyClients); // ... 处理透明Activity等待绘制的逻辑 } finally { mStackSupervisor.endActivityVisibilityUpdate(); } }

ActivityStack自己也没有大包大揽，它雇佣了一个专业的“工具人”——EnsureActivitiesVisibleHelper。这个Helper类，才是真正干脏活累活的“一线员工”。这种设计是典型的“委托模式”，将复杂的可见性计算逻辑封装到一个独立的类中，使得ActivityStack的代码更清晰，也便于单独测试和维护这个核心算法。

3. 核心算法揭秘：EnsureActivitiesVisibleHelper如何决策？

现在，我们来到了最核心的部分。EnsureActivitiesVisibleHelper.process()方法是整个可见性判定的“大脑”。它接收一个关键的参数starting，这通常代表正在启动或恢复的那个最顶层的Activity。它的工作可以分为三个关键步骤：

第一步：重置与初始化。调用reset()方法，准备好本次计算所需的所有“原材料”。这其中最关键的是确定当前栈（Container）的“顶层运行中的Activity”（mTop），以及计算一个至关重要的布尔值：mBehindFullscreenActivity。

// EnsureActivitiesVisibleHelper.java - reset 方法关键片段 void reset(ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { mStarting = starting; mTop = mContiner.topRunningActivity(); // 找到栈顶Activity mContainerShouldBeVisible = mContiner.shouldBeVisible(mStarting); // 判断整个栈是否应该可见 mBehindFullscreenActivity = !mContainerShouldBeVisible; // 核心逻辑：如果栈本身不该见，那其中的Activity就被全屏Activity挡住了 // ... 其他初始化 }

这里的mContiner就是调用它的ActivityStack。mBehindFullscreenActivity这个变量名非常形象，它表示当前栈是否处在一个不透明的全屏Activity后面。它的值取反于mContiner.shouldBeVisible(mStarting)。也就是说，系统先判断这个任务栈整体是否应该可见，如果栈都不可见，那栈里的每个Activity自然都被“全屏Activity”挡住了。

第二步：遍历与判定。初始化完成后，Helper会遍历当前栈内的所有ActivityRecord。对每一个ActivityRecord，都会调用私有的setActivityVisibilityState方法，这是决定单个Activity命运的“法官”。

第三步：执行可见性操作。在setActivityVisibilityState方法里，根据判定结果，调用ActivityRecord的makeVisibleIfNeeded（需要可见时）或makeInvisible（需要隐藏时）方法，最终触发窗口的显示或隐藏。

那么，这个“法官”setActivityVisibilityState究竟依据什么来判案呢？它的核心判决依据只有一条：ActivityRecord.shouldBeVisible()方法的返回值。这个方法综合了多方面因素：

// ActivityRecord.java - shouldBeVisible 核心逻辑 boolean shouldBeVisible(boolean behindFullscreenActivity, boolean ignoringKeyguard) { // 1. 先忽略锁屏，看是否被全屏Activity挡住 visibleIgnoringKeyguard = (!behindFullscreenActivity || mLaunchTaskBehind) && okToShowLocked(); if (ignoringKeyguard) { return visibleIgnoringKeyguard; } // 2. 再结合锁屏状态、Display睡眠状态等进行最终判断 // ... (后续详细分析) }

首先，它利用上一步传来的behindFullscreenActivity（就是mBehindFullscreenActivity）判断自己是否被前面的全屏Activity遮挡。如果没有被遮挡（或者自己是mLaunchTaskBehind方式启动），并且自身状态okToShowLocked()（比如没有正在销毁），那么“忽略锁屏的可见性”就为真。 然后，它会进一步结合设备的锁屏状态、屏幕是否休眠等现实因素，给出最终的可见性判决。例如，即使逻辑上应该可见，但如果设备正处于锁屏状态，且这个Activity不是可以显示在锁屏之上的类型，那么最终仍然不可见。

4. 可见性判定的基石：Task.shouldBeVisible的复杂逻辑

刚才我们看到，决定mBehindFullscreenActivity的关键是mContiner.shouldBeVisible(mStarting)，对于ActivityStack（其本质是Task）来说，就是Task.shouldBeVisible()方法。这个方法是我认为整个流程中最复杂、也最体现Android多窗口系统设计精髓的部分。它要回答一个问题：在一个可能包含分屏、浮动窗口、透明Activity的复杂屏幕环境下，我这个任务栈到底能不能被用户看到？

它的核心是getVisibility()方法，返回三种状态：

• STACK_VISIBILITY_VISIBLE：完全可见。
• STACK_VISIBILITY_VISIBLE_BEHIND_TRANSLUCENT：可见，但前面有透明的Activity（全屏或分屏）覆盖。
• STACK_VISIBILITY_INVISIBLE：完全不可见。

它的判断逻辑是一个严谨的“排查法”，我把它总结为以下几个步骤，你可以想象成在人群中找位置：

1. 检查自身状态：如果栈没被正确附加（!isAttached()）或被强制隐藏（isForceHidden()），直接返回不可见。这就像你连进入会场的资格都没有。

2. 检查“父亲”的状态：如果这个栈有父栈（比如在递归任务中），那么父亲栈的可见性直接限制了儿子。父亲完全不可见，儿子肯定不可见；父亲只是被透明物遮挡，那儿子最多也只能获得“被透明遮挡的可见”状态。

3. 与“兄弟姐妹”栈竞争：这是最核心的循环逻辑。它会遍历同一个TaskDisplayArea下的所有其他栈（Task），从最顶上的那个开始往下看（for (int i = parent.getChildCount() - 1; i >= 0; --i)）：

   • 遇到不透明的全屏栈：如果前面有一个不透明的、全屏模式的栈，那么自己肯定被完全挡住，直接返回不可见。
   • 遇到分屏栈：这里要仔细区分主分屏（SPLIT_SCREEN_PRIMARY）和副分屏（SPLIT_SCREEN_SECONDARY）。系统会记录是否遇到了不透明的主/副分屏栈。如果自己也是主分屏栈，且前面已经有一个不透明的主分屏栈，那自己就被挡住了。副分屏同理。
   • 特殊规则：像助理类型的栈（如语音助手），如果发现已经有分屏栈存在，则自己不可见。这是为了避免Z-order冲突和视觉混乱。

4. 处理透明覆盖物：经过上述残酷竞争，如果还没被判为不可见，最后还要检查覆盖物是否透明。比如自己是全屏栈，但覆盖在顶上的分屏栈是透明的，那么自己就是VISIBLE_BEHIND_TRANSLUCENT状态。

为了更直观，我们可以用一个表格来总结不同场景下，一个普通全屏任务栈（Task）的可见性结果：

这套复杂的逻辑，确保了在多任务、多窗口环境下，视觉层级的正确性，避免了窗口的胡乱叠加和显示错误。

5. 实战优化：从原理到性能提升的可行路径

理解了“为什么”之后，我们来看看“怎么做”。如何利用这些知识，来优化我们应用的Activity切换性能，减少黑屏和卡顿呢？我分享几个从系统原理引申出的实战经验。

优化点一：谨慎使用透明主题和窗口背景。从Task.getVisibility()的逻辑我们知道，透明（Translucent）Activity会影响后面栈的可见性状态（变成VISIBLE_BEHIND_TRANSLUCENT）。虽然这能实现一些酷炫效果，但它增加了系统计算的复杂度。更关键的是，当你的Activity设置为透明时，系统在切换过程中可能需要额外的时间来处理“等待绘制”的逻辑（即mTranslucentActivityWaiting和mUndrawnActivitiesBelowTopTranslucent的判断）。

• 建议：如果不是必须（比如需要实现模糊背景、对话框式Activity），尽量使用不透明主题。如果必须透明，确保其布局层次简单，避免在onCreate或onResume中执行繁重的初始化，因为此时后面的Activity可能正处于等待绘制的状态。

优化点二：理解并优化Configuration变化。在ensureActivitiesVisible的调用链中，始终伴随着一个configChanges参数。当Activity可见性发生变化时，系统通常会检查配置（如屏幕旋转、尺寸变化）并决定是否要重启Activity。这个过程是冻结屏幕（freeze）的，可能导致短暂白屏。

• 建议：仔细评估你的Activity需要处理哪些配置变化。在AndroidManifest.xml中，通过android:configChanges声明你可以自行处理的配置，例如orientation|screenSize|smallestScreenSize。这样，当屏幕旋转时，系统不会重启你的Activity，而是调用onConfigurationChanged方法，你可以在这里手动调整UI，体验会流畅得多。但切记，只声明你能完美处理的选项，否则会出现布局错乱。

优化点三：避免在“不可见”或“即将可见”时执行繁重操作。ActivityRecord.shouldBeVisible的判断涉及到锁屏和屏幕休眠。如果你的应用需要在后台准备数据，请注意判断Activity的当前可见状态。

• 代码示例：

  // 在Activity中 @Override public void onWindowFocusChanged(boolean hasFocus) { super.onWindowFocusChanged(hasFocus); if (hasFocus) { // 真正获得焦点，适合执行一些视图动画或高频率更新 startHeavyAnimationOrUpdate(); } else { // 失去焦点，暂停不必要的操作 pauseBackgroundWork(); } } // 结合生命周期，更精确 @Override protected void onResume() { super.onResume(); // 注意：onResume时，窗口可能还未完成绘制（尤其是透明主题下） // 繁重的UI操作可以稍后延迟执行 getWindow().getDecorView().post(() -> { if (isResumed() && !isDestroyed()) { // 此时UI更可能已准备好 loadDataAndUpdateUI(); } }); }

  不要盲目在onResume中加载所有数据。对于非立即必须的数据，可以延迟加载，或者根据isVisibleToUser()这样的方法来判断。

优化点四：处理深度链接（Deep Link）或外部启动时的冷启动压力。当你的应用从完全后台被一个Deep Link唤醒时，系统需要创建进程、初始化Activity、并走完完整的可见性判断流程。如果此时你的Application和Activity的onCreate里做了太多事情，黑屏时间就会很长。

• 建议：采用“渐进式启动”。在SplashActivity或首个Activity中，只做最必要的初始化（如恢复登录态），立即显示一个简单的占位界面。将耗时的网络请求、数据库初始化等，放在后台线程或延迟到主界面显示后再进行。使用ViewStub延迟加载复杂布局。给用户一种“应用已经启动”的即时响应感。

6. 调试与监控：让黑盒变成白盒

理论优化之后，我们还需要工具来验证效果。Android系统贴心地为我们预留了调试可见性处理的日志开关。

方法：打开Visibility调试日志在终端使用adb命令，可以动态打开系统层关于Visibility处理的详细日志：

adb shell setprop log.tag.ActivityTaskManagerVisibility V adb shell stop && adb shell start # 可能需要重启system_server，或者重启设备使配置生效

之后，通过adb logcat | grep -i visibility过滤日志，你就能看到类似ensureActivitiesVisible behind ...、Make visible? ...、Make invisible? ...这样的详细输出。这能帮你清晰地看到在某个用户操作（如返回、分屏）后，系统遍历了哪些ActivityRecord，并对它们做出了什么可见性决策。这对于复现和定位那些“时好时坏”的显示问题非常有帮助。

进阶监控：使用Perfetto进行系统跟踪对于更深入的性能分析，我强烈推荐使用Perfetto。它可以记录内核、系统服务、应用进程的完整调用栈和事件。

1. 在开发者选项中打开“系统跟踪”。
2. 使用adb shell perfetto命令或Perfetto的Web UI（ui.perfetto.dev）开始录制。
3. 执行你怀疑有问题的操作（如快速切换应用）。
4. 停止录制并分析。

在Perfetto的am（Activity Manager）轨道中，你可以直观地看到ensureActivitiesVisible、makeVisibleIfNeeded等函数的耗时，以及它们发生在哪个线程。如果发现某个调用耗时异常长（比如超过16ms，一帧的时间），结合调用栈，你就能精准定位到是系统本身的瓶颈，还是你的Activity某些回调（如onConfigurationChanged）执行过慢所拖累。

踩过几次坑之后，我最大的体会是：对于Android开发，尤其是追求极致体验的开发，不能只停留在应用API的层面。偶尔把头探进系统层的“引擎室”看看，理解那些黑盒机制是如何运作的，往往能让我们写出更健壮、更高效的应用代码。当你明白了ActivityRecord可见性处理的这套精密的“决策树”后，再遇到UI显示问题，你就不再是盲目地猜测和试错，而是能够有方向、有依据地进行排查和优化。希望这篇深度解析，能成为你工具箱里的一把利器。