解读

面试官抛出这道题，核心想验证两点：

1. 候选人是否真正理解“最小宽度”与“当前宽度”在 Android 资源匹配体系里的本质区别；
2. 能否结合国内多 ROM、折叠屏、强制分屏、Pad 外接键盘等真实场景，解释为什么 sw600dp 在工程上几乎成了“平板判断”的金标准。
   如果仅回答“sw600dp 表示屏幕最短边大于 600dp”，只能拿 60 分；必须点出“最小宽度是系统在整个生命周期里给应用保证的‘不变量’”，才能拿到 90+。

知识点

1. 最小宽度（smallestWidth，简称 sw<N>dp）
   系统在 Activity 启动时，根据当前 Configuration 的 screenWidthDp 与 screenHeightDp 取最小值，一旦确定，在该 Activity 生命周期内不再变化，即使后续旋转、折叠、分屏，资源也不会重新加载。
2. 当前宽度/高度（w<N>dp / h<N>dp）
   资源匹配时使用的是 Configuration 的当前 widthDp 或 heightDp，旋转或折叠后数值立即改变，会触发 Activity 重建并重新选资源。
3. 资源匹配优先级
   Android 在 Resources.getIdentifier 阶段会按“限定符多少”+“匹配范围”排序，sw600dp 属于“硬指标”，比 w/h 更靠前；同时由于数值不变，可以避免“横屏用平板布局、竖屏用手机布局”的抖动。
4. 国内特殊场景
   华为平行视界、小米自由窗口、ColorOS 可拖拽分屏，都会让 Activity 的当前宽度在 320dp-720dp 之间动态漂移；若用 w600dp，布局会在用户拖拽过程中反复切换，体验灾难。sw600dp 不受拖拽影响，只要系统最短边≥600dp，就始终命中平板资源。
5. 适配成本
   国内项目普遍把“平板”定义为 sw≥600dp，再配一套 layout-sw600dp、values-sw600dp，一次打包即可覆盖折叠屏展开、Pad、车载中控、TV（720p AOSP 盒子最短边 600dp 刚好踩线），无需在 Java/Kotlin 里写多套运行时判断。

答案

最小宽度限定符 sw600dp 是 Android 3.2 引入的“最短边≥600dp”资源限定符。系统在 Activity 创建时计算屏幕宽高中的最小值，只要该值≥600dp，就永久命中 sw600dp 目录下的资源；后续即使旋转、折叠、分屏，只要 Activity 不被重建，该限定符不会改变。
相比之下，w600dp/h600dp 使用的是“当前”宽度或高度，一旦用户旋转设备或拖拽分屏，当前宽高会立即变化，导致资源重新匹配、Activity 重建，出现“横屏是平板、竖屏变手机”的反复抖动。
因此，sw600dp 比 width/height 更可靠：它提供的是系统向应用承诺的“生命周期内不变”的最短边阈值，能一次性锁定平板形态，避免运行时因 Configuration 变化带来的布局震荡，在国内折叠屏、自由窗口、平行视界等碎片化场景下尤其稳定，已成为国内大厂平板适配的事实标准。

拓展思考

1. 折叠屏展开后最短边刚好 586dp（如某国产旗舰），如何兼容？
   可在 sw586dp 目录放“准平板”布局，再把关键断点组件（双窗格、抽屉宽度）用 ConstraintLayout 百分比或 composeWindowSizeClass 做二次平滑，避免“差 14dp”导致回退手机布局。
2. 如果业务需要“横屏强制双栏、竖屏强制单栏”，是否还用 sw？
   这种“方向强耦合”需求应放弃 sw，改用 w600dp-land/w600dp-port，并在代码层监听 onConfigurationChanged，手动 reload 片段；但要接受旋转闪屏代价，通常只在 TV 类固定横屏设备使用。
3. 国内渠道包要求最小宽度限定符动态化（云控切换断点），可否实现？
   sw<N>dp 是编译期写死的资源路径，无法云控；可退而在代码层用 WindowSizeClass 计算，把“是否双栏”做成 RemoteConfig 字段，下发到客户端后重启 Activity，实现“伪动态断点”。