折叠屏手机从新奇品类逐渐变成主流旗舰的标配，但对应用开发者来说，这类设备带来的挑战远比想象中复杂。设备展开与折叠会造成屏幕尺寸和宽高比的剧烈变化，而多窗口模式、分屏、悬停态等使用场景，会让应用窗口进一步被压缩或拉伸。如果应用只按照传统的固定屏幕假设来写布局和逻辑，在这些场景下就容易出现界面错乱、数据丢失、功能异常等问题。本文将从屏幕状态感知、布局适配、生命周期处理三个方面，系统讲解折叠屏与多窗口模式的适配思路。
一、先搞清楚：折叠屏和多窗口到底改变了什么
传统开发中有一个隐含假设：应用启动后，屏幕尺寸基本不变，直到应用退出。这个假设在折叠屏和多窗口模式下彻底失效了。当用户把一台折叠屏手机从折叠态展开为大屏时，应用的窗口宽度可能从几百像素瞬间跳变到接近平板的级别；当用户开启分屏模式时，应用又被限制在半个屏幕的空间里运行。
这些变化本质上是配置变更。如果应用没有主动处理，系统默认会销毁并重建Activity，导致界面重新加载、用户输入的临时数据丢失。更麻烦的是，折叠屏的展开折叠不一定触发标准配置变更，部分厂商设备的铰链角度、悬停态（屏幕半折立在桌面上的状态）属于额外的传感器事件，需要专门的API来监听。
因此在动手适配前，建议先明确三类典型场景：一是折叠屏展开与折叠导致的尺寸跳变；二是分屏、自由窗口模式下的窗口压缩；三是悬停态等特殊形态下的双区域布局。三类场景的应对策略有重叠也有差异，下面逐一展开。
二、使用Jetpack WindowManager感知屏幕状态
官方推荐的方案是引入androidx.window库，也就是Jetpack WindowManager。相比旧的Display API，它能更好地处理折叠屏的折叠特性、铰链位置以及多窗口环境。首先在项目中添加依赖：
dependencies {
implementation "androidx.window:window:1.2.0"
implementation "androidx.window:window-java:1.2.0"
}
核心是获取WindowInfoTracker并监听窗口布局信息，代码示例如下：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
WindowInfoTracker.getOrCreate(this).windowLayoutInfo(this)
.addOnCompleteListener(task -> {
// 首次获取窗口布局信息
updateLayout(task.getResult());
});
// 持续监听后续变化
new WindowInfoTrackerCallbackAdapter(
WindowInfoTracker.getOrCreate(this))
.addWindowLayoutInfoListener(this, getMainExecutor(),
layoutInfo -> updateLayout(layoutInfo));
}
private void updateLayout(WindowLayoutInfo info) {
for (DisplayFeature feature : info.getDisplayFeatures()) {
if (feature instanceof FoldingFeature) {
FoldingFeature ff = (FoldingFeature) feature;
// 判断当前是否处于悬停态（半折叠立起）
if (ff.getState() == FoldingFeature.State.HALF_OPENED) {
// 进入双区域布局：上半屏显示内容，下半屏显示操作区
}
}
}
}
}
这段代码的关键在于FoldingFeature。它提供了折叠点的位置（bounds）、状态（展开还是半开）以及方向（横向还是纵向铰链）。拿到这些信息后，就可以在悬停态时把应用拆成上下两个逻辑区域，比如视频应用在上半屏播放、下半屏放控制按钮，这是折叠屏特有的体验优化点。
需要注意监听器的生命周期管理。上面的写法使用了WindowInfoTrackerCallbackAdapter，记得在onStop中移除监听器，避免内存泄漏。另外，窗口布局信息只在Activity可见时有效，后台期间发生的变化会在恢复可见时重新回调，不必担心遗漏。
三、基于窗口尺寸类做响应式布局
感知到变化只是第一步，更重要的是如何切换布局。目前业界普遍采用窗口尺寸类的思路，把当前窗口的宽度分为紧凑（compact，小于600dp）、中等（medium，600dp到840dp）、展开（expanded，大于840dp）三档，针对不同档位提供不同的布局结构。
推荐用资源限定符的方式实现，系统会自动根据当前窗口尺寸选择对应资源，不需要写任何Java代码：
res/
layout/
activity_main.xml # 默认布局（单栏列表）
layout-w600dp/
activity_main.xml # 中等宽度：列表加详情的双栏
layout-w840dp/
activity_main.xml # 展开宽度：三栏或侧边导航
这里的w600dp指的是当前窗口宽度而不是物理屏幕宽度，这一点在多窗口模式下尤其重要。用户把应用拖到分屏的一半屏幕时，即使设备本身是大屏平板，应用窗口的有效宽度也可能落入compact档位，布局会自动回退到单栏模式。这正是我们期望的行为，也解释了为什么不要再用layout-sw600dp这种基于最小屏幕宽度的限定符，它依据的是整个屏幕，无法响应窗口尺寸变化。
在代码逻辑层面，如果某些业务判断需要知道当前尺寸类，可以通过WindowSizeClass库获取，并结合android:configChanges="screenSize|smallestScreenSize|screenLayout"在Manifest中声明自行处理配置变更，避免Activity重建：
<activity
android:name=".MainActivity"
android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation"
android:resizeableActivity="true" />
resizeableActivity设置为true表示应用支持多窗口和自由缩放，从Android 7.0之后这是默认值，但显式声明更稳妥。声明了configChanges后，窗口尺寸变化会回调onConfigurationChanged而不是销毁重建，性能更好，但要自己负责更新布局相关状态：
@Override
public void onConfigurationChanged(@NonNull Configuration newConfig) {
super.onConfigurationChanged(newConfig);
int widthDp = newConfig.screenWidthDp;
if (widthDp >= 840) {
// 切换到展开态逻辑：显示侧边导航，加载更多内容
} else if (widthDp >= 600) {
// 中等宽度：双栏模式
} else {
// 紧凑模式：底部导航加单栏内容
}
}
四、多窗口下的生命周期与状态恢复
多窗口模式还有一个容易被忽视的坑：生命周期行为和全屏模式不同。在分屏状态下，两个应用都处于onResume之前的可见状态，但只有获得焦点的那个处于onResume，另一个处于onPause却依然可见。如果应用在onPause里暂停了视频播放或动画，就会出现在分屏中画面静止的尴尬情况。
正确的做法是引入onStop与onPause的区分逻辑：onPause时只暂停纯交互类的操作（比如弹幕输入），视频播放的暂停放到onStop中处理，这样在分屏失去焦点但仍然可见时，内容可以继续展示。配合Lifecycle库的Lifecycle.State判断，可以让代码更清晰。
另一个重点是把所有需要跨窗口变化保留的状态放入onSaveInstanceState或者ViewModel。即使用了configChanges规避重建，某些极端场景（比如窗口被系统回收）仍会导致Activity重建。ViewModel在配置变更时自动存活，是保存列表滚动位置、表单输入这类临时数据的首选方案：
public class MainViewModel extends ViewModel {
private final MutableLiveData<Integer> scrollPosition = new MutableLiveData<>(0);
private final MutableLiveData<String> draftInput = new MutableLiveData<>("");
// 用户在多窗口间切换或折叠展开后，这些数据不会丢失
public LiveData<Integer> getScrollPosition() { return scrollPosition; }
public void saveScroll(int pos) { scrollPosition.setValue(pos); }
public LiveData<String> getDraftInput() { return draftInput; }
public void saveDraft(String text) { draftInput.setValue(text); }
}
此外还要检查多窗口下的一些硬性限制：应用无法在多窗口模式中隐藏状态栏做全屏沉浸，也无法调用部分系统弹窗覆盖对方窗口；相机取景器在分屏中可能出现比例异常，需要按窗口实际比例重新计算预览尺寸。建议在适配完成后，用开发者选项中的强制可调整大小来模拟各种窗口尺寸逐一验证。
五、适配验证清单与总结
最后整理一份可执行的验证清单。第一，在折叠屏设备或模拟器上反复展开折叠，确认布局切换流畅、无闪烁、无状态丢失。第二，进入分屏模式并拖动分割线，验证各种中间宽度下布局都能正常显示。第三，检查横竖屏切换与宽高比极端变化（比如长条形的自由窗口）下的表现。第四，验证悬停态下的双区域布局，确保铰链位置不被内容遮挡。第五，测试分屏中失去焦点时的播放和动画行为。
整体来看，折叠屏与多窗口适配的核心思想只有一句话：把应用看作一个可变尺寸的窗口，而不是一整块固定屏幕。用Jetpack WindowManager感知折叠特性，用窗口尺寸类驱动布局切换，用ViewModel保障状态延续，三者结合就能覆盖绝大多数场景。前期投入的适配成本，换来的是在新兴设备形态上不打折扣的用户体验，这笔账是划算的。