背景

近期有学员在fw面试wms相关业务时候，有问到关于deferWindowLayout和continueWindowLayout相关的作用，学员对这块理解相对比较浅导致面试没有通过，今天我们来深入剖析一下关于这块内容（基于aosp13版本）。

在 Android 系统源码中，deferWindowLayout 和 continueWindowLayout 是成对出现的窗口布局控制方法，定义在 ActivityTaskManagerService 中，底层委托给 WindowSurfacePlacer 的 deferLayout 和 continueLayout。这套机制用于在连续修改多个窗口状态时，把布局计算延后到修改全部完成之后，统一执行一次。

一、为什么需要这两个方法

一般面试能回答到这个就是不错的，能回答到说明理解还是到位，当然背书也不行哈，还是要结合代码真正理解，才可以不变应万变。

窗口状态的任何变化（添加、移除、大小变化、可见性变化）最终都要触发一次全局布局计算，即 performSurfacePlacement。这个操作会遍历整个窗口树，重新计算所有窗口的 frame 和可见性，再同步给 SurfaceFlinger，开销比较大。

deferWindowLayout / continueWindowLayout 解决的问题有两个：

1. 性能：连续修改多个窗口状态时，如果每次修改都立即触发布局，会重复执行多次 performSurfacePlacement。通过 defer 把布局延后，等所有修改完成后统一执行一次。
2. 一致性：一组相关的状态修改作为一个整体提交，中间状态不会单独触发一次布局被渲染出来。

二、实现原理

1. WindowSurfacePlacer 中的计数器

核心实现位于 WindowSurfacePlacer。它用两个字段记录挂起状态：

// WindowSurfacePlacer.javaprivateint mDeferDepth = 0;/** The number of layout requests when deferring. */privateint mDeferredRequests;

• mDeferDepth：挂起深度计数器。deferLayout 每次加 1，continueLayout 每次减 1，减到 0 才恢复布局。用计数器而不是布尔值，是因为调用可能嵌套。
• mDeferredRequests：挂起期间被请求布局的次数。挂起期间如果有代码调用了 performSurfacePlacement，不会真正执行，而是把这次请求记到这个字段里。

deferLayout 和 continueLayout 的实现：

// WindowSurfacePlacer.java:73voiddeferLayout(){    mDeferDepth++;}// WindowSurfacePlacer.java:86voidcontinueLayout(boolean hasChanges){    mDeferDepth--;if (mDeferDepth > 0) {return;    }if (hasChanges || mDeferredRequests > 0) {        performSurfacePlacement();        mDeferredRequests = 0;    }}// WindowSurfacePlacer.java:104booleanisLayoutDeferred(){return mDeferDepth > 0;}

continueLayout 只有在最外层（mDeferDepth 减到 0）时才真正执行布局，并且需要满足两个条件之一：

• hasChanges 为 true：调用方明确说明挂起范围内有变化；
• mDeferredRequests > 0：挂起期间有代码请求过布局。

两个条件都不满足时，这次 continue 直接什么都不做（即取消了这次布局）。

2. performSurfacePlacement 的拦截

performSurfacePlacement 本身也会检查挂起状态：

// WindowSurfacePlacer.java:118finalvoidperformSurfacePlacement(boolean force){if (mDeferDepth > 0 && !force) {        mDeferredRequests++;return;    }// ... 真正的遍历计算 ...}

挂起期间（mDeferDepth > 0）且不是强制布局时，不执行布局，只把 mDeferredRequests 加 1。force 为 true 的调用可以绕过挂起状态直接执行。

3. ActivityTaskManagerService 中的封装

deferWindowLayout / continueWindowLayout 是对上面两个方法的封装，额外引入了一个 mLayoutReasons 位掩码，用来记录挂起范围内具体发生了什么变化：

// ActivityTaskManagerService.java:691staticfinalint LAYOUT_REASON_CONFIG_CHANGED = 0x1;staticfinalint LAYOUT_REASON_VISIBILITY_CHANGED = 0x2;/** The reasons to perform surface placement. */@LayoutReasonprivateint mLayoutReasons;

// ActivityTaskManagerService.java:4398voiddeferWindowLayout(){if (!mWindowManager.mWindowPlacerLocked.isLayoutDeferred()) {// 只有第一次进入（最外层）才重置，因为只需要关心 defer 范围内的变化        mLayoutReasons = 0;    }    mWindowManager.mWindowPlacerLocked.deferLayout();}// ActivityTaskManagerService.java:4409voidcontinueWindowLayout(){    mWindowManager.mWindowPlacerLocked.continueLayout(mLayoutReasons != 0);}// ActivityTaskManagerService.java:4421voidaddWindowLayoutReasons(@LayoutReason int reasons){    mLayoutReasons |= reasons;}

mLayoutReasons 的作用是让 continue 时能判断挂起范围内是否真的有变化。deferWindowLayout 在最外层入口把 mLayoutReasons 清零，挂起范围内如果有代码改动了配置或可见性，就调用 addWindowLayoutReasons 打上对应标记。最后 continueWindowLayout 把 mLayoutReasons != 0 作为 hasChanges 传给 continueLayout。这样只有在 defer 范围内确实发生了需要布局的变化时，continue 才会触发一次布局，避免无意义的空布局。

addWindowLayoutReasons 的几个调用点：

// ActivityRecord.java:5007 可见性变化时mAtmService.addWindowLayoutReasons(        ActivityTaskManagerService.LAYOUT_REASON_VISIBILITY_CHANGED);// WindowOrganizerController.java:503 客户端没有自己处理配置时mService.addWindowLayoutReasons(LAYOUT_REASON_CONFIG_CHANGED);

三、典型使用场景

1. Activity 启动

ActivityStarter 在启动 Activity 的核心逻辑 startActivityInner 前后加 defer/continue，把启动过程中的窗口变化合并成一次布局：

// ActivityStarter.java:1659mService.deferWindowLayout();Trace.traceBegin(Trace.TRACE_TAG_WINDOW_MANAGER, "startActivityInner");result = startActivityInner(r, sourceRecord, voiceSession, voiceInteractor,        startFlags, doResume, options, inTask, inTaskFragment, restrictedBgActivity,        intentGrants);// ...mService.continueWindowLayout();

2. 屏幕旋转