Android应用从7.0引入分屏模式开始，窗口尺寸调整就成为一种常态运行条件。折叠屏、平板以及桌面模式进一步放大了这种变化：同一个应用可能在竖屏手机、横屏平板、自由窗口和展开后的折叠屏之间动态切换。Resize调整大小测试的核心不是简单拖动窗口边缘观察是否变形，而是验证系统配置变更链路、资源匹配逻辑以及UI适配策略能否在尺寸变化过程中保持一致。
Resize触发的配置变更与资源匹配机制
当窗口尺寸发生变化时，Android系统会重新计算屏幕方向、屏幕宽度、屏幕高度、最小宽度以及像素密度等配置项，并将这些变化封装成一个新的Configuration对象。默认情况下，系统会销毁当前Activity并重新创建它，以便让应用从资源目录中重新选择合适的布局、字符串、图片和尺寸资源。这个过程中，Activity会依次执行onPause、onStop、onDestroy，然后再次执行onCreate、onStart、onResume。因此，如果应用把关键界面状态只保存在内存变量中，resize后很容易出现输入框清空、列表滚动位置丢失或Fragment重复创建等问题。
有些开发者会在AndroidManifest中通过configChanges属性声明自行处理部分配置变化，从而避免Activity重建。例如屏幕尺寸和最小宽度变化可以配置为screenSize与smallestScreenSize。这种方式确实可以减少重建开销，但官方并不推荐把全部配置变更都拦截下来，因为系统自动重建配合资源分区，通常能更稳定地完成适配。更合理的做法是让Activity正常重建，同时利用onSaveInstanceState、ViewModel以及持久化存储来保存关键状态。
资源匹配是resize测试中容易忽略的环节。Android使用dp作为布局单位，而dp与实际像素之间的换算依赖屏幕密度。同样一个720dp宽的窗口，在160dpi的模拟器中可能是720像素，在320dpi的设备上则是1440像素。因此调整大小时不仅要关注窗口的长宽比例，还要结合density修改来验证资源目录是否正确命中。常见的layout-sw600dp、values-sw720dp、drawable-nodpi等限定符，都需要在不同密度和尺寸组合下测试。
<activity
android:name=".MainActivity"
android:resizeableActivity="true"
android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation"
android:exported="true">
</activity>
用ADB与模拟器手工执行Resize测试
Android Studio提供的可调整尺寸模拟器是手工测试的第一选择。创建模拟器时选择Resizable设备定义，运行后可以直接拖动窗口边缘改变尺寸，也可以切换横竖屏。这种操作与真实设备上的分屏拖拽行为类似，但模拟器环境更容易控制变量。测试时应当记录应用在极小尺寸如320dp宽、常规手机尺寸如360dp至400dp宽、平板尺寸如600dp至840dp宽下的表现，特别关注按钮是否被挤出屏幕、文本是否被截断、图片是否溢出边界。
ADB命令可以进一步精确控制分辨率和密度，适合在持续集成环境中快速切换设备形态。常用的wm size命令用于修改屏幕分辨率，wm density命令用于修改密度。执行adb shell wm size 720x1280后，系统会立即将窗口调整为对应尺寸，从而触发配置变更。测试完成后必须使用adb shell wm size reset和adb shell wm density reset恢复默认值，避免影响后续用例。以下命令展示了从修改到恢复的完整流程。
adb shell wm size 720x1280 adb shell wm density 320 # 观察应用布局和状态恢复情况 adb shell wm size reset adb shell wm density reset
对于分屏和自由窗口模式，可以使用am task resize命令直接调整任务窗口的边界。首先通过dumpsys activity activities获取目标任务的taskId，然后指定左上角和右下角坐标来改变窗口大小。这种方式无需手动拖动分割线，能够复现精确的窗口尺寸，特别适合测试多窗口并排显示时的布局压缩。需要注意的是，不同Android版本对自由窗口的最小宽高限制有所不同，测试数据应基于目标系统版本记录。
adb shell dumpsys activity activities | grep ResumedActivity adb shell am task resize 12345 0 0 800 1200 adb shell am task resize 12345 0 0 400 1200
编写自动化Resize测试与状态恢复断言
手工测试能够发现明显的布局问题，但无法高效覆盖每一次配置变更带来的状态恢复风险。自动化测试可以通过ActivityScenario显式触发Activity重建，模拟系统在resize时销毁并重新创建Activity的行为。ActivityScenario的recreate方法会经历完整的销毁与重建流程，测试用例可以在重建后断言关键控件仍然存在、文本内容没有丢失、RecyclerView的选中项保持正确。
状态恢复测试需要注意两个层次。第一层是onSaveInstanceState保存的临时状态，适合存储输入框文本、滚动位置等轻量数据；第二层是ViewModel保存的业务状态，适合存储页面数据、网络请求结果等。Resize导致的配置变更不会销毁ViewModel，因此正确使用ViewModel可以在Activity重建后直接从ViewModel恢复数据，而不需要重新加载。自动化测试应当验证这两层状态在重建后是否都能正确恢复。
@RunWith(AndroidJUnit4::class)
class ResizeStateTest {
@get:Rule
val scenarioRule = ActivityScenarioRule(MainActivity::class.java)
@Test
fun inputTextSurvivesActivityRecreate() {
onView(withId(R.id.input_name)).perform(typeText("Android"))
closeSoftKeyboard()
scenarioRule.scenario.recreate()
onView(withId(R.id.input_name))
.check(matches(withText("Android")))
onView(withId(R.id.main_container))
.check(matches(isDisplayed()))
}
}
如果项目使用Jetpack Compose，可以使用ComposeTestRule配合ActivityScenario或createAndroidComposeRule来执行重建测试。Compose的状态保存依赖于rememberSaveable和ViewModel，测试时需要确认重组和重建后语义树中的节点仍然存在。无论采用View体系还是Compose体系，核心目标都是确保resize不会让用户已经输入的内容、已经选择的选项或正在浏览的位置凭空消失。
折叠屏姿态与多窗口下的边界适配测试
折叠屏设备的展开与折叠可以看作一种极端的resize场景。设备从一个窄长屏幕瞬间切换为接近方形的宽屏，窗口尺寸变化幅度远超普通手机。此时系统不仅会调整分辨率，还可能触发屏幕方向变化和折叠姿态变化。针对折叠屏的resize测试需要覆盖闭合态、半开态和完全展开态，并检查应用在姿态切换过程中是否出现黑屏、视图重叠或点击区域偏移。AndroidManifest中声明的resizeableActivity属性需要保持为true，否则部分设备可能拒绝将应用放入多窗口环境。
多窗口模式下的边界适配同样重要。应用可能被用户拖到只剩很窄的一条区域，也可能从窄窗口突然恢复为全屏。测试时应当设置极小宽度和极小高度，确认关键操作按钮不会因空间不足而无法点击。对于不支持某些尺寸压缩的页面，可以在布局中使用ScrollView或ConstraintLayout的约束链，让内容在小尺寸下也能滚动查看。不要在代码中写死固定像素尺寸，否则一旦窗口变小就会出现控件溢出和交互失效。
完整的Resize调整大小测试需要结合模拟器、ADB命令、分屏模式以及自动化状态恢复验证。只有覆盖资源匹配、生命周期、状态保存和极端边界，才能确保应用在Android多样化的窗口环境中保持稳定。测试结果应记录为具体尺寸、密度和配置变更类型，方便后续回归时快速定位适配问题。
Android resize配置变更多窗口测试修改时间：2026-08-30 20:03:51